Спойлер: никак. В статье рассказываю, почему адекватный работодатель не ищет бесплатных тестировщиков, для чего нужны тестовые задания и когда можно от них отказаться.   Привет, я Таня Рашидова, QA-инженер в KODE и организатор небольшого комьюнити инженеров по тестированию. Мы с ребятами встречаемся за чашечкой кофе и обсуждаем рабочие проблемы в телеграм-чате. Однажды от коллеги прилетел такой вопрос: Первое, что пришло в голову: если мне как нанимателю надо проверить какой-то флоу, я бы точно хотела, чтобы этим занимался специалист, чьи компетенции мне известны и чьим решениям я доверяю. Во-вторых, есть NDA, вопросы безопасности — зачем мне раскрывать все данные приложения, ради одного выполненного задания.  В ответ на свой скептицизм я получила кучу весомых аргументов и историй из жизни знакомых знакомых, что недобросовестные работодатели именно так и поступают. Расскажу, почему осталась при своем мнении, почему мы при найме практически отказались от тестовых и что мы используем вместо них.  Своё первое тестовое я получила, когда училась в университете и хотела попасть на стажировку. Сейчас в компании, где я работаю, мы тоже отправляем будущим стажёрам тестовые с задачами, приближенными к реальной работе. Последнее было таким: установить наше приложение из стора, погонять его без определенных требований, выписать все замечания и странности, оформив как баг. Вместе с тестовыми заданиями мы тоже получили немного хейта: вы нас используете! Но нет, приложение давно было снято с нашей поддержки.  Для чего это было нужно? Нам прислали около 110 ответов на тестовые. Все ребята безусловно постарались и были довольно хороши. Но нам необходимо было отобрать всего 10 человек, которые соответствовали нашим требованиям.  У меня есть три основных критерия.  Стиль оформления бага — в чём оформлен и как. Хорошо, если соискатель оформил баг в Excel, ещё лучше — в Jira или YouTrack, так я сразу вижу, что у него есть навык работы с этими инструментами. Блокнот — плохой выбор, потому что этот инструмент не подходит для заведения кейсов или дефектов, теряется наглядность и структурированность.  Структура и содержание бага. Одна из главных черт QA — умение структурировать мысли. Когда вместо чётко заведённых дефектов мы получаем поток сознания, то понимаем, что это потребует дополнительного времени на обучение азам, а мы хотели давать реальную практику. Чтобы было понятнее, покажу реальные примеры.  В этом задании — слишком яркое форматирование и очень много шагов.  В следующем примере с форматированием всё хорошо, но есть другие недостатки:  Нет ожидаемого результата. Добавлена заметка. Вместо заметок, лучше добавлять информацию в предусловие или описание. К тому же в контексте этого бага то, что описано в заметке, вообще не играет роли. Первый шаг описан в некорректной форме. Лучше: написать «Открыть вкладку Магазин», а остальное вынести в предусловие. Некорректное название. Обычно его пишут по правилу «Что? Где? Когда?». Баг должен иметь основные атрибуты: заголовок, окружение, шаги, ожидаемый результат, фактический результат, аттачи. Всё описанное не должно противоречить логике.   Проверка на внимательность. В нашем тестовом задании нужно было описать 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% от всего функционала и реальной работы тестировщика. При выполнении тестового лучше всего не зацикливаться на том, что ваш труд используют бесплатно, а сконцентрироваться на задании, обратить внимание на свои ощущения: интересно ли вам это делать, легко или нет, что вызывает затруднения, как быстро у вас получилось его выполнить.  Разработчик цифровых продуктов