Спойлер: никак. В статье рассказываю, почему адекватный работодатель не ищет бесплатных тестировщиков, для чего нужны тестовые задания и когда можно от них отказаться.  

Привет, я Таня Рашидова, QA-инженер в KODE и организатор небольшого комьюнити инженеров по тестированию. Мы с ребятами встречаемся за чашечкой кофе и обсуждаем рабочие проблемы в телеграм-чате. Однажды от коллеги прилетел такой вопрос:

Первое, что пришло в голову: если мне как нанимателю надо проверить какой-то флоу, я бы точно хотела, чтобы этим занимался специалист, чьи компетенции мне известны и чьим решениям я доверяю. Во-вторых, есть NDA, вопросы безопасности — зачем мне раскрывать все данные приложения, ради одного выполненного задания. 

В ответ на свой скептицизм я получила кучу весомых аргументов и историй из жизни знакомых знакомых, что недобросовестные работодатели именно так и поступают. Расскажу, почему осталась при своем мнении, почему мы при найме практически отказались от тестовых и что мы используем вместо них. 

Зачем делать тестовое, если хочешь попасть на стажировку 

Своё первое тестовое я получила, когда училась в университете и хотела попасть на стажировку. Сейчас в компании, где я работаю, мы тоже отправляем будущим стажёрам тестовые с задачами, приближенными к реальной работе. Последнее было таким: установить наше приложение из стора, погонять его без определенных требований, выписать все замечания и странности, оформив как баг.

Вместе с тестовыми заданиями мы тоже получили немного хейта: вы нас используете! Но нет, приложение давно было снято с нашей поддержки. 

Для чего это было нужно? Нам прислали около 110 ответов на тестовые. Все ребята безусловно постарались и были довольно хороши. Но нам необходимо было отобрать всего 10 человек, которые соответствовали нашим требованиям. 

На что я обращаю внимание, когда проверяю тестовые задания будущих QA

У меня есть три основных критерия. 

Стиль оформления бага — в чём оформлен и как. Хорошо, если соискатель оформил баг в Excel, ещё лучше — в Jira или YouTrack, так я сразу вижу, что у него есть навык работы с этими инструментами. Блокнот — плохой выбор, потому что этот инструмент не подходит для заведения кейсов или дефектов, теряется наглядность и структурированность. 

Структура и содержание бага. Одна из главных черт QA — умение структурировать мысли. Когда вместо чётко заведённых дефектов мы получаем поток сознания, то понимаем, что это потребует дополнительного времени на обучение азам, а мы хотели давать реальную практику. Чтобы было понятнее, покажу реальные примеры. 

В этом задании — слишком яркое форматирование и очень много шагов.

В следующем примере с форматированием всё хорошо, но есть другие недостатки: 

1. Нет ожидаемого результата.

2. Добавлена заметка. Вместо заметок, лучше добавлять информацию в предусловие или описание. К тому же в контексте этого бага то, что описано в заметке, вообще не играет роли.

3. Первый шаг описан в некорректной форме. Лучше: написать «Открыть вкладку Магазин», а остальное вынести в предусловие.

4. Некорректное название. Обычно его пишут по правилу «Что? Где? Когда?».

Баг должен иметь основные атрибуты: заголовок, окружение, шаги, ожидаемый результат, фактический результат, аттачи. Всё описанное не должно противоречить логике.  

Проверка на внимательность. В нашем тестовом задании нужно было описать 5–7 кейсов. Большинство выполнило это условие, но некоторые впадали в крайность — писали по 15 кейсов. В будущей работе это может стать потенциальной проблемой: нужно стараться тратить на задачу столько времени, сколько на неё отведено, и укладываться в сроки. К тому же проверяющие QA-инженеры заняты на основных проектах, их время на проверку тестовых тоже ограничено. 

С требованиями к формату отправки задания тоже справились не все, хотя это важный показатель: если на этом этапе стажёр не может выполнить четкие инструкции, в работе тоже может возникнуть недопонимание. 

