Управление качеством
Эта статья завершает серию моих публикаций на тему различий между тестированием (Часть 1 — Что такое тестирование? и Часть 2 — Типы тестирования) и управлением качеством (Часть 3 — Что такое качество? и Часть 4 — Управление качеством).
Кто ответственен за качество?
Ответственность за качество лежит на всей команде. Эти слова я говорю из раза в раз, когда хочу донести суть, что не только тестировщики несут ответственность за качество. Но в реальности за качество отвечает не только команда разработки. Люди на каждом уровне предприятия вносят свою лепту. Изображение ниже — это последний слайд с нашей с Лизой Криспин (Lisa Crispin) беседой, которая состоялась в рамках серии вебинаров Agile Testing Days. На нем выделены сферы, в рамках которых люди способствуют качеству:
Организация — обеспечивая безопасную среду для вопросов и обучения
Продукт-менеджер — четкое выделяя приоритетность задач, что способствует повышению эффективности работы команды
Бизнес — понимая что и зачем мы создаем, и отвечая на вопрос “Мы создаем то что нужно?”
Команда разработчиков — создавая “это” правильно
Индивидуум — зная то, какое влияние он оказывает на качество продукта
Все начинается с организации рабочего процесса путем обеспечения психологической безопасности, где не играют в игру “найди виноватого”, и команды чувствуют, что могут экспериментировать, не боясь быть наказанным в случае неудачи.
Во многих организациях есть своего рода “Центр передового опыта” (Center of Excellence), который устанавливает процессы, которым должны следовать команды. По моему опыту, такой способ не работает, поскольку команды, которые не видят ценности в процессе, будут искать обходные пути или будут слепо следовать тому, чего они не понимают. Я добился большего успеха, работая с командами, которые начинали с малого, оценивали обстановку и адаптировались, становясь лучше с каждым изменением. В случае если эксперименты не так успешны, как вы изначально ожидали, или они окажутся провальными, эти уроки не потребуют огромных затрат, поскольку масштаб ошибки невелик.
Организация определяет желаемый или необходимый уровень качества, но каким образом достичь этого уровня качества позвольте определять разработчикам. В основном, начиная с базового определения Release Done. Конечно, есть исключения. Не каждая команда может выполнять свою работу так, как им хотелось бы, если их работа связана с другими командами. Им нужно быть хорошо скоординированными и налаживать общие процессы. Возможно, у них есть общее определение Feature Done, но у каждой команды свое определение Story Done.
Людям, занимающимся управлением продуктами, необходимо координировать свои усилия, чтобы наиболее важные части работы выполнялись своевременно. Если команды борются за ресурсы, а люди могут работать сразу в нескольких командах, эффективность снижается, и усилия, скорее всего, не сосредоточены на качестве продукта. Реализация фич может казаться самым приоритетной задачей, но иногда командам нужно потратить время на недоработки по технической части. Со временем технический долг подорвет качество продукта, поскольку с ним становится все сложнее справляться и, соответственно, добавлять новые фичи.
Заинтересованным сторонам бизнеса, будь то владельцы продукта, бизнес-аналитики или маркетологи, необходимо понимать, что именно должны создавать команды и как наиболее эффективно им донести это «что». Затем группы разработчиков могут сконцентрироваться на том, «как», и наладить свои процессы так, чтобы обеспечить качество с самого начала. Демоверсии — это один из способов получить быструю обратную связь от заинтересованных сторон, чтобы узнать, тот ли продукт мы создаем.
Еще одна группа людей, которые могут захотеть внести свой вклад в качество, — это руководство — они заботятся о соответствии нормативным требованиям и, возможно, о безопасности. Присмотритесь к своей организации, чтобы понять, как люди на разных должностях с разными целями могут воспринимать качество. Пора начинать вести об этом диалог, если вы еще этого не сделали.
Я считаю, что каждый человек в организации должен уметь сформулировать свой вклад в качество своей продукции, и все начинается с вас.
Критерии оценки качества
У нас есть много способов измерить качество наших процессов, но гораздо труднее измерить качество нашей продукции. Я обратился к коллегам в твиттере, чтобы узнать, как их команды оценивают качество, и получил множество ответов. Большинство ответов касалось метрик, уделяющих внимание процессам. Только один ответ концентрировался на пользователях, но ни один не учитывал ценность или лояльность клиентов. Респонденты, похоже, очень сосредоточились на вопросе «как».
Цитата от Лизы Криспин из моей второй книги «More Agile Testing» отлично передает мой взгляд на качество процессов.
«Когда вы работаете в компании, руководители которой понимают, что упор на качество - один из лучших способов регулярно приносить пользу клиентам, ваша команда — и компания — скорее всего, добьются успеха. Частота и последовательность доставки со временем улучшаются. И наоборот, если компания делает упор в первую очередь на скорость, часто в жертву приносят качество. Техническая задолженность в виде хрупкого кода, который трудно изменить, и более медленных циклов обратной связи снижает способность команды к последовательной доставке».
Примеры метрик, которые я получил от респондентов в Твиттере, которые относятся к производственному качеству (процесса): количество ошибок на проде (продакшн — prod), серьезность ошибок на проде, количество дней с момента последнего пуша в прод, количество новых заявок в службу поддержки в течение пяти, десяти и тридцати дней с момента последнего пуша на прод, сколько радиатор сборки остается зеленым, капризничают ли автоматизированные тесты, статический анализ кода, количество доработок, количество ошибок, которые открываются повторно. Ни одна из них не говорит нам, ценен ли продукт для пользователей, но они хорошо удовлетворяют человеческую потребность в числах. Их легко измерить количественно, но они могут привести к неправильным выводам о качестве продукции. Даниэль Канеман (Daniel Kahneman) говорит о предвзятости и о том, как мы неверно интерпретируем показатели в своей книге «Thinking, Fast and Slow».
Важно понимать разницу между качеством процесса и качеством продукции. Например, в рамках обсуждения качества продукта люди часто хотят измерить количество ошибок, потому что это достаточно просто сделать. Однако я не думаю, что это показывает нам именно то, что мы думаем. Я считаю, что количество ошибок измеряет, насколько плох наш продукт, но не насколько хорош, особенно те, о которых сообщает клиент. Допустим, клиент сообщает о 5 мелких ошибках. Значит ли это, что качество хорошее? А что, если они сообщат о 5 серьезных ошибках?
На самом деле нет простого способа измерить качество продукции, но мы можем попробовать это сделать. Например, Изабель Эванс (Isabel Evans) представила этот график на конференции, показывая два разных продукта, которые в целом имеют одинаковые функциональные характеристики. Однако они были нацелены на совершенно разных пользователей. Одну группу не заботила скорость, но пугала возможность ошибиться (они не разбирались в технологиях). Другая группа в первую очередь ценила возможность быстро выполнять задачи и хотела гибкости в своем продукте.
В этом случае разница в ценности была не разницей в стоимости, а разницей в атрибутах. Эти организации входили в одну линейку продуктов, но не являлись конкурентами, поскольку у них была совершенно разная клиентская база. Они основывают свои показатели качества на ценности и пользовательских метриках от всех пользователей. Оба продукта создают ценность для клиента, на которого они нацелены.
Организации склонны использовать более квалитативные показатели качества продукции, как указано выше, на основе опросов или отзывов от службы поддержки. Мы также можем измерить такие вещи, как лояльность клиентов - как часто клиенты возвращаются или как долго они остаются нашими клиентами. Например, если компания предлагает продукт бесплатно, но получает доход от дополнительных услуг, удержание клиентов чрезвычайно важно.
Однако в таких отраслях, как страхование здоровья и коммунальные услуги, где потребителям трудно переключиться из-за отсутствия какого-либо качества, измерение лояльности, вероятно, не является хорошим показателем качества продукта.
В моем примере с кофе из моей предыдущей публикации этой серии клиенты также разные. Например, человек, который любит любой черный кофе за 50 центов, скорее всего, не купит его в дорогом кафе. Клиенты, которые предпочитают платить 5 долларов за особый вкус или отличный капучино, становятся постоянными покупателями, если им нравится кофе. Можем ли мы измерить, сколько времени люди стоят каждое утро в очереди за кофе, чтобы оценить лояльность? Или нам помогут карты лояльности? Нет простого способа, но, возможно, мы могли бы экстраполировать, посмотрев на позиции, которые продают больше, чтобы увидеть, что нравится клиентам.
Вы знаете, какую нишу занимает ваш продукт? Есть ли у вас возможность удержать потребителя, несмотря ни на какие ваши эксперименты? Или вам нужно постоянно беспокоиться о том, что ваши клиенты уйдут, если их опыт ухудшится? Думали ли вы о том, что вы можете сделать, чтобы повлиять на качество своей продукции? Когда вы смотрите на метрики, не переходите сразу к простым - продолжайте задавать сложные вопросы, чтобы начать отслеживать правильную информацию. Спросите себя: «Какую проблему вы пытаетесь решить?»
Как начать разговор о качестве?
Разговор о качестве вести трудно. Я считаю, что задавать вопросы о рисках — это хорошая отправная точка. Начните со своей команды, а затем перейдите к другим заинтересованным сторонам, которых вы определили. Спросите: «Что может случиться в худшем случае?» — это был бы самый большой риск. Спросите: «Что было бы для нас лучше всего?». Это может быть то, что вы хотите измерить.
Стратегия хорошего качества должна быть основана на снижении рисков, но также должна быть направлена на достижение этого превосходного качества для ваших клиентов (упомянутого в моей последней статье), если это организационная цель или цель продукта.
Маргарет Дайнен (Margaret Dineen) выступила с докладом и написала пост об использовании ползунков для качественных атрибутов, с целью помочь начать этот разговор в команде. Определите качественные атрибуты, которые важны для вашего продукта, а затем обсудите их, используя примеры, которые помогут понять, что люди имеют в виду. Используйте ползунки, чтобы узнать, одинаково ли люди понимают, что важно. Это может быть очень показательным и может раскрыть новые темы для диалога. Я бы пошел еще дальше и поделился этой идеей с другими заинтересованными сторонами, возможно, даже с вашими клиентами, чтобы они поняли, что для них важно.
Будьте изобретательны — например, Марко Равичини (Marco Ravicini) создал карту сокровищ для своей команды. Мне нравится, что он говорит об этом как о путешествии открытий и начале долгой дискуссии. Сила заключается в том, чтобы совместно понять, что значит качество для вашей команды и вашей организации.
Пара мыслей в заключение
В соцсетях я видел фразу, которая мне очень понравилась, но, к сожалению, я не могу вспомнить, кому принадлежит ее авторство — «качество вплетено в ткань» (quality is woven into the fabric). Я думаю, что это отличный визуальный пример, который соответствует нашей более распространенной фразе «встраиваем качество» (building quality in).
Много лет назад я входил в группу обсуждения качества, состоящую из людей из всех отраслей — производства, нефти и газа, здравоохранения и безопасности и т. д. Я часто был единственным представителем разработчиков программного обеспечения среди них. Я многому научился, слушая разговоры. Одно из моих самых запоминающихся обсуждений касалось стоимости качества.
Мы часто думаем, что качество стоит чего-то… дополнительных процессов, дополнительной работы. Но недостаток качества может обойтись намного дороже, если не учитывать как материальные, так и нематериальные затраты. Это потеря возможностей или подрыв доверия и репутации. После потери их трудно вернуть. Начните с анализа и понимания ваших рисков. Именно здесь кроется ваше самое ценное тестирование.
Я постоянно развиваю свои мысли о тестировании и качестве, и я надеюсь, что вы тоже не стоите на месте. Я получаю невероятное удовольствие от разговоров на эту тему с такими людьми, как Пол Симэн (Paul Seaman) или Майк Токс (Mike Talks), которые бросают мне вызов и заставляют больше думать, когда я пишу статьи. Не стесняйтесь писать мне, если вы хотите обсудить любую из этих концепций из этой серии статей о тестировании и управлении качеством. Всего доброго!
Переводы предыдущих частей: Часть 1, Часть 2, Часть 3.
Материал подготовлен в рамках курса «QA Lead».
Всех желающих приглашаем на бесплатный двухдневный интенсив «Организация тестирования при различных методологиях разработки». На занятии рассмотрим особенности организации тестирования при методологиях разработки и их правильное применение:
1. Behaviour Driven Development (BDD)
2. Acceptance Test Driven Development (ATDD)
3. Test Driven Development (TDD)
>> РЕГИСТРАЦИЯ