💡 На проекте нет требований? (Идеальная ситуация для QA)
Очень часто можно услышать, в том числе и на собеседованиях: «На проекте нет требований, как вообще тестировать?»
И вот тут начинается самое интересное.
На многих проектах документации или нет совсем, или она давно устарела. И в этот момент тестировщик не должен терять почву под ногами - он становится связующим звеном между продуктом, кодом и бизнесом. Теперь от него зависит очень многое.
Как это работает на практике:
Берём за основу то, что уже работает в проде (или последнего релиз-кандидата) - фактическое as-is.
Уточняем у бизнеса: что критично для пользователя, где потенциальные деньги и репутационные риски.
Сверяем с разработкой: задумывалось ли именно так, как сделано?
Всё фиксируем в артефактах (тест-планах, чек-листах, тест-кейсах).
При этом помним, что подход к тестированию зависит от контекста: где-то хватит чек-листа, а где-то нужны тест-кейсы.
Именно так рождается «живая спецификация» - не толстый документ ради галочки, а минимальные правила и сценарии, на которых начинает строиться тестирование.
Что делать QA, если требований нет:
- Собери требования сам (аналитика, разработка).
- Изучи продукт глазами пользователя и попробуй построить ожидания клиента.
- Построй модель поведения реального юзера.
- Оформи happy-path приложения и ключевые негативные сценарии.
- Фиксируй всё в чек-листы, тест-кейсы, схемы или заметки.
- В результате у тебя получится упорядоченная система, на основе которой уже можно базировать полноценное тестирование.
QA может превратить хаос в понятные правила и сценарии.
Главное тут - внимание и методичный подход, необходимо уметь общаться с бизнесом и разработкой, фиксировать, документировать и упорядочивать знания команды.
p.s. Не забывайте запрашивать обратную связь от команды и бизнеса по процессам тестирования.
Очень часто можно услышать, в том числе и на собеседованиях: «На проекте нет требований, как вообще тестировать?»
И вот тут начинается самое интересное.
На многих проектах документации или нет совсем, или она давно устарела. И в этот момент тестировщик не должен терять почву под ногами - он становится связующим звеном между продуктом, кодом и бизнесом. Теперь от него зависит очень многое.
Как это работает на практике:
Берём за основу то, что уже работает в проде (или последнего релиз-кандидата) - фактическое as-is.
Уточняем у бизнеса: что критично для пользователя, где потенциальные деньги и репутационные риски.
Сверяем с разработкой: задумывалось ли именно так, как сделано?
Всё фиксируем в артефактах (тест-планах, чек-листах, тест-кейсах).
При этом помним, что подход к тестированию зависит от контекста: где-то хватит чек-листа, а где-то нужны тест-кейсы.
Именно так рождается «живая спецификация» - не толстый документ ради галочки, а минимальные правила и сценарии, на которых начинает строиться тестирование.
Что делать QA, если требований нет:
- Собери требования сам (аналитика, разработка).
- Изучи продукт глазами пользователя и попробуй построить ожидания клиента.
- Построй модель поведения реального юзера.
- Оформи happy-path приложения и ключевые негативные сценарии.
- Фиксируй всё в чек-листы, тест-кейсы, схемы или заметки.
- В результате у тебя получится упорядоченная система, на основе которой уже можно базировать полноценное тестирование.
QA может превратить хаос в понятные правила и сценарии.
Главное тут - внимание и методичный подход, необходимо уметь общаться с бизнесом и разработкой, фиксировать, документировать и упорядочивать знания команды.
p.s. Не забывайте запрашивать обратную связь от команды и бизнеса по процессам тестирования.