Что такое ADR
Что проверяют
Понимаете ли вы, как команда фиксирует архитектурные решения, и видите ли в этом пользу для тестирования. Для QA вопрос проверяет ещё и зрелость: тестировщик, который читает и пишет такие документы, работает с причинами решений, а не только с готовой сборкой.
Как отвечать
ADR это Architecture Decision Record, короткая запись об одном значимом решении и о том, почему выбрали именно так. Живёт рядом с кодом в репозитории, нумеруется и не переписывается задним числом: если решение отменили, заводят новый документ, а старый помечают как заменённый.
Классическая структура из четырёх частей:
Заголовок и статус: предложено, принято, заменено.
Контекст: какая задача и какие ограничения были на тот момент.
Решение: что выбрали, коротко и без перебора вариантов.
Последствия: что стало проще, что сложнее, за что заплатили.
Чем полезно тестировщику: в разделе последствий лежат готовые риски и границы, отсюда берутся идеи тест-дизайна и приоритет регрессии. Запись о том, почему сервис не хранит состояние, заодно объясняет, почему поведение при повторах именно такое.
QA и сам заводит такие документы: выбор инструмента автотестов, стратегия тестовых данных, граница между модульным и интеграционным уровнем, решение не тащить сквозные сценарии в каждый прогон.
Где спотыкаются
Расшифровывают аббревиатуру наугад, как отчётность автотестов или что-то про дефекты. Это запись архитектурного решения, и промах в расшифровке сразу закрывает тему.
Правят принятый документ вместо нового. Ценность как раз в истории: видно, при каких ограничениях решение было верным и что с тех пор изменилось.
Пишут только выбранный вариант, без последствий и отвергнутых альтернатив. Такой текст не помогает ни новому человеку в команде, ни тестировщику: рисков из него не достать.