Познай себя и своего врага
Введение
Как руководителя отдела QA, меня часто спрашивают о моей философии управления тестированием. По сути, это вопрос о том, как выбрать подход, стратегию и исполнение для различных проектов по тестированию. Дело вот в чем: все компании, проекты, продукты — разные, и продуктовые команды тоже. Это не фастфуд, где всё всегда стандартно. Более того, количество ресурсов для тестирования (или любого другого аспекта инженерной деятельности, если на то пошло) ограничено. Вам приходится «выбирать битвы, в которых стоит участвовать» и сосредотачиваться на вещах, которые имеют значение. Как это сделать?
Я недавно размышлял об этом, и поскольку я изучаю китайский язык, мне пришел на ум афоризм «знай себя и своего врага, и ты выиграешь все битвы» (知己知彼，百战百胜). Авторство этого изречения приписывается Сунь-Цзы (Sun Tzu) из знаменитого «Искусства войны» (Art of War). Я сразу же подумал, можно ли его применить. Подробнее об этом позже.
Афоризм
В полном виде афоризм, приписываемый Сунь-Цзы, звучит следующим образом:
Если ты знаешь себя и своего врага, ты выиграешь любое сражение. Если ты знаешь себя, но не своего врага, то можешь одержать победу с вероятностью 50-50. Если ты не знаешь ни себя, ни своего врага, ты проиграешь любое сражение.
Раз уж мы затронули тему управления тестированием — что значит знать себя и своего врага в этом контексте?
Применение афоризма к управлению тестированием
Размышляя над этим изречением и вспоминая все проекты, которыми я руководил, мне удалось перечислить следующие важные моменты:
Понять пользователя.
Понять продукт.
Понять архитектуру продукта.
Понять, кто работал над программным обеспечением, его историю. В свою очередь это поможет прояснить истоки его сложности.
Понять команду разработчиков.
Понять возможности и ресурсы команды тестирования.
Понять продуктовую команду.
Понять бизнес.
Как это соотнести со словами «знать себя и знать своего врага?». В статье «Просто отлавливая ошибки, не получится исправить качество» я объяснил, что стремление к качеству — это командный спорт. В нем участвуют разработчики, тестировщики, продакты, клиентская поддержка и т.д. Следовательно, пункты (2), (5), (6), (7) относятся к категории «знание себя».
Что же тогда является «врагом»? Враг — это «сложность» продукта. Баги — это результат сложности. При прочих равных условиях ни один инженер не рад появлению багов. Баги означают потерю сна, свободного времени, выходных, нарушение сроков поставки и т.д. Тем не менее, из-за требований к срокам выхода на рынок и все более сложной природы систем появляются баги, технический долг и скрытый долг (dark debt) (см. [2]). Следовательно, (1), (3), (4) и (8) попадают в лагерь сложности, а сложность — это то, что мы стремимся уменьшить или по крайней мере управлять ею.
Попутно заметим, что в статье «Кто должен заниматься тестированием программного обеспечения? Dev или Test?" [3] я писал о нездоровых, и даже враждебных отношениях между командами разработчиков и тестировщиков. Корень этого конфликта лежит в установке, согласно которой баги возникают вследствие «человеческого фактора» (см. [4]), вместо того, чтобы рассматривать ошибки как симптомы чрезмерной или недостаточно хорошо управляемой сложности. В результате тестировщики обвиняют разработчиков в том, что те допустили появление багов в кодовой базе, а разработчики обвиняют тестировщиков в том, что те допустили появление багов в продакшене. Это нездоровая ситуация. В конце концов, и разработчики, и тестировщики находятся в одной лодке. Мы все хотим создавать качественное программное обеспечение.
В следующих разделах я кратко объясню, почему я считаю, что каждое из 8 «пониманий» помогает нам получить лучшее представление о том, как стоит подходить к управлению тестированием.
Понять пользователя
Чаще всего команду QA просят быть «голосом пользователя», поэтому имеет смысл иметь полное представление о том, какую ценность приложение или услуга приносит пользователю, как оно используется, когда оно используется и т.д. Это также помогает при планировании тестов и определении приоритетов, поскольку позволяет сосредоточиться на том, что наиболее важно для пользователя на момент релиза. Например, однажды я участвовал в тестировании систем для цифрового сельского хозяйства. В этой области есть два ключевых временных периода: посадка и сбор урожая. Именно в эти периоды приложения/услуги используются чаще всего. Поэтому во время посадки в северном полушарии основное внимание при тестировании уделяется посевным работам (а точнее, программному обеспечению, которое их поддерживает).
Понять продукт
Этот продукт создается для конечного потребителя или является корпоративным? Кто платит за продукт? За продукты, подразумевающие подписку, платит пользователь. Бесплатные же продукты обычно оплачиваются за счет рекламы. В таких случаях клиентом является рекламодатель. Убедитесь, что вы знаете, кто является клиентом.
Каково его ключевое ценностное предложение, т.е. какую ключевую ценность пользователи получают от вашего продукта? Это действительно поможет вам оценить влияние багов. В случае большинства e-commerce продуктов, например, Etsy, предлагаемой ценностью является слаженная продажа и выполнение заказа; в случае социальных сетей, например, Instagram, это, с одной стороны, FOMO, зависть или облегчение скуки для пользователя и понимание намерений и желаний потребителя, а также возможность показать нужное рекламное объявление нужному пользователю для рекламодателя.
Понимание архитектуры
Однажды я занимался тестированием части мобильного поиска. В типичной архитектуре поиска есть «домены» с триггерными ключевыми словами. В большой поисковой системе разные домены обрабатываются разными командами и подсистемами. Одна из уязвимых областей в архитектуре заключалась в том, каким образом индексируются наборы ключевых слов. Чтобы решить эту проблему, я написал несколько скриптов синтетического мониторинга (тогда это еще так не называлось), чтобы периодически выполнять поиск по наборам ключевых слов, за которые отвечала моя команда. Это был простой скрипт, но он позволил нам снизить MTTR примерно до 2 часов.
Итак, главный вывод: попросите старшего инженера или архитектора провести вас через архитектуру системы и задайте уточняющие вопросы. Это позволит выявить слабые места и, следовательно, потенциальные причины проблем.
Также интересуйтесь распространенными паттернами проектирования систем. На YouTube есть много каналов, посвященных этой теме. Помните,
Если вы не знаете, как что-то построено, вы не узнаете, как это должно быть протестировано.
Понять историю программного обеспечения
Однажды мне поручили тестировать приложение Fantasy Sports для iOS. Это было всего спустя несколько лет после того, как приложения для iPhone и iPad стали популярными. Излишне говорить, что разработчики не только были новичками на этой платформе, но из-за неопределенного характера компании в то время в коде было достаточно много изменений. Это привело к появлению неиспользуемого или недостаточно используемого кода, дублированию кода и большому техническому долгу. Нужно ли говорить, что качество кода было плохим, а значит, и качество продукта тоже.
В таких ситуациях вы не можете ожидать тестируемого кода, так как требуется серьезный рефакторинг. Лучшее, что вы можете сделать, — это написать автоматизированные E2E-тесты или провести ручное тестирование, пока команда разработчиков не найдет ресурсы и бюджет для полного перепроектирования или создания продукта с нуля.
Понять команду инженеров
Все команды инженеров (или разработчиков) отличаются друг от друга. Каковы их сильные и слабые стороны? Кто в команде с наибольшей вероятностью может быть источником багов? Насколько зрелыми являются их процессы разработки? Один из ключевых моментов, на который я обращаю внимание, — насколько хорош процесс код-ревью и насколько активно команда в целом участвует в нем. Много ли обзоров, в которых присутствует только "LGTM"? Еще одна область, на которую следует обратить внимание, — это покрытие юнит-тестами. В статье «Юнит-тесты и код-ревью: основа качества программного обеспечения» я объясняю, как юнит-тесты и код-ревью формируют прочный фундамент для достижения высокого качества кода и как они усиливают друг друга.
Конечно, весьма очевидным показателем является также количество багов, которые производит команда. Другими очень показательными метриками являются: (a) профиль устаревания багов команды (b) сколько инцидентов в продакшене было приписано коду команды (c) сколько багов, о которых сообщает служба поддержки, приписывается команде.
Чем менее зрелой является команда разработчиков, тем более ценными являются сквозные (end-to-end, E2E) тесты. По мере того, как команда разработчиков вырастает до более контрактного подхода к разработке программного обеспечения, команда тестирования может перейти к более контрактному подходу к тестированию.
Понимание возможностей и ресурсов команды тестирования
Давайте признаем, что у вас никогда не будет всех необходимых ресурсов. По своей сути QA или организация тестирования всегда будет центром затрат. Потратьте время на то, чтобы понять, какие сильные стороны и навыки привносит каждый член команды тестирования. Дополните их навыки необходимыми инструментами для тестирования, чтобы они приумножили силы команды.
Понять команду разработчиков продукта
Как менеджеру по тестированию, вам необходимо установить прочные отношения с коллегами по продукту. Поймите, что продукт или функция приносит бизнесу. Получите хорошее представление о приоритетах команды продукта и о том, как они хотят продвинуться вперед с помощью пересмотра и изменения фичей. Это позволит вам лучше спланировать ресурсы команды для проектов в будущем.
Кроме того, обеспечения качества — это командный спорт. Привлекайте своих коллег по продукту к работе над качеством. Они тоже хотят, чтобы продукт радовал пользователей. В конечном итоге они хотят получить продукт, которым они могут гордиться.
Поймите бизнес
Я не могу не подчеркнуть, насколько это важно: понять бизнес. В конце концов, именно бизнес оплачивает счета. Направьте свои усилия по тестированию на то, что наиболее важно для людей, которые платят зарплату вам и вашей команде. Стремитесь понять сложности, которые привносит в продукт сама природа бизнеса.
Разработайте глубокое понимание цены качества. Другими словами, какова альтернативная стоимость отсутствия QA в компании. Что может упасть и какова будет стоимость для бизнеса, если это произойдет. Это даст вам представление о том, какую ценность приносит тестирование.
Заключение
В этой статье я изложил несколько идей подхода к управлению тестированием. Все начинается с понимания ключевой проблемы в разработке программного обеспечения: укрощение сложности. Для этого вам нужно понять источники сложности, а также команды и людей, вовлеченных в ее решение. Качество — это командная работа, а менеджер по тестированию — это организатор и координатор усилий по сдерживанию и управлению этой сложностью. Если это делается хорошо, то это приносит большую пользу компании и бизнесу.
О важной роли понимания бизнеса в построении эффективной стратегии тестирования мы продолжим говорить на открытом уроке.
На этом уроке вы узнаете, как понять свою ответственность, определить, является ли ваш объект работы продуктом или проектом, в какой стадии развития он находится и какие у него бизнес-цели. Это важно для построения эффективной стратегии и процесса тестирования, который поможет сократить расходы и увеличить прибыль для бизнеса. Вы также познакомитесь с основной терминологией, необходимой для эффективного общения с бизнес-заказчиками. Вы поймете, как понимание стратегии бизнеса влияет на роль QA и как это помогает определить задачи и действия QA-специалистов в соответствии с требованиями бизнеса.
Основные темы открытого урока:
Различия между IT-продуктом и проектом и их влияние на стратегию тестирования.
Жизненный цикл проекта и продукта: что следует учитывать в разных этапах развития.
Важные артефакты для изучения вашей зоны ответственности: CJM, user story map, портреты ЦА и другие инструменты.
Влияние бизнес-метрик на подходы к тестированию: как определить приоритеты и модель тестирования, исходя из их влияния на ключевые показатели бизнеса.
Записаться на открытый урок можно на странице курса "QA Lead".