Качество, что за зверь и как его обнаружить

Не секрет, насколько молоды профессии контроля и особенно обеспечения качества. Их значимость для IT индустрии давно обоснована. Но и сейчас, по мнению многих соискателей, это проходная ступень, которая не требует особых знаний и навыков. В моем багаже опыт работы с ПО из разных областей — ЖКХ, платежные терминалы, интернет-провайдер, retail и наконец игры. Во всех компаниях, на разных позициях, раньше и теперь я ручаюсь за качество продукта. Казус в том, что нигде я не получила убедительного ответа к какому именно «качеству» мы стремимся. Сегодня, на должности руководителя QA, я отвечаю на этот вопрос сама и хочу провести ликбез как можно шире.

Отмечу самые популярные требования к качеству.

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

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

— «После выпуска должно быть все хорошо/ удовлетворять пользователя»
по моему мнению это требование точнее остальных, проблема только в его неточности. В погоне за симпатией пользователя, тестирование становится необъятным, никогда не достаточно времени, чтобы убедиться в качественности и выпустить достаточно хороший продукт. Приходится выбирать наиболее критичное и смиряться с «кое-какерством». Это довольно грустно. И в этих условиях появляется привычка противопоставлять качество скорости.

абсолютное качество/скорость = прибыли

Однако, я считаю, что «качество», понятие индивидуальное и не требует абсолютности, конкретное и исчисляемое. А также не существует конфликта между качеством и скоростью, так как индивидуальное качество равнозначно прибыльности и включает в себя скорость.

индивидуальное качество = конкурентоспособность = прибыли

Качество — старт


Первым, кто связал качество продукта с прибылями, выявил и описал причинно-следственные связи, стал Эдвардс Деминг, доктор в области физики, статистик и основоположник качества в производстве. Успех его работы на заводах Toyota в 80-х годах, позже был назван Японским чудом.

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

Деминг выделяет 2 типа потребителя — промежуточного и конечного. Как вычислить, кто они и чего хотят, отлично сформулировано в его «Вопросах, призванных команде взять старт». Опросник применим к любому уровню организационной структуры:

Ваша организация:

  1. Где расположен ваш отдел в общей организационной структуре?
  2. Какие товары и услуги производит и оказывает ваша организация?
  3. Как производится этот товар и оказывается услуга, с помощью каких процессов?
  4. Что случится, если ваша компания (подразделение, отдел, группа) вдруг перестанет производить продукцию и оказывать услуги?

Вы:

  1. Какие задачи выполняет ваш отдел, в чем состоит его работа?
  2. Что вы создаете или производите в отделе, что именно является результатом работы?
  3. Как вы это делаете (дайте общее описание того, что вы делаете)?
  4. Откуда вы знаете, получились ли у вас хорошие или плохие результаты (существуют ли стандарты или критерии хорошей работы)?
  5. Как были установлены стандарты?

Вопросы, касающиеся ваших потребителей:

  1. Промежуточный потребитель
    • Кто промежуточный потребитель товара или услуги, которые вы производите или оказываете (ваш персональный потребитель)?
    • Как ваш потребитель использует то, что вы производите?
    • Что произойдет, если вы допустите ошибку?
    • Как на ваши ошибки отреагируют потребители?
    • Как вы узнаете о том, удовлетворили ли вы запросы ваших потребителей (от потребителей, от босса из отчетов)?
  2. Промежуточный и конечный потребитель
    • Насколько далеко (от вашего конечного потребителя) вы находитесь, можете проследить эффект от того, что вы сделали?

Вопросы, касающиеся ваших поставщиков:

  1. Кем инициируется ваша работа (указание начальника, запрос потребителя, собственная инициатива)?
  2. Кто поставляет вам материалы, информацию, услуги и другие средства, которые нужны для выполнения вашей работы (начальник, потребитель, коллега — из вашей бригады, люди из других подразделений)?
  3. Что будет с вами, если ваши поставщики не сделают своей работы?
  4. Есть ли у них стандарты качества их работы?
  5. Как их ошибки повлияют на вашу работу?
  6. Как они обнаруживают, удовлетворили ли они ваши потребности или требования? Вы с ними сотрудничаете? Выполняете ли вы свои обязательства по отношению к ним?


Качество — составляющие


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

Конечный потребитель прихотливее, он готов платить только за полученное благо от использования продукта. Международный стандарт ISO-9126 классифицировал продукт по 6 качественным характеристикам, каждая из которых отражает укрупненное потребительское свойство.

image

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

Неконкретные качественные характеристики разбиваются на атрибуты, однозначные и измеримые. Их рекомендуется приоритизировать и сосредотачиваться на наиболее значимых с точки зрения своего личного потребителя — пользователя продукта, заказчика и команды проекта.

Качество — определение


