Когда я работала инженером по автоматизации на Java, постепенно всё меньше кайфовала от написания автотестов и всё больше от анализа и архитектуры сервисов. Так я стала тест-аналитиком. В прошлой компании начала плотно работать с архитекторами, и этот опыт стал ключевым, когда устраивалась в текущую.
Перед тем как ревьюить тестовые модели, я всегда погружаюсь в требования: люблю читать архитектуру, разбираться в диаграммах последовательностей, смотреть, как сервисы взаимодействуют между собой, понимать логику запросов по бэку. А вот макеты - не моя любовь 😁
Иногда даже предлагаю аналитикам менять формулировки требований или уточнять нефункциональные параметры, особенно когда платформа обновляется, а в документации всё ещё живут старые шаблоны.
Итак, как тестировать документацию?
Важно знать, что каждое требование должно обладать рядом характеристик от полноты и однозначности до проверяемости, модифицируемости и трассируемости. Но на практике часто встречаются противоречивые, неактуальные или просто непроверяемые требования.
Например, при ревью тестовых моделей коллеги иногда говорят: «Это требование невозможно протестировать только из под капота». Формально оно плохое, но главное, что его можно проверить (пусть и вместе с разработчиком).
А если требование воспроизводится только на проде - это уже зона риска. Оно вроде бы выполнимо, но качество сильно зависит от окружения.
Мой совет: ищите противоречия и нелогичность в документации - они чаще всего выдают некачественные требования. Если вы знаете продукт, вы точно заметите несостыковки.
И не забывайте про модифицируемость - требования нужно обновлять или вести историю изменений. А при трассировке связывать каждое требование с тестом - так вы точно не потеряете ничего важного.

Дополняйте в комментариях свои любимые характеристики требований ❤️

@protestinginfo