Аналитик готовит очередную спецификацию требований и постановку задачи на разработку новой функциональности в монолитной системе со сложной бизнес-логикой. Затрагивается поведение ряда функций системы - для них описывается новое ожидаемое поведение.
То, что не затрагивается, фиксируется в виде
как в текущей реализации/функциональность не изменяется
Тестировщик готовится к тестированию, в том числе к регрессу. Для этого обновляет и создает новую тестовую документацию. Наткнувшись на такую формулировку, пытается в документации найти пропущенные/забытые знания. Не находит.
Считая аналитика источником истины и ходячей базой знаний, тестировщик идет к нему с вопросом, а чаще с требованием - добавить «недостающее описание» о текущем поведении в задачу.
Аналитик парирует:
Поведение в этом месте не изменяется! Я исследовал. Если вам не хватает информации, то воспроизводите сами для ваших нужд. Вы же тестировщики.
А судьи что?
Мне довольно легко понять боли обеих сторон.
Но решить, как правильно и чья эта обязанность или зона ответственности было не просто. А что если поискать ответ со стороны провокационных вопросов?
Зона ответственности аналитика это ИТ-продукт, за который отвечает команда или постановка задачи? Цель анализа и проектирования это грамотная постановка задачи, или задачу дальше по конвейеру пустить?
Я считаю, что аналитик отвечает за ИТ-продукт, как и тестировщик, разработчик и другие участники команды разработки. Насчет постановки - ключевой вопрос в необходимости/достаточности, ответ на который лежит в плоскости командных потребностей и договоренностей.
При этом считаю важным:
💡Во время исследования AS IS системы аналитиком вносить заметки в пробелы документации по текущей версии ПО. Когда ты в контексте, то восполнить потерянную документацию можно легко и быстро, и тем самым сэкономить время членам команды на более поздних этапах. Если времени вносить изменения пр ходу дела нет, то явно проговаривать текущее (любое волнующее других) поведение на командных встречах по обсуждению задач.
💡Тестировщикам следить за тестовой документацией, и не надеяться на качество и полноту иной документацию.
❓А вы что думаете?
Допускаете ли вы в своих документах подобные формулировки? Приводило ли такое к проблемам с качеством ПО?
