Разбор типового take-home task для Manual QA
В рамках собеседования на позицию Manual QA часто предлагают выполнить небольшое тестовое задание — take-home task. Обычно от кандидата не ждут сотни тест кейсов или попытки найти все возможные баги. Работодатель хочет увидеть как вы анализируете требования, определяете риски, выбираете сценарии тестирования и оформляете результат своей работы.
В этой статье разберём пример типового задания для Manual QA: от первого прочтения условия до итогового решения.
Мы не делаем полное готовое решение со всеми возможными проверками и заполненным чек-листом. Вместо этого разберём подход к решению: как структурировать задачу, на что обратить внимание, как выбрать тестовую документацию, сделать декомпозицию и расставить приоритеты.
В этой статье разберём пример типового задания для Manual QA: от первого прочтения условия до итогового решения.
Мы не делаем полное готовое решение со всеми возможными проверками и заполненным чек-листом. Вместо этого разберём подход к решению: как структурировать задачу, на что обратить внимание, как выбрать тестовую документацию, сделать декомпозицию и расставить приоритеты.
Дисклеймер: задание, приведённое в этой статье, полностью вымышленное и создано исключительно в учебных целях. Оно не является реальным тестовым заданием какой-либо компании и не воспроизводит внутренние материалы, процессы или требования конкретного работодателя.
1 Пример задания
Рассмотрим типовое тестовое задание для ручного тестировщика. Обычно его присылают кандидату после одного из этапов собеседования, чаще всего по электронной почте. В сообщении описывают саму задачу, указывают примерное время на выполнение и добавляют основные требования к результату: что именно нужно проверить, в каком виде оформить ответ и на что стоит обратить внимание.
При этом требования не всегда бывают подробными. Часть деталей может быть намеренно не описана — в том числе для того, чтобы посмотреть, какие вопросы возникнут у кандидата и как он будет работать с неполной информацией.
Ниже — один из примеров такого задания.
При этом требования не всегда бывают подробными. Часть деталей может быть намеренно не описана — в том числе для того, чтобы посмотреть, какие вопросы возникнут у кандидата и как он будет работать с неполной информацией.
Ниже — один из примеров такого задания.
Вы тестируете мобильное приложение для заказа такси. Один из основных пользовательских сценариев — выбор маршрута поездки. Перед заказом пользователь должен указать:
- точку А — место, откуда его необходимо забрать;
- точку Б — место назначения.
Обе точки можно выбрать через поиск адреса. Во время ввода приложение показывает подходящие варианты адресов, из которых пользователь может выбрать нужный. После выбора точки А и точки Б приложение отображает маршрут и позволяет перейти к следующему этапу оформления поездки.
Приложение используется в разных городах и странах, поэтому формат адресов и результаты поиска могут отличаться в зависимости от региона.
1.1 User story (Пользовательская история)
Как пассажир, я хочу выбрать адрес отправления и адрес назначения, чтобы построить маршрут своей поездки. В рамках задания необходимо протестировать только поиск и выбор точки А и точки Б. Проверять сам заказ такси не требуется.
Часть требований намеренно оставлена открытой: задача кандидата — не только придумать проверки, но и показать, как он работает с неопределённостью, рисками и ограниченным временем.
1.2 Что необходимо подготовить в рамках задания
A. Описание подхода к тестированию
Кратко опишите:
- с чего вы начали бы тестирование;
- что решили бы проверить в первую очередь и почему;
- какие основные группы проверок выделили бы;
- какие проверки считаете наиболее важными;
- какие вопросы по требованиям задали бы.
Не требуется описывать абсолютно все возможные проверки. Нам важнее понять логику ваших решений.
B. Основные сценарии проверки
Подготовьте небольшой список наиболее важных сценариев.
C. Наблюдения и найденные ошибки
Также опишите по возможности:
- найденные ошибки;
- неожиданное поведение приложения;
- спорные моменты;
- возможные проблемы с удобством использования;
- вопросы, которые появились в процессе тестирования.
Если вы нашли ошибку, оформите её так, как сделали бы это в реальном проекте. При необходимости можно приложить снимки экрана или запись экрана.
D. Дополнительное исследование
Если вы использовали дополнительные инструменты, кратко укажите:
- какой инструмент использовали;
- что именно проверяли;
- что удалось выяснить.
2 Как подойти к решению такого задания
Первое, что хочется сделать после прочтения задания, — создать таблицу и начать записывать проверки: правильный адрес, неправильный адрес, пустое поле и так далее.
Важно отметить, что хорошее тестовое задание показывает не количество придуманных проверок, а то, насколько последовательно вы умеете разобраться в новой функциональности и понять требования задачи.
У нас есть достаточно простой пользовательский сценарий:
пользователь выбирает точку А → выбирает точку Б → приложение строит маршрут.
Это основной сценарий, который должен работать всегда. Именно его логично проверить одним из первых.
Крайне важно помнить о том, что не нужно придумывать требования. В реальной работе уточняющие вопросы нужно спросить у команды. В тестовом задании можно поступить так же: отдельно записать вопросы и предположения, на которых строится дальнейшее тестирование.
2.1 Какую тестовую документацию выбрать ?
Перед тем как переходить к конкретным проверкам, стоит определить, в каком виде их удобнее оформить: как тест-кейсы или как чек-лист.
Для такого тестового задания оптимальным вариантом будет чек-лист. Он позволяет быстро зафиксировать основные сценарии, показать покрытие функциональности и при этом не тратить значительную часть ограниченного времени на подробное описание каждого шага.
Чек-лист — это список проверок, где для каждой проверки обычно указывается её статус: например, пройдено, не пройдено или не проверялось.
Чек-лист — это список проверок, где для каждой проверки обычно указывается её статус: например, пройдено, не пройдено или не проверялось.
Чтобы было удобнее работать, проверки можно объединять в отдельные группы (test suite).
2.2 Определяем границы тестирования
Следующий шаг — понять, что относится непосредственно к нашей задаче.
Нас интересует именно выбор маршрута:
поиск адреса → выбор точки → отображение выбранного адреса → построение маршрута.
В условии задания нас явно просят протестировать конкретную функциональность, а не проводить полный регресс приложения. Поэтому важно не выходить за рамки задачи и не тратить ограниченное время на проверку оплаты, поиска водителя, промокодов или других частей приложения.
Хороший тестировщик должен уметь не только находить, что ещё можно проверить, но и понимать, что сейчас проверять не нужно.
2.3 Разбиваем большую задачу на небольшие части
Теперь функциональность уже можно условно разделить на несколько областей:
- поиск точки А по адресу;
- поиск точки Б по адресу;
- изменение выбранного адреса;
- смена позиций точки А и точки Б;
- построение маршрута;
- ошибки и нестандартные ситуации.
Каждая такая область в дальнейшем может стать отдельным тест-сьютом — группой связанных проверок. Это делает структуру документа понятнее и помогает увидеть, какие части функциональности уже покрыты тестами, а какие ещё нет.
Например, для тест-сьюта «Поиск адреса» можно добавить следующие проверки:
Например, для тест-сьюта «Поиск адреса» можно добавить следующие проверки:
- поиск по полному адресу;
- поиск по части адреса;
- неправильный или несуществующий адрес;
- выбор адреса по карте
Это удобно: проверки не смешиваются в одном длинном списке, а распределяются по логическим группам.
2.4 Сначала проверяем самое главное
Частая ошибка при выполнении тестового задания — сразу начинать с негативных и необычных сценариев: вводить несуществующие адреса, отключать интернет, использовать специальные символы или пытаться «сломать» приложение.
Но сначала важно убедиться, что работает основной сценарий:
Но сначала важно убедиться, что работает основной сценарий:
- Найти и выбрать точку А.
- Найти и выбрать точку Б.
- Убедиться, что выбраны правильные адреса.
- Проверить, что маршрут построился.
- Изменить одну из точек и убедиться, что маршрут обновился.
После этого можно переходить к негативным сценариям и граничным ситуациям.
Например:
- адрес не найден;
- соединение с интернетом пропало;
- редактирование точки
Если основной сценарий не работает, это уже критичная проблема для функциональности. Только после этой проверки имеет смысл переходить к негативным сценариям и нестандартному поведению пользователя.
Такой порядок помогает правильно распределить ограниченное время и сначала проверить то, ради чего эта функциональность вообще существует.
2.5 Ошибки и нестандартные ситуации
Отдельную группу составляют ситуации, в которых обычный сценарий прерывается или пользователь действует нестандартно:
- отсутствует интернет-соединение;
- соединение пропадает во время поиска;
- приложение сворачивается и снова открывается.
Важно проверить не только стабильность приложения, но и то, получает ли пользователь понятную информацию о произошедшей проблеме.
2.6 Региональные особенности
Если приложение работает в разных странах и городах, необходимо учитывать особенности адресов и языков.
Например:
- адреса на разных языках;
- разные форматы номеров домов;
- адреса без номера дома;
- поиск районов, станций, аэропортов и других объектов вместо обычного почтового адреса.
Проверить все подобные варианты в рамках ограниченного времени может быть невозможно, однако выделение этой области позволяет показать понимание особенностей реального продукта.
3 Ограничения тестирования
Одним из ограничений при выполнении такого задания может быть отсутствие возможности полноценно проверить работу приложения с разной геолокацией.
Например, если тестирование проводится на обычном мобильном устройстве без специальных инструментов, может быть невозможно имитировать нахождение пользователя в другом городе или стране.
Из-за этого часть сценариев останется непроверенной, например:
- поиск адресов в других регионах;
- поведение приложения при нахождении пользователя в другой стране;
Такие проверки стоит отдельно отметить как область, которую необходимо было бы проверить при наличии возможности изменять или имитировать геолокацию.
4 Дополнительное исследование
Для более глубокого тестирования можно использовать дополнительные инструменты. Например, эмулятор Android или симулятор iOS позволяют задать тестовую геолокацию пользователя и проверить, как поиск адресов работает в разных городах и странах.
С их помощью можно проверить:
- меняются ли результаты поиска в зависимости от текущего местоположения;
- как приложение работает при изменении геолокации;
Это особенно полезно для приложений заказа такси, где результаты поиска и доступность адресов напрямую зависят от местоположения пользователя.
5 Тестирование доступности
Ещё одна область, которую стоит учитывать, — это доступность приложения.
Тестирование доступности — это проверка того, насколько удобно приложением могут пользоваться люди с разными ограничениями: например, слабым зрением.
Для такого тестирования достаточно нескольких базовых проверок: например, убедиться, что поля точки А и точки Б корректно озвучиваются экранным диктором, найденные адреса можно выбрать без проблем, а интерфейс остаётся понятным при увеличенном размере текста.
Для мобильных приложений можно использовать встроенные инструменты, такие как VoiceOver на iOS и TalkBack на Android.
Полный аудит доступности в рамках небольшого тестового задания совершенно не требуется, но само внимание к этой области хорошо дополняет общий подход к тестированию.
6 Частые ошибки и антипаттерны
Стоит отдельно остановиться на том, что чаще всего портит впечатление от тестового задания — даже когда оно формально выполнено.
Самая частая история — кандидат старается написать как можно больше кейсов. Количество кейсов не равно качеству тестирования. С этим связана ещё одна ошибка, о которой уже шла речь выше: начинать с необычных и граничных ситуаций, не убедившись сначала, что вообще работает базовый флоу.
К этому же классу проблем относится выход за рамки задания — например, тестирование оплаты или поиска водителя, когда в user story прямо написано, что нужна только точка А и точка Б. Это не страшная ошибка, но она показывает, что условие прочитали невнимательно.
Часто встречается и обратная ситуация — когда кандидат вместо вопроса просто додумывает требование сам. Например, решает, что «наверное, поиск должен работать без интернета через кэш», и тестирует это придуманное поведение вместо того, чтобы отметить как открытый вопрос. В реальной работе это тоже плохая привычка, поэтому имеет смысл показать её отсутствие уже на этом этапе.
Отдельная группа проблем в том, как оформлен результат. Баг вида «поиск адреса не работает» без шагов воспроизведения и без описания того, что ожидалось и что произошло на самом деле, по сути бесполезен — его нельзя ни воспроизвести, ни оценить.
Отдельно стоит сказать про ограничения. Если что-то не удалось проверить — например, поведение приложения в другом регионе без возможности сменить геолокацию — об этом стоит написать прямо. Кандидаты часто просто не упоминают такие пробелы, и со стороны это выглядит как то, что до этой области руки просто не дошли.
Если задание рассчитано на 2 дня, а решение присылают через неделю, это тоже красный флаг, даже если само содержание хорошее. Умение оценить объём работы и вовремя остановиться — часть той же самой компетенции, которую тестовое задание и должно показать.
Самая частая история — кандидат старается написать как можно больше кейсов. Количество кейсов не равно качеству тестирования. С этим связана ещё одна ошибка, о которой уже шла речь выше: начинать с необычных и граничных ситуаций, не убедившись сначала, что вообще работает базовый флоу.
К этому же классу проблем относится выход за рамки задания — например, тестирование оплаты или поиска водителя, когда в user story прямо написано, что нужна только точка А и точка Б. Это не страшная ошибка, но она показывает, что условие прочитали невнимательно.
Часто встречается и обратная ситуация — когда кандидат вместо вопроса просто додумывает требование сам. Например, решает, что «наверное, поиск должен работать без интернета через кэш», и тестирует это придуманное поведение вместо того, чтобы отметить как открытый вопрос. В реальной работе это тоже плохая привычка, поэтому имеет смысл показать её отсутствие уже на этом этапе.
Отдельная группа проблем в том, как оформлен результат. Баг вида «поиск адреса не работает» без шагов воспроизведения и без описания того, что ожидалось и что произошло на самом деле, по сути бесполезен — его нельзя ни воспроизвести, ни оценить.
Отдельно стоит сказать про ограничения. Если что-то не удалось проверить — например, поведение приложения в другом регионе без возможности сменить геолокацию — об этом стоит написать прямо. Кандидаты часто просто не упоминают такие пробелы, и со стороны это выглядит как то, что до этой области руки просто не дошли.
Если задание рассчитано на 2 дня, а решение присылают через неделю, это тоже красный флаг, даже если само содержание хорошее. Умение оценить объём работы и вовремя остановиться — часть той же самой компетенции, которую тестовое задание и должно показать.
7 Заключение
В этой статье мы разобрали типовое тестовое задание для Manual QA и посмотрели, как к нему можно подойти на практике: с чего начать, как определить границы тестирования, какую документацию выбрать, как разбить функциональность на отдельные группы проверок и расставить приоритеты.
Также рассмотрели, как добавлять проверки доступности и использовать дополнительные инструменты для более глубокого исследования функциональности.
Главная идея здесь в том, что хорошо выполненное тестовое задание — это не максимально длинный список проверок. Нанимающий менеджер хочет увидеть понятный и последовательный подход к решению задачи: что проверять, почему именно это и в каком порядке.
Также рассмотрели, как добавлять проверки доступности и использовать дополнительные инструменты для более глубокого исследования функциональности.
Главная идея здесь в том, что хорошо выполненное тестовое задание — это не максимально длинный список проверок. Нанимающий менеджер хочет увидеть понятный и последовательный подход к решению задачи: что проверять, почему именно это и в каком порядке.
В этой статье мы разбирали тестовое задание на примере мобильного приложения, но сам подход универсален. Те же принципы можно применять и при тестировании веб-приложений, API или backend-функциональности: определить границы задачи, сделать декомпозицию, выделить группы проверок, расставить приоритеты и выбрать подходящую тестовую документацию.
В рамках нашего курса такие типовые задачи разбираются на практических проектах: студенты составляют чек-листы, делают декомпозицию функциональности, оформляют тест-сьюты, учатся расставлять приоритеты, находить и описывать ошибки, а также работать с инструментами, которые используются в реальном тестировании.
16.08.2026