Что делать, если на тестирование вечно не хватает времени, разработчики не читают спеку, а мотивация работать ниже плинтуса? Оля Ерина, QA Lead red_mad_robot в Томске, рассказывает о хитрой методологии, которую можно использовать как на всём проекте, так и в QA-процессах. И даже в личной жизни!
Что болит у QA: зависимость, авралы, недопонимание и изобилие инструментов
За 15 лет в QA мне удалось понаблюдать и поучаствовать во многих проектах всевозможной направленности, степени организованности и предметной области. И основную боль QA я бы субъективно сформулировала в следующем:
1_
QA очень зависимы от других процессов проекта. В частности — от разработки. Идеальная картина при работе двухнедельными спринтами — это 2–3 дня на тестирование. Но на практике это обычно происходит по остаточному принципу, и тестирование вынуждено втискиваться в остаток спринта.
2_
Не все понимают специфику QA. Например, менеджер думает, что если основная фаза разработки закончилась, то и тестировать нечего — поэтому закладывает меньше времени. У меня совсем недавно был кейс, когда с проекта хотели снять тестировщика, потому что фичи уже не разрабатывали.
3_
Сложно подобрать эффективные инструменты. Всевозможных методологий и техник так много, что в них сложно ориентироваться — одна похожа на другую, глаз замыливается, особенно у тех, кто давно работает в этой сфере.
Есть и ежедневные сложности: иногда времени и тестировщиков не хватает, спецификации написаны невнятно, а мотивация, если быть совсем откровенной, порой отсутствует.
Но в мире взрослых людей приходится искать решения!
Семь альф SEMAT
Методику Software Engineering Method and Theory в 2009 году придумали и изложили в своей книге The Essence of Software Engineering: Applying the SEMAT Kernel учёные-разработчики Ивар Якобсон, Бертран Мейер и Ричард Соули.
Главное преимущество SEMAT в том, что он применим совместно с любыми методологиями управления проектами: Agile, Scrum, Waterfall и другими. И именно это позволяет сгенерировать собственную, идеально подходящую методику для конкретной команды или проекта.
В основе методики такой принцип: у любого проекта есть семь сущностей (альф), которые его характеризуют. Ещё одно преимущество в том, что значения этих альф можно и нужно адаптировать под нужды своего проекта и процессов. Вот эти альфы:
1_
Стейкхолдеры: клиент, конечный пользователь и т. д.
2_
Возможности: границы системы, предметной области, технические возможности, которые можно реализовать в проекте.
3_
Определение системы: спецификация, техническое задание и т. д.
4_
Программная система: сервис, разработка которого планируется.
5_
Команда: участники проекта.
6_
Работа: процесс разработки, жизненный цикл программного обеспечения.
7_
Технология: используемый стек технологий.
Эти «рыбки» на схеме ниже — и есть альфы. И то, в каком статусе они находятся, характеризует состояние всего проекта.
Альфы влияют друг на друга и постоянно взаимодействуют разными способами, которые описаны в концепции SEMAT.
Например:
стейкхолдеры предоставляют возможности,
работа вносит изменения и обновления в программную систему,
команда планирует и выполняет работу,
команда использует технологии,
стейкхолдеры — потребители программной системы.
Если какие-то альфы находятся в статусе, не соответствующем текущему этапу жизненного цикла (например, стейкхолдеры должны иметь статус «определены», а они не определены, потому что никто этим не озаботился), то нужно срочно менять процесс или разбираться с конкретными артефактами.
Например, тестировщики проверяют билд и на этапе быстрой проверки основных функций системы видят несоответствия спецификации. Значит, просели альфы «Команда» и «Определение системы»: разработчики не читают спецификацию и делают так, как сами предполагают. Это аффектит QA, потому что они получают много лишних багов, которые только отнимают время на оформление, перепроверку и т. д.
SEMAT в QA и не только
Что нужно QA? Чтобы стейкхолдеры (лид, менеджер, разработчики) были заинтересованы в процессе, а сам процесс был формализован и прозрачен. Техника SEMAT позволяет адаптировать альфы под себя, сохраняя общую концепцию методологии.
Поэтому в рамках QA на основе семи главных альф создаём свои локальные субальфы:
1_
Стейкхолдеры в QA. Клиент и вся команда проекта, за исключением команды QA.
2_
Возможности. Определение качества сервиса на конкретном проекте (для другого проекта могут отличаться).
3_
Определение системы. Всё то же техническое задание и спецификация.
4_
Программная система. Всё программное и аппаратное обеспечение, которое задействуем в QA-процессе.
5_
Команда. QA-команда.
6_
Технологии. QA-технологии и практики, используемые методы проектирования тестов — эквивалентное разбиение, граничные значения и т. д.
7_
Работа. Непосредственно QA-процесс.
Немного полезных советов:
Если вы QA Lead компании и отвечаете за несколько проектов, берите все семь субальф: если это возможно, то назначьте на каком-то одном проекте ответственного для проработки этого процесса.
Если вы локальный тимлид на проекте, выберите только те альфы, которые нужны по вашему мнению. Если не общаетесь со стейкхолдерами, уберите их, а сами сосредоточьтесь на команде.
Если вы тестировщик проекта, выберите несколько субальф, за которые непосредственно отвечаете, и работайте с ними. Например, субальфа «Технология» — то, на что вы объективно можете влиять.
Процесс QA живёт весь цикл разработки, так что эти субальфы проходят через весь жизненный цикл. Вот какие активности совершаются с субальфами на каждом этапе жизненного цикла:
Нужно, чтобы на каждом этапе субальфы проходили определённые состояния и нужным образом взаимодействовали друг с другом и внешним миром. На примере концепции посмотрим, что происходит с субальфами в QA.
На этапе концепции должны быть:
1_
Определены стейкхолдеры.
2_
Выявлены возможности тестирования.
3_
Выявлены границы тестирования системы (например, какие виды тестирования будем применять, — да, это не всегда можно решить на начальном этапе, нужно исходить из особенностей проекта, но лучше сделать это как можно раньше).
4_
Выбраны критерии качества сервиса или фичи (что должно быть — артефакты или состояния, которые считались бы удовлетворительными с точки зрения качества).
5_
Определены участники QA-команды на проекте.
6_
Определены критерии входа/выхода этапов процесса тестирования.
7_
Определён перечень QA-практик (например, будет ли автоматизация).
Так метод SEMAT адаптируется и локализуется конкретно для вашего QA-процесса: для каждой субальфы получаем таблицу, по которой легко двигаться.
Для удобства можно для каждой субальфы составить карточку состояний, в котором она находится на конкретном жизненном этапе. На примере стейкхолдера выглядеть будет примерно так:
Стейкхолдеры:
на этапе «Концепции» должны быть определены;
на этапах начиная с «Разработки ТЗ» и до последнего этапа поддержки должны быть включены в работу;
на последних двух этапах — «Развёртывание» и «Поддержка» — нам бы очень хотелось, чтоб они были удовлетворены результатом.
Пока стейкхолдеры не определены, эта субальфа заблокирована для перехода на следующий этап.
Преимущества SEMAT в QA
Их, кстати, тоже семь — как и альф.
1_
Вы следите за ключевыми сущностями в своём процессе и точно знаете, когда и с кого вам следует получить нужные артефакты.
2_
Процесс формализован, что особенно важно в гибких разработках, а также учитывая, что многие риски сваливаются на QA (например, авральное тестирование под конец проекта).
3_
Вы заранее знаете, какие виды работ и какие практики вы примените на каждом из этапов.
4_
Понимаете объём работ на каждом из этапов.
5_
Есть критерии перехода на следующий этап.
6_
Вы избежите одних и тех же ошибок (например, если всегда пропускаете этап статического тестирования).
7_
Сводная таблица охватывает все аспекты QA.
Это делает процесс более понятным для неспециалистов в QA, с которыми мы работаем на одном проекте. Откройте доступ к таблице всем участникам проекта — и они будут знать, сколько операций требует от QA тот или иной этап. Принцип SEMAT помогает добавить прозрачности в общее дело, а значит, выигрывают все.
SEMAT в обычной жизни
Можно ли использовать принцип SEMAT в какой-нибудь другой сфере? Легко. Эту технику можно адаптировать даже к организации своей жизни. Предположим, вы решили встать на путь тотального саморазвития. Базово всё неплохо, резкие движения не нужны, но как и в QA — то мотивации не хватает, то времени, то зависишь много от кого. Можно немного формализовать этот процесс и добавить в него прозрачности.
Выделяем субальфы, которые важны для вас в вашей жизни, и что вас приведёт к некой своей улучшенной версии.
Например:
1_
Комфортное общение с окружающими / коммуникативные навыки.
2_
Интересы, хобби, досуг.
3_
Семья, отношения.
4_
Профессиональная жизнь.
5_
Финансы.
6_
Здоровье.
7_
Что-то ещё, что важно лично для вас.
1_
Коммуникация. Составить список своих багов в коммуникации с семьёй, партнёром и коллегами.
2_
Досуг. Проанализировать увлечения и выявить самые приоритетные.
3_
Семья/Отношения. Определить список родных, с кем хочется улучшить отношения, и как на это может повлиять работа с субальфой коммуникации.
4_
Профессия. Составить список навыков и планов.
5_
Финансы. Посчитать, сколько есть, сколько нужно ежемесячно, ежегодно, в запасе, через пять лет.
6_
Здоровье. Пройти чекап и проанализировать, хватит ли физических сил на досуг, профессиональный рост и улучшение коммуникации с другими людьми.
Полезные материалы
Список со всеми статьями, которые я использовала при подготовке и изучении концепции SEMAT, — для тех, кто хочет сильнее погрузиться в тему.
Над материалом работали:
текст — Оля Ерина,
редактура — Ника Черникова, Виталик Балашов,
иллюстрации — Петя Галицкий.