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

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

Андрей Бракоренко, QA-лид IT Test

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

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

• что тестировать;
• когда тестировать;
• насколько тестировать;
• как тестировать.

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

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

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

Работа строится следующим образом: формулируются критерии качества > исходя из них формулируются требования > исходя из них выводится стратегия тестирования.

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

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

• Что тестировать? Выявляются группы объектов тестирования — ими могут быть функциональности или, например, весь бэкенд приложения.
• Когда тестировать? Формируется воркфлоу, который обслуживает релизный цикл.
• Насколько тестировать? Создаются условия приемки, запуска и завершения тестов.
• Как тестировать? Составляется глобальный чек-лист проверок и актуальный для проекта список видов и типов тестирования, а также подбирается инструментарий.

1. Подбирается формат документации и отчётности.

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

1. Формируется проектный глоссарий.
2. Определяется ролевая модель.

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

1. Устанавливается частота и формат рабочих встреч.

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

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

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

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

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

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

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

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

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

Антон Дуенин, Senior QA и автор Telegram-канала «Горящий тестер»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Отсутствие документации и устаревшая документация. Бывает, что тебе прилетает таска в Jira без описания. Ты уточняешь подробности у разработчика, а он говорит, что в офисе все уже обсудили, но ты при этом работаешь на удаленке. Что тестить — непонятно.
• Нечеткие и неполные требования. Что-то описано, но без подробностей, и этого не хватает для качественного тестирования.
• Отсутствие код-фриза на этапе тестирования. На одном из прошлых проектов я участвовал в разработке приложения, у которого горели сроки, и не было времени, чтобы сделать код-фриз на период тестов. Разработчики переделывали модули в процессе, я тестил фичу и мог отвечать за ее правильную работу буквально в течение 15 минут. Через это время коллеги могли что-то поменять, а я даже не знал, что именно.
• Мало времени на тестирование. Еще одна история — разработчики дали оценку на разработку фичи и не спросили тестеров, сколько времени займет проверка. Релиз должен быть в понедельник, предшествующий четверг при этом — выходной, а в пятницу никто уже особо не напрягается. Мне в конце рабочего дня среды накануне выходного приходит сборка, которую я вижу в первый раз, и мне надо за два с половиной часа до конца рабочего дня все успеть, что, конечно, невозможно. После одного такого аврала мы изменили процессы, и я как QA задаю время на тестирование сразу на этапе презентации дизайна фичи.
• Долгая раскатка приложения на стенды.
• Сложности с коммуникацией — непонятно, куда идти, кто за что ответственен и так далее.

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

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

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

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

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

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

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

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

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

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

• Расширяйте команду.
• Отслеживайте метрики и эффективность работы.
• Меняйте неудобные или бесполезные практики.
• Акцентируйте внимание при планировании на наиболее проблемных модулях, функциях и платформах.
• Не бойтесь признавать ошибки и отбрасывать неудачные решения.
• Применяйте инструменты и практики, исходя из реальных потребностей, а не потому что так все делают.
• Будьте готовы доказывать коллегам и руководству, что ваши идеи и видение процесса принесут пользу команде.

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

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

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

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

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

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

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