Почему требований нет (и это нормально).
Думаю, каждому читателю‑тестировщику знакома картина, когда ты приходишь на работу, завариваешь кофе, садишься за Jira, а там на тест упала задача, в которой из контекста только название. Причем что‑то вроде «Улучшить авторизацию».
Требования очень редко полностью попадают под характеристики:
полные
измеримые
прослеживаемые
тестируемые и тд
Гораздо чаще мы имеем дело с запросом от бизнеса в формате «сделайте чтобы работало», а дальше PO (Product Owner) передает аналитикам, аналитики прорабатывают, разработчики пишут на основе этого. И не всегда в конечном продукте переговоров, доходящем до разработчика, прослеживается 1в1 связь с тем, что хочет заказчик, потому что о чем‑то не подумали, где‑то не поняли, а где‑то разработчик сделал как привык. И тогда важные части могут быть упущены, а доп требования появятся только на этапе тестирования
Явные и неявные требования
Все требования, которые прошли через РО‑аналитика‑разработчика и пришли ко мне, я делю на явные и неявные. Допустим описание таски или страничка в Confluence — это явные требования. А когда ты зарываешься носом под капот продукта и видишь, что какой‑то функционал не описан, то это не значит, что требований нет. Они с вероятностью 99% есть у бизнеса, просто для команды разработки они неявные. И тут самое время начинать ходить по всем и спрашивать все. Мечта интроверта, идущего в ИТ, чтобы не общаться с людьми, сбылась на этом моменте.
Правило № 1: закрытые вопросы
Самое главное правило общения с людьми, которое я вывела для себя — задавай закрытые вопросы. Иначе при попытке выяснить одну маленькую деталь поведения рискуешь выслушать очень длинную и, безусловно, интересную, но занимающую полчаса лекцию о работе продукта. А нужно быстрое да‑да нет‑нет.
Так вот — вопросы в формате «пост после создания попадает куда?» мы вычеркиваем. Вместо этого ходим с козырей — «Пост после создания попадает в фид пользователя, сообщества или и туда и туда?».
Чувствуете разницу? А она есть.
Правило № 2: Показ лучше слов
Второе главное правило — рисовать схемы и задавать вопросы наглядно. Например ниже таблица перехода состояний заказа. Когда ты просто заходишь к человеку в созвон и спрашиваешь «Что будет, если создаем заказ на 500 р, выходит автоматический ассоциированный с заказом пост, на него пожаловалось 20 пользователей? Снимаем же с публикации? А если поста нет, а пожаловаться хочется?»
Для таких ситуаций мы рисуем таблицы перехода состояний со всеми вероятными и невероятными событиями, которые только могут быть. Есть очень большой шанс того, что после окончания сего творчества появится пул вопросов, которые повторяются от сценария к сценарию. В итоге нужному человеку ты задашь один вопрос вместо десяти, то есть сэкономишь ему и себе время, не погружая коллегу в лишний контекст.
Правило №3: Полное покрытие
Третье правило вытекает из первого, только здесь мы не рисуем, а чертим. Речь о таблице CRUD операций, и применим такой подход скорее к бековским операциям. Конечно, самые критичные сценарии разработчики всегда покроют, то есть тот, кому нельзя Х, не сможет этого сделать, API скорее всего будет устойчива к SQL инъекциям и тд. Однако учитывать каждый граничный сценарий не их работа, и поэтому составление подобных CRUD таблиц очень даже помогает не то что при тестировании, а иногда даже в разработке. Бывает, что что‑то подобное я предлагаю беку перед тестированием с вопросом «как думаешь это все покрыто и я могу тестить или еще допишем?». После пары таких диалогов ребята из команды бека тегают меня еще на этапе постановки задачи им и просят сразу предоставить подобный чеклист.
Роль | Create | Read | Update | Delete | Условия |
|---|---|---|---|---|---|
Пользователь | 200 - свои | 200 - свои | 200 - свои | 200 - свои | Только свои посты |
Модератор | 403 | 200 | 200 | 200 | При наличии жалоб |
Администратор | 200 | 200 | 200 | 200 | Без ограничений |
Заключение + Правило №4: Оставь работу соседу
Это были три выведенных мной паттерна работы в отсутствие требований. Последнее, что хочу сказать на эту тему — правку требований лучше оставлять аналитикам. Это не про то, что тестировщик слишком хорош, чтобы писать требования, а про то, что у аналитиков как правило есть распределение по фичам, и хозяин фичи Х более чем хотел бы быть в курсе того, что происходит. А если требования будут уже описаны, то как будто лишний хаос постучится в дверь вашей команды, а мы ведь так старались этого избежать, применяя первые 3 шага.
Итого — если требований нет, то это рабочий момент, а не масштабная проблема, с которым, я надеюсь, стало проще работать.
