Привет! Меня зовут Артем. Я тестировщик и занимаюсь обучением будущих специалистов в этом направлении на rusau.net. Обучение – это первый шаг, гораздо важнее – поиск первой работы.
Достаточно часто соискателям на позицию QA Engineer компании высылают тестовые задания (ТЗ). Их решение дает первичное понимание об уровне специалиста и является дополнительным фильтром для нанимающего менеджера.
Я собрал всю информацию про тестовые задания и рекомендации в одном гайде. В конце статьи вы найдете ссылку на репозиторий с большой подборкой тестовых заданий.
Что может включать в себя ТЗ?
Список не является исчерпывающем и может быть дополнен, согласно вашему домену:
-
Задачи на тестирование приложения и создание тестовой документации для него
-
Задачи на проектирование тестов с учетом техник тест-дизайна
-
Задачи на анализ требований и поиск нарушений их качественных характеристик
-
Задачи на тестирование API по документации
-
Поиск дефектов в приложении или на статическом изображении
-
Задачи на написание SQL-запросов (SELECT и JOIN)
-
Логические задачи
-
Ситуационные кейсы
-
Теоретические тесты
-
Задачи на работу с прикладными инструментами
Советы по оформлению и работе с ТЗ
-
Если в ТЗ есть шаблон, по которому необходимо выполнить решение, то используйте его.
-
Документацию проще создавать в специализированном ПО, например, Jira, TestRail и их аналоги. Так вы не забудете об обязательных атрибутах, но в то же время всегда проверяйте, чтобы они были настроены до создания отчетов о дефекте, тест-кейсов. Не всегда все поля есть в проекте по умолчанию.
-
После создания документации обязательно делайте экспорт ваших артефактов, т.к. прямая ссылка на ваш проект приведет к сообщению «нет доступа», если только у самой системы нет возможности сделать его публичным.
-
Другой вариант: использование Google Docs. Необходимо оформить таблицу с отдельными вкладками для каждого артефакта, где в названии столбцов указать обязательные атрибуты.
-
Позаботьтесь о корректном названии файлов, отдельных листов, а главное о доступе к вашему документу. Он должен быть публичным.
-
Все доступы можно легко проверить через режим инкогнито в браузере. Так ваше тестовое задание будет видеть любой человек, который захочет его посмотреть.
-
Помните о форматировании, выделении разными видами шрифтов, автоматическом переносе строк, использовании спокойной цветовой гаммы, орфографии и пунктуации.
-
Обращайте внимание на требования к объему вашего решения. Если вас просят написать только 3 самых приоритетных тест-кейса, то пишите именно их.
-
Своим студентам я рекомендую дополнительно использовать github, как для создания портфолио, так и для публикации решений тестовых заданий. Не забывайте оформлять файл README.md для описания вашего проекта.
-
Возможны креативные варианты выполнения тестовых задания в виде интеллектуальных карт (XMind) или отдельных досок (Miro).
-
Всегда помните о доступе: при создании документации, при создании коллекций в Postman, при работе с github (публичный и приватный профиль), все, где есть ссылка, проверяем согласно пункту 5.
-
Не бойтесь задавать уточняющие вопросы. В худшем случае их просто проигнорируют, в лучшем – от вас их ожидали.
-
Не берите в работу тестовые задания, которые требуют инвестиции большого количества времени и/или предлагают полноценное тестирование продукта в релизе. В идеальном мире, тестовые задания должны проводиться на отдельных тестовых средах.
Подборки тестовых заданий по различным направлениям
Желаю удачи в выполнении тестовых заданий и поиске работы!
Напоминаю, что секция комментариев открыта для обсуждения.
ссылка на оригинал статьи https://habr.com/ru/articles/790438/
Добавить комментарий