Как действовать тестировщику или разработчику, когда требования к функциональности не описаны или размыты?

А, ну это же классика, блядь! Работа с неполными требованиями — это как пытаться собрать шкаф из Икеи, когда половину инструкции кот сожрал, а вторую половину тебе надиктовали по телефону, пока ты в метро ехал. Но, сука, живём же как-то!

Вот, смотри, как обычно выкручиваемся, чтобы не остаться крайним, когда всё пиздец как накроется.

1. Первым делом — не молчи, как Герасим, блядь!

• Собери всех, кто хоть как-то в теме, на быструю пиздюлину. Продакт, аналитик (если он, конечно, не мифический зверь), разработчики. Цель — не заседание на три часа, а быстро накидать, что за фигню мы вообще хотим сделать. Хоть какие-то истории пользователя или сценарии.
• Вспомни про «Трёх амигос». Это когда за одним столом садятся представитель от разработки (чтобы сразу сказать, что нереально), от тестирования (чтобы спросить «а что если…») и от бизнеса (чтобы объяснить, зачем это всё). Идея — выебать из них хоть какую-то внятную картину.

2. Копайся в том, что уже есть, как старая маньячка в чужом мусоре.

• Посмотри, как у других. Конкуренты, старые версии системы — там могут быть подсказки, как это должно работать в принципе.
• Залезь в код, если доступ есть. Иногда логика и все ограничения уже сидят там, просто про них все забыли. Разработчики — они как те немые силачи, блядь: молчат, но в коде всё написано.
• Потыкай смежную функциональность. С чем эта новая штука будет общаться? Может, там уже какие-то правила зашиты.

3. Начинай тестить и всё записывай, а то потом «я не говорил», блядь.

• Нарисуй чек-лист или майнд-мап. Не формальный документ на 100 страниц, а просто набросок, куда смотреть. Живой, чтобы дополнять.

• Напиши самые очевидные смоук-тесты. Даже если ТЗ — хуй да маленько, какие-то базовые вещи должны работать. Это сразу покажет, жив ли проект вообще.

  # Пример: Даже без ТЗ, логин с валидными данными должен работать
  def test_login_positive(base_url, valid_credentials):
      """Проверяет, что система позволяет войти с корректным логином и паролем."""
      auth_service = AuthService(base_url)
      token = auth_service.login(valid_credentials['user'], valid_credentials['pass'])
      assert token is not None, "Авторизация не прошла. Нет токена доступа."

• ВСЕ свои догадки и допущения — документируй, ёпта! Прям в тест-кейсе или в комментарии к автотесту пиши, откуда ноги растут. Чтобы когда придёт PO и скажет «чё за хуйню ты проверяешь?», ты мог ткнуть пальцем: «Смотри, вот на этой встрече ты сам это сказал, я записал!».

  # В коде автотеста
  # Допущение: После успешной оплаты статус заказа должен смениться на 'PAID'
  # (Основано на обсуждении с PO 12.10.2023 и анализе старой системы)
  def test_order_status_after_payment(self):
      ...

4. Работай короткими итерациями и гони обратную связь, как последний курьер.

• Сначала просто поисследуй систему (Exploratory Testing). Потыкай кнопки, погоняй данные. Пойми, с каким зверем имеешь дело.
• Быстро делай демо или пиши тесты под конкретные спорные моменты и неси это показывать PO. «Вот, я так понял, это должно работать так. Я прав?». Это в сто раз эффективнее, чем месяц переписываться в почте, блядь.
• Предложи внедрить ATDD (Acceptance Test-Driven Development). Суть проста: до того как разработчик напишет хоть строчку кода, вы все вместе (те самые «три амигоса») пишете простенькие критерии приемки в виде тестов. И сразу становится ясно, кто что подразумевал. А то потом — «ой, а я думал, тут будет не поле, а выпадающий список!». Пиздец просто.

Короче, суть в чём: в условиях неопределённости главное — не сидеть сложа руки, а активно двигаться, но каждый свой шаг фиксировать и сразу согласовывать. Чтобы когда грянет «почему так сделано?», у тебя была не виноватая морда Герасима, который только «Муму» мычит, а железобетонная доказательная база, блядь.