1) Функциональность
Разумеется наиважнейшая характеристика функциональность. Остальные усиливают ее результативность или наоборот, у кого как с качеством. Одновременно она же самая сложная для формализации, «соответствие требованиям» необходимо, но недостаточно. Потребитель хочет провести время, выполнить свои задачи, получить доход, увеличить экономию и не думать о программном обеспечении, тем более не формулировать требования к нему. А также не нацелен использовать все возможные функции продукта. Качество функциональности определяется количеством бесперебойно работающих сценариев, во всех существенных контекстах потребителя. Это доказывает огромное количество литературы об исследовательском тестировании, появившееся в последние годы. Обеспечить работоспособность всего вообще во всех возможных случаях использования невозможно и не требуется. Жизненно важно выяснить контексты своих потребителей, в том числе с помощью требований к ПО. Приоритизировать их и зорко контролировать, так как любая поломка повлечет потери.

2) Удобство использования
Функциональность предоставляется еще задолго до появления первых тестировщиков на проекте, а порой и разработчиков. Один из признанных знатоков приготовления MVP (Minimum Viable Product) Рэнд Фишкин, известный за рубежом SEO-специалист и маркетолог, напоминает, что первое впечатление нельзя произвести дважды, и успешно продвигает концепцию входить на рынок с EVP (Exceptional, Viable Product), который не только полезен, но и симпатичен пользователю. Справедливо, что в условиях искушенного потребителя, характеристика удобства использования занимает второе место. Технология usability дизайна непрерывно развивается и обрастает новыми лучшими практиками, которые можно и нужно устанавливать и применять в своем продукте.

3) Переносимость
Продукт, привлекший внимание широкого круга, обычно начинает использоваться в различных условиях. Его пользователи ожидают корректной работы во всех из них. Определить стандарты переносимости помогают внутренняя и внешняя статистики, и конечно же здравый смысл. При определенной доле настойчивости, в любой компании можно получить статистику о распространенных условиях активной аудитории. Статистику о популярных трендах можно найти в интернете в свободном доступе, при этом важно учитывать по крайней мере территориальную когорту — данные по России и миру имеют свойство различаться. Здравый смысл нужен, чтобы стандарт к переносимости не включал в себя поддержку +100500 условий использования. С учетом, что у ОС, девайсов, браузеров также существуют стандарты, часть из них гарантированно будет работать одинаково или не хуже предыдущей версии.

4) Надежность и Эффективность
Первый настоящий успех продукта, по обыкновению, бьет по нему же проблемами с эффективностью и надежностью. Массовое потребление — мечта и трудность одновременно. Надежность, которая в конечном счете исчисляется временем доступности системы, должна стремиться к 100% не зависимо ни от чего. Эффективность оценивается пользователем через время отклика. Кто-то из Badoo сказал: «Будьте на 20% быстрее своего самого быстрого конкурента» и это хорошее подспорье для нахождения своей персональной нормы эффективности.

5) Удобство сопровождения
Проекты долгожители неизбежно усложняются, обрастают противоречиями, архитектурной несогласованностью. Специфика текучести кадров в IT не улучшает положение. Чем старше продукт, тем весомее значение удобства сопровождения. Документация всех уровней, от инструкций к использованию до комментирования кода и логгирования работы функций, значительно ускоряет работу с системой на всех этапах — при постановке требований, разработке, тестировании и поддержке. А в некоторых случая даже защищает от заведомо неверных решений.

Вот, пожалуй, и все. Однако должна сделать несколько оговорок:

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

  • наиболее сложная характеристика — функциональность. Реалии таковы, что ПО теперь неотделимо от сервиса, предоставляющего ПО, а это выходит за определения стандарта ISO-9126. Только знание ценностей потребителей и ориентир на них позволит выявить, какие именно функциональности важны и что конкретно они в себя включают.

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

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

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

функциональность + удобство использования + переносимость + надежность+ эффективность + удобство сопровождения + частота обновлений = индивидуальное качество

