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

Из каждого утюга сегодня звучит призыв двигаться в сторону IT. Информационные технологии — это уже не только про математику, но и про дизайн, менеджмент, аналитику и тестирование. Причём о тестировании говорят как о чём-то очень лёгком для начала карьеры. Мол, стать тестировщиком может каждый. Но стать — это одно, а стать профессионалом — совсем другое.

Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи  по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических. 

QA-инженер  — это не волк-одиночка, который только ищет баги. Задача тестирования — проверка работы продукта в соответствии с требованиями заказчика. Есть даже поговорка, что разработчики радуются, когда работает, а тестировщики радуются, когда не работает. Потому что тестировщики проверяют работу программы согласно требованиям к ПО и удостоверяются, что нет багов. Но поиск багов — не цель тестировщика, а следствие его кропотливой работы.

Я расскажу о самых распространённых проблемах в процессе разработки ПО, с которыми сталкиваются тестировщики.

Место тестирования в жизненном цикле ПО

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

• Появились требования — тестирование оценивает их. 

• Появились макеты — тестирование не отстаёт, оценивает, задаёт наводящие вопросы согласно требованиям и сценариям приёмки. 

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

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

Если тестировать начинают после выполнения разработчиком задачи, то при обнаружении ошибки в требованиях вернуть на доработку или переделать функциональность становится дорого. В результате на ежедневных и ретроспективных встречах звучат фразы: «мы не подумали, надо было раньше». Проведение грумингов по задаче с активным участием тестировщиков снизит риск возникновения ошибок в требованиях. А внедрение практики «3 Амиго» поможет покрыть тестами всю функциональность и уменьшит количество тяжёлых e2e-тестов благодаря написанию модульных и интеграционных тестов.

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

«Нужно срочно выкатить хотфикс»

Как часто тестировщик сталкивается с тем, что в чате команды объявляется хотфикс через час? При этом задача ещё не дошла до этапа тестирования (находится на стадии ревью или разработки)? К тому же в этот момент тестировщик погружён в другую задачу со сложной функциональностью. И вот за считанные минуты надо перестроиться, переключиться на новую задачу, ознакомиться с требованиями, накидать примерный план тестирования, приготовить тестовых пользователей и ждать изменение статуса задачи на Ready_for_test. Бизнес давит, что это срочное исправление, DevOps давят, что хотфикс должен выйти через час, а к задаче ты ещё не приступал. Обычно после таких ситуаций на ретроспективной встрече выносится тезис: давать больше времени на проверку, не затягивать задачу в разработке и т. д. Здесь правда на стороне бизнеса: баг должен быть исправлен вовремя (и не важно, какой ценой). Но для удобства тестирования стоит установить правило: переносить хотфикс на следующий день, если баг обнаружен во второй половине дня, а для запуска автотестов и ручного регресса необходимо около 2-3 часов. Тогда тестировщики не будут задерживаться на работе в день обнаружения бага и спокойно проверят хотфиксовую задачу и проведут регрессионное тестирование, если это необходимо, на следующий день.

«В задаче всё описано»

Недостаточное описание задачи — это частая проблема. Обычно ее обсуждают на ретроспективных встречах и устанавливают правила описания раздела «для тестирования». Но находятся коллеги, которые объясняют недостаточно описанные задачи прикреплённым МР с кодом, в котором «можно разобраться». Конечно, во всём можно разобраться, но не все могут сходу найти нужную правку или понять логику в коде, особенно если задача не проходила груминги или человек не присутствовал на встречах, посвящённых именованию переменных.

Это страшное слово «регресс»

Когда тестировщик проводит регрессионное тестирование в первый раз, это больше похоже на онбординг. Но когда он подключается к регрессу в десятый раз, сложно совладать с чувством «скорее бы пройти все тестовые сценарии», потому что однообразная, монотонная работа мало кому приносит удовольствие. Регресс стоит наивысшим приоритетом среди других задач, поэтому с его началом тестировщики бросают текущие дела и все силы направляют на регресс. Напоминаю, что умение быстро переключиться с одной задачи и погрузиться в другую — это необходимое качество тестировщика. И сильно выгоревшие тестировщики боятся найти баги во время проведении регресса, потому что иначе придётся останавливать регресс до выявления причин, а после их устранения начинать заново. Поэтому есть правило: если во время регресса найден баг — незамедлительно сообщи команде тестировщиков, которые занимаются регрессом. Регресс не страшен только тогда, когда тебе не надо проверять результаты прогонов автотестов или вручную проверять всю функциональность. Во всех остальных случаях это слово из фильмов ужасов.

«Гибкий график, лежишь с ноутбуком у бассейна, пьёшь коктейль»

Сложно назвать рабочий день тестировщика свободным, так как он чуть больше связан с процессами команды и продукта в целом, да и день у тестировщика нормирован жёстче, нежели у разработчика (конечно, разработчики с этим поспорят). Но если в команде есть мобильная разработка, веб-, бэкенд-разработка, то релизов и регрессионных тестирований получается много. А значит, есть и план релизов, и дежурства по проведению регресса, потому что в момент релиза тестировщик должен присутствовать и подстраховывать на проде. Он может быть должен провести smoke-тестирование после успешного релиза или отката. Так что работа в IT по ненормированному графику — это миф, тестировщик больше всех привязан к  рабочему расписанию. Конечно, всегда можно договориться с другими членами команды о подмене на регрессе или релизе, но регресс не любят 99 % тестировщиков, поэтому поменявшись однажды, тебе придётся отработать в следующий раз.

Усмешки разработчиков, что задачи тестируются дольше, чем разрабатываются

