В книжках для аналитиков иногда пишут, что написанные требования к системе неплохо бы протестировать до того, как отдавать в разработку. Делают это, конечно же, единицы – не все вообще знают, что так можно, поджимают сроки, нет бюджета, сложность закупочной процедуры нивелирует пользу и т.д.
Так что этот пост для тех, кто этого никогда не делал, но давно хотел попробовать.
Давайте сначала про самое главное – тестирование требований — это НЕ требования к тестированию! А то я несколько раз видела, что эти понятия путают несмотря на то, что они очень далеки друг от друга.
Цель тестирования требований – выявить проблемы и устранить противоречия в них еще до начала разработки и избежать дорогостоящих доработок и изменений на поздних этапах проектов.
В идеале, конечно, отдавать требование на тестирование стороннему подрядчику (особенно если разработка тоже не внутренняя, а силами подрядчика), но если такой возможности нет – сойдет и внутренний тестировщик или бизнес-аналитик.
Что проверяется при тестировании требований
В рамках процесса тестирования бизнес-аналитик или тестировщик проверяют следующие аспекты требований:
- Структуру документа на соответствие утвержденному шаблону;
- Отсутствие дублирования требований в различных разделах документа;
- Соответствие требований бизнес-правилам: законодательные акты, нормативы, стандарты, правила, описанные бизнес-процессы и др.;
- Однозначность интерпретации требований;
- Достаточность детализации задокументированных требований: детальное текстовое описание элементов интерфейса системы либо наличие прототипов/макетов пользовательского интерфейса системы;
- Отсутствие противоречий между текстовым описанием элементов интерфейса, вариантами использования, прототипами/макетами пользовательского интерфейса системы, моделями данных и/или бизнес-процессов.
Также, конечно, проверяется наличие и полнота описания:
- перечня классов и ролей пользователей системы и их характеристик;
- требований к реализации в системе всех возможных сценариев протекания автоматизируемого бизнес-процесса (альтернативных/исключительных);
- требований к проверке корректности вводимых данных (автоматическая валидация);
- требований к поведению системы при прерывании либо изменении направления выполнения шагов процесса (возврат к предыдущему шагу, закрытие окна и др.);
- всех сущностей данных с указанием необходимого набора атрибутов для каждой;
- всех возможных состояний/статусов сущностей данных и условия перехода между ними; • требований при работе со списками сущностей данных;
- требований к взаимодействию с внешними системами.
В результате тестирования требований у вас могут появиться следующие артефакты:
- Реестр замечаний, содержащий перечень выявленных в требованиях проблем. Для каждой из них указывается ее уникальный номер, дата выявления, автор, раздел документа, в котором она обнаружена, суть проблемы, тип проблемы, критичность и т.д.
- Перечень предложений по улучшению разрабатываемой системы, если таковые будут – например, добавить требования к дизайну, сделать этап прототипирования и проч.
- Перечень предложений по улучшению подхода к документированию требований в компании в целом – например, присвоение кодировки, соблюдение гранулярности, степень детализации, подход к описанию НСИ и проч.
К слову о типе проблемы – возможные типы, которые должны быть выявлены в результате тестирования, имеет смысл проговорить с исполнителем заранее, чтобы он лучше понимал ваши ожидания (например, кому-то приоритетен поиск противоречий и ошибок, а кто-то считает нужным включить также поиск опечаток, получение рацпредложений по структурированию и проч.). Так как тестирование требований – редкая вещь, почти как снежный барс (все слышали, но никто не видел) – формализованных подходов к такому тестированию даже на рынке профессионального QA не очень много, поэтому лучше все обозначить на берегу.
Пример реестра замечаний по итогам тестирования требований
Ниже скрин из одного из моих старых отчетов по тестированию требований, уже не под NDA.
Тоже делаю это тестирование не всегда, но стараюсь все-таки впихнуть в проект, если на это есть время и деньги.
Как выбрать подрядчика для тестирования требований (и для тестирования вообще)
Ну для начала – просто спросите, какой у него опыт в этой отрасли тестирования. С большой вероятностью вам скажут какую-нибудь расплывчатую вещь типа «да, что-то подобное делали, уточню у коллег, можем сделать, конечно», что можно однозначно интерпретировать как «неа, не умеем, но с удовольствием отдадим джуну почитать, а с вас возьмем денег как за команду сеньоров». Понятно, что тогда лучше требования самому под бокал вина почитать вечером, толку будет больше.
Если подрядчик вопроса не испугается и выдаст что-то более осмысленное – то стоит попросить пример реестра замечаний и предложений и оценить его на соответствие тому, что вы ждете от тестирования. Часто это будет несколько листочков с притянутыми за уши рекомендациями «надо делать хорошо и по Вигерсу, а плохо делать не надо». Тоже не стоит связываться.
А вот если реестр вдохновляет детализацией, в рекомендациях – конкретика, а пример вам дали не через неделю (как только нарисовали его на коленке), а вот прямо в течение дня – с этим подрядчиком можно попробовать поработать.
Причем с большой вероятностью это будет очень-очень-очень хороший подрядчик с высоким уровнем организации процессов (раз уже до тестирования требований дорос), по крайней мере, в моем опыте это было так.
В общем, тестирование требований – отличный инструмент, который может сэкономить много часов и нервов, остается сущая ерунда – убедить заказчика и спонсора включить эти работы в проект.
Как-то так.
Как считаете, полезно? Используете тестирование требований в своих проектах?
Добавить комментарий