image
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 12
  • +3
    Не увидел определения качеству. Есть «диалектические» признаки, но может я невнимательно прочел, не увидел ISO-шного качества как «уровня соответствия результата заявленным требованиям».

    По моей практике, в том числе и исошной возни, которая куда-то канула и слава богу отсюда (у 1с-франчайзи может так и застряла в бытие), качество это распределение дефектов (при должном покрытии при тестировании) по критичности. Продукт признают качественным при приемке, если критичных дефектов нет, а низкокритичных мало и они устранимы в дальнейшем.

    Выглядит банальщиной, но этого достаточно при наличии всевозможных тестирований. Собственно работа с качеством это не столько работа с продуктом, а работа с процессом обеспечния качества (PMBoK впитал в себя куски ISO). Вот обеспечение всестороннего тестирования (не только конечного продукта, но и промежуточных артефактов) — собственно и есть обеспечение качества в разработке ПО.
    • 0
      Спасибо за грамотный комментарий и я не вижу противоречий…

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

      Я выработала свою стратегию на основе многих практик, стандартов, в том числе ISO, и личного опыта. И теперь представляю ее критике (тестированию).

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

      Про контроль и обеспечение качества, как процессы, уже не в этот раз
    • 0
      качество индивидуально

      Да, за этот момент спасибо. Обычно такой взгляд в корпоративных практиках не присутствует, или присутствует максимум на уровне опросника «поставьте оценку качеству от 1 до 10».
      • 0
        Когда количество переходит в качество, ему (качеству) становится проблематично дать точную количественную оценку.
        • 0
          не уверена, что правильно вас поняла… а именно свойство количества переходить в качество. Я думаю, такого не бывает. Ну или уточните пожалуйста.

          предполагаю, вы говорите о том, что не все можно посчитать, чтобы оценить и это действительно так.

          Посчитать можно не все, удобство использования не вычисляется цифрами, но качественная норма (оценка) тоже норма. Брендбуки, гайдлайны, своды правил в области юзабити, персонализированные для бренда/ проекта/продукта, могут быть мерой между «качественно/некачественно». Инициировать их может кто-угодно, в т.ч. QA.

          А вот эффективность, может исчисляться только цифрами. Никакие какчественные «быстро»-«медленно» тут неприемлемы. Сколько тестировщиков ломали голову над такими багами «Эта функция работала слишком медленно, мы пофиксили» — как было, как стало, никто не знает. Что-то сделали, проверьте.
      • 0
        С Демингом, вы, конечно, загнули. Он не работал непосредственно на заводах Тойоты, тем более в 80 годах (https://deming.org/deming-the-man/timeline). Термины «ублажение потребителя», боюсь, тоже не из его репертуара
        • 0
          Ублажение потребителя — это емкое словосочетание, которое в его риторике действительно не фигурирует. Но его 14 принципов направлены именно на это. В долгосрочной перспективе вы сэкономите время и сделаете ваш продукт более успешным, если научитесь слышать своего «потребителя» (внутреннего и конечного). И сильно облегчите себе жизнь, если научите этому своего «поставщика».

          В статье я хочу рассказать не о Деминге, хотя не скрою, его книга «Выход из кризиса. Новая парадигма управления людьми, системами и процессами», сильно утвердила лично мои взгляды. Я хочу сказать, что «качество» начинается с определения своего потребителя и понимания, что именно вы ему даете и каким образом. Поставщика, что хотите от него получать, в каком виде.

          Я отвечаю за тестирование, поэтому пример про тестирование. Что производят ручные тестировщики? На низком уровне, для внутренних потребителей они не производят ничего, кроме отчетов (о дефектах, о состоянии релиза, о рисках). Очевидно, эти отчеты, должны быть понятными, достоверными и своевременными. Для кого? Для разработчиков, руководителей проекта, саппорта. А если нет? В лучшем случае они будут приходить за уточнением и тем самым тратить время (и ваше и свое), которое могли бы не тратить. В худшем принимать неправильные решения, которые негативно повлияют на конечно потребителя.

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

          Он не работал непосредственно на заводах Тойоты, тем более в 80 годах

          ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.

          • 0
            Он не работал непосредственно на заводах Тойоты, тем более в 80 годах

            ух ты. Я перепроверю, и отпишусь. Исторические факты перевирать нельзя. Спасибо.


            в соответствии со статьей от центра сертификации и лицензирования прорыв заводов Toyota был назван Японским чудом и случилось оно на основе трудов Деминга.

            в соответствии со статьей от ассоциации Деминга император Хирохито вручил ученому «Орден священного сокровища второй степени» в 1960г. Полагаю этот год можно считать официальным признанием его работы.

            Итак, с годом, вы правы, я борщенула. Сбил с толку год публикации книги, нужно было проверить.
        • +1

          Про качество хорошо написано в статье google https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html?m=1


          Качество определяется метриками проекта. А влиять на него при росте проекта нужно путем автоматизации процессов релизного цикла.


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

          • 0
            Статья очень похожа на краткое изложение книги «Как тестируют в Google». Я даже удивлена что там нет прямой ссылки. Очень рекомендую ее к прочтению, там куда больше занимательного. Тем более, что книга уже несколько лет выпускается в русском переводе.

            И все таки, она не про качество, а про процессы контроля и обеспечения качества. Попробую объяснить разницу

            Качество определяется метриками проекта. А влиять на него при росте проекта нужно путем автоматизации процессов релизного цикла.


            метрики сами по себе не определяются, их должен кто-то определить. Кто? Допустим вы QA и взяли на себя эту задачу. Как это сделать, чтобы не строить башню из слоновой кости и не занизить планку? Структурировать эту задачу и определить для каждого пункта границы между «качественно» и «некачетсвенно». Как? Попыталась описать в своей статье.

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

            • 0
              есть прекрасная книга «дзен или искусство ухода за мотоциклом». там тоже все началось с вопроса что такое «качество»)
              • 0
                не читала. Порекомендуйте, почему ее стоит прочитать, по комментарию это не ясно. Я здесь пишу о вполне конкретных вещах и хочу понять, как ваш отклик к относится к содержанию.

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