Приведи пример взаимодействия с заказчиком

Пример взаимодействия с заказчиком в роли QA Engineer

Взаимодействие с заказчиком — это критически важный навык для QA-инженера, так как оно напрямую влияет на понимание требований, ожиданий и конечного качества продукта. Я, как старший QA с более чем 10-летним опытом, рассмотрю реальный кейс из моей практики — разработку мобильного банкинга для регионального банка.

Ситуация: неясные требования к функционалу «Быстрый платеж по QR-коду»

На старте проекта заказчик (представитель банка) предоставил краткое описание: «Пользователь должен сканировать QR-код и оплачивать счёт». Для QA такая формулировка недостаточна, так как порождает множество вопросов.

Процесс взаимодействия

1. Подготовка к встрече (Предварительный анализ):

    Я не стал ждать официального уточнения, а самостоятельно проанализировал возможные сценарии и подготовил структурированный список вопросов. Цель — превратить размытое пожелание в детализированные, тестируемые требования.

1. Проведение рабочей сессии (Уточнение требований):

    Мы организовали онлайн-встречу с заказчиком и бизнес-аналитиком. Я выступил модератором обсуждения, задавая подготовленные вопросы:

    *   **Источники QR-кода:** Он генерируется системой банка, сторонним сервисом (например, магазином) или это статический код получателя?
    *   **Данные в коде:** Какая именно информация закодирована? Это только номер счёта, или также сумма, назначение платежа, валюта?
    *   **Сценарии обработки:**
        *   Если сумма указана — платеж должен быть автоматически подтверждён или пользователь может её изменить?
        *   Если сумма не указана — каково поведение формы?
        *   Что если валюта счёта и валюта в QR-коде различаются?
    *   **Обработка ошибок:** Что должно происходить, если код повреждён, отсканирован не финансовый QR, или счёт получателя заблокирован?
    *   **Нефункциональные требования:** Какое максимальное время обработки сканирования и перехода к форме оплаты?

    В ходе обсуждения мы использовали **прототипы экранов (wireframes)**, чтобы визуализировать логику. Заказчик, видя конкретные сценарии, смог чётко сформулировать: «Сумму из QR-кода можно редактировать, но при этом должна появляться предупреждающая подпись “Сумма изменена”».

1. Фиксация и верификация результатов:

    После сессии я формализовал принятые решения в виде **детальных Acceptance Criteria** в Confluence и создал на их основе тест-кейсы в **TestRail**. Это исключило разночтения.

    Пример критерия в формате **Gherkin**:

```gherkin
Feature: Оплата по QR-коду со сторонней суммой
  Как пользователь мобильного банка,
  Я хочу сканировать QR-код с указанной суммой,
  Чтобы быстро и безошибочно совершить платеж.

  Scenario: Редактирование предустановленной суммы
    Given Я отсканировал валидный QR-код с суммой "1000 RUB"
    When Я изменяю сумму в поле "Сумма платежа" на "1500 RUB"
    Then Под полем "Сумма платежа" отображается текст-предупреждение "Сумма изменена"
    And Кнопка "Оплатить" остаётся активной
```

    Я отправил документ заказчику на подтверждение: «Правильно ли мы всё поняли?». Получив письменное согласие, мы получили **единственный источник истины** для разработки и тестирования.

1. Постоянная коммуникация и демонстрации (Showcases):

    На этапе тестирования альфа-версии я обнаружил проблему: при сканировании кода с очень большой суммой (например, 10 млн рублей) превышался лимит на операцию, но приложение просто показывало ошибку «Лимит превышен» без возможности её исправить. Вместо того чтобы просто завести баг-репорт, я сразу созвонился с заказчиком и продемонстрировал проблему через **сессию общего доступа к экрану**.

    **Моё предложение:** «Мы видим два варианта: 1) При превышении лимита показывать ошибку и сбрасывать форму (как сейчас, плохой UX). 2) Автоматически подставлять максимально допустимую сумму в поле, а пользователь подтверждает платёж на неё. Что предпочтительнее для ваших клиентов?»

    Заказчик выбрал второй вариант, и мы оперативно скорректировали требование и тесты.

Ключевые принципы успешного взаимодействия, которые я применяю

• Говорить на языке бизнеса: Избегать сугубо технических терминов («404 ошибка»), объяснять через бизнес-последствия («клиент не сможет совершить платёж в критический момент»).
• Проактивность и структурированность: Приходить к заказчику не с проблемой, а с анализом и вариантами решений.
• Документировать всё: Любое устное решение должно быть зафиксировано письменно и подтверждено.
• Использовать визуализацию: Скриншоты, скринкасты, прототипы — лучший способ донести мысль.
• Быть партнёром, а не «полицейским качества»: Цель — помочь заказчику выпустить качественный продукт, а не просто найти все баги. Доверительные отношения — основа эффективной работы.

Итог: В описанном кейсе прямое, проактивное и структурированное взаимодействие с заказчиком позволило:

1. На этапе планирования выявить и устранить 30% неочевидных требований.
2. Избежать дорогостоящих переделок на поздних стадиях проекта.
3. Создать продукт, который с первого релиза получил высокие оценки удобства от фокус-группы клиентов банка.

Для QA-инженера заказчик — не сторонний наблюдатель, а ключевой участник процесса построения качества. Умение выстраивать с ним диалог так же важно, как и технические навыки тестирования.