Привет, хабровчанки и хабровчане!
Меня зовут Настя. На данный момент работаю младшим ручным тестировщиком в небольшой компании.
Свой путь в QA я начала около полугода назад. Перед тем, как устроиться на нынешнюю работу, взялась за самостоятельное тестирование одного проекта – об этом опыте и хочу рассказать.
Мои советы будут полезны, если ты тоже джун и:
• попал на первую работу, где сразу надо брать и делать, а у тебя все ещё лапки;
• задумался о фрилансе, но не понимаешь, как взяться за тестирование в одиночку;
• оказался единственным тестировщиком в команде, слышавшей про тестировщиков только из рекламных баннеров.
Компания, с которой я сотрудничала, как раз прямиком из третьего пункта. У них сильная разработка, но нет своего отдела тестирования. Из-за загруженности программисты не всегда успевают с проверками – и тут настал мой час.
Сразу оговорюсь, что пригласили меня на проект по знакомству. Много лун назад я работала в этой компании в BD-отделе. Когда ребята узнали, что я только что отучилась на QA-джуна, предложили протестировать их новый сайт в качестве фрилансера. Понимаю, что так везёт далеко не всем.
Всё же когда настанет время твоего первого проекта, пусть у тебя под рукой будет шпаргалка с идеями, как выстроить работу.
Мои советы – от джуна джунам:
Общайся
Первая заповедь тестирования – выяснить требования к продукту. Высока вероятность, что вся документация лежит только у разработчиков в голове. Придется её оттуда доставать.
Это был как раз мой случай – кроме макета сайта в PS, требования отсутствовали.
Рецепт: проявить инициативу и пригласить в Telegram-чат программистов, проджект-менеджеров и дизайнеров, чтобы можно было оперативно выяснять все детали.
Расставляй приоритеты
Получив информацию у ПМ и разработчиков, можно продумать план тестирования. Начни с выстраивания приоритетов – ведь нужно уложиться в дедлайн и не упустить ничего важного.
Например, на моем проекте в приоритете были верстка, страницы контактов и кейс-стади. А вот гигантский блог можно было не проверять досконально. Также проверкой бэкенда занимался лично старший разработчик. Выяснив это, я сберегла силы и время.
Рецепт: спрашивать и ещё раз спрашивать. Ты джун – к тому же пришедший со стороны, если речь идет об аутсорсе или фрилансе. Задавать вопросы нормально и, вероятнее всего, команда будет к этому готова.
Обговори условия
Для эффективного тестирования тебе понадобится код-фриз. Это не всегда приходит в голову команде, для которой сотрудничество с QA в новинку.
Расскажи, что тебе нужна тестовая среда, совпадающая с продом. И постарайся убедить разработчика, что на период тестирования код желательно не менять – иначе может пропасть смысл твоей работы.
На моем проекте во время тестирования меняли фон для большого слайдера на главной странице. Это повлияло на верстку, и пришлось заново проходить несколько проверок.
Рецепт: объясни механизм тестирования команде. Если на проекте ещё ни разу не было тестировщика, другие сотрудники просто не привыкли с ним работать.
Обозначь свои возможности и ограничения
Вряд ли ты сможешь провести полноценное нагрузочное тестирование или устроить пентестинг. Также какие-то части продукта могут быть недоступны для тестирования. Например, в моем случае нельзя было работать с базой данных, и это нормально.
Но иногда у команд, никогда не имевших дело с тестировщиками, возникают завышенные ожидания. Чтобы избежать неприятностей, обговори, что именно ты умеешь и не умеешь делать.
Рецепт: расскажи команде о своем стеке. Например, ты знаешь Postman и можешь замокать бэкенд, пока над ним трудятся разработчики. Но не построишь за неделю систему автотестов.
Документируй
Даже если ты единственный тестировщик проекта, составляй хотя бы чек-листы. Они помогут в первую очередь тебе самому не запутаться в проверках.
Также обрати внимание на баг-репорты. Если это проектная работа, скорее всего, ты уже будешь занят чем-то другим, когда за эти баг-репорты возьмутся разработчики. Пусть все формулировки будут максимально понятными. Обязательно добавляй скриншоты и записи экрана.
Рецепт: визуализируй чек-лист – например, в Miro. Так может быть проще разобраться в структуре сайта и распределить проверки.
Не жди мгновенных результатов
Возможно, найденные тобой баги исправят в ту же неделю. Возможно, на это уйдёт месяц. А может быть, разработчики и дизайнеры не посчитают их багами вовсе. Твоя задача – сообщить о состоянии продукта то, что сможешь.
Например, я месяц спустя вижу на сайте несколько ошибок, на которые указывала в своих отчетах. И это тоже нормально – значит, эти баги не в приоритете, или команда пока до них не дошла.
Рецепт: пойми, где заканчиваются твои задачи – и отпусти эту ситуацию :)
Подведу итоги
Как можно раньше переходи к практике. Теория важна, но работа с реальными проектами и командой – бесценна.
Не бойся ошибаться. Ты все ещё учишься и набивать шишки, задавать вопросы, не знать чего-то – нормально.
Не откладывай на потом. Может казаться, что после обучения тебе не достаёт знаний, чтобы поработать с “живым” сайтом или приложением. Постарайся оценить себя более объективно – без страхов, предрассудков и синдрома самозванца. Подумай, что ты уже умеешь и чем можешь помочь продукту. И вперёд :)