Поздравляю, вы — тест-лид: как зайти на новый проект и не упустить ничего важного (удобный чек-лист)

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

В этой статье я хочу сосредоточиться на этапах знакомства с проектом с позиции QA Test Lead. Это может быть только стартующий проект или уже действующий. Тогда вас могут присоединить к команде как еще одного QA или на смену другому.

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

Поздравляю, вы — тест-лид

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

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

Потому дальнейший сценарий разобьем на несколько шагов.

Определите ожидания от работы

Как правило, о новом проекте тест-лида сообщает руководитель. Потому и познакомиться с проектом можно уже в разговоре с ним. Начните беседу с обсуждения ожиданий руководства:

• Цели. Узнайте, чего вам нужно достичь в качестве тест-лида в рамках этого проекта и какие конкретные задачи ставит ваш руководитель.
• Полномочия. Возможно, вы сами будете принимать все решения и нести за них ответственность. Или вам нужно будет согласовывать как стратегические, так и малейшие действия на проекте. Расспросите обо всем этом.
• Сроки. Желательно заранее определить дедлайны на вхождение в проект и на knowledge transfer. Узнайте, насколько длительным будет проект и ваша роль в нем.

Целью этого разговора должно стать исключение недоразумений в будущем. Иначе существует риск, что через некоторое время руководитель скажет что-то вроде: «Я думал, ты это сделаешь», а вы ответите из серии: «Мне показалось, что кто-то этим занимается…».

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

• Ожидание. Выясните требования, которые заказчик будет выдвигать вам, команде тестирования и, возможно, всей проектной команде. Он может сказать: «Мне безразлично, как вы это сделаете, но я хочу вовремя получить хороший продукт». Или клиент может захотеть отслеживать каждый ваш шаг.
• Ответственные лица. От заказчика необходимо получить список людей с его стороны, к которым вы можете обращаться с вопросами и предложениями. Помимо самого клиента это может быть проектный менеджер или тест-лид на стороне его команды разработки.

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

Если проект не новый, то важно перенять опыт прошлого тест-лида:

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

Познакомьтесь с командой

Не могу отказать себе в удовольствии сравнить команду супергероев детства с командой QA.

Если ваш новый проект только стартует, вам вместе с HR нужно сформировать свою команду мечты. Если вы попали в действующий проект, то познакомьтесь с людьми как скоупом, так и с каждым специалистом отдельно. Узнайте, какие у них квалификации, желания и состояние в целом. В идеале нужно распределить ответственность по ролям.

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

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

Оцените ресурсы

После знакомства с людьми следует оценить имеющиеся и необходимые ресурсы на проекте.

Я бы выделил следующие категории:

• Железо. Подумайте о конфигурации компьютеров и ноутбуков, количестве мониторов, планшетов или смартфонов и другой технике, которая вам понадобится для тестирования продукта. Если будете работать над сайтом-визиткой, то заимствованного у бабушки ноутбука наверняка хватит. Но если производить тестирование нагрузки, понадобится более серьезная техника.
• Инструменты. Кроме hardware, для тестирования требуется и software. При выборе этих инструментов помните о доступном бюджете. Если денег достаточно, покупайте продвинутое ПО. В противном случае поищите бесплатные аналоги и оцените, насколько они подходят конкретной задаче.
• Окружение. Попытайтесь рассчитать, сколько и какие энвайроменты вам нужны. В идеале нужно иметь хотя бы одно окружение исключительно для тестирования. Это вообще хорошая практика: один энвайромент для девелоперов, один — для аналитиков, один — для тестировщиков.
• Люди. Оцените квалификацию сотрудников. Людям не должно быть тесно на проекте. Если у вас только крутые сеньоры, вряд ли они будут долго сверять буквы в приложении. Им нужны задачи соответствующего уровня, а таких банально на всех не хватит. Если же у вас только джуны, они могут не осилить тестирование сложной и запутанной логики. Команда должна быть сбалансирована по скиллам.

Исследуйте объект тестирования

Это знакомство с продуктом. Здесь я бы выделил три вектора:

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

Определите возможные риски и способы тестирования

Разобравшись с продуктом, попытайтесь предусмотреть потенциальные проблемы на проекте:

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

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

Ограничусь простым перечислением:

