Общие зоны ответственности: аналитик как первый тестировщик
Сразу скажу, что системный аналитик и тестировщик — это самодостаточные роли, которые всё время пересекаются в ежедневной работе. Но вот степень вовлеченности у них разная — в зависимости от стадии спринта или развития проекта.
По сути, аналитик тестирует требования еще до того, как QA начнет тестировать систему, и делает это в процессе сбора и формулирования требований. Именно аналитик формулирует, что должно быть на выходе, и фиксирует это в критериях приемки (Acceptance Criteria).
Хороший аналитик всегда немножечко тревожный, поскольку задает максимальное количество вопросов «А что, если…?». Тем самым он прокладывает путь тестированию на будущее, продумывает альтернативные пути: что будет, если пользователь передумает, если сервис зависнет, если данные придут в кривом формате и так далее. А еще аналитик ищет нестыковки в логике на этапе обсуждений, задает «глупые» (на самом деле самые полезные) вопросы и фиксирует ответы. Как раз в этом смысле аналитик — первый тестировщик, его артефакты становятся фундаментом для QA: из критериев приемки рождаются тест-кейсы, из BPMN-диаграмм (при условии, что они сделаны качественно) — чек-лист сценариев, а из прототипов дизайна могут получиться почти полноценные UX-тесты.
Что аналитик может сделать, чтобы упростить тестирование
Аналитик не пишет тесты, но может очень сильно упростить жизнь QA.
Артефакты аналитики
Я уже упомянула, что Acceptance Criteria — это готовый список проверок и что аналитик подсвечивает edge cases («А что, если пользователь введет код три раза неверно?»). В ручном тестировании, помимо этого, аналитик фиксирует предусловия и постусловия. Например, прорабатывает статусную модель: «После отмены заказа статус становится „Отменен“, деньги не списываются».
Еще полезным артефактом со стороны аналитика будет создание прототипов и диаграмм, где видно не только happy path, но и все «если что-то пошло не так».
На диаграмме последовательности (о ней я рассказывала в этой статье) тестировщик может видеть весь интеграционный сценарий целиком: какие сервисы вызываются, где возможны таймауты, какие ответы приходят асинхронно.
Ручное и автотестирование
Хотя у аналитика нет задачи кликать интерфейс или прогонять автотесты, он всё равно может выявить баги самостоятельно и завести баг-репорт.
Что касается автоматизации, аналитик может помочь тем, что опишет сценарий так, чтобы его можно было превратить в автотест. Для этого необходимо описать исходные условия, начальное состояние системы, конкретное действие пользователя или системы и ожидаемый результат.
Многие специалисты описывают сценарии именно по такой структуре, не задумываясь о том, что непроизвольно соблюдают формат описания сценариев Given-When-Then из методологии BDD (Behavior-Driven Development, разработка через поведение).
Суть в том, чтобы описывать требования и ожидаемое поведение системы простым структурированным языком, который одинаково понимает бизнес, аналитики, разработчики и тестировщики.
Структура:
- Given (Дано).
- When (Когда).
- Then (Тогда).
Вот пример описания пользовательского сценария по формату BDD:
- Given: пользователь указал email.
- When: система отправила код подтверждения.
- Then: пользователь может задать новый пароль.
Инженер по тестированию дальше сам решает, как это автоматизировать, но за основу он может брать именно работу аналитика.
Подчеркну: аналитику не нужно лезть в код автотестов, учить Selenium или Playwright. Но когда аналитик понимает, как работают тесты, и формулирует требования так, чтобы их можно было автоматизировать без лишних интерпретаций, это ускоряет и упрощает тестирование.
Идеальный аналитик = бывший тестировщик?
Есть мнение, что лучший аналитик — это человек, который когда-то работал тестировщиком. У него выработалась привычка искать пробелы, продумывать сценарии, сомневаться и задавать, может быть, неудобные вопросы. Хотя, возможно, так можно сказать про любого специалиста: хороший аналитик — бывший бэкендер, или, наоборот, тестировщик более прокачан, если раньше был аналитиком.
Аналитик и без этого бэкграунда тоже может быть сильным, но ему нужно специально тренировать в себе этот QA-режим: всегда проверять требования на полноту и противоречия.
T-shape развитие: понимать, но не подменять
Команды ценят T-shape специалистов — тех, кто глубоко разбирается в своей области, но при этом понимает смежные роли. В контексте тестирования для аналитика это значит знать основы тестирования (виды тестов, как работает автотест, зачем нужны негативные сценарии), обзорно понимать, как устроены тестовые данные и как ими пользуются QA. Всё это позволит говорить с QA на одном языке и помогать им работать быстрее.
Кстати, это может работать и в обратную сторону: фактически тестировщик тестирует не только продукт, но и сами требования, его задача — критично смотреть на формулировки и задавать вопросы, ведь аналитик может что-то упустить, а QA подсветит пробелы. Если баг обнаружат на этапе требований, заводить полноценный тикет на документацию, на мой взгляд, уже излишняя бюрократия — быстрее добавить комментарий в документации, которую аналитик оперативно обновит. Только важно отразить правку в действующей спецификации в истории изменений, чтобы избежать коллизий со стороны разработки.
Заходит как-то тестировщик в бар, а там аналитик и разработчик…
Есть такая техника Three Amigos («3 амигос») — это когда встречаются аналитик, разработчик и тестировщик. Именно в рамках таких встреч на берегу снимаются противоречия, обсуждаются требования и будущие сценарии, и каждый смотрит на задачу со своей стороны. Если на этом этапе нашли спорный момент — даже хорошо, поскольку это во много раз дешевле, чем потом разбираться с багами уже на продакшене.
Это инструмент, который реально помогает убрать пробелы и двусмысленность еще до того, как задача ушла в разработку. На такой встрече команда синхронизируется по трем ключевым вопросам: какая проблема стоит, какие есть варианты ее решения, что именно должно быть сделано, чтобы задача считалась готовой.
Аналитик формулирует бизнес-контекст, тестировщик наперед думает о негативных сценариях и возможных багах, разработчик оценивает технические ограничения и подсчитывает эстимейт — сколько времени уйдет на разработку. Когда эти три взгляда накладываются друг на друга, задача перестает быть абстрактной и превращается в конкретный, проверяемый и реализуемый сценарий.
Вместо заключения
Аналитик и тестировщик — невзаимозаменяемые роли: у каждого своя зона ответственности. Аналитик не пишет тесты, но создает условия, при которых тесты будут полными, осмысленными и полезными, и чем раньше аналитик включается в процесс «как это будут тестировать», тем меньше сюрпризов на продакшене и тем быстрее команда выпускает качественный продукт. Время — деньги 🙂
