что такое качество продукта в тестировании
Что такое качество продукта в тестировании
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Евгений Марченко
Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами.
Попробуем ответить на вопросы:
Что такое качество программного обеспечения?
В нашем первом выпуске мы попытаемся дать определение терминами качество и качество программного обеспечения.
Основной проблемой в управлении качеством является тот факт, что определение качества слишком неясное и неоднозначное. Это вызвано тем, что обычно термин качество понимается неправильно. Такая путаница может объясняться несколькими причинами.
Первая, качество это не отдельно взятая идея или понятие, скорее многомерная и разноплановая концепция.
Вторая, для любого понятия и определения существует несколько уровней абстракции, например, когда люди говорят о качестве, одна часть понимает под этим слишком широкий и размытый смысл, в то время как другая может ссылаться на конкретное определение и значение.
Третья, термин качество является неотъемлемой частью нашего повседневного общения, однако общепринятое и профессиональное использование может быть весьма сильно отличаться.
Популярный взгляд на качество
Общепринятое мнение о качестве таково, что это нечто нематериальное и «неосязаемое» — о нем могут вестись споры и дискуссии, его можно критиковать и восхвалять, но взвесить и измерить качество невозможно. Такие выражения как «хорошее качество» и «плохое качество» служат наглядным примером, как люди говорят о чем-нибудь неопределенном для них, то, что они не могут четко характеризовать и определить. Такое мнение отражает тот факт, что люди воспринимают и интерпретируют качество по-разному. Подразумевается, что качество не может быть контролируемым и управляемым, и тем более оно не может быть количественно измеримым. Такой взгляд ярко контрастирует с профессиональным подходом к управлению качеством — качество это четко определенная величина, которую можно измерить и проконтролировать, она поддается управлению и улучшению.
Другое популярное мнение, что качество неразрывно связанно с роскошью, первым сортом и тонким вкусом. Дорогой, досконально продуманный и более технически сложный продукт рассматривается как гарантия высочайшего качества, нежели более дешевые аналоги. Следуя такой логике Кадиллак — это качественная машина, а Шевроле нет, невзирая на надежность и количество поломок; или же HI-FI система это качественная система, а обыкновенное радио — нет. Согласно такому подходу, качество ограниченно определенным классом дорогостоящих продуктов с замысловатой функциональностью и классовым продуктам. Проще говоря, едва ли недорогой продукт будет классифицирован как качественный продукт.
Профессиональный подход к качеству
К сожалению, такое неопределенное и расплывчатое представление не может быть использовано для улучшения процессов разработки программного обеспечения. Следовательно, необходимо дать четкое и удобное для работы определение. В 1979 году Crosby определил качество как «соответствие требованиям» («conformance to requirements»), а Juran и Gryna в 1970 определили качество как «пригодность к использованию» («fitness for use»). Эти два определения тесно связанны и прекрасно согласуются, как мы увидим позже.
«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Позже, на этапе разработки, производятся регулярные измерения разработанного продукта, для определения соответствия требованиям. Любые несоответствия должны рассматриваются как дефекты – отсутствие качества. Например, спецификация на определенную модель радиостанции может требовать возможности принимать определенную частоту радиоволн на расстоянии более чем 30 километров от источника вещания. В случае, если радиостанция неспособна выполнить данное требование, она не удовлетворяет требования к качеству и должна быть признана негодной и некачественной. Исходя из тех же принципов, если Кадиллак соответствует всем требованиям к машинам Кадиллак, значит это качественная машина. Если Шевроле соответствует всем требованиям к машинам Шевроле, следовательно, это тоже качественная машина. Эти две машины могут быть совершенно разными по стилю, скорости и экономичности, но если обе измерять по стандартным для них наборам, тогда они обе будут являться качественными машинами.
Определение «Пригодность к использованию» принимает во внимание требования и ожидания конечных пользователей продукта, которые ожидают, что продукт или предоставляемый сервис будет удобным для их нужд. Однако разные пользователи могут использовать продукт по-разному, это означает, что продукт должен обладать максимально разнообразными вариантами использования. Согласно определению Juran каждый вариант использования это характеристика качества и все они могут быть классифицированы по категориям в качестве параметров пригодности к использованию.
Эти два определения качества («соответствие требованиям» и «пригодность к использованию») по существу одинаковы. Разница в том, что вариант «пригодность к использованию» указывает на важную роль требований и ожиданий заказчика. Роль заказчика, связанная с качеством, никогда не может быть переоценена. С точки зрения заказчика, качество продукта, который он приобрел, состоит из множества различных факторов, таких как: цена, производительность, надежность и т.д.
Только ваш заказчик может рассказать вам о качестве, потому что это единственное что он действительно покупает. Заказчик не покупает продукт. Он покупает ваши гарантии того, что все его ожидания к продукту будут реализованы.
Guaspari ”I Know It When I See It”
Выводы
Давайте еще раз попытаемся дать определение качеству с точки зрения заказчика или пользователя продукта.
Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно.
А теперь посмотрим на точку зрения разработчика.
Качество — это соответствие специфицированным и собранным требованиям делает ли данный продукт все то, что указано в требованиях.
Проблема в том, что специфицированные и собранные требования это обычно лишь часть всех реальных требований и ожиданий заказчика. Где же правильное определение качества?
Качество это соответствие реальным требованиям, явным и неявным. Очень часто неявные требования настолько очевидны для заказчика или пользователя, что он даже не предполагает, что они неизвестны разработчикам. Для примера вернемся к нашим автомобилям — заказчик может детально описать требования к дизайну, параметрам двигателя, оформлению салона, цвету кузова, но нигде не указать, что шины должны быть круглыми, а лобовое стекло — прозрачным.
Заказчик будет удовлетворен только тогда, когда купленный продукт будет полностью удовлетворять его реальным и жизненным требованиям, как специфицированным, так и нет.
Тестирование или управление качеством. Часть 3. Что такое качество?
В двух последних постах Что такое тестирование? и Организация тестирования я поделилась своими соображениями об испытаниях. Хотя между понятиями «тестирование» и «качество» есть тесная связь, одно из них не обязательно подразумевает второе. Тестирование лишь дает нам какое-то представление о качестве.
Я хотела завершить эту серию публикаций постом, полностью посвященным качеству и управлению качеством, но у меня оказалось так много мыслей на эту тему, что его пришлось разделить на две части. В первой из них я расскажу о своем взгляде на качество.
Я предпочитаю использовать в отношении него термин «управление», а не «обеспечение» (QA), потому что информация, полученная в ходе тестирования, может помочь улучшить качество продукта, но не может «обеспечить» его. Проходя сертификацию на менеджера по качеству в Американском обществе качества (ASQ), я узнала, что QA подразумевает прежде всего правильную организацию процессов. Сейчас значение термина QA искажено, и зачастую он употребляется неверно, поэтому я не думаю, что он по-прежнему применим, — по крайней мере, в сфере разработки ПО.
Существует множество разных контекстов, каждый из которых требует отдельного взгляда на качество. Но в любом случае оно, как характеристика, должно быть «встроено» в продукт с самого начала, и мне нравится, когда клиенты становятся участниками этого процесса.
Самое популярное определение, которое я слышала, принадлежит Джеральду Вайнбергу: «Качество — это ценность для определенного человека». Оно мне нравится, но кажется слишком упрощенным и оставляющим за скобками некоторые параметры, которые следует иметь в виду.
Вот уже несколько лет Алан Пейдж (Alan Page) и Брент Дженсен (Brent Jensen) обсуждают современные принципы проведения тестирования. Пятый из этих принципов звучит так: «Клиент — единственный, кто может судить о качестве нашего продукта и оценивать его». На мой взгляд, как и в случае с определением Джеральда, это чересчур простая концепция. Мне хотелось чего-то более содержательного, поэтому я решила сосредоточиться на том, какой должна быть стратегия качества для продукта, над которым я работаю.
Вернемся в прошлое. Уильям Эдвардс Деминг определял хорошее качество как «предсказуемый уровень единообразия, надежности и соответствия стандартам клиента». И здесь мы также видим ориентацию на клиента. Многие из 14 принципов Деминга, описанных в его книге Выход из кризиса (Out of Crisis), по-прежнему применимы и, вероятно, останутся актуальными в будущем. Например, он говорил о «встраивании» качества и уменьшении зависимости от проверок.
Дэн Эшби (Dan Ashby) в своем посте о четырех абсолютах качества Кросби показывает, что эти абсолюты, с поправкой на контекст, все еще можно применять к программному обеспечению.
Несколько лет назад, когда я готовилась к беседе о процессах качества, Изабель Эванз (Isabel Evans) показала мне статью Дэвида Гарвина (David A. Garvin), которая снова заставила меня задуматься, что же в действительности представляет собой качество. Ниже я приведу несколько мыслей оттуда, но лучше прочитайте ее целиком. А в этой статье автор дополнительно раскрывает значение восьми параметров качества.
Люди обычно говорят о качестве, как об одной общей категории. Большая часть того, что мы можем измерить, касается выполнения процессов — я называю это «качество процесса». В свою очередь, «качество продукта» связано с конечным продуктом и опытом наших клиентов.
Подходы к качеству
Качество продукта можно рассматривать с разных сторон. Точка зрения клиента — лишь одна из них. Она показывает, насколько продукт пригоден к использованию или удовлетворяет потребностям, которые у разных клиентов могут отличаться. Мы также должны учитывать мнение других ключевых лиц, заинтересованных в качестве продукта.
Дэвид Гарвин говорит о пяти подходах к качеству. Ниже вы можете увидеть их в форме диаграммы.
Все мы смотрим на качество под разными углами, которые могут меняться в зависимости от обстоятельств. Я начну с внутреннего круга, как с самого простого, и буду постепенно двигаться наружу.
Ориентация на производство
Рассматривая цикл разработки как производственный процесс, мы должны сосредоточиться на методах, которые используем, и соблюдении требований. Наивысший уровень качества в данном случае достигается путем выполнения спецификаций, а основное внимание уделяется предотвращению неполадок и переделок. Вот почему многие разработчики тратят время на выстраивание правильного производственного процесса и оценку его качества, а также проводят тестирование, направленное на эти цели.
Однако нужно понимать, что разработка ПО отличается от производства одного и того же продукта раз за разом. Мы постоянно развиваем то, что у нас есть, меняем и адаптируем.
Вот несколько мероприятий, которые позволяют поддерживать качество разработки (производства): разработка через тестирование (TDD), написание кода с учетом удобства отладки, рецензирование кода, непрерывная интеграция, исследовательское тестирование и даже обеспечение соответствия критериям готовности. Мы оцениваем качество процесса и отвечаем на вопрос: «Правильно ли он организован?».
Ориентация на продукт
Гарвин определяет этот подход как обеспечение качества отдельных компонентов, составляющих целое. Из лучших ингредиентов получается лучший продукт.
При таком подходе производство компонентов стоит недешево, поэтому товары, сделанные из них, тоже имеют более высокую цену. Повышение качества продукта, который является качественным по умолчанию, подразумевает улучшение производительности и дополнительные возможности — что также увеличивает стоимость.
Обсуждая этот вопрос, мы с Полом Симаном (Paul Seaman) придумали интересную метафору: обычный повар не обязательно приготовит из хороших ингредиентов вкусное блюдо, но умелый шеф даже из обычных продуктов может сделать нечто волшебное. Мы должны понимать, из чего состоит наш продукт и как эти части соединяются друг с другом.
Вот несколько мероприятий, которые помогают поддерживать качество продукта: разработка на основе приемочных испытаний (ATDD) или разработка на основе поведения (BDD), а также тестирование параметров качества, таких как безопасность, производительность и эксплуатационная надежность. В этом случае мы отвечаем на вопрос: «Работает ли продукт так, как должен (или как нам хотелось)?».
Ориентация на потребителя
Взгляд на качество с точки зрения пользователя — один из самых часто используемых, но при этом очень субъективных и индивидуальных критериев.
Он подразумевает, что потребители имеют достаточно информации для оценки качества продукта. А если это не так, они могут ориентироваться на некие признаки, чтобы произвести такую оценку. Возьмем, например, чашку кофе. Я предпочитаю простой черный кофе из зерен средней обжарки, а моя сестра всегда заказывает капучино. Что это значит для вас? Кто ваш потребитель? Кто сможет оценить качество вашего продукта? Должны ли вы удовлетворить потребности большинства потребителей или ориентироваться на конкретную целевую группу?
Вот процессы, которые, по моему мнению, могут помочь поддерживать потребительское качество: разработка дизайна взаимодействия с клиентом для понимания его потребностей, ATDD, испытания с использованием тест-персон, A/B-тестирование, тестирование доступности и наблюдаемости, проведение аналитики использования продукта. Здесь мы пытаемся ответить на вопрос: «Этого ли хочет потребитель?».
Ценностный подход
Ценность продукта определяется его стоимостью и затратами на производство. Может ли он обеспечить нужную производительность по приемлемой цене? Возьмем все ту же чашку кофе: одни люди хотели бы купить ее за 50 центов, а другие могут заплатить 5 долларов. Разница в цене составляет 1000 %. Неужели бобы, из которых готовится этот кофе, так сильно отличаются друг от друга? А может, дело в обжарке? Или в чем-то другом?
Специалисты по маркетингу часто задаются этими вопросами. Чтобы найти ответы, они исследуют ценовые точки, проводят опросы среди покупателей, анализируют количество продаж и определяют, какую прибыль может принести та или иная специфическая характеристика продукта. Такие исследования позволяют подтвердить предположения и помогают организациям понять, как именно потребители используют их товары и какую ценность в них находят.
Менеджеры по продукту также заинтересованы в поддержании этой ценности. Они должны найти такие ценовые точки, которые помогут сделать предложение привлекательным для клиента и в то же время позволят им получить прибыль, чтобы не выпасть из бизнеса. Вопрос, на который нам нужно ответить, звучит так: «Представляет ли наш продукт достаточную ценность для клиента?».
Абсолютный подход
Я намеренно оставила абсолютное качество напоследок. Гарвин описывает его как «изначальное совершенство», которое способен распознать кто угодно, признак высочайших стандартов и отличных показателей. Оно с трудом поддается количественному определению, но вы узнаете его, когда увидите. Ваши чувства подскажут вам. Возможно, это вкус и аромат того великолепного капучино, который вы заказываете снова и снова.
Когда организация собирает команду специалистов для создания чего-то особенного, выходящего за рамки обыденности, получается продукт абсолютного качества. Это может быть, например, неожиданно прекрасная графика для новой игры. Однажды я работала над системой, которая должна была заменить другую — ту, что больше не поддерживалась. Когда я спросила, нравится ли новая система пользователям, мне ответили: «Да, очень!» — все потому, что она подстраивалась под их рабочие процессы, а не наоборот. Небольшой пример абсолютного качества.
Заключение
Я бы хотела, чтобы сейчас вы еще раз подумали о том, что значит качество лично для вас. Это непростая тема, поэтому ее редко обсуждают. На одном из своих семинаров я попросила участников дать собственное определение качеству конкретного продукта. Задайте этот же вопрос своим специалистам и посмотрите, о чем говорят их ответы — о качестве разработки (процесса) или все же самого продукта.
Мой следующий пост будет посвящен управлению качеством: я расскажу о тех, кто его осуществляет, о проведении измерений и о том, как создать стратегию качества.
Вы также можете прочитать пост о качестве и его стоимости, опубликованный в моем старом блоге в 2010 году. P.S. Я все еще езжу на «Мини Купере» — правда, на новой модели, которая еще шикарнее, чем я описывала в том посте. Если вы это читаете, я надеюсь, вы прочтете и комментарии тоже.
В преддверии старта курса QA Lead приглашаем всех желающих на бесплатный двухдневный интенсив в рамках которого изучим теоретические основы методов тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Изучим Example Mapping как способ протестировать технические требования. А также попрактикуемся в построении Example Mapping.
Тестирование или управление качеством? Часть 1. Что такое тестирование?
В чем заключается разница между тестированием и управлением качеством?
В последние несколько лет я часто задумывалась о том, что означает качество. У меня были и лекции на эту тему, и дискуссии с различными людьми. Недавнее обсуждение в LinkedIn направило мои мысли в новое русло: я начала рассматривать взаимосвязь тестирования и качества. Это моя первая (из двух) заметка с мыслями о тестировании. Впоследствии я опубликую как минимум одну статью, посвященную качеству.
Что такое тестирование?
Выкорчевывая сорняки в саду (очень неблагодарное дело, тем более что они отрастут завтра, если их не выдергивать с корнями), я начала проводить различные аналогии с этим процессом в контексте дискуссии о тестировании и управлении качеством. В той дискуссии был высказан следующий тезис:
«Тестирование помогает выявлять баги и недоработки — в идеях, требованиях, спецификациях, проектных решениях, модулях, компонентах и целых системах. Тестирование не предотвращает появление багов, поэтому целесообразнее заниматься именно поиском багов.
Тестирование показывает, в каком месте и каким образом сломана система или взаимосвязи в ней». — Майкл Болтон (Michael Bolton).
Я понимаю, что эти слова вырваны из контекста, но если провести аналогию с моим садом, то получится, что я могу лишь указывать на сорняки (баги), но не могу их вырывать. Я могу задавать вопросы об организации сада, но никак не могу на нее повлиять. То есть у меня нет возможности работать вместе с садовником и помочь ему каким-то образом предотвратить появление сорняков. Моя участь — задавать вопросы и выдергивать сорняки или даже просто показывать на них пальцем, а уже садовник будет решать, что с ними делать.
Лично я совсем иначе воспринимаю тестирование. Думаю, я могу спросить у садовника, как можно предотвратить появление сорняков, и предложить ему различные способы — органический подход или какие-то пестициды. Я могу обсудить с ним риски, после чего мы остановимся на каком-то варианте или отметем их все разом. Возможно, в итоге мы придем к тому, что лучший способ — заменить почву на новую, в которой уже нет семян сорняков. Станет ли меньше дефектов, если мы реализуем какое-то из предложений? Помогла ли я делу как тестировщик?
Как и наши продукты, сады постоянно растут и претерпевают изменения, и если мы не будем постоянно погашать наш «технический долг», борясь с сорняками и вырывая их с корнями, сад превратится в бесполезную непролазную чащу. Два года назад мы оставили наш сад без присмотра на две недели, когда мне нужно было отлучиться на конференцию. Когда мы вернулись, все вокруг заросло сорняками. В тот год растения плохо цвели, даже когда мы избавились от сорняков и зачистили свой «технический долг».
Но довольно аналогий. Продукты — это никакой не сад.
Что могут тестировщики?
Существует несколько взглядов на то, чем занимаются тестировщики. Кто-то считает, что тестировщики отвечают за «тестирование», то есть проверку программного обеспечения. В этом заключается суть их работы, они должны гордиться своим призванием и тщательно все тестировать, чтобы полностью раскрыть свой потенциал тестировщика.
Я не разделяю этот взгляд. Мое определение тестирования гораздо более всеобъемлющее. Я работаю в agile-командах уже 20 лет, и самые успешные из них именно те, где обязанности по тестированию ложатся на плечи всей команды. Тестировщики привносят неоценимый вклад в работу команды, но не потому, что они отвечают за все аспекты тестирования, а потому, что помогают понять, каким образом тестирование может улучшить качество продукта. Тестирование — лишь одна из составляющих понятия «качество», но к этому мы вернемся позднее.
В той же дискуссии на LinkedIn Ден Эшби (Dan Ashby) сказал следующее о тестировщиках:
«Они участвуют в дискуссиях типа „три амиго“ и обсуждают направления развития продукта, работают в тандеме с разработчиками по мере создания продукта, предлагают идеи, сотрудничают с дизайнерами, иногда выступают в роли коучей и менторов, задавая команде правильную установку в отношении качества, и борются за неугасающее внимание к качеству и тестированию продукта. Задачи тестировщиков выходят далеко за пределы тестирования».
Ден считает, что на деле тестировщики участвуют в создании продукта, даже не написав ни одной строчки кода. Мой опыт показывает, что так оно и есть.
Установка на развитие
Есть одна фраза, которая, на мой взгляд, очень удачно описывает мысленную установку, подходящую для тестировщика:
«Не стоит зацикливаться на том, где можно найти баги, как проследить за соблюдением требований или как сломать программу (или видимость ее корректной работы). Лучше сосредоточиться на том, что я могу сделать, чтобы продукт получился успешным?»
Такая мысленная установка дает тестировщикам возможность положительно повлиять на самые разные аспекты разработки. Вот несколько примеров ситуаций, когда тестировщики вносят свою лепту:
помогают делить пользовательские истории таким образом, чтобы было проще тестировать разрабатываемые функции;
участвуют в дискуссиях типа «три амиго»: запрашивают примеры, обращают внимание на неявные допущения, спрашивают о важных атрибутах качества и обсуждают планы действий при существующих ограничениях;
занимаются анализом моделей и прототипов;
участвуют в технических совещаниях и помогают найти самый простой способ реализации функций, подходя к вопросу со стороны тестирования: «Как мы будем это тестировать?»;
работают совместно с программистом или специалистом по автоматизации тестов над выбором подходящих методов тестирования и необходимых для этого данных, а также над определением уровня захвата операций для генерации автоматических тестов;
анализируют перечень тестов и их целесообразность.
Все эти мероприятия нужно проделать еще до того, как будет написана первая строчка кода, ведь это действительно помогает сделать продукт лучше. Разве нет?
Итоги
Мы все живые люди, и у каждого из нас может быть свое мнение о том, что такое тестирование, но, думаю, никто не возразит, что суть тестирования сводится к выявлению и устранению рисков. Задумайтесь, что означает тестирование именно для вас. Оно ограничивается лишь тестированием программной части или охватывает проверку идей, допущений, процесса и продукта в целом?
В следующей заметке о тестировании я рассмотрю различные виды тестирования и некоторые ситуации, влияющие на то, как мы организуем тестирование.
Перевод материала подготовлен в рамках курса «QA Lead». Если вам интересно узнать подробнее о формате обучения и программе курса, регистрируйтесь на день открытых дверей онлайн.