Не начинайте проведение приемочного тестирования, пока… [Перевод]

По мере того, как работа над проектом затягивается, а бюджет становится все более ограниченным, первым аспектом, на котором экономят время и средства, становится тестирование. Даже при самом лучшем раскладе, стадии планирования, проектирования и разработки обычно занимают больше времени, чем планировалось изначально. Поэтому попытки успеть завершить работу к назначенному сроку могут привести к сжатию стадии тестирования (UAT). Тем не менее, очень важно, чтобы тестирование было проведено должным образом, и это требует тщательного планирования. Поэтому даже в самых сложных ситуациях не начинайте проведение UAT до тех пор, пока вы не…

…будете абсолютно уверены, что команда разработчиков успела завершить ВСЕ свои тесты

Если разработчики не успели должным образом доделать свою работу и провести внутреннее тестирование продукта, бессмысленно приглашать бизнес-стейкхолдеров на приемочные тесты. Потому что найденные ошибки приведут к тому, что стейкхолдеры просто потеряют доверие к данной системе, будут серьезно разочарованы и обозначат большее количество дефектов. Я в курсе, что у вас поджимают сроки. Я знаю, что ваши бизнес-пользователи хотят как можно быстрее испытать систему в действии. Но если система объективно не готова к тестированию, не нужно демонстрировать стейкхолдерам «сырой» продукт.

…установили четкие границы для каждой стадии, чтобы дать возможность команде тестировщиков разработать тест-скрипты

Движущуюся мишень гораздо сложнее поразить, чем стационарную. Это относится к планированию тестирования ровно в той же степени, что и к стрельбе из лука или стрельбе по тарелочкам. Если тестирование представляет собой поэтапное развертывание, крайне важно, чтобы вы определили временные рамки для каждой стадии на раннем этапе, используя любимый вами метод приоритетов – мы советуем использовать бизнес-моделирование и ключевые показатели эффективности. С их помощью можно определить, какие функции вашего проекта принесут наиболее существенную прибыль, чтобы начать именно с них. Однако вам придется распределить функции по приоритетности для каждой стадии, обговорив заранее, что и когда должно быть протестировано, тем самым значительно облегчая работу тестировщиков.

…уверены, что пользователи, участвующие в приемочных тестах, будут свободны в назначенную дату и время, они понимают, что именно от них требуется, и согласны с используемым методом

Основное внимание во время проведения приемочных тестов должно быть сосредоточено на ваших бизнес-пользователях. Убедитесь, что вы учитываете их напряженный рабочий график и пожелания по поводу времени проведения приемочных тестов, также обсудите с ними, почему им важно участие в UAT. С большой вероятностью это поможет им осознать важность данного шанса по тестированию продукта и его соответствию всем требованиям заказчика. Успешное приемочное тестирование означает нечто большее, чем присутствие нескольких бизнес-пользователей, равнодушно смотрящих на экраны, которые нажали несколько кнопок, чтобы расставить флажки. Успешное тестирование предполагает, что бизнес-пользователям удобно пользоваться разработанной системой, и что эта система достаточно функциональна и может обеспечивать выполнение задач заказчика. И единственный способ убедиться, что это именно так – это убедить пользователей посвятить некоторое количество времени на пользование системой в тестовой среде, выполнение тестовых скриптов и соотношение системы с бизнес-процессами.

…разработали процесс для выявления дефектов, сообщения о них, ранжирования их по приоритетности, а также их исправления

Изъяны в работе практически неизбежны. Приемочные тесты существуют для выявления тех изъянов, которые играют большую роль для бизнеса и которые не были замечены разработчиками. Разработчики качественно выполняют свою работу и разбираются в ее тонкостях, но только бизнес-пользователи точно знают, какой именно функционал должен быть у системы, и как именно она должна работать. Поэтому крайне важно обсудить с бизнес-тестировщиками, что именно представляют собой дефекты, и как правильно составлять отчеты о них, которые позволили бы разработчикам быстрее исправить все недоработки. Замечание типа «система не работает» никак не помогает найти дефект, не говоря уже о том, чтобы помочь его быстро исправить. В идеале ваши бизнес-пользователи должны уметь последовательно описывать действия, которые они выполняли перед тем, как был выявлен дефект, делать скриншоты для визуального представления проблемы, а также давать оценку серьезности недоработки с их точки зрения. В таком случае ваши команды тестировщиков и разработчиков смогут получить ценную информацию, которая позволит им эффективно организовать работу по исправлению недочетов.

Какие советы для успешного проведение UAT можете дать вы?

Автор: David Reinhardt
Перевод подготовила Екатерина Зданевич
Оригинальная статья

P.S. Если вы недавно прочитали классную статью по бизнес-анализу и считаете, что ее стоит перевести, дайте нам знать, например, поделившись ссылкой в комментариях.