Не секрет, насколько молоды профессии контроля и особенно обеспечения качества. Их значимость для 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 качественным характеристикам, каждая из которых отражает укрупненное потребительское свойство.



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

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

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

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

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

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

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

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

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

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

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

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