На основании чего вы тестируете свой продукт? Или управление требованиями к ПО 101

По мере того как компания росла, на работу поступало все больше людей, привыкших к традиционному процессу разработки. Однажды ко мне пришла начальница другой команды и сказала: «Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете». «Нет проблем, – ответил я, – только расскажите мне, для кого мы делаем эти изменения и какие задачи люди будут решать с их помощью». Что я услышал в ответ? «Это нужно для соответствия требованиям». «Я вас понял, – кивнул я. – Мне только нужно знать подробнее, для кого мы внедряем эти штуки, как эти люди будут их использовать, а также какой этап их рабочего процесса изменится». Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом: «Это. Для. Соответствия. Требованиям». И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись». Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить.
—Джефф Паттон — «Пользовательские истории»

Цитата выше очень злободневная, но даже она отражает лишь часть проблемы. Удивительно, но факт — в двух из трёх компаниях, в разработке пяти из шести программных продуктов, с которыми мне довелось иметь дело, про требования вообще не задумывались. Либо применяли что-то похожее на эту концепцию к отдельным, наиболее ярко выраженным частям (как правило, базовый функционал продукта) и только на отдельных этапах. Как результат, изрядная часть продукта развивается хаотично, накапливает избыточные элементы или, наоборот, недоделки, наращивает техдолг, а значительную часть усилий команда прикладывает не к тому, что на самом деле важно.

Дальнейший мой спич имеет целью небольшой ликбез в части важности управления требованиями в разработке ПО. Учебник Вигерса заменить не претендую, но и ориентируюсь не столько на бизнес-/системных аналитиков, сколько на остальных участников — разработчиков и QA. Хотя если у аналитиков всплывёт что-то в памяти или возникнет потребность что-то добавить — тоже неплохой результат.

Ещё одна грань — на основании собеседований десятков инженеров по тестированию (QA инженеров) и ответам на вопрос «На основании чего вы проводите тестирование?» могу выделить регулярно повторяющиеся дисфункции проверки качества:

на основании того, что говорят программисты (то есть на любой результат программист может сказать «так и было задумано»?);
на основании здравого смысла. Неплохо, но эта штука — здравый смысл — бывает такой субъективной;
на основании описания фичи/таски — пожалуй, самый неплохой вариант. Если верить, что описание содержало всю ключевую информацию. Чаще всего дальнейшая беседа показывает, что нет, не содержала. И возвращаемся к первому пункту.

Всё же есть негативные факторы узкой специализации, и один из них — отрыв от общей картины процесса. С этой стороны у меня и к аналитикам на собеседованиях возникает много вопросов, потому что в большинстве случаев зона ответственности заканчивается на «собрал требования — отнёс в разработку». Ещё и описал «в свободной форме».

Что есть требование к программному обеспечению?

Если вкратце, это какое-то конкретное описание потребности клиента.

Если согласно IEEE, то:

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

Управление требованиями

Ниже представлен упрощённый жизненный цикл.

Выявление требований

Часто фигурирует как «сбор требований». Но стоит хорошо понимать разницу между сбором и выявлением. Сбор требований — это прийти к заказчику, спросить чего он хочет, тщательно (или как-то) задокументировать ответы, вернуться с результатами. Выявление требований — это определение истинных потребностей заказчика. Первый вариант в моменте минимально энергозатртаный, но есть немалая вероятность, что по итогам цель заказчика не будет достигнута, он сам не будет удовлетворён, а продукт обрастёт ненужным функционалом, и станет немного тяжелее в поддержке и сопровождении.

Выявлять требования и определять реальные потребности непросто. Ведь приходится ставить под сомнения хотелки и докапываться до ответа на вопрос «Какую проблему решаем?». Люди не любят, когда их идеи и решения ставят под сомнение. Но, как говорил мой учитель по проектированию автоматизированных систем в далёком 200х году «Нет проблемы — нет системы». И в большинстве случаев такой ответ будет мудрым решением, экономящим время, деньги, нервы…

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

Представление требований

Здесь происходит описание того, что выявили на предыдущем этапе и приведение к виду, позволяющему делать продукт. Это могут быть спецификации, сценарии использования (Use Cases), пользовательские истории (User Stories), сториборды (Storyboards) и любой другой приемлемый для разработчиков формат.

Приоритезация требований

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

Лично для меня простыми и разумными кажутся

система определения приоритетов WSJF (Weghted Shortest Job First)

система указания приоритетов MoSCoW (Must have, Should have, Could have, Would/Won’t have)

Анализ требований

Тут происходит проверка требований на то, что они ясные, полные и консистентные (не противоречат другим требованиям). Фаза полезна тем, что выявление «багов» на этом этапе сильно дешевле и проще к устранению, чем на этапе разработки (когда внезапно возникает вопрос «А что тут имеется ввиду?») и уж тем более на продакшене (когда выясняется, что сделали не то, потому что поняли не так. Или новая фича заблокировала старую).

Валидация требований

И вот когда продукт, система, компонент или отдельная фича реализованы, стоит проверить, насколько соответствует то, что мы сделали тому, что требовалось.

Другими словами тестирование ПО происходит, по логике, на основании требований к ПО.

И более того, валидация должна предполагать не только проверку того, сделали ли мы то, что планировали, но и добились ли мы предполагаемой цели. То есть не техническая, а бизнесовая валидация должна происходить. Но такое встречается гораздо реже, чем техническая.

Типы требований

Бизнес-требования — по сути определяют собой цель проекта. Например, «снизить количество ошибок на 25% чтобы поднять ревенью на $10000».
Бизнес-правила — ограничения со стороны бизнеса (регуляторы, безопасность, имидж бренда).
Пользовательские требования — задачи, решаемые пользователем при помощи продукта.
Функциональные требования — поведение продукта. От пользовательских отличает то, что требования могут быть к входам/выходам отдельных компонент или модулей.
Нефункциональные требования (требования к качеству) — определяют, насколько хорошо продукт выполняет свои задачи (производительность, безопасность, стабильность, удобство интерфейса и т.д.).
Физические ограничения — ограничения физического мира. Если мы делаем продукт, который должен будет работать под водой или в условиях экстремальных температур, стоит это учитывать.
Ограничения разработки — технологии, лимиты по памяти/CPU, ограничения каких-то процессов, архитектуры и принятых правил и регламентов.

Заключение

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

Особенно людям, которые отвечают за качество, стоит помнить, что «качество — это степень соответствия присущих характеристик требованиям» (ISO 9001).

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