• мануальное;
• автоматизированное;
• погрузочное;
• безопасности;
• доступности;
• локализации;
• регрессионное;
• любое другое специфическое.

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

После тестирования определитесь с браузерами. Обычно достаточно последних версий Edge и Chrome. Но может не повезти с продуктом для пользователей, работающих на Windows XP. В таком случае следует проводить тесты в IE 8 или более экзотических вариантах.

Также подумайте об операционных системах, даже если имеете дело с веб-приложением. Подготовьте все необходимое для тестов на разных ОС. То же касается и мобильных операционных систем. Узнайте, будет ли ваше приложение работать еще и на них. Тут основным ориентиром должна быть целевая аудитория.

Сформулируйте стратегию тестирования

Переходим к составлению планов тестирования. Ключевые вопросы: кто, что и когда будет проверять в продукте. Такие сценарии могут принять один из форматов:

• Тест-план. Больше подходит для проектов с фиксированным скоупом, когда четко ясны стадии, итоговые результаты и сроки.
• Тестовая стратегия. Этот вариант лучше приспособлен к Agile-проектам, где все быстро меняется и нет ориентиров по срокам и итогам разработки.

Поработайте с требованиями к продукту и документации

Эта часть работы наиболее объемна. Сначала сосредоточьтесь на требованиях. В идеальном мире тест-лид на входе в проект получает большую папку документации, которая включает в себя:

• бизнес-требования;
• требования пользователя;
• функциональные требования;
• требования к внешним интерфейсам;
• требования к данным;
• бизнес-правила;
• атрибуты качества;
• ограничение;
• идеи решения.

Мы всегда надеемся, что придется иметь дело с детально написанной спецификацией или детализированными User Stories. Но лучше сразу настроить себя на возможное выделение требований из отрывков писем, разговоров и митингов с заказчиком. В самом худшем случае он вообще ограничится фразой вроде: «Сделайте мне как там». К этому тоже нужно быть готовыми.

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

• в каком формате оценивать требования;
• кто, как и когда это будет делать;
• какая требуется точность оценки.

Следующий документ — Jira или любая подобная система трекинга и менеджмента. В Jira определите типы сущностей, порядок их перемещения по доске, изменение статусов и жизненный цикл тикета. Заранее обсудите с коллегами, как действовать с тестированием Stories: заводить обычный дефект, инстраспринт, сабтаск и т.д.

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

В работе по документации обратите внимание на:

• Вид и формат. Это могут быть разные артефакты: чек-листы, подробные тест-кейсы в тест-рейле, пользовательские сценарии в Google Docs или краткие комментарии к таскам в Jira.
• Место хранения. Определите, где вы будете писать и размещать документацию. Не забудьте о доступе к этим хранилищам.
• Техники тест-дизайна. Определите, какие из них будут использоваться для написания тестов. Какой бы подход к ведению документации вы ни выбрали, он должен быть формализованным, четким и понятным всем участникам процесса.

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

Без менеджмента не обойтись

Ваша задача — обеспечить прозрачность работы как всех QA, так и проектной команды в целом. Если каждый понимает, кто и чем занимается, к тест-лиду будет минимум вопросов. Для обеспечения прозрачности на проекте рекомендую ввести несколько параметров:

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

Как только это определили, переходите к тонким настройкам — к этапу митингов. Здесь все зависит от многих моментов: особенностей проекта, бизнес-домена, состава команды, методов менеджмента. Я остановлюсь на самых популярных приемах.

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

Менеджеры с аналитиками иногда предпочитают паяльники, чтобы выуживать из команды сроки, оценки и другую информацию. Лично я за мирное урегулирование вопросов, поэтому предлагаю при организации митингов узнавать следующее:

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

Продумайте процесс доставки кода

Этот этап в тестировании и разработке — фактически выход на финишную прямую. Заранее продумывайте принципы деплоя на QA, стейдже, проде:

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

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

Постоянно развивайте свою команду

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

Рассказывайте о ходе работы

Спланировав работу над продуктом и в общем в команде, возвращайтесь к коммуникациям. Принципы просты:

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

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

Вы ведь помните, что это все было только входом в проект? Вот теперь можете начать работать! На позиции тест-лида хватает ежедневных рутинных задач:

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

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