Просто добавь прозрачности: техника SEMAT в тестировании и не только

2d7c3ffb747a98509278d019ea275987.png

Что делать, если на тестирование вечно не хватает времени, разработчики не читают спеку, а мотивация работать ниже плинтуса? Оля Ерина, QA Lead red_mad_robot в Томске, рассказывает о хитрой методологии, которую можно использовать как на всём проекте, так и в QA-процессах. И даже в личной жизни!

Что болит у QA: зависимость, авралы, недопонимание и изобилие инструментов

За 15 лет в QA мне удалось понаблюдать и поучаствовать во многих проектах всевозможной направленности, степени организованности и предметной области. И основную боль QA я бы субъективно сформулировала в следующем:  

  1. QA очень зависимы от других процессов проекта. В частности — от разработки. Идеальная картина при работе двухнедельными спринтами — это 2–3 дня на тестирование. Но на практике это обычно происходит по остаточному принципу, и тестирование вынуждено втискиваться в остаток спринта.

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

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

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

Но в мире взрослых людей приходится искать решения!  

Семь альф 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. Технология: используемый стек технологий.

Эти «рыбки» на схеме ниже — и есть альфы. И то, в каком статусе они находятся, характеризует состояние всего проекта. 

ea76f87a4a63ead669ce2d1762654dcb.png

Альфы влияют друг на друга и постоянно взаимодействуют разными способами, которые описаны в концепции SEMAT.

Например:  

  • стейкхолдеры предоставляют возможности,

  • работа вносит изменения и обновления в программную систему,

  • команда планирует и выполняет работу,

  • команда использует технологии,  

  • стейкхолдеры — потребители программной системы

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

Если какие-то альфы находятся в статусе, не соответствующем текущему этапу жизненного цикла (например, стейкхолдеры должны иметь статус «определены», а они не определены, потому что никто этим не озаботился), то нужно срочно менять процесс или разбираться с конкретными артефактами. 

Например, тестировщики проверяют билд и на этапе быстрой проверки основных функций системы видят несоответствия спецификации. Значит, просели альфы «Команда» и «Определение системы»: разработчики не читают спецификацию и делают так, как сами предполагают. Это аффектит QA, потому что они получают много лишних багов, которые только отнимают время на оформление, перепроверку и т. д.

SEMAT в QA и не только

Что нужно QA? Чтобы стейкхолдеры (лид, менеджер, разработчики) были заинтересованы в процессе, а сам процесс был формализован и прозрачен. Техника SEMAT позволяет адаптировать альфы под себя, сохраняя общую концепцию методологии.

Поэтому в рамках QA на основе семи главных альф создаём свои локальные субальфы:  

949b5a86f064a608a6503276f17c7681.png

  1. Стейкхолдеры в QA. Клиент и вся команда проекта, за исключением команды QA. 

  2. Возможности. Определение качества сервиса на конкретном проекте (для другого проекта могут отличаться). 

  3. Определение системы. Всё то же техническое задание и спецификация. 

  4. Программная система. Всё программное и аппаратное обеспечение, которое задействуем в QA-процессе. 

  5. Команда. QA-команда.

  6. Технологии. QA-технологии и практики, используемые методы проектирования тестов — эквивалентное разбиение, граничные значения и т. д. 

  7. Работа. НепосредственноQA-процесс.

Немного полезных советов:

  1. Если вы QA Lead компании и отвечаете за несколько проектов, берите все семь субальф: если это возможно, то назначьте на каком-то одном проекте ответственного для проработки этого процесса.

  2. Если вы локальный тимлид на проекте, выберите только те альфы, которые нужны по вашему мнению. Если не общаетесь со стейкхолдерами,  уберите их, а сами сосредоточьтесь на команде.

  3. Если вы тестировщик проекта, выберите несколько субальф, за которые непосредственно отвечаете, и работайте с ними. Например, субальфа «Технология» — то, на что вы объективно можете влиять.

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

12558490758394c88bb36328931ac9fa.png997d25fe4b65736f117222fc362b4992.png

Нужно, чтобы на каждом этапе субальфы проходили определённые состояния и нужным образом взаимодействовали друг с другом и внешним миром. На примере концепции посмотрим, что происходит с субальфами в 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, — для тех, кто хочет сильнее погрузиться в тему.

  1. Использование SEMAT для управления ИТ-проектами в госсекторе

  2. SEMAT? Приятно познакомиться. 

  3. Как за две недели освоиться с реальным проектом: стандарт OMG Essence

  4. Выжимка из книги о SEMAT

Над материалом работали:

  • текст — Оля Ерина,

  • редактура — Ника Черникова, Виталик Балашов,

  • иллюстрации — Петя Галицкий. 

© Habrahabr.ru