“I`ll be back”, -  сказал себе я, начиная вторую статью и…наконец, сделал ее спустя два месяца. Но лучше поздно, чем никогда ( главное - не берите себе это за правило, если вы QA-лид, потому что в этом случае вовремя - всегда лучше, чем поздно). Но что-то я отвлекся от главного. В комментах к прошлой статье просили сделать продолжение. Я подумал-подумал и решил, а почему бы и нет. Ну в общем, что долго тянуть.
Для всех новоприбывших - меня зовут Ваня и QA-лид в международном агентстве аутсорс-тестирования “Кавычки”. В прошлый раз я рассказывал о болях QA - лида и, собственно, что же с ними делать-то. Сегодня поговорим о том, что делать после того, как вы приложили подорожник к ранкам и теперь пора определить, сработало или нет. 

Намбер уан. Выстроенный релизный цикл

Вот давайте только глаза не закатывать тут, ладно? Видел я, как на очень многих проектах, когда приходишь, тебе говорят - “у нас все-все работает”. Даже старый дедушкин приемник. Но стоит чуть забросить удочки и уже можно подсекать - клев на ошибки удался. Релизы выходят, когда захотят (например, в третьи лунные сутки), команда ждет знака свыше, в общем, почти пир во время чумы. Вот так не надо. 

Надо вот так: 

• мы понимаем, когда и что выпускаем; 

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

• команда разработки понимает и прикидывает объем задач к этому сроку, тестирование планирует регрессы  за несколько дней + все закладывают форс-мажоры/риски;

• ситуации “Бросаем все, завтра катим релиз” - крайне редкие, если только хотфиксы.

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

Намбер ту. Коммуникации внутри компании/проекта 

Почему-то про этот пункт многие тоже предпочитают забывать, особенно всегда радует “РАБОТА - это РАБОТА”. Но потом сильно пыхтят и возмущаются, когда из-за непонимания и дискоммуникации происходит лажа, всем приходится этой лажей заниматься, иногда в выходные. Тут лучше пользоваться принципом ленивых людей: “Лучше сразу сделать все хорошо, чтобы потом не переделывать”. Поэтому, чисто как на тренингах по “бохатству”, записываем себе и повторяем перед зеркалом несколько раз: 

• команда - это единое целое;

• менеджмент/ПМ/PO - это не недосягаемые боги.По любым вопросам (в большей степени - рабочим) можно свободно коммуницировать;

• тестирование плотно завязано с клиентом/заказчиком - дабы понимать его хотелки, пожелания, проблемы в использовании ПО;

• тестовая документация включает в себя - Use Cases (сценарии использования).

Если по этим пунктам все оки-доки, ставим себе вторую радостную галочку, хлопаем в ладоши, упиваемся своей победой и чекаем дальше.

Намбер фри.Требования к продукту

Ну что же. Все мы знаем этот священный принцип: “Без ТЗ результат ХЗ”. Поэтому проверяем и идем дальше. У нас с вами должно быть: 

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

• процесс тестирования прозрачен, и каждый тест-кейс покрывает конкретные вещи.

Намбер фор. Дорожная карта развития проекта и QA-отдела

Оставьте все свои фантазии на тему: “Главное-не конечная точка, а путь”. КОНЕЧНАЯ ТОЧКА! Запомните, конечная точка! Она - главная! Бежать как оголтелые лоси через лес навстречу чему-то там - так себе перспектива. Вы всегда должны знать и понимать, куда движется проект и весь QA-отдел. Поэтому: 

У проекта своя Дорожная карта - все знают, куда мы идем и что хотим через условные полгода. QA-отдел строит свои дорожные карты. Весь год расписан по кварталам. Пример: 1 квартал - тестирование этого и того, покрытие функционала тест-кейсами; 2 квартал - сбор и формирование метрик качества, создание сценариев использования, описание регламентов; 3 квартал - автоматизация регресса, отчетность и т.д. Каждый член команды видит эти планы и понимает, к чему мы стремимся.

Намбер файв. Метрики качества

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

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

Намбер сикс. Разбор и грумминг багов

QA-команда держит руку на пульсе и знает все о багах в бэклоге. Как так выходит? Лид или старший тестер совместно с ПM разбирает эти баги - может быть, функционал так изменился, что они неактуальные; приоритеты сменились - теперь нам это неважно, или наоборот “горит-пожар” и  надо чинить; исполнитель уволился - надо переназначить; появилась дополнительная инфа по поведению в баге - добавляем комментарием, тэгаем разработчика, чтобы все были в курсе дел.

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

Намбер севен. Тестовая документация и регламенты

Да-да, как бы не сводило скулы от этих пунктов. Но это нужно. Поверьте, просто поверьте. Это приходит с опытом, как приходит желание с возрастом поскорее надеть шапку с первым ветерочком. 

Поэтому: 

В команде проекта есть База знаний, которая содержит информацию о проекте, команде, дорожные карты, тестовые артефакты. QA-команда поддерживает и наполняет документацию. Можно еще добавить - регламент постановки багов (как мы описываем баг-репорт, метки, компонент, на кого ставить баг и др.); регламент описания задач на тестирование (важные детали, ожидаемый результат, окружение и др.); шаблоны для Сценариев использования; Да и вообще у нас Стратегия тестирования расписана и т.д.

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

Поэтому заботимся заранее об: 

• Онбординге новых сотрудников

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

• Иерархии в компании

  Дерево иерархии компании - все сотрудники понимают, кто чей лид или наставник. К кому идти с тем или иным вопросом. У ключевых сотрудников есть замы (пускай и не официальные) - с уходом в отпуск\увольнением работа не останавливается, не начинается хаос.

• Общей и открытой доске задач

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

• Мотивации и целеустремленности сотрудников

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

Уф, ну вроде все! Постарался прямо-таки отлепить от своей души и поделиться. Есть ли еще что-то о чем хотелось бы почитать или что-то хочется дополнить, го в комменты, буду рад как всегда!