Сунь-Цзы и искусство управления тестированием программного обеспечения

Познай себя и своего врага

Введение

Как руководителя отдела QA, меня часто спрашивают о моей философии управления тестированием. По сути, это вопрос о том, как выбрать подход, стратегию и исполнение для различных проектов по тестированию. Дело вот в чем: все компании, проекты, продукты — разные, и продуктовые команды тоже. Это не фастфуд, где всё всегда стандартно. Более того, количество ресурсов для тестирования (или любого другого аспекта инженерной деятельности, если на то пошло) ограничено. Вам приходится «выбирать битвы, в которых стоит участвовать» и сосредотачиваться на вещах, которые имеют значение. Как это сделать?

Я недавно размышлял об этом, и поскольку я изучаю китайский язык, мне пришел на ум афоризм «знай себя и своего врага, и ты выиграешь все битвы» (知己知彼，百战百胜). Авторство этого изречения приписывается Сунь-Цзы (Sun Tzu) из знаменитого «Искусства войны» (Art of War). Я сразу же подумал, можно ли его применить. Подробнее об этом позже.

Афоризм

В полном виде афоризм, приписываемый Сунь-Цзы, звучит статье «Просто отлавливая ошибки, не получится исправить качество» я объяснил, что стремление к качеству — это командный спорт. В нем участвуют разработчики, тестировщики, продакты, клиентская поддержка и т.д. Следовательно, пункты (2), (5), (6), (7) относятся к категории «знание себя».

Что же тогда является «врагом»? Враг — это «сложность» продукта. Баги — это результат сложности. При прочих равных условиях ни один инженер не рад появлению багов. Баги означают потерю сна, свободного времени, выходных, нарушение сроков поставки и т.д. Тем не менее, из-за требований к срокам выхода на рынок и все более сложной природы систем появляются баги, технический долг и скрытый долг (dark debt) (см. [2]). Следовательно, (1), (3), (4) и (8) попадают в лагерь сложности, а сложность — это то, что мы стремимся уменьшить или по крайней мере управлять ею.

Попутно заметим, что в статье «Кто должен заниматься тестированием программного обеспечения? Dev или Test?» [3] я писал о нездоровых, и даже враждебных отношениях между командами разработчиков и тестировщиков. Корень этого конфликта лежит в установке, согласно которой баги возникают вследствие «человеческого фактора» (см. [4]), вместо того, чтобы рассматривать ошибки как симптомы чрезмерной или недостаточно хорошо управляемой сложности. В результате тестировщики обвиняют разработчиков в том, что те допустили появление багов в кодовой базе, а разработчики обвиняют тестировщиков в том, что те допустили появление багов в продакшене. Это нездоровая ситуация. В конце концов, и разработчики, и тестировщики находятся в одной лодке. Мы все хотим создавать качественное программное обеспечение.

В следующих разделах я кратко объясню, почему я считаю, что каждое из 8 «пониманий» помогает нам получить лучшее представление о том, как стоит подходить к управлению тестированием.

Понять пользователя

Чаще всего команду QA просят быть «голосом пользователя», поэтому имеет смысл иметь полное представление о том, какую ценность приложение или услуга приносит пользователю, как оно используется, когда оно используется и т.д. Это также помогает при планировании тестов и определении приоритетов, поскольку позволяет сосредоточиться на том, что наиболее важно для пользователя на момент релиза. Например, однажды я участвовал в тестировании систем для цифрового сельского хозяйства. В этой области есть два ключевых временных периода: посадка и сбор урожая. Именно в эти периоды приложения/услуги используются чаще всего. Поэтому во время посадки в северном полушарии основное внимание при тестировании уделяется посевным работам (а точнее, программному обеспечению, которое их поддерживает).

Понять продукт

Этот продукт создается для конечного потребителя или является корпоративным? Кто платит за продукт? За продукты, подразумевающие подписку, платит пользователь. Бесплатные же продукты обычно оплачиваются за счет рекламы. В таких случаях клиентом является рекламодатель. Убедитесь, что вы знаете, кто является клиентом.

Каково его ключевое ценностное предложение, т.е. какую ключевую ценность пользователи получают от вашего продукта? Это действительно поможет вам оценить влияние багов. В случае большинства e-commerce продуктов, например, Etsy, предлагаемой ценностью является слаженная продажа и выполнение заказа; в случае социальных сетей, например, Instagram, это, с одной стороны, статье «Юнит-тесты и код-ревью: основа качества программного обеспечения» я объясняю, как юнит-тесты и код-ревью формируют прочный фундамент для достижения высокого качества кода и как они усиливают друг друга.

Конечно, весьма очевидным показателем является также количество багов, которые производит команда. Другими очень показательными метриками являются: (a) профиль устаревания багов команды (b) сколько инцидентов в продакшене было приписано коду команды (c) сколько багов, о которых сообщает служба поддержки, приписывается команде.

Чем менее зрелой является команда разработчиков, тем более ценными являются сквозные (end-to-end, E2E) тесты. По мере того, как команда разработчиков вырастает до более контрактного подхода к разработке программного обеспечения, команда тестирования может перейти к более контрактному подходу к тестированию.

Понимание возможностей и ресурсов команды тестирования

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

Понять команду разработчиков продукта

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

Кроме того, обеспечения качества — это командный спорт. Привлекайте своих коллег по продукту к работе над качеством. Они тоже хотят, чтобы продукт радовал пользователей. В конечном итоге они хотят получить продукт, которым они могут гордиться.

Поймите бизнес

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

Разработайте глубокое понимание цены качества. Другими словами, какова альтернативная стоимость отсутствия QA в компании. Что может упасть и какова будет стоимость для бизнеса, если это произойдет. Это даст вам представление о том, какую ценность приносит тестирование.

Заключение

В этой статье я изложил несколько идей подхода к управлению тестированием. Все начинается с понимания ключевой проблемы в разработке программного обеспечения: укрощение сложности. Для этого вам нужно понять источники сложности, а также команды и людей, вовлеченных в ее решение. Качество — это командная работа, а менеджер по тестированию — это организатор и координатор усилий по сдерживанию и управлению этой сложностью. Если это делается хорошо, то это приносит большую пользу компании и бизнесу.

О важной роли понимания бизнеса в построении эффективной стратегии тестирования мы продолжим говорить на открытом уроке.

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

Основные темы открытого урока:

• Различия между IT-продуктом и проектом и их влияние на стратегию тестирования.

• Жизненный цикл проекта и продукта: что следует учитывать в разных этапах развития.

• Важные артефакты для изучения вашей зоны ответственности: CJM, user story map, портреты ЦА и другие инструменты.

• Влияние бизнес-метрик на подходы к тестированию: как определить приоритеты и модель тестирования, исходя из их влияния на ключевые показатели бизнеса.

Записаться на открытый урок можно на странице курса «QA Lead».