Тестовых заданий было больше сотни, но около 20% не соблюдали описанные требования и не выполняли поставленные задачи. У остальных 80% мы тщательно проверяли каждый баг, читали каждый описанный кейс. Нужно было убедиться, что заявленный баг является багом, а кейсы не противоречат требованиям. 

Чтобы оценка была максимально объективной, мы оценивали задания по определённым критериям. За каждый выполненный критерий начисляли баллы. Максимум 100 баллов за все задания. В итоге набралось 29 претендентов, которых мы пригласили на собеседования, чтобы оценить софт-скиллы будущих сотрудников.

Можно ли не делать тестовое задание

Можно. Если у соискателя уже есть опыт работы. 

Сейчас на собеседованиях мы отказались от тестовых заданий для мидлов и сеньоров. Релевантность навыков сильных кандидатов мы проверяем по-другому: даём реальный кейс из практики. Если с соискателем подписан NDA (человек работает в нашей компании, но на другом проекте), то просим установить приложение на девайс и решать кейсы. Если человек с рынка и NDA не подписан, используем аналогичное приложение из стора.

Пример кейса: мы разрабатываем приложение N, которое содержит в себе функционал выбора товара, корзины, добавление в избранное, личный кабинет. В этом случае мы попросим кандидата открыть приложение любого маркетплейса и будем задавать вопросы по текущим кейсам, основному функционалу и возможным дополнительным решениям.

С тестированием API всё намного проще: есть сервисы, которые имитируют взаимодействие протоколов с интерфейсом, Postman или Swagger. Мы просим кандидата расшарить экран и на месте решаем и анализируем предоставленное API.

Основные компетенции, которые мы ожидаем от кандидата уровня мидл, такие: 

• Знает теорию тестирования и применяет на практике.

• Разбирается в клиент-серверной архитектуре, есть опыт тестирования REST API.

• Есть опыт тестирования мобильных приложений и веб-сервисов. 

• Работал с Charles, Postman, Swagger, AndroidStudio/xCode, Firebase.

Если таких навыков нет или они развиты слабо, мы предлагаем соискателям тестовое задание. 

Конечно, грейды в QA не всегда рабочая штука. Можно несколько лет тестировать мобилки, всё о них знать, стать настоящим профи, а завтра попросят протестировать IoT-устройства — и ты уже джун. 

Почему адекватный работодатель не будет использовать ваше тестовое

Теперь я объясню, почему так удивилась, когда увидела в чате, что соискатели часто остерегаются тестовых заданий, и почему тестовые — не бесплатная работа. 

1. Компания уже знает обо всех багах. Если в качестве тестового задания вам предложили потестировать реальное приложение, это не значит, что вас просят работать бесплатно. Это значит, что в будущем придётся работать с этим или похожим приложением. Нанимателю важно посмотреть на ваши методы и подходы к тестированию. Вероятнее всего, это приложение уже находится в сторе, а значит все баги уже поймали пользователи и команда QA.

2. Некогда ждать. Представьте, у вас горит фича, её нужно срочно выпустить в релиз. Неужели вы будете ждать кандидата, который протестирует её за вас? Конечно, нет. Нет никакой гарантии, что этот кандидат вообще будет и выполнит задание на 100%. При выполнении тестового мы смотрим на действия, а не на результат.

3. Это небезопасно. Никто не просит работать бесплатно в тестовом задании, как минимум потому что соискатель не может знать всех аспектов. Чаще всего, если задания основываются на реальном сервисе, затрагивается не больше 5% от всего функционала и реальной работы тестировщика.

При выполнении тестового лучше всего не зацикливаться на том, что ваш труд используют бесплатно, а сконцентрироваться на задании, обратить внимание на свои ощущения: интересно ли вам это делать, легко или нет, что вызывает затруднения, как быстро у вас получилось его выполнить.