Почему UAT терпит неудачу, когда кажется успешным
Во многих кругах пользовательского приемочного тестирования (User Acceptance Testing, UAT) все сценарии помечаются как пройденные, и через две недели после запуска в эксплуатацию поступают десятки обращений. Это не парадокс. Это прямой результат тестирования, построенного вокруг экранов.
Тестирование, ориентированное на экран, задает вопрос: «Можно ли создать запись?». Тестирование, ориентированное на процесс, спрашивает: «Может ли агент принять обращение, идентифицировать существующего клиента по другому имени, проверить его правомочность в основной системе, открыть обращение, передать его другому сотруднику и закрыть его — при этом клиент дважды присутствует в системе?». Второй сценарий выявляет то, что пропускает первый.
Данное руководство представляет структуру UAT, ориентированную на второй вопрос. Связь с другими этапами проекта описана в руководстве по внедрению Salesforce.
Что должно быть готово до начала работы
- Стабильная среда, которая не принимает развертываний в середине цикла, за исключением одобренных исправлений, блокирующих работу.
- Тестовые данные по объему и сложности, аналогичные производственным.
- Пользователи с реальными разрешениями — не Admin для всех. Половина проблем с разрешениями обнаруживается только тогда, когда тестировщик имеет правильный профиль.
- Определенные критерии приемки для каждого основного процесса.
- Единый механизм отчетности по дефектам с минимально обязательными полями.
Чаще всего пропускается третий пункт, и именно он приводит к наиболее неудобным ошибкам в день запуска.
Как создать сценарий, выявляющий проблемы
Хороший сценарий начинается с персоны и исходного состояния, а не с клика. Рабочая структура:
- Кто — точная роль и разрешение.
- Исходное состояние — какая информация существует в системе до начала сценария.
- Что происходит — бизнес-событие, запускающее процесс.
- Что делает тестировщик — на уровне бизнес-операции, а не на уровне клика.
- Ожидаемый результат — включая то, что произошло в других системах.
- Что не должно происходить — запись не раскрывается тому, кому не следует, уведомление не отправляется дважды.
Шестой пункт отличает чек-лист от профессионального тестирования.
Шесть семейств сценариев, которые должны быть включены
| Семейство | Пример сценария | Что выявляет |
|---|---|---|
| Корректный путь | Полный сквозной процесс | В принципе ли процесс выполним |
| Бизнес-исключение | Отмена, возврат, возврат на предыдущий этап | Логика, построенная только в одном направлении |
| Проблемные данные | Дублирующийся клиент, имя на иврите и английском, пустое поле | Недостаточное сопоставление и очистка |
| Разрешения | Пользователь, пытающийся получить доступ к записи другого подразделения | Пробелы в модели раскрытия |
| Сбой интеграции | Целевая система недоступна | Обработка ошибок, циклы, дублирование |
| Объем | Групповая операция над большим количеством записей | Ограничения производительности и автоматизации |
Отсутствие целого семейства в списке указывает на то, что тестирование обеспечит ложную уверенность.
Классификация критичности — условие для управления циклом
Без согласованной классификации каждая ошибка кажется срочной, и решение о запуске в эксплуатацию становится предметом спора. Достаточна четырехступенчатая модель:
| Уровень | Определение | Влияние на запуск в эксплуатацию |
|---|---|---|
| Блокирующий | Невозможно завершить основной процесс, обходной путь отсутствует | Блокирующий |
| Критический | Процесс возможен с серьезным обходным путем или сохраняются неверные данные | Блокирующий, если не одобрено явно |
| Средний | Значительное неудобство, разумный обходной путь | Не блокирующий, включается в план исправления |
| Низкий | Формулировка, порядок полей, улучшение | Откладывается до следующей итерации |
Важное правило: классификацию определяет владелец процесса вместе с технической командой, а не тот, кто сообщил о дефекте.
Условия перехода в производство
Формулируются до начала цикла, а не в конце:
- Ноль открытых блокирующих дефектов.
- Каждый критический дефект закрыт или одобрен в письменной форме с обходным путем и временем исправления.
- Все основные процессы были выполнены во втором цикле без новых сбоев.
- Владельцы процессов подтвердили в письменной форме.
- Существует проверенный, а не только написанный, план отката.
Пример для иллюстрации: Пенсионный фонд
Сценарий гипотетический и предназначен для иллюстрации. Пенсионный фонд тестировал процесс обработки обращений участников. Первый цикл UAT прошел почти полностью. Команда заметила, что все тестировщики использовали один расширенный профиль, поскольку точное назначение профилей задерживалось.
Во втором цикле, с реальными профилями, было обнаружено одиннадцать дефектов: агенты не видели записи участников, переведенных между планами, кнопка одобрения исключения появлялась тем, кто не уполномочен, а отчет о нагрузках возвращал частичные результаты руководителям групп. Ни один из дефектов не был связан с функциональностью, протестированной в первом цикле — все они касались модели раскрытия.
Практический вывод, принятый там: не начинать цикл UAT до тех пор, пока все участники не будут работать с профилем, который они будут использовать в производстве.
Управленческие ошибки, удорожающие цикл
- Развертывание версий в середине цикла, что обнуляет действительность уже выполненных тестов.
- Тестировщики, сообщающие через WhatsApp и электронную почту параллельно с системой отслеживания.
- Сценарии, написанные на уровне клика, что превращает любое изменение интерфейса в обновление документации.
- Сокращение второго цикла из-за графика — это цикл, который выявляет регрессии.
Эти паттерны появляются наряду с другими сбоями в руководстве по распространенным ошибкам, и ответственность за каждый из них определена в руководстве по ролям команды проекта Salesforce.
При замене существующей системы
В проекте замены добавляется вторая функция UAT: сравнение. Те же десять сценариев запускаются в обеих системах, и результаты сравниваются поле за полем. Это наиболее эффективный инструмент для выявления пробелов в сопоставлении до того, как они превратятся в пробелы в доверии. Последовательность действий при таком переходе подробно описана в руководстве по замене CRM на Salesforce.
Что остается после цикла
Сценарии UAT не являются одноразовым документом. Они являются основой для регрессионного тестирования при каждом будущем выпуске, и они являются лучшим источником учебных материалов — потому что они написаны на языке процесса, а не на языке системы. Сохранение их в формате, который можно повторно запускать, является самой дешевой инвестицией, которую можно сделать на следующий год.