[Перевод] На ком лежит ответственность за качество программного обеспечения?

Agile методология разработки программного обеспечения и DevOps, и в особенности их упор на юзер экспириенс, обращают наше внимание на людей, стоящих за продуктами. Но действительно ли процесс разработки имеет значение или же цель попросту оправдывает средства? Лондонская P3X или People, Product, and Process Exchange в значительной степени сфокусирована на точке пересечения трех этих P, причем, пожалуй, последняя из них является наиболее интересной, поскольку объединила в себе самое большое количество акронимов – разработка через тестирование (TDD – test-driven development), разработка на основе поведения (BDD – behavior-driven development), непрерывная доставка (CD – continuous delivery), разработка на основе предметной области (DDD – domain-driven development) и многие другие – чтобы помочь командам определить, как систематически создавать лучшие системы.

Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.

Как так получилось, что с момента подписания Agile-манифеста прошло 17 лет (на момент доклада), а все еще так мало людей вышли за рамки созерцания теней на стене пещеры? Быть может, у нас все еще нет правильного диалога. Быть может, мы все еще не ведем его с правильными людьми. Или, может быть, диалог вообще не являются частью наших процессов.

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

Но что такое «качество»?

Грегори отмечала, что субъективное определение качества зачастую должно быть определено заранее. Чтобы с чего-то начать определение качества, она предложила «Пять подходов к определению качества» Дэвида А. Гарвина 1984 года:

Трансцендентный (абстрактный) – Атмосфера, врожденное совершенство, универсально узнаваемые достоинства

На основе ценности – Цена и стоимость

С точки зрения пользователя – Ценность для пользователя – это то, что будут представлять большинство людей, думая о качестве

На основе продукта – Что необходимо вашим пользователи? (например, какой именно вид молока из представленных)

На основе производства – Методы, процессы, стандарты, требования, спецификации – Правильно ли мы наладили производство?

Грегори визуализировала насущность каждой категории следующим образом, где самые насущные находятся ближе к центру, и применила это к современной agile-среде.

Подход на основе производства

Во-первых, все должно работать, поэтому производственное качество лежит в основе.

Грегори утверждает, что оно предполагает проектирование через тестирование, потому что «написание чистого кода значительно сокращает количество доработок. Давайте делать правильно с первого раза, чтобы не плодить баги. Тогда мы сможем релизить с уверенностью».

TDD, практика разработки автоматизированных тестов до самого тестируемого программного обеспечения, что, в свою очередь, приводит к уменьшению связанности этого программного обеспечения, является важной частью производственного качества. Грегори процитировала исследование, в котором говорится, что команды, которые внедрили TDD, получают в итоге на 60-90 процентов меньше дефектов, чем те, кто его не практикует, но TDD отнимает в среднем на 15–30 процентов больше времени на разработку.

Многие команды сталкиваются с этим компромиссом между качеством и скоростью.

«Может случиться, что PO (Product Owner – владелец продукта) говорит, что предпочел бы качеству реализацию новой фичи. Кто должен принимать такие решения?»

Помимо TDD, Грегори рассказала, что производственные процессы включают в себя:

Написание кода для обеспечения поддерживаемости

Мониторинг логов ошибок

Непрерывную интеграцию

Исследовательское тестирование по историям (stories)

Тестирование продукта на соответствие спецификациям

Автоматическое создание тестов для быстрой обратной связи

Статический анализ платформы

Четкое определение состояния ”Готово”

Наконец, она сказала: «Практики, такие как DevOps, стараются снизить риск клиента во время релиза их клиентам».

Подход на основе продукта

Проще говоря, если производственное качество, заключается в том, чтобы что-то работало, то продуктовое качество – это обеспечение того, чтобы оно работало должным образом. Например, мы склонны платить больше за более высокое качество и мы более снисходительны, если ломается что-то, что стоит очень дешево. Исключение могут составлять бесплатные приложения, от которых мы ожидаем, что они должны хорошо работать.

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

Вся суть заключается в двух вопросах:

Создаем ли мы то, что нужно?

Добавляем ли мы функционал, который нужен?

Это включает:

