![](https://habrastorage.org/getpro/habr/upload_files/2d7/c3f/fb7/2d7c3ffb747a98509278d019ea275987.png)
Что делать, если на тестирование вечно не хватает времени, разработчики не читают спеку, а мотивация работать ниже плинтуса? Оля Ерина, 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 и другими. И именно это позволяет сгенерировать собственную, идеально подходящую методику для конкретной команды или проекта.
В основе методики такой принцип: у любого проекта есть семь сущностей (альф), которые его характеризуют. Ещё одно преимущество в том, что значения этих альф можно и нужно адаптировать под нужды своего проекта и процессов. Вот эти альфы:
-
Стейкхолдеры: клиент, конечный пользователь и т. д.
-
Возможности: границы системы, предметной области, технические возможности, которые можно реализовать в проекте.
-
Определение системы: спецификация, техническое задание и т. д.
-
Программная система: сервис, разработка которого планируется.
-
Команда: участники проекта.
-
Работа: процесс разработки, жизненный цикл программного обеспечения.
-
Технология: используемый стек технологий.
Эти «рыбки» на схеме ниже — и есть альфы. И то, в каком статусе они находятся, характеризует состояние всего проекта.
![](https://habrastorage.org/getpro/habr/upload_files/ea7/6f8/7a4/ea76f87a4a63ead669ce2d1762654dcb.png)
Альфы влияют друг на друга и постоянно взаимодействуют разными способами, которые описаны в концепции SEMAT.
Например:
-
стейкхолдеры предоставляют возможности,
-
работа вносит изменения и обновления в программную систему,
-
команда планирует и выполняет работу,
-
команда использует технологии,
-
стейкхолдеры — потребители программной системы
Альфы переходят из одного состояния в другое, меняя свой статус, и если состояние альфы в данный момент времени коррелируется с тем этапом жизненного цикла, через который сейчас проходит проект, то мы можем уверенно сказать, что с проектом всё хорошо, всё идет по плану, продолжаем в том же духе. То есть альфы — это некая характеристика проекта.
Если какие-то альфы находятся в статусе, не соответствующем текущему этапу жизненного цикла (например, стейкхолдеры должны иметь статус «определены», а они не определены, потому что никто этим не озаботился), то нужно срочно менять процесс или разбираться с конкретными артефактами.
Например, тестировщики проверяют билд и на этапе быстрой проверки основных функций системы видят несоответствия спецификации. Значит, просели альфы «Команда» и «Определение системы»: разработчики не читают спецификацию и делают так, как сами предполагают. Это аффектит QA, потому что они получают много лишних багов, которые только отнимают время на оформление, перепроверку и т. д.
SEMAT в QA и не только
Что нужно QA? Чтобы стейкхолдеры (лид, менеджер, разработчики) были заинтересованы в процессе, а сам процесс был формализован и прозрачен. Техника SEMAT позволяет адаптировать альфы под себя, сохраняя общую концепцию методологии.
Поэтому в рамках QA на основе семи главных альф создаём свои локальные субальфы:
![](https://habrastorage.org/getpro/habr/upload_files/949/b5a/86f/949b5a86f064a608a6503276f17c7681.png)
-
Стейкхолдеры в QA. Клиент и вся команда проекта, за исключением команды QA.
-
Возможности. Определение качества сервиса на конкретном проекте (для другого проекта могут отличаться).
-
Определение системы. Всё то же техническое задание и спецификация.
-
Программная система. Всё программное и аппаратное обеспечение, которое задействуем в QA-процессе.
-
Команда. QA-команда.
-
Технологии. QA-технологии и практики, используемые методы проектирования тестов — эквивалентное разбиение, граничные значения и т. д.
-
Работа. Непосредственно QA-процесс.
Немного полезных советов:
-
Если вы QA Lead компании и отвечаете за несколько проектов, берите все семь субальф: если это возможно, то назначьте на каком-то одном проекте ответственного для проработки этого процесса.
-
Если вы локальный тимлид на проекте, выберите только те альфы, которые нужны по вашему мнению. Если не общаетесь со стейкхолдерами, уберите их, а сами сосредоточьтесь на команде.
-
Если вы тестировщик проекта, выберите несколько субальф, за которые непосредственно отвечаете, и работайте с ними. Например, субальфа «Технология» — то, на что вы объективно можете влиять.
Процесс QA живёт весь цикл разработки, так что эти субальфы проходят через весь жизненный цикл. Вот какие активности совершаются с субальфами на каждом этапе жизненного цикла:
![](https://habrastorage.org/getpro/habr/upload_files/125/584/907/12558490758394c88bb36328931ac9fa.png)
![](https://habrastorage.org/getpro/habr/upload_files/997/d25/fe4/997d25fe4b65736f117222fc362b4992.png)
Нужно, чтобы на каждом этапе субальфы проходили определённые состояния и нужным образом взаимодействовали друг с другом и внешним миром. На примере концепции посмотрим, что происходит с субальфами в QA.
На этапе концепции должны быть:
-
Определены стейкхолдеры.
-
Выявлены возможности тестирования.
-
Выявлены границы тестирования системы (например, какие виды тестирования будем применять, — да, это не всегда можно решить на начальном этапе, нужно исходить из особенностей проекта, но лучше сделать это как можно раньше).
-
Выбраны критерии качества сервиса или фичи (что должно быть — артефакты или состояния, которые считались бы удовлетворительными с точки зрения качества).
-
Определены участники QA-команды на проекте.
-
Определены критерии входа/выхода этапов процесса тестирования.
-
Определён перечень QA-практик (например, будет ли автоматизация).
Так метод SEMAT адаптируется и локализуется конкретно для вашего QA-процесса: для каждой субальфы получаем таблицу, по которой легко двигаться.
Для удобства можно для каждой субальфы составить карточку состояний, в котором она находится на конкретном жизненном этапе. На примере стейкхолдера выглядеть будет примерно так:
![Карточка состояний для субальфы «Стейкхолдеры» Карточка состояний для субальфы «Стейкхолдеры»](https://habrastorage.org/getpro/habr/upload_files/a0b/530/f22/a0b530f22d77b7ea1ec1eaf3a084777a.png)
Стейкхолдеры:
-
на этапе «Концепции» должны быть определены;
-
на этапах начиная с «Разработки ТЗ» и до последнего этапа поддержки должны быть включены в работу;
-
на последних двух этапах — «Развёртывание» и «Поддержка» — нам бы очень хотелось, чтоб они были удовлетворены результатом.
Пока стейкхолдеры не определены, эта субальфа заблокирована для перехода на следующий этап.
Можно ограничиться такими значениями состояний, а можно пойти дальше и расписать для себя и для проекта, что подразумевает каждое состояние. Например, состояние «определены» значит, что мы знаем, кто у нас стейкхолдер, и он знает, что он стейкхолдер, понимает свои обязанности и т. д. Расписывать такие подробности для всех субальф и этапов жизненного цикла — избыточно и индивидуально, поэтому на своём проекте вы можете взять эту карточку за основу и создать свои для своих процессов и проектов.
Преимущества SEMAT в QA
Их, кстати, тоже семь — как и альф.
-
Вы следите за ключевыми сущностями в своём процессе и точно знаете, когда и с кого вам следует получить нужные артефакты.
-
Процесс формализован, что особенно важно в гибких разработках, а также учитывая, что многие риски сваливаются на QA (например, авральное тестирование под конец проекта).
-
Вы заранее знаете, какие виды работ и какие практики вы примените на каждом из этапов.
-
Понимаете объём работ на каждом из этапов.
-
Есть критерии перехода на следующий этап.
-
Вы избежите одних и тех же ошибок (например, если всегда пропускаете этап статического тестирования).
-
Сводная таблица охватывает все аспекты QA.
Это делает процесс более понятным для неспециалистов в QA, с которыми мы работаем на одном проекте. Откройте доступ к таблице всем участникам проекта — и они будут знать, сколько операций требует от QA тот или иной этап. Принцип SEMAT помогает добавить прозрачности в общее дело, а значит, выигрывают все.
SEMAT в обычной жизни
Можно ли использовать принцип SEMAT в какой-нибудь другой сфере? Легко. Эту технику можно адаптировать даже к организации своей жизни. Предположим, вы решили встать на путь тотального саморазвития. Базово всё неплохо, резкие движения не нужны, но как и в QA — то мотивации не хватает, то времени, то зависишь много от кого. Можно немного формализовать этот процесс и добавить в него прозрачности.
Выделяем субальфы, которые важны для вас в вашей жизни, и что вас приведёт к некой своей улучшенной версии.
Например:
-
Комфортное общение с окружающими / коммуникативные навыки.
-
Интересы, хобби, досуг.
-
Семья, отношения.
-
Профессиональная жизнь.
-
Финансы.
-
Здоровье.
-
Что-то ещё, что важно лично для вас.
![Что делать с каждой из субальф Что делать с каждой из субальф](https://habrastorage.org/getpro/habr/upload_files/9fc/1ff/22b/9fc1ff22b4f1fc0320bceeeedd12ab90.png)
-
Коммуникация. Составить список своих багов в коммуникации с семьёй, партнёром и коллегами.
-
Досуг. Проанализировать увлечения и выявить самые приоритетные.
-
Семья/Отношения. Определить список родных, с кем хочется улучшить отношения, и как на это может повлиять работа с субальфой коммуникации.
-
Профессия. Составить список навыков и планов.
-
Финансы. Посчитать, сколько есть, сколько нужно ежемесячно, ежегодно, в запасе, через пять лет.
-
Здоровье. Пройти чекап и проанализировать, хватит ли физических сил на досуг, профессиональный рост и улучшение коммуникации с другими людьми.
Полезные материалы
Список со всеми статьями, которые я использовала при подготовке и изучении концепции SEMAT, — для тех, кто хочет сильнее погрузиться в тему.
-
Использование SEMAT для управления ИТ-проектами в госсекторе
-
Как за две недели освоиться с реальным проектом: стандарт OMG Essence
Над материалом работали:
-
текст — Оля Ерина,
-
редактура — Ника Черникова, Виталик Балашов,
-
иллюстрации — Петя Галицкий.
ссылка на оригинал статьи https://habr.com/ru/articles/822673/
Добавить комментарий