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