Разработку через приемочные тесты (ATDD) или, как ее иногда называют, разработка на основе сюжетного тестирования – привлечение ключевых клиентов к этапу TDD

Тестирование безопасности

Устранение ошибок, например, командный хакатон с целью найти как можно больше багов

Непрерывную доставку

Исследовательское тестирование фич

Бетаверсии

Тестирование производительности

Нагрузочное тестирование

Подход с точки зрения пользователя

Именно здесь точки зрения разнятся. Как сказала Грегори: «Разные люди выбирают разные вещи. У них разные желания, разные потребности. Если мы пытаемся предоставить покупателю право выбора, нам все-равно нужно удовлетворить его».

Но не забывайте, продолжила она, «мы также делаем предположение, что у потребителей достаточно информации, чтобы они могли принять квалифицированное решение».

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

Подход на основе ценности

Это просто то, за что люди готовы платить. Трудно судить о ценности, практически невозможно, не узнав мнение потенциальных клиентов.

Качество с точки зрения ценности, оценивается с помощью некоторой комбинации следующих факторов:

Эффективность

Практичность

Комфорт

Доверие

Сложность

Соответствие контексту

Трансцендентное качество

И, наконец, самое сложно измеримое качество – трансцендентное. Грегори объясняет, что это связано с тем, что эмоции сложно измерить, а трансцендентное качество получается сочетанием артистизма, вовлеченности и лояльности клиентов.

Как мы измеряем качество программного обеспечения?

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

Количество ошибок в продакшене

Серьезность ошибок в продакшене

Количество дней с момента последнего запуска в продакшн

Количество новых обращений в службу поддержки за X дней с момента последнего релиза

Индикатор сборки остается зеленым

Нет непройденных автоматизированных тестов (случайных сбоев)

Статический анализ кода кодовой базы не выявляет проблем

Количество исправлений на низком уровне

Одни и те же баги не всплывают повторно

Также можно существует мера качества с точки зрения пользователя в форме опросов удовлетворенности пользователей.

Однако вы не можете реально измерить качество с точки зрения продукта, ценности или трансцендентное качество. Однако вы можете обсудить и оценить все пять уровней качества. Тестирование – важный показатель качества, но Грегори напоминает, что продуктовые группы не могут отрицать ценность обсуждения качества друг с другом, с пользователями и с конкурентами.

И конечно, командам необходимо соблюдать баланс между желанием избегать ошибок и скоростью разработки.

Вся команда несет ответственность за качество

Очевидно, что обеспечение качества – или попытка решить эту неверно названную невозможность – это задача не только одного отдела тестирования, которому код просто спихивается.

Вся команда владеет качеством

«Если ваша организация, если ваша компания начинает с заботы о качестве, вы, вероятно, добьетесь успеха, потому что все остальное встанет на свои места. Все будет работать естественным образом. Но если вы начнете с идеи, что скорость – это самое главное, не обращая внимания на качество, есть вероятность, что в долгосрочной перспективе вам придется много переделывать, исправлять много неподдерживаемого кода, и ваше качество будет снижаться все дальше и дальше,» – говорит Грегори.

Но она не раскрыла никакого секретного рецепта идеального стремления к качеству.

«Какие подходы к качеству вы используете, меня не волнует, но вам нужно задаться вопросом, когда вы смотрите на ваши процессы – приводит ли это к уверенности в релизах?» – говорит Грегори. «Измеряет ли качество процесса качество продукта?»

Она процитировала соавтора BDD Book 1: Discovery Себа Роуза: «Когда мера становится целью, она перестает быть хорошей мерой».

«Независимо от того, как вы это измеряете, это должно привести к разговору, дискуссии о том, что вам нужно», – говорит Грегори.

Она продолжила: «У команды есть качество, но нужно думать шире. Качество в процессах и качество в практике. Компетентность в вашей команде, компетентность в том, как вы доставляете программное обеспечение».

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

«Давайте встроим управление качеством в наш процесс и научимся говорить о том, что мы делаем», – сказала Грегори.

Перевод статьи был подготовлен специально в преддверии старта курса “QA Lead”. А всех желающих приглашаем на бесплатный демо урок курса по теме: “Организация тестирования при различных методологиях разработки”.

Let’s block ads! (Why?)