Манифест Тестирования в Agile среде. В чем отличия от классического подхода к QA?

В данной статье мы рассмотрим 5 ключевых принципов, которые помогут вам улучшить процесс тестирования и обеспечения качества в Agile, и рассмотрим, как эти принципы коррелируют с основными ценностями Agile манифеста.

Возьмемся за интересный аспект: в 2001 году был представлен Манифест Agile, а через 12 лет, что является значительным промежутком времени, появился манифест тестирования, основанный на Agile.

Этот манифест сегодня служит основой для работы специалистов по тестированию в большинстве компаний. Хотел бы прояснить один момент: если вы обучались QA, вы, вероятно, знакомы с ISTQB и их семью ключевыми принципами тестирования. Однако Agile не противоречит этим принципам. Скорее, он предлагает иной угол зрения на тестирование, и это важно учитывать.

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

1. Непрерывное тестирование

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

В манифесте тестирования мы рассматриваем тестирование как непрерывный процесс, который тесно связан с документацией и взаимодействием с заказчиком, с тем, какие вопросы мы задаем и какие артефакты мы используем. Таким образом на каждом этапе разработки существуют определенные действия со стороны QA-специалистов, которые они могут предпринять.

2. Предотвращение появления дефектов

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

Много внимания в этом контексте уделяется взаимодействию с заказчиком, анализу документации и обратной связи. Это больше, чем просто чтение спецификаций и создание тестовых планов и случаев. В Agile вы, скорее всего, потратите большую часть времени на понимание пользователя и его потребностей.

В сравнении с традиционными подходами, например, waterfall, деятельность QA-специалиста меняется. В моей прошлой практике на waterfall проектах, соотношение времени, которое мы тратили на непосредственное тестирование, описание дефектов и подготовку тестовых случаев, было примерно 40% к 60%. В Agile этот баланс смещается. Вы уделяете больше времени на понимание потребностей пользователя, как он использует систему, и какие ключевые сценарии существуют. В результате у вас остается меньше времени на само тестирование, поскольку вы уже более подготовлены и продуманы в своем подходе к этому процессу.

3. Тестирование глазами клиента

Третья ценность подчеркивает важность понимания тестирования вместо простой проверки функциональности. Это ключевой момент. Да, вы можете систематически проверять каждую функцию приложения, сайта или модуля, используя такие инструменты, как decision tables. Вы можете тщательно тестировать каждый пункт, пытаясь обеспечить максимальное покрытие. Но у этого подхода есть недостатки.

Во-первых, он может занять много времени. Во-вторых, вы никогда полностью не предугадаете, как пользователь будет использовать определенную функцию. Пользователи часто используют функции такими способами, о которых создатели ПО даже не догадывались.

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

С точки зрения Agile, наиболее приоритетным становится то, что важно и полезно для нашего пользователя, и это становится главным фокусом нашего тестирования.

4. Фокус на создании лучшего продукта

Четвертая ценность подчеркивает важность переосмысления вашей роли как специалиста по тестированию. Если вы видите себя только как человека, работающего в команде с целью "сломать" продукт, то такая позиция может быть проблематичной. Вместо конструктивного вклада в качество продукта вы фокусируетесь на его деструкции. Если продукт сломан, что дальше? Вы нашли дефект и ждете его исправления? Но суть вашей работы не в этом.

Вместо этого ваш главный фокус, как и у всех в команде, должен быть направлен на создание лучшего продукта. Это продукт, который будет сложно "сломать". Способ, как вы этого достигаете, может быть разнообразным — от поиска дефектов на определенных стадиях до работы над спецификациями, прототипами с владельцем продукта или заказчиком. Но ваша цель должна быть не в "ломании" продукта, а в создании качественного и надежного продукта.

5. За качество отвечает вся команда

Пятая ценность обращает внимание на командную ответственность за качество, вместо ответственности отдельного специалиста по тестированию. Это концепция была введена еще в старые добрые времена Toyota через подход "Total Quality Control", или тотальный контроль качества. Что это означает? Вместо того, чтобы один человек на производственной линии отвечал за качество, ответственность была распределена среди всех участников процесса создания продукта.

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

Отсылки к Agile манифесту

Когда мы возвращаемся назад и смотрим на Agile манифест, можно заметить, что акцент делается на работающем продукте, а не на исчерпывающей документации. Сотрудничество с заказчиком ставится выше, чем строгие договоренности. Это прямо коррелирует с ценностями, выдвинутыми в манифесте тестирования.

Все эти принципы важны, поскольку они помогают направить команду на создание продукта высокого качества, а не на следование жестким и иногда ненужным процедурам и процессам. С помощью этих принципов команда Agile может стать более гибкой, эффективной и продуктивной, сосредоточив свое внимание на достижении конечной цели — создании высококачественного продукта, который в полной мере удовлетворяет потребности пользователей и заказчика.