ru:https://highload.today/blogs/pozdravlyayu-vy-test-lid-kak-zajti-na-novyj-proekt-i-ne-upustit-nichego-vazhnogo-udobnyj-chek-list/ ua:https://highload.today/uk/blogs/vitayu-vi-test-lid-yak-zajti-na-novij-proyekt-i-ne-upustiti-nichogo-vazhlivogo-zruchnij-chek-list/
logo
Тестирование      19/10/2022

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

Олександр Фіалка BLOG

QA Lead у NIX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Онлайн курс з промт інжинірингу та ефективної роботи з ШІ.
Курс-інтенсив для отримання навичок роботи з ChatGPT та іншими інструментами ШІ для професійних та особистих задач, котрі допоможуть як новачку, так і професіоналу.
Записатися на курс

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Топ-5 самых популярных блогеров февраля

Всего просмотровВсего просмотров
229
#1
Всего просмотровВсего просмотров
229
Всего просмотровВсего просмотров
209
#2
Всего просмотровВсего просмотров
209
QA в CodeGeeks Solutions
Всего просмотровВсего просмотров
156
#3
Всего просмотровВсего просмотров
156
Senior Project Manager at Nemesis
Всего просмотровВсего просмотров
99
#4
Всего просмотровВсего просмотров
99
Software Architect at Devlify
Всего просмотровВсего просмотров
95
#5
Всего просмотровВсего просмотров
95
Рейтинг блогеров

Ваша жалоба отправлена модератору

Сообщить об опечатке

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