Мы уже знаем, по каким свойствам оценивать требования. Теперь — как организована сама проверка: какие есть техники, как формулировать вопросы, на которые отвечают по существу, и как работать с чужим документом, не наживая врагов. Последнее звучит как мелочь, но именно на этом новички чаще всего обжигаются.
Требование с оценочным словом «быстро» прогоняют тремя вопросами. Первый пробует построить по нему проверку и упирается в пустой ожидаемый результат; второй проходит сценарий и находит, что конец запуска не определён; третий показывает, что расплывчатый вопрос возвращает такой же ответ. Три находки складываются в один вопрос, ответ на который делает требование проверяемым.
Три формы ревью
Взаимный просмотр (peer review) — главная техника проверки требований. По нарастанию формальности:
- Беглый просмотр (walkthrough). Автор показывает документ коллегам, собирает вопросы и замечания. Как проверить сочинение друг у друга перед сдачей: быстро, дёшево, ловит очевидное. Самая частая форма — большинство ревью задач в командах именно такие.
- Технический просмотр (technical review). Документ смотрит группа специалистов, каждый — со своей стороны: тестировщик ищет непроверяемое, разработчик — нереализуемое, аналитик — противоречия с соседними задачами. Документ не считается готовым, пока у кого-то остаются замечания. Как договор, который визируют юристы и бухгалтерия.
- Формальная инспекция (inspection). Структурированный, документируемый процесс с ролями и протоколом. Дорого, долго, применяется редко — например, когда команда принимает на поддержку чужой продукт и должна вычитать всю его документацию. Как генеральная уборка: не каждый день, но иногда необходимо.
Для новичка практический вывод: когда вам присылают задачу «глянь требования» — это walkthrough, и от вас ждут не «всё ок», а вопросов и замечаний.
Приём: придумай проверку
Самый рабочий способ протестировать требование — попытаться придумать по нему чек-лист или тест-кейс. Логика простая: хорошее требование проверяемо, значит, проверки должны сочиняться легко.
- Проверки придумались сразу — с требованием, скорее всего, порядок (но сверьте его с соседними: противоречия так не ловятся).
- Идей нет вообще — тревожный знак. Сначала убедитесь, что вы поняли требование: перечитайте соседние, спросите коллег. Не помогло — проблема не в вас, а в требовании.
Родственный приём — мысленная прогулка по системе: представьте, что вы пользователь и выполняете задачу по этим требованиям, шаг за шагом. Там, где «прогулка» спотыкается («а что система покажет здесь?», «а откуда возьмётся это значение?»), — дыра, которую не видно при чтении требований по одному.
Плохой вопрос против хорошего
Вопрос — главный инструмент улучшения требований, и его качество решает всё. Плохой вопрос провоцирует бесполезный ответ.
Требование: «Приложение должно быстро запускаться».
- Плохо: «Насколько быстро?» — получите «ну… быстро» или наугад названную цифру.
- Плохо: «А если не получится быстро?» — получите раздражение.
- Хорошо: «Какое время запуска считаем допустимым? На каком оборудовании? Что считаем моментом окончания запуска — появление окна или готовность к работе?» — получите данные для конкретного, проверяемого требования.
Требование: «Если дата события не указана, она выбирается автоматически».
- Плохо: «А если указана?» — то она указана, вам ответят тем же.
- Хорошо: «Возможно, имелось в виду, что дата генерируется, а не выбирается? Если да — по какому алгоритму? Если нет — из какого набора выбирается? Может, просто брать текущую дату?» — вы показали неоднозначность и предложили путь.
Общий принцип: хороший вопрос сформулирован так, что ответ на него позволяет улучшить требование. Перед отправкой перечитайте вопрос и спросите себя: что я смогу сделать с ответом?
Три вида вопросов, которые выдают новичка: вопрос от незнания азов («а что такое чек-бокс?» — это гуглится, а не спрашивается); «что такое X?» вместо «что вы имеете в виду под X?»; и «а что будет, если мы этого не сделаем?» — ничего не будет, вы это точно сделаете, вопрос должен быть другим.
Правила работы с чужим документом
Требования — чей-то труд, и от того, как вы оформите замечания, зависит, услышат ли их вообще.
- Не меняйте формат и структуру документа. Перенести текст в свою табличку, «переписать по-человечески», сохранить в PDF — значит уничтожить чужую работу и историю изменений. Замечания оставляют средствами документа: комментарии, режим правок.
- Не редактируйте требования втихую. Молча исправленное требование автор не заметит — а потом продукт реализуют не так, как он задумал. Любая правка — явно помеченная, и лучше как предложение, а не как свершившийся факт.
- Привязывайте замечание к месту. Комментарий «есть противоречия» без указания, где именно, бесполезен. Нашли противоречие между требованиями 20 и 30 — пометьте оба и поясните суть.
- Не отмечайте «здесь всё хорошо». Пометки без проблемы только шумят: становится труднее найти замечания, которые требуют действий.
- Критикуйте требование, не автора. «Неужели непонятно, как глупо это звучит» — недопустимо. «Это невозможно» без обоснования — тоже: переформулируйте в вопрос: «Мы сомневаемся, что эта функция будет востребована. Какова важность этого требования?»
- Пишите коротко. Страница требований, обросшая двадцатью страницами комментариев, — это провал: на ранних стадиях требования нестабильны, и ваш трактат устареет раньше, чем его дочитают.
Где это применяется
Ревью требований — не отдельная церемония, а часть обычного цикла: обсуждение задачи на планировании, комментарии в задаче, вопросы аналитику в чате. Тестировщик, чьи вопросы улучшают задачи, быстро становится тем, кого зовут на обсуждения до начала разработки — а это самая ценная позиция в команде.
Где спотыкаются начинающие:
- Отмалчиваются на ревью — «я тут недавно, кто я такой, чтобы задавать вопросы». Свежий взгляд как раз и ловит то, к чему остальные привыкли.
- Задают вопросы, на которые нельзя ответить полезно — «а это точно нужно?», «насколько быстро?». Перечитывайте свои вопросы глазами отвечающего.
- Правят чужой документ как свой. Даже из лучших побуждений: исправленное без пометки — потерянное.
Коротко
- Беглый просмотр — повседневная форма ревью: от вас на нём ждут вопросов и замечаний, а не «всё ок».
- Требование тестируют попыткой построить по нему проверку: не сочиняется чек-лист — дело в требовании, а не в читателе.
- Мысленная прогулка по сценарию ловит дыры между требованиями — там, где непонятно, что система покажет дальше.
- Хороший вопрос измеряется ответом: если с ответом нельзя улучшить требование, вопрос переписывают.
- Замечание привязывают к месту и оставляют средствами документа; молча исправленное требование — потерянное.
- Пометки «здесь всё хорошо» и двадцать страниц комментариев мешают одинаково: нужные замечания в них тонут.
Что почитать дальше
- Уровни и свойства требований — по каким признакам видно, что требование плохое.
- Тестирование по требованиям — откуда требования берутся и как за ними следят.
- Как писать тест-кейс — та самая проверка, которой мы тестируем требование.
- Техники тест-дизайна — как из проверенного требования получаются проверки.