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

Автор оригинала: Janet Gregory Jennifer Riggins
  • Перевод

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". А всех желающих приглашаем на бесплатный демо урок курса по теме: "Организация тестирования при различных методологиях разработки".

OTUS. Онлайн-образование
Цифровые навыки от ведущих экспертов

Комментарии 22

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

    А нашем деле, когда все системы управления бизнесом уже давно программные, руководитель подразделения IT сам себе постановщик задач, сам себе контролер/тестировщик и сам себе аудитор.

    Это одна из причин плохого качества софта и его применения.
      –1

      Нет проблем делать софт без багов, но он будет в 10 раз дороже и в 10 раз дольше делаться. А это никому не надо

        +3

        Это демагогический аргумент подмены тезиса на заведомо абсурдный, потому что вопрос не ставится как "как написать софт без багов", он ставится, например, как "можем ли мы написать софт со стабильно меньшим числом багов за те же деньги" или "сколько нужно денег и на что конкретно из потратить, чтобы уменьшить число багов до приемлемого (и какое число и степень серьезности приемлемы)".


        А аргументы вроде вашего служат только тому, чтобы напугать несведущих и продолжать работать с как можно более мутными критериями, чтобы особенно не утруждать себя.


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

          0

          Вы правы, но не совсем. Есть пример — был в статье о том, как писался софт для космоса в НАСА. Дорого и медленно. Но без багов.

            +1

            А не об Марс ли разбился посадочный модуль из-за ошибки в расчётах (не верные единицы использованы были):
            https://ru.m.wikipedia.org/wiki/Mars_Climate_Orbiter


            Ошибки будут всегда. Нужно стремиться минимизировать от них ущерб.

              0

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

              +1

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

                +1

                Я не понимаю, с чем вы спорите. Да, процессом разработки, как и любым другим процессом, часто руководят идиоты, ставящие взаимоисключающие требования. Но вопрос не в том, как бывает, а в том, как сделать лучше. И сделать лучше, как раз, более всего возможно (технически) именно тогда, когда творится бардак, потому что на фоне бардака почти что угодно — лучше.

              +2
              Это неправда, гораздо чаще я встречал системы, которые стоят в 10 раз меньше и работают в 10 раз лучше, чем конкуренты. Все дело в команде, одну вещь делают те, кто уже 10 раз это сделал, а другую те, кто делает ее в первый раз.
              +1
              Несомненно ответственность за качество программного обеспечения лежит на его разработчике.
                +2

                Очень спорно. Что бы вина всегда однозначно была на разработчике нужно ему ставить максимально детализированную задачу.
                Постановка должна быть полной и не иметь разночтений.
                Но это бывает только у сферических коней, да и то при условии абсолютного вакуума.
                Очевидно, что обычным языком такую постановку не сделать. Значит надо воспользоваться более формализованными средствами — uml, например. Oh wait!..

                  +1
                  Представьте себе, что вы разработчик. К вам приходит руководитель и говорит: «срочно нужно вставить в программу новую функцию А.Б.В. Времени в обрез. Проект горит, а также горят другие проекты, с которых мы вас снимаем ради этой функции».

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

                  А потом кто-то из клиентов попадает на ошибку в вашей программе. Подаёт на фирму в суд. Фирма подаёт регрессный иск к вам — ведь вы разработчик. И вы несёте ответственность. Хорошие перспективы?
                    0
                    Как вариант, надо воткнуть большой и развёрнутый TODO, объясняющий почему функция А.Б.В. реализована именно так, и как её нужно реализовать в будущем, в код, и оповестить всех остальных насчёт этого.
                      0

                      Ну что вы гиперболизируете? Следуя вашей логике, на того, кто отвечает за качество и кто бы это ни был, компания должна подавать в суд. Если отдел QA отвечает за качество, то компания на него должна подавать в суд? Сейчас же этого ни в одной компании не происходит. Ответственность действительно должен нести разработчик, но естественно не материальную, как вы описали. И такие ситуации, когда сроки горят, опытные разработчики сразу менеджера ставят в известность, что при такой постановке качество может пострадать. Грамотный менеджер либо поменяет сроки, либо возьмёт риски на себя. А с неграмотными лучше не работать

                        0
                        А потом кто-то из клиентов попадает на ошибку в вашей программе. Подаёт на фирму в суд.
                        Бесполезно. Практически в любом EULA написано примерно следующее: «Компания не несёт ответственности за убытки, причиненные использованием настоящей программы».
                      +2
                      Проще говоря, если производственное качество, заключается в том, чтобы что-то работало, то продуктовое качество — это обеспечение того, чтобы оно работало должным образом.

                      Производственное качество — это качество процесса разработки.
                      Продуктовое качество — качество конечного продукта.

                      В статье вообще много, ну даже сложно сказать что воды, возможно такой перевод.

                      А если в двух словах — идейная ответственность за качество лежит в первую очередь на заказчике, который обеспечивает ресурсами (деньгами) свою идею.
                      А техническая — ответственность за качество программного обеспечения лежит на техлиде/архитекторе, качество разработки — на менеджере.
                        +1
                        идейная ответственность за качество лежит в первую очередь на заказчике, который обеспечивает ресурсами (деньгами) свою идею.
                        Еще бы донести эту замечательную мысль до стейкхолдеров. :-) Но мысль as agile as it could get. Супер, снимаю шляпу, прекрасная формулировка!
                        +3
                        Я понимаю что вопрос/комментарий не к переводу, а к первоисточнику, но меня сильно удивила цифра про «исследование, подтвердившее увеличение длительности проекта на 15-30% при использовании TDD». Оказалось, что это хороший пример ситуации, когда категорически не следует верить цитирующим, какими бы регалиями они не обладали, а искать первоисточник.

                        Первоисточник нашелся, это исследование Realizing quality improvement through test driven development: results and experiences of four industrial teams by Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams, опубликованное Microsoft вот тут
                        www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf

                        Интересно, что аннотации на самом сайте Microsoft это не совсем корректное «цитирование» про 15-30% повторяется почти слово в слово, но в работе мы видим нечто совершенно другое:

                        Прямо в абстракте: по субъективным ощущениям, время изначального написания кода увеличилось на 15-30%

                        Далее (стр 298), следом за таблицей 2, показывающей KPI команд после внедрения TDD, в статье говориться следующее, опять-таки категорически не совпадающее с «цитированием» в обсуждаемом тексте:
                        По субъективным оценкам менеджмента(sic!), время разработки выросло на 15-30%. Однако, это изменение будет компенсировано снижением эксплутационных расходов благодаря выросшему качеству. Этот эффект подтвержден практическими наблюдениями команд IBM и Microsoft.

                        К сожалению, далее, из некорректного цитирования исследования делаются выводы о «компромиссе между скоростью и качеством». В случае TDD этого «компромисса» просто нет, посколько вся «экономия» моментально съедается отладкой и интеграцией.

                        Компромисс между ценой/скоростью и качеством существует в совершенно другом измерении, но он не о «допустимом количестве багов». Он, скорее, о том что объем реализации требований во всем диапазоне FURPS+ сильно зависит от имеющегося времени и средств. Но есть принципиальная разница между требованиями или ожиданиями которыми пожертвовали для сокращения бюджета или сжатия сроков, и некачественным кодом. А работоспособность продукта, как и свежесть рыбы в известной цитате из Мастера и Маргариты, бывает только одна.

                        Особенно странно слышать это в контексте Agile, где, «только работающий продукт является измерением прогресса», и «постоянное стремление к техническому совершенству», и, в конце-концов, definition of done как ключевой элемент обеспечения прозрачности создаваемых артефактов.
                          0
                          Смотрю в статю от MS и очень слабо верится, что TDD снизило количество багов до 9% от дефектов другой сравномой команды в сравнимом проекте. Скорее всего сравнивают апельсины с яблоками.
                            +1
                            Мои личные наблюдениям со статьей совпадают. У меня выборка не то что бы по которой можно двойное слепое провести, но пара-тройка десятков разных команд есть. Каждый раз внедренное TDD действительно резко сокращает и время на отладку, и количество дефектов, пробравшихся в production. Даже там где был вполне себе отстроенный классический QA.

                            Но ключевое слово тут «правильно», т.е. когда полностью построена пирамида, и вся пирамида основана на бизнес-сценариях и жестко выдерживается единая стратегия тестирования на всех уровнях от unittest до acceptance. Как-то консультировал команду, как раз жаловались что у них «это ваше TDD не работает»… Оказалось что они разделили (sic!) разработку и создание авто-тестов по разным офисам! Типа тут такие крутые специалисты что царское это дело тесты писать. Ну эффект ожидаемый получился, добрая половина эффекта от TDD в том, что мы активно вовлекаем девелоперов в поддержание качества, а если этого не случилось — то с чего количество дефектов станет уменьшаться-то…

                            Ну или еще бывает — «мы перешли на TDD, тестеры теперь не нужны, экономия, все ж программисты сделают». Ну да, их же учили стратегию тестирования строить, и времени у них на это вагон прям… Короче, главное не нарваться на реализацию которая описывается известной поговоркой про отправление духовных потребностей человеком с ограниченными умственными способностями. :-) Увы, среди эффективного менеджмента таких хватает, когда с MBAсами сталкиваешься.

                          +1

                          На ком лежит ответственность?


                          На кого положили, на том и лежит. Всë остальное — шаманство и отклонение от договорëнностей/подразумеваний.

                            0
                            Кто взял отвественность — тот её и несёт. А остальном — рыночек порешает.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое