Как выстроить тестирование с нуля: опыт QA-лида и Senior QA

Компании, выпускающие ПО, могут существовать без отдельного этапа тестирования или регламентированного процесса QA. Но рано или поздно становится очевидна его необходимость. QA-лид IT Test (компания-разработчик TMS DoQA) Андрей Бракоренко и Senior QA и автор Telegram-канала «Горящий тестер» Антон Дуенин рассказали, как внедрить управление качеством на проекте.

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

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

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

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

QA-лиду нужно понимать и уметь формулировать, какие критерии качества к продукту применяет бизнес, как технически достигается соответствие продукта требованиям, которые лиду может понадобиться составить самостоятельно, и какими средствами можно удостовериться, что продукт им соответствует.

В рамках последней процедуры, наиболее актуальной для QA-лида, работы планируются в несколько этапов.

1. Формулируются ответы на ранее обозначенные вопросы.

2. Подбирается формат документации и отчётности. Так будущая команда тестирования будет знать, с какими артефактами предстоит работать и какими артефактами обслуживать проект.

3. Формируется проектный глоссарий.

4. Определяется ролевая модель. Члены будущей команды будут коммуницировать не только между собой, но и с другими сотрудниками, вовлеченными в проект. Все участники QA должны знать, к кому и с какими вопросами обращаться.

5. Устанавливается частота и формат рабочих встреч. Процессы должны быть прозрачными, а частые коммуникации не должны вредить работе команд.

Имея на руках план, лид осуществляет подбор команды. Помимо этого, он опирается на следующие факторы:

Последний этап формирования процессов включает в себя онбординг, распределение задач и мониторинг.

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

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

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

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

Внедрение и мониторинг этих метрик позволят QA-лиду удостовериться, что предыдущие этапы работ были осуществлены грамотно.

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

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

2. Небольшие компании в заказной разработке. Здесь уже может присутствовать команда тестирования с общим представлением о процессах, но требования к ней формулируются очень просто — «чтобы все нормально работало, и баги с прода не сыпались».

3. Большие компании в заказной разработке с внушительным штатом и историей на рынке, которые каким-то образом существовали без тестировщиков. Разработчики все пилили, менеджеры, может быть, поверхностно тестировали, а в какой-то момент компания задумалась о том, что нужно повышать качество. Именно в такие обстоятельства я попал, когда устроился на текущее место работы — команда искала специалиста-сеньора, который сможет наладить тестирование.

Как могут выглядеть этапы выстраивания QA с нуля:

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

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

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

1. Узнайте, чего хочет компания, и что она представляет под тестированием. Постановка задачи с формулировкой «нам нужно выстроить процесс с нуля» ничего не значит. Поговорите с руководителем, нанимающим менеджером, коллегами, чтобы узнать, что конкретно они имеют в виду, чтобы у вас сформировалось одинаковое видение и цели работы.

2. Изучите текущий процесс разработки, проблемы и ожидания коллег.

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

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

3. Внедрите ручное тестирование фич в процесс разработки.

Это базовый шаг, чтобы тестирование просто появилось и встало в Jira между колонками «разработка» и «релиз». Внедрять что-то новое всегда больно, и на этом этапе, скорее всего, все будет криво. Коллеги могут первое время путаться и забывать, что в процессе появились вы, но без этого никуда.

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

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

4. Проанализируйте наиболее болезненные моменты в текущем процессе.

Вот наиболее частые проблемы, с которыми я встречался на опыте.

5. Расширяйте сферу влияния с тестирования до QA.

После того, как этап тестирования устаканился, я распространил свою сферу влияния и на другие этапы (синий цвет на схеме).

Написание требований — аналитики или PM пишут требования, закидывают тестерам, тестеры проверяют, находят нестыковки и неоднозначные трактовки, которые могут привести к багам, и фиксят их. Отлично, если удается найти ошибки еще на этом этапе.

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

6. Пишите документацию.

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

7. Автоматизируйте рутину.

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

8. Оптимизируйте процесс.

После завершения выстраивания процесса работа не заканчивается.

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

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

Тестировщикам, которые впервые с нуля выстраивают процессы тестирования, нужно быть готовым к двум основным сложностям.

И немного про ошибки в выстраивании процессов.

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

TMS — важная часть процессов тестирования, которая делает их более структурированными, прозрачными и эффективными. Убедитесь в том, насколько система управления тестированием DoQA облегчает жизнь тестировщиков — регистрируйтесь на 30-дневный триал без ограничений по количеству пользователей и функционалу.

Больше экспертных материалов о тестировании — в нашем Telegram-канале.