Почему требований нет (и это нормально).

Думаю, каждому читателю‑тестировщику знакома картина, когда ты приходишь на работу, завариваешь кофе, садишься за Jira, а там на тест упала задача, в которой из контекста только название. Причем что‑то вроде «Улучшить авторизацию».

Требования очень редко полностью попадают под характеристики:

полные
измеримые
прослеживаемые
тестируемые и тд

Гораздо чаще мы имеем дело с запросом от бизнеса в формате «сделайте чтобы работало», а дальше PO (Product Owner) передает аналитикам, аналитики прорабатывают, разработчики пишут на основе этого. И не всегда в конечном продукте переговоров, доходящем до разработчика, прослеживается 1в1 связь с тем, что хочет заказчик, потому что о чем‑то не подумали, где‑то не поняли, а где‑то разработчик сделал как привык. И тогда важные части могут быть упущены, а доп требования появятся только на этапе тестирования

Явные и неявные требования

Все требования, которые прошли через РО‑аналитика‑разработчика и пришли ко мне, я делю на явные и неявные. Допустим описание таски или страничка в Confluence — это явные требования. А когда ты зарываешься носом под капот продукта и видишь, что какой‑то функционал не описан, то это не значит, что требований нет. Они с вероятностью 99% есть у бизнеса, просто для команды разработки они неявные. И тут самое время начинать ходить по всем и спрашивать все. Мечта интроверта, идущего в ИТ, чтобы не общаться с людьми, сбылась на этом моменте.

Правило № 1: закрытые вопросы

Самое главное правило общения с людьми, которое я вывела для себя — задавай закрытые вопросы. Иначе при попытке выяснить одну маленькую деталь поведения рискуешь выслушать очень длинную и, безусловно, интересную, но занимающую полчаса лекцию о работе продукта. А нужно быстрое да‑да нет‑нет.

Так вот — вопросы в формате «пост после создания попадает куда?» мы вычеркиваем. Вместо этого ходим с козырей — «Пост после создания попадает в фид пользователя, сообщества или и туда и туда?».

Чувствуете разницу? А она есть.

Правило № 2: Показ лучше слов

Второе главное правило — рисовать схемы и задавать вопросы наглядно. Например ниже таблица перехода состояний заказа. Когда ты просто заходишь к человеку в созвон и спрашиваешь «Что будет, если создаем заказ на 500 р, выходит автоматический ассоциированный с заказом пост, на него пожаловалось 20 пользователей? Снимаем же с публикации? А если поста нет, а пожаловаться хочется?»

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

Пример выявления скрытых требований - что делать, если шумит гость с чеком ниже 200 USD?

Правило №3: Полное покрытие

Третье правило вытекает из первого, только здесь мы не рисуем, а чертим. Речь о таблице CRUD операций, и применим такой подход скорее к бековским операциям. Конечно, самые критичные сценарии разработчики всегда покроют, то есть тот, кому нельзя Х, не сможет этого сделать, API скорее всего будет устойчива к SQL инъекциям и тд. Однако учитывать каждый граничный сценарий не их работа, и поэтому составление подобных CRUD таблиц очень даже помогает не то что при тестировании, а иногда даже в разработке. Бывает, что что‑то подобное я предлагаю беку перед тестированием с вопросом «как думаешь это все покрыто и я могу тестить или еще допишем?». После пары таких диалогов ребята из команды бека тегают меня еще на этапе постановки задачи им и просят сразу предоставить подобный чеклист.

Роль	Create	Read	Update	Delete	Условия
Пользователь	200 - свои 400 - чужие	200 - свои 200 - чужие	200 - свои 400 - чужие	200 - свои 400 - чужие	Только свои посты
Модератор	403	200	200	200	При наличии жалоб
Администратор	200	200	200	200	Без ограничений

Заключение + Правило №4: Оставь работу соседу

Это были три выведенных мной паттерна работы в отсутствие требований. Последнее, что хочу сказать на эту тему — правку требований лучше оставлять аналитикам. Это не про то, что тестировщик слишком хорош, чтобы писать требования, а про то, что у аналитиков как правило есть распределение по фичам, и хозяин фичи Х более чем хотел бы быть в курсе того, что происходит. А если требования будут уже описаны, то как будто лишний хаос постучится в дверь вашей команды, а мы ведь так старались этого избежать, применяя первые 3 шага.

Итого — если требований нет, то это рабочий момент, а не масштабная проблема, с которым, я надеюсь, стало проще работать.

Если требований нет, а тестировать хочется