Привет, хабровчанки и хабровчане! 

Меня зовут Настя. На данный момент работаю младшим ручным тестировщиком в небольшой компании. 

Свой путь в QA я начала около полугода назад. Перед тем, как устроиться на нынешнюю работу, взялась за самостоятельное тестирование одного проекта – об этом опыте и хочу рассказать.

Мои советы будут полезны, если ты тоже джун и:

 • попал на первую работу, где сразу надо брать и делать, а у тебя все ещё лапки;

 • задумался о фрилансе, но не понимаешь, как взяться за тестирование в одиночку;

 • оказался единственным тестировщиком в команде, слышавшей про тестировщиков только из рекламных баннеров. 

Компания, с которой я сотрудничала, как раз прямиком из третьего пункта. У них сильная разработка, но нет своего отдела тестирования. Из-за загруженности программисты не всегда успевают с проверками – и тут настал мой час. 

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

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

Мои советы – от джуна джунам:

Общайся

Первая заповедь тестирования – выяснить требования к продукту. Высока вероятность, что вся документация лежит только у разработчиков в голове. Придется её оттуда доставать.

Это был как раз мой случай – кроме макета сайта в PS, требования отсутствовали. 

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

Расставляй приоритеты

Получив информацию у ПМ и разработчиков, можно продумать план тестирования. Начни с выстраивания приоритетов – ведь нужно уложиться в дедлайн и не упустить ничего важного. 

Например, на моем проекте в приоритете были верстка, страницы контактов и кейс-стади. А вот гигантский блог можно было не проверять досконально. Также проверкой бэкенда занимался лично старший разработчик. Выяснив это, я сберегла силы и время.

Рецепт: спрашивать и ещё раз спрашивать. Ты джун – к тому же пришедший со стороны, если речь идет об аутсорсе или фрилансе. Задавать вопросы нормально и, вероятнее всего, команда будет к этому готова.

Обговори условия

Для эффективного тестирования тебе понадобится код-фриз. Это не всегда приходит в голову команде, для которой сотрудничество с QA в новинку. 

Расскажи, что тебе нужна тестовая среда, совпадающая с продом. И постарайся убедить разработчика, что на период тестирования код желательно не менять – иначе может пропасть смысл твоей работы.

На моем проекте во время тестирования меняли фон для большого слайдера на главной странице. Это повлияло на верстку, и пришлось заново проходить несколько проверок.

Рецепт: объясни механизм тестирования команде. Если на проекте ещё ни разу не было тестировщика, другие сотрудники просто не привыкли с ним работать. 

Обозначь свои возможности и ограничения

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

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

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

Документируй

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

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

Рецепт: визуализируй чек-лист – например, в Miro. Так может быть проще разобраться в структуре сайта и распределить проверки.

Не жди мгновенных результатов

Возможно, найденные тобой баги исправят в ту же неделю. Возможно, на это уйдёт месяц. А может быть, разработчики и дизайнеры не посчитают их багами вовсе. Твоя задача – сообщить о состоянии продукта то, что сможешь. 

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

Рецепт: пойми, где заканчиваются твои задачи – и отпусти эту ситуацию :)

Подведу итоги

Как можно раньше переходи к практике. Теория важна, но работа с реальными проектами и командой – бесценна. 

Не бойся ошибаться. Ты все ещё учишься и набивать шишки, задавать вопросы, не знать чего-то – нормально. 

Не откладывай на потом. Может казаться, что после обучения тебе не достаёт знаний, чтобы поработать с “живым” сайтом или приложением. Постарайся оценить себя более объективно – без страхов, предрассудков и синдрома самозванца. Подумай, что ты уже умеешь и чем можешь помочь продукту. И вперёд :)