В тестировании много бюрократии с написанием тестовой документации: тестовых сценариев, чек-листов, отчётов. Часто в компании есть требование, чтобы тестировщик прописывал в комментарии к задаче проверенные тестовые сценарии и результат их выполнения. Я уже не говорю о прикреплении логов и скриншотов с доказательствами (для багов или проверенных задач), чтобы можно было вернуться к задаче через полгода и выяснить, что этот сценарий работал, или он работал так — и это правильно. На сбор таких «доказательств» и описаний тоже уходит время. Но когда через полгода ты возвращаешься к задаче и находишь  комментарии тестировщика, чувствуешь невероятное облегчение. А если нет комментариев, или, не дай бог, нет тестовых сценариев в Allure, то приходится заново погружаться в контекст, искать людей, причастных к задаче, или просить разработчиков посмотреть код. На это уходит ещё больше времени. Чтобы передать «будущему поколению» создание новой фичи и добавление новых тестовых сценариев в регресс, необходимо потратить время и силы.

«Ты не помнишь? Мы на груминге это обсуждали»

Чем позже в жизненном цикле создания ПО тестировщики подключаются к работе, тем больше времени проходит от груминга до тестирования. Это значит, что чёткие требования к фиче могли миллион раз обсуждаться на этапе зарождения идеи, проработки на груминге, но в момент тестирования у тестировщика могут появиться уточняющие вопросы. Тестировщик задаёт их в чате ответственным лицам, те начинают отвечать «мы же на груминге это обсуждали». Но для QA-инженера столько воды утекло с тех пор, всё не запомнить. Поэтому обязательно нужно записывать в задачах или в Confluence все пожелания и требования к фиче.

«Тестирование не успевает, давайте поможем»

Бывают случаи, когда тестирование на протяжение нескольких спринтов не может разгрести задачи в своей колонке, при этом разработка новых фичей не останавливается. Колонка Ready_for_test заполняется быстрее, чем убывает. Как можно в этом случае помочь тестированию?

• Отправить всех разработчиков в отпуск (где-то в параллельной реальности).

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

• Запросить помощь в тестировании у другой команды.

• Отправить разработчиков в помощь тестировщикам.

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

В подобных ситуациях QA-инженеры часто отодвигают саморазвитие на второй план. А иначе как на ежедневной встрече объявить о часе саморазвития или задаче на ИПР (индивидуальный план развития), если вся команда пришла тебе помочь с продуктовыми задачами, а ты ушёл «развиваться»? Но отсутствие в мотивации или невозможности развиваться — первые сигналы в поиске новой работы или выгорании.

Пренебрежение интеграционным тестированием

Интеграционное тестирование гарантирует, что все компоненты приложения работают вместе, как ожидается. Но часто про него забывают или  «не вспоминают», чтобы лишний раз не контактировать с соседней командой. Обычно на интеграционное тестирование не закладывают время, оно где-то когда-то должно произойти. Однако для его проведения надо выделить конкретных тестировщиков из разных команд, договориться, чтобы их графики совпали, чтобы было настроено окружение, подобраны тестовые пользователи для совместной проверки основных сценариев взаимодействия продуктов.
Эта «нелюбовь» к интеграционному тестированию ещё связана с желанием переложить на соседнюю команду ответственность за корректную работу фичи: «вы сами проверьте, зачем мы вам нужны?» Хотя тестировщики одной команды не могут знать тонкости работы другой команды. Как результат — интеграционное тестирование как бы и есть, но его как бы и нет.

Тестировщики vs разработчики

Разработка и тестирование, с одной стороны, идут рука об руку, но с другой стороны, это две разнонаправленные силы: одна защищает «свой код», другая — продукт. Что касается коллективной работы, то в таких условиях сложно дружить и спорить одновременно. Поэтому зачастую тестировщики держатся особняком от разработчиков.

«Может, тестировщики кодить будут?»

Порой критика в команде или жаркое обсуждение фичи приводит к конфликту. В таких случаях у нежных разработчиков главный козырь: «Может, тестировщики кодить будут?» Эта маркерная фраза говорит о многом: об отсутствии договорённости, об обиде за неоценённый труд, об указании на «место» тестировщиков, потому что код пишут только разработчики (в данном случае автотестировщики не в счёт). Конечно, каждый случай стоит разбирать отдельно, но после этой фразы тестировщики и разработчики точно не пойдут вечером в бар вместе.

Конец спринта

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

Как уменьшить напряжённость работы в конце спринта? Ставить разные цели для разработчиков и тестировщиков. Например, в одном спринте цель для разработки — реализовать фичу Б, для тестирования — довести до релиза фичу А, во втором спринте цель для разработки — реализовать фичу С, для тестирования — довести до релиза фичу Б.

Инженерный день

Не во всех IT-компаниях сотрудникам устанавливают ИПР, но даже при его наличии можно устанавливать инженерный день или полдня, когда тестировщик может изучить какой-то новый инструмент и поделиться опытом на внутреннем митапе. Обычно инженерный день устанавливают в пятницу под конец спринта, когда все задачи уже выполнены и команда готовится к ретро. Если тестировщиков несколько в одной команде, то когда сразу двое не работают над продуктовыми задачами, это может негативно сказаться на производительности команды. В этом случае инженерный день устанавливается для каждого тестировщика индивидуально в течение недели, так, чтобы эти дни не пересекались.

Как сказал Л.Н. Толстой: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Это высказывание можно применить и к продуктовой IT-команде. Какая она — счастливая и успешная команда? Что нужно сделать, как нужно работать, чтобы команда стала dream team? Наверное, стоит не замалчивать проблемы на ретро, активно говорить, что именно не нравится в работе команды. Зачастую самая высокая текучка именно среди тестировщиков. Создавайте такие условия для работников, чтобы всем было комфортно.