Errare humanum est sed stultum est in errore perseverare
Если человека, близкого к айти (не тестировщика), спросить, какие виды тестирования он знает, он, скорее всего, ответит:
- Смоук тестирование;
- Функциональное тестирование;
- Регрессионное тестирование;
- Интеграционное тестирование;
- Тестирование производительности;
- Тестирование безопасности;
- Юзабилити-тестирование;
- Приёмочное тестирование;
- Модульные тесты;
- Автоматические тесты.
На этом, обычно, всё. Потому что тестировать надо продукт. Но на самом деле, есть такая qa-шная компетенция как тестирование требований. Это одна из причин, по которым тестировщиков есть смысл подключать на ранних этапах, когда требования уже более-менее написаны, но разработка ещё не стартовала.
Основная цель тестирования требований — устранение в них логических противоречий.
В рамках процесса тестирования бизнес-аналитик или тестировщик (а лучше — специально нанятый подрядчик) проверяют следующие аспекты требований:
- Соответствие артефактов требований принятым в компании шаблонам;
- Отсутствие дубликатов требований в разных разделах;
- Однозначность формулировок требований, отсутствие разночтений;
- Достаточность детализации требований: насколько полны текстовые описания, есть ли вайрфреймы или прототипы;
- Отсутствие противоречий между юзкейсами и вайрфреймами-прототипами.
- Отсутствие орфографических ошибок и опечаток (хорошая практика — если тестировщик находит три ошибки или опечатки, документ считается неготовым и возвращается аналитику).
Также, конечно, проверяется наличие и полнота описания:
- Перечня системных сущностей и ролей;
- Наличие и полнота описания альтернативных потоков;
- Требования к валидации и экранированию вводимых данных (вы же не хотите схлопотать SQL-инъекцию?);
- Наличие требований к поведению системы, вызванному пользовательскими действиями, такими как нажатие «Назад» в браузере, перезагрузка окна;
- Все ли состояния всех сущностей описаны, есть ли описания всех переходов из одного статуса в другой;
- Требования к интеграции с внешними системами. Чаще всего, баги возникают именно в этих точках.
В результате должны получиться такие артефакты:
- Набор замечаний к требованиям. Лучше реализовывать его не в виде отдельного реестра, чтобы не разводить бюрократию, а в виде комментарий к документами. Конфлю, Ноушен, гуглодоки, все эти инструменты поддерживают инлайн-комментарии.
- Предложения по улучшению разрабатываемой системы. Всё, что упустил (по мнению тестера) аналитик и что было бы неплохо добавить, пока мы не зафиксировали оценку (при работе по ватерфолу, по скраму не так критично).
- Предложения по корректировке процессов работы с требованиями и артефактам аналитики в целом, в компании.
В целом, будет здорово, если пиэм, аналитик и тестировщик заранее договорятся, какие именно аспекты требований имеет смысл тестировать особенно тщательно и в каком виде подавать замечания.
Также нужно договориться, нужна ли презентация тестировщиком замечаний. Например, в одной компании я сталкивался с церемонией «рекваймент-ревью». Тестеры оффлайново изучали требования, потом рассказывали о найденных замечаниях на очной встрече, замечания тут же фиксировались.
Процедура тестирования требований особенно полезна в контексте особого «разрушительного» мышления тестировщиков. Если пиэм, разрабы и аналитики мыслят категориями «хоть бы работало», тестер думает: «как бы это сломать». Это мышление позволяет находить несостыковки там, где люди с «созидательным» мышлением их не видят, порождая риски.
