Вход в новый проект — волнующий и немного сложный момент для всех специалистов. Начинающим нужно не растеряться и не допустить ошибок, а опытным специалистам — с самого начала грамотно и эффективно выстраивать рабочие процессы.
В этой статье я хочу сосредоточиться на этапах знакомства с проектом с позиции 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 и другими специалистами, с руководителем проекта и клиентом.
Все это необязательно делать самостоятельно. Каждый проект реализуется силами команды. Некоторые задачи можно выполнять совместно с разработчиками, менеджерами или бизнес-аналитиками. А что-то действительно только самостоятельно. Учитывайте и то, что все задуманное в проекте может изменяться. Поэтому старайтесь быть гибкими, а не слепо следовать определенным паттернам.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: