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

Три формы ревью

Взаимный просмотр (peer review) — главная техника проверки требований. По нарастанию формальности:

  • Беглый просмотр (walkthrough). Автор показывает документ коллегам, собирает вопросы и замечания. Как проверить сочинение друг у друга перед сдачей: быстро, дёшево, ловит очевидное. Самая частая форма — большинство ревью задач в командах именно такие.
  • Технический просмотр (technical review). Документ смотрит группа специалистов, каждый — со своей стороны: тестировщик ищет непроверяемое, разработчик — нереализуемое, аналитик — противоречия с соседними задачами. Документ не считается готовым, пока у кого-то остаются замечания. Как договор, который визируют юристы и бухгалтерия.
  • Формальная инспекция (inspection). Структурированный, документируемый процесс с ролями и протоколом. Дорого, долго, применяется редко — например, когда команда принимает на поддержку чужой продукт и должна вычитать всю его документацию. Как генеральная уборка: не каждый день, но иногда необходимо.

Для новичка практический вывод: когда вам присылают задачу «глянь требования» — это walkthrough, и от вас ждут не «всё ок», а вопросов и замечаний.

Приём: придумай проверку

Самый рабочий способ протестировать требование — попытаться придумать по нему чек-лист или тест-кейс. Логика простая: хорошее требование проверяемо, значит, проверки должны сочиняться легко.

  • Проверки придумались сразу — с требованием, скорее всего, порядок (но сверьте его с соседними: противоречия так не ловятся).
  • Идей нет вообще — тревожный знак. Сначала убедитесь, что вы поняли требование: перечитайте соседние, спросите коллег. Не помогло — проблема не в вас, а в требовании.

Родственный приём — мысленная прогулка по системе: представьте, что вы пользователь и выполняете задачу по этим требованиям, шаг за шагом. Там, где «прогулка» спотыкается («а что система покажет здесь?», «а откуда возьмётся это значение?»), — дыра, которую не видно при чтении требований по одному.

Плохой вопрос против хорошего

Вопрос — главный инструмент улучшения требований, и его качество решает всё. Плохой вопрос провоцирует бесполезный ответ.

Требование: «Приложение должно быстро запускаться».

  • Плохо: «Насколько быстро?» — получите «ну… быстро» или наугад названную цифру.
  • Плохо: «А если не получится быстро?» — получите раздражение.
  • Хорошо: «Какое время запуска считаем допустимым? На каком оборудовании? Что считаем моментом окончания запуска — появление окна или готовность к работе?» — получите данные для конкретного, проверяемого требования.

Требование: «Если дата события не указана, она выбирается автоматически».

  • Плохо: «А если указана?» — то она указана, вам ответят тем же.
  • Хорошо: «Возможно, имелось в виду, что дата генерируется, а не выбирается? Если да — по какому алгоритму? Если нет — из какого набора выбирается? Может, просто брать текущую дату?» — вы показали неоднозначность и предложили путь.

Общий принцип: хороший вопрос сформулирован так, что ответ на него позволяет улучшить требование. Перед отправкой перечитайте вопрос и спросите себя: что я смогу сделать с ответом?

Три вида вопросов, которые выдают новичка: вопрос от незнания азов («а что такое чек-бокс?» — это гуглится, а не спрашивается); «что такое X?» вместо «что вы имеете в виду под X?»; и «а что будет, если мы этого не сделаем?» — ничего не будет, вы это точно сделаете, вопрос должен быть другим.

Правила работы с чужим документом

Требования — чей-то труд, и от того, как вы оформите замечания, зависит, услышат ли их вообще.

  • Не меняйте формат и структуру документа. Перенести текст в свою табличку, «переписать по-человечески», сохранить в PDF — значит уничтожить чужую работу и историю изменений. Замечания оставляют средствами документа: комментарии, режим правок.
  • Не редактируйте требования втихую. Молча исправленное требование автор не заметит — а потом продукт реализуют не так, как он задумал. Любая правка — явно помеченная, и лучше как предложение, а не как свершившийся факт.
  • Привязывайте замечание к месту. Комментарий «есть противоречия» без указания, где именно, бесполезен. Нашли противоречие между требованиями 20 и 30 — пометьте оба и поясните суть.
  • Не отмечайте «здесь всё хорошо». Пометки без проблемы только шумят: становится труднее найти замечания, которые требуют действий.
  • Критикуйте требование, не автора. «Неужели непонятно, как глупо это звучит» — недопустимо. «Это невозможно» без обоснования — тоже: переформулируйте в вопрос: «Мы сомневаемся, что эта функция будет востребована. Какова важность этого требования?»
  • Пишите коротко. Страница требований, обросшая двадцатью страницами комментариев, — это провал: на ранних стадиях требования нестабильны, и ваш трактат устареет раньше, чем его дочитают.

Где это применяется

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

Где спотыкаются начинающие:

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

Что учить дальше. Свойства, по которым оценивают требования, — в предыдущей статье; как из проверенных требований рождаются проверки — в статьях про тест-кейсы и техники тест-дизайна.