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