Тестирование и обеспечение качества в чем разница
Тестирование и обеспечение качества в чем разница
Почему это важно
Когда-то я работала в стартапе среднего размера. В нем не было процессных менеджеров, сертифицированных консультантов и высококлассных управленцев. Но было другое – команда энтузиастов с горящими глазами, амбициозными планами, и зарядом позитива. Мы мечтали о создании потрясающего продукта, польза, новаторство и качество которого переплюнут все известные человечеству программные разработки. И мы потихоньку начали наступать на все грабли начинающего стартапа.
«Разработчики все безответственные… Этот тестировщик неквалифицированный… Я нахожу баги через минуту использования продукта… Да вы кроме чаепитий там вообще что-то делаете?!» – выслушивали мы от директора после каждого релиза. Дальше последовало решение руководства о наборе команды опытных тестировщиков вместе с руководителем отдела. Всё это сопровождалось многочисленными разговорами о том, каким должен быть качественный продукт.
Ребята-тестировщики оказались профессионалами: заводили понятные баги, которые было приятно читать, бесконечно разговаривали с менеджером проекта, выясняя нужные и важные детали поведения продукта. Разработчики стали тратить меньше времени на исправление ошибок, но руководитель компании так и не получил того, что ожидал от внедрения тестирования в процесс разработки. Примерно через полгода случился неприятный разговор с начальством, по итогам которого выяснилось, что качество нашего продукта совсем не улучшилось, хотя затраты на разработку возросли. Оказывается, от отдела тестирования ожидали влияния на качество продукта.
И это не единичный случай – многие мои знакомые работали в похожих компаниях. Этот пример наглядно демонстрирует нам распространенное в мире IT заблуждение: многие думают, что тестирование само по себе способно улучшить качество ПО.
Отличия тестирования и обеспечения качества
В соответствии с глоссарием ISTQB, Тестирование – это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ, с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. Только вдумайтесь! Оценка продукта и результатов работ… Разве может оценка улучшить качество? Качество же – это способность ПО при заданных условиях удовлетворять установленным или предполагаемым потребностям.
Качество продукта улучшилось? Нет, конечно. В рамках процесса тестирования мы работаем с готовым продуктом – заботимся о том, чтобы вовремя найти и устранить критичные дефекты, снижая уровень риска. У нас появляется ценнейшая информация о работе продукта и его слабых местах, и мы можем передать ее заинтересованным лицам. Те, в свою очередь, смогут использовать ее как опорную точку для организации комплексных мероприятий, направленных на работу с процессами постановки задач, разработки, тестирования и анализа результатов.
Именно на специалистах по обеспечению качества лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла производства, а также обеспечение уверенности в том, что эти процессы выполняются. Таким образом, если мы хотим улучшать качество продукта, мы нанимаем на работу не тестировщиков, а специалистов в области QA.
Что делает QA-специалист:
В идеальном мире с идеальными процессами тестировщики вообще не нужны! Специалисты QA примут превентивные меры, и на долю тестировщика останется так мало работы, и она будет настолько примитивная, что каждый участник процесса сможет отвечать за выполнение необходимых критериев на вверенном ему участке функционала. На тему современного обеспечения качества без бюрократии и простоев очень советую прочитать потрясающую книгу «Как тестируют в Google». Описанные в ней идеи просты и понятны, и в то же время от них веет масштабностью и результативностью.
Что могут сделать тестировщики для улучшения качества продукта
Многие ли компании могут позволить себе целый отдел обеспечения качества? Задумаемся: действительно ли тестировщики – такие ограниченные в правах, замкнутые в оковы регламентов и инструкций люди, которые не в состоянии повлиять на качество продукта? Чаще всего, это не так. Все, кто хочет изменить мир к лучшему, начинают с себя, со своей работы над продуктом. Например, руководители в тестировании – с работы своей команды, ведь качественная организация процесса позволяет повысить эффективность тестирования.
Основой для любых изменений служит оценка деятельности и анализ результатов. Оценка формируется на основании сбора статистики по конкретным метрикам. Выбор метрик осуществляется после определения целей проекта применительно к ожиданиям от тестирования и выявления главной проблемы проекта на текущий момент. Несомненно, ожидания формируются каждым участником цикла разработки: менеджером проекта, разработчиками, аналитиками, специалистами службы поддержки.
Например, если есть жалобы на пропускаемые дефекты, то мы начинаем их фиксировать для анализа причин пропуска. Допустим, после пары итераций станет понятно, что причина в недостаточном покрытии функционала тестами. Отлично! Начинаем фиксировать процент покрытия. Ага, у нас недостаточно тестов. Почему? Да потому, что сроки на подготовку и тестирование слишком сжатые, и мы не успеваем писать тесты в требуемом для полного покрытия объеме. Оценка сроков адекватная, только вот передача версии в тестирование происходит позже запланированной даты, а сроки релиза отодвигать нельзя. В чем проблема? Разработчики не успевают – их оценка на разработку всегда оказывается на 2-3 дня меньше фактического времени на реализацию. Почему? Допустим, менеджер подбрасывает незапланированные задачи в середине итерации. Зачем? Заказчик требует – он не видит разницы между разработкой сайта-каталога и сайта-магазина.
Всё, корень проблемы ясен, и можно действовать. Само собой, решение этой проблемы не ляжет на плечи отдела тестирования, а вот менеджеру проекта будет гораздо проще объяснить клиенту важность стабилизации задач версии, имея красивые таблички статистики и графики влияния незапланированных задач на качество продукта на выходе. За чашечкой чая заказчик и менеджер решат: либо стоит развивать продукт итеративно, стараясь соблюдать поставленные сроки – и тогда придется умерить желания заказчика; либо любое изменение в составе версии будет сопровождаться повторной оценкой и откладыванием срока релиза.
Пример не самый впечатляющий, зато из реального опыта. Самое важное правило внедрения улучшений: сначала формулируем цель и выявляем проблемы в ее достижении, а затем решаем, что нам надо замерять для оценки изменений. И, конечно, без сплоченности всех членов команды и без общей заинтересованности в успехе проекта сбор метрик совершенно бесполезен – собранные результаты не получится даже адекватно оценить, чтобы использовать их в дальнейшем.
Влияние процесса тестирования на качество ПО
Итак, тестирование не влияет на качество напрямую. Оно позволяет на протяжении всего жизненного цикла ПО оценивать и контролировать соответствие программных продуктов заданным параметрам качества. Контроль гарантируется через предоставление информации о состоянии продукта на любой стадии его жизненного цикла после выполнения соответствующих проверок. Наряду с такими мерами, как разработка планов обеспечения качества, внедрение стандартов в процессы и регулирование отношений между участниками проекта, тестирование позволяет обрести уверенность в том, что принимаемые меры эффективно или неэффективно влияют на качество разрабатываемого ПО.
Тестирование, обеспечение качества и контроль качества: в чём разница?
Тестирование и обеспечение качества (Quality Assurance, QA) для многих «братья-близнецы», отличить которые друг от друга может только специалист IT-сферы. Несмотря на их взаимосвязь, это совершенно разные термины. Кроме того, их нельзя путать с третьим понятием – контролем качества (Quality Control, QC).
В сегодняшней статье мы расскажем подробнее о каждом из вышеперечисленных видов деятельности и окончательно расставим все точки над i в этом вопросе.
Тестирование vs. обеспечение качества
Так в чем же различие между этими понятиями и почему тестировщиков часто называют специалистами в сфере QA?
Обеспечение качества, в сравнении с тестированием, является более широким понятием. QA помогает оценить правильность протекания технологических процессов на всех этапах разработки ПО для обеспечения его высокого качества.
Кроме тестирования, QA также включает в себя контроль качества, который отвечает за соблюдение предъявляемых к системе требований. Если представить все три термина в виде иерархии, то тестирование окажется частью QC, а QC – частью QA.
Таким образом, тестирование заключается в большей степени в проверке работоспособности программного продукта и поиске дефектов, в то время как для QA важно также обеспечить соблюдение стандартов и предотвратить появление ошибок и багов в ПО.
Зачастую профессии тестировщика ПО и QA-инженера воспринимаются тождественно, однако в выполняемых специалистами задачах существует ряд отличий.
Особенности обеспечения качества
Процесс QA включает в себя подготовку плана тестирования, планирование и проведение тестирования, а также управление его результатами. Это помогает определить требования как для разработки ПО, так и для проверки его качества.
В обязанности QA-инженера зачастую входят:
В работе QA-инженера также очень много коммуникации, в том числе с заказчиком. Но не стоит пугаться. В зависимости от компании и проекта часть обязанностей QA-инженер может разделять с бизнес-аналитиками, техническими писателями или тестировщиками, поэтому одна из отличительных черт процесса QA – вовлечённость всей проектной команды.
Исходя из этого, соотношение работы QA-инженера по планированию и по тестированию может сильно отличаться.
Что нужно знать о контроле качества?
В QA существует более узкая специализация – это контроль качества. Специалисты этой сферы занимаются анализом результатов тестирования и ликвидацией обнаруженных дефектов. Процедура QC позволяет обеспечить соответствие программного продукта определённому набору критериев и требований, установленных на этапе обеспечения качества.
По сравнению с QA контроль качества требует больше времени и может быть выполнен только после этапа обеспечения качества.
Чтобы процесс контроля качества прошёл максимально эффективно, на проекте нужно:
Если выявляется отклонение, его корректируют, а процедуру повторяют. QC нужен, чтобы убедиться, что все внесённые изменения дали нужные результаты.
Таким образом, основная задача контроля качества – предоставлять информацию о текущем качестве программного продукта на всех этапах разработки.
Что же тогда делает тестировщик?
Профессия тестировщика предполагает составление технической документации, разработку автотестов и их прогон, выявление и анализ ошибок в системе, разработку сценариев тестирования, документирование и многое другое.
В действительности так сложилось, что должности тестировщика и QA-инженера стали синонимами. Даже в документации для заказчика тестировщики обычно записываются как QA Engineers, хотя, как мы уже поняли, выполняемые ими функции отличаются.
Сейчас в большинстве случаев специалисты начинают свою карьеру в IT именно с позиции junior-тестировщика. Это одна из самых лёгких и быстрых точек входа, особенно после прохождения курсов по тестированию ПО. Именно junior-специалисты тестируют разработку по готовым сценариям, в то время как их middle- и senior-коллеги ответственны за разработку планов и тест-кейсов.
Подведём итог
Несмотря на всю разницу между такими понятиями, как обеспечение качества, контроль качества и тестирование, у них есть общая цель, а именно, выпустить высококачественное ПО, которое сможет удовлетворить потребности потенциального пользователя.
Пока не изобрели способ, как создать идеальное ПО, но изобрели методы, которые позволяют свести вероятность ошибок к минимуму и предотвратить их появление. Именно такими методами и являются обеспечение качества, контроль качества и тестирование.
Тестирование или управление качеством? Часть 4. Управление качеством
Эта статья завершает серию моих публикаций на тему различий между тестированием (Часть 1 — Что такое тестирование? и Часть 2 — Типы тестирования) и управлением качеством (Часть 3 — Что такое качество? и Часть 4 — Управление качеством).
Кто ответственен за качество?
Ответственность за качество лежит на всей команде. Эти слова я говорю из раза в раз, когда хочу донести суть, что не только тестировщики несут ответственность за качество. Но в реальности за качество отвечает не только команда разработки. Люди на каждом уровне предприятия вносят свою лепту. Изображение ниже — это последний слайд с нашей с Лизой Криспин (Lisa Crispin) беседой, которая состоялась в рамках серии вебинаров Agile Testing Days. На нем выделены сферы, в рамках которых люди способствуют качеству:
Организация — обеспечивая безопасную среду для вопросов и обучения
Продукт-менеджер — четкое выделяя приоритетность задач, что способствует повышению эффективности работы команды
Бизнес — понимая что и зачем мы создаем, и отвечая на вопрос “Мы создаем то что нужно?”
Команда разработчиков — создавая “это” правильно
Индивидуум — зная то, какое влияние он оказывает на качество продукта
Все начинается с организации рабочего процесса путем обеспечения психологической безопасности, где не играют в игру “найди виноватого”, и команды чувствуют, что могут экспериментировать, не боясь быть наказанным в случае неудачи.
Во многих организациях есть своего рода “Центр передового опыта” (Center of Excellence), который устанавливает процессы, которым должны следовать команды. По моему опыту, такой способ не работает, поскольку команды, которые не видят ценности в процессе, будут искать обходные пути или будут слепо следовать тому, чего они не понимают. Я добился большего успеха, работая с командами, которые начинали с малого, оценивали обстановку и адаптировались, становясь лучше с каждым изменением. В случае если эксперименты не так успешны, как вы изначально ожидали, или они окажутся провальными, эти уроки не потребуют огромных затрат, поскольку масштаб ошибки невелик.
Организация определяет желаемый или необходимый уровень качества, но каким образом достичь этого уровня качества позвольте определять разработчикам. В основном, начиная с базового определения Release Done. Конечно, есть исключения. Не каждая команда может выполнять свою работу так, как им хотелось бы, если их работа связана с другими командами. Им нужно быть хорошо скоординированными и налаживать общие процессы. Возможно, у них есть общее определение Feature Done, но у каждой команды свое определение Story Done.
Людям, занимающимся управлением продуктами, необходимо координировать свои усилия, чтобы наиболее важные части работы выполнялись своевременно. Если команды борются за ресурсы, а люди могут работать сразу в нескольких командах, эффективность снижается, и усилия, скорее всего, не сосредоточены на качестве продукта. Реализация фич может казаться самым приоритетной задачей, но иногда командам нужно потратить время на недоработки по технической части. Со временем технический долг подорвет качество продукта, поскольку с ним становится все сложнее справляться и, соответственно, добавлять новые фичи.
Заинтересованным сторонам бизнеса, будь то владельцы продукта, бизнес-аналитики или маркетологи, необходимо понимать, что именно должны создавать команды и как наиболее эффективно им донести это «что». Затем группы разработчиков могут сконцентрироваться на том, «как», и наладить свои процессы так, чтобы обеспечить качество с самого начала. Демоверсии — это один из способов получить быструю обратную связь от заинтересованных сторон, чтобы узнать, тот ли продукт мы создаем.
Еще одна группа людей, которые могут захотеть внести свой вклад в качество, — это руководство — они заботятся о соответствии нормативным требованиям и, возможно, о безопасности. Присмотритесь к своей организации, чтобы понять, как люди на разных должностях с разными целями могут воспринимать качество. Пора начинать вести об этом диалог, если вы еще этого не сделали.
Я считаю, что каждый человек в организации должен уметь сформулировать свой вклад в качество своей продукции, и все начинается с вас.
Критерии оценки качества
У нас есть много способов измерить качество наших процессов, но гораздо труднее измерить качество нашей продукции. Я обратился к коллегам в твиттере, чтобы узнать, как их команды оценивают качество, и получил множество ответов. Большинство ответов касалось метрик, уделяющих внимание процессам. Только один ответ концентрировался на пользователях, но ни один не учитывал ценность или лояльность клиентов. Респонденты, похоже, очень сосредоточились на вопросе «как».
Цитата от Лизы Криспин из моей второй книги «More Agile Testing» отлично передает мой взгляд на качество процессов.
Примеры метрик, которые я получил от респондентов в Твиттере, которые относятся к производственному качеству (процесса): количество ошибок на проде (продакшн — prod), серьезность ошибок на проде, количество дней с момента последнего пуша в прод, количество новых заявок в службу поддержки в течение пяти, десяти и тридцати дней с момента последнего пуша на прод, сколько радиатор сборки остается зеленым, капризничают ли автоматизированные тесты, статический анализ кода, количество доработок, количество ошибок, которые открываются повторно. Ни одна из них не говорит нам, ценен ли продукт для пользователей, но они хорошо удовлетворяют человеческую потребность в числах. Их легко измерить количественно, но они могут привести к неправильным выводам о качестве продукции. Даниэль Канеман (Daniel Kahneman) говорит о предвзятости и о том, как мы неверно интерпретируем показатели в своей книге «Thinking, Fast and Slow».
Важно понимать разницу между качеством процесса и качеством продукции. Например, в рамках обсуждения качества продукта люди часто хотят измерить количество ошибок, потому что это достаточно просто сделать. Однако я не думаю, что это показывает нам именно то, что мы думаем. Я считаю, что количество ошибок измеряет, насколько плох наш продукт, но не насколько хорош, особенно те, о которых сообщает клиент. Допустим, клиент сообщает о 5 мелких ошибках. Значит ли это, что качество хорошее? А что, если они сообщат о 5 серьезных ошибках?
На самом деле нет простого способа измерить качество продукции, но мы можем попробовать это сделать. Например, Изабель Эванс (Isabel Evans) представила этот график на конференции, показывая два разных продукта, которые в целом имеют одинаковые функциональные характеристики. Однако они были нацелены на совершенно разных пользователей. Одну группу не заботила скорость, но пугала возможность ошибиться (они не разбирались в технологиях). Другая группа в первую очередь ценила возможность быстро выполнять задачи и хотела гибкости в своем продукте.
В этом случае разница в ценности была не разницей в стоимости, а разницей в атрибутах. Эти организации входили в одну линейку продуктов, но не являлись конкурентами, поскольку у них была совершенно разная клиентская база. Они основывают свои показатели качества на ценности и пользовательских метриках от всех пользователей. Оба продукта создают ценность для клиента, на которого они нацелены.
Однако в таких отраслях, как страхование здоровья и коммунальные услуги, где потребителям трудно переключиться из-за отсутствия какого-либо качества, измерение лояльности, вероятно, не является хорошим показателем качества продукта.
В моем примере с кофе из моей предыдущей публикации этой серии клиенты также разные. Например, человек, который любит любой черный кофе за 50 центов, скорее всего, не купит его в дорогом кафе. Клиенты, которые предпочитают платить 5 долларов за особый вкус или отличный капучино, становятся постоянными покупателями, если им нравится кофе. Можем ли мы измерить, сколько времени люди стоят каждое утро в очереди за кофе, чтобы оценить лояльность? Или нам помогут карты лояльности? Нет простого способа, но, возможно, мы могли бы экстраполировать, посмотрев на позиции, которые продают больше, чтобы увидеть, что нравится клиентам.
Как начать разговор о качестве?
Разговор о качестве вести трудно. Я считаю, что задавать вопросы о рисках — это хорошая отправная точка. Начните со своей команды, а затем перейдите к другим заинтересованным сторонам, которых вы определили. Спросите: «Что может случиться в худшем случае?» — это был бы самый большой риск. Спросите: «Что было бы для нас лучше всего?». Это может быть то, что вы хотите измерить.
Стратегия хорошего качества должна быть основана на снижении рисков, но также должна быть направлена на достижение этого превосходного качества для ваших клиентов (упомянутого в моей последней статье), если это организационная цель или цель продукта.
Маргарет Дайнен (Margaret Dineen) выступила с докладом и написала пост об использовании ползунков для качественных атрибутов, с целью помочь начать этот разговор в команде. Определите качественные атрибуты, которые важны для вашего продукта, а затем обсудите их, используя примеры, которые помогут понять, что люди имеют в виду. Используйте ползунки, чтобы узнать, одинаково ли люди понимают, что важно. Это может быть очень показательным и может раскрыть новые темы для диалога. Я бы пошел еще дальше и поделился этой идеей с другими заинтересованными сторонами, возможно, даже с вашими клиентами, чтобы они поняли, что для них важно.
Будьте изобретательны — например, Марко Равичини (Marco Ravicini) создал карту сокровищ для своей команды. Мне нравится, что он говорит об этом как о путешествии открытий и начале долгой дискуссии. Сила заключается в том, чтобы совместно понять, что значит качество для вашей команды и вашей организации.
Пара мыслей в заключение
В соцсетях я видел фразу, которая мне очень понравилась, но, к сожалению, я не могу вспомнить, кому принадлежит ее авторство — «качество вплетено в ткань» (quality is woven into the fabric). Я думаю, что это отличный визуальный пример, который соответствует нашей более распространенной фразе «встраиваем качество» (building quality in).
Много лет назад я входил в группу обсуждения качества, состоящую из людей из всех отраслей — производства, нефти и газа, здравоохранения и безопасности и т. д. Я часто был единственным представителем разработчиков программного обеспечения среди них. Я многому научился, слушая разговоры. Одно из моих самых запоминающихся обсуждений касалось стоимости качества.
Мы часто думаем, что качество стоит чего-то… дополнительных процессов, дополнительной работы. Но недостаток качества может обойтись намного дороже, если не учитывать как материальные, так и нематериальные затраты. Это потеря возможностей или подрыв доверия и репутации. После потери их трудно вернуть. Начните с анализа и понимания ваших рисков. Именно здесь кроется ваше самое ценное тестирование.
Я постоянно развиваю свои мысли о тестировании и качестве, и я надеюсь, что вы тоже не стоите на месте. Я получаю невероятное удовольствие от разговоров на эту тему с такими людьми, как Пол Симэн (Paul Seaman) или Майк Токс (Mike Talks), которые бросают мне вызов и заставляют больше думать, когда я пишу статьи. Не стесняйтесь писать мне, если вы хотите обсудить любую из этих концепций из этой серии статей о тестировании и управлении качеством. Всего доброго!
Всех желающих приглашаем на бесплатный двухдневный интенсив «Организация тестирования при различных методологиях разработки». На занятии рассмотрим особенности организации тестирования при методологиях разработки и их правильное применение:
1. Behaviour Driven Development (BDD)
2. Acceptance Test Driven Development (ATDD)
3. Test Driven Development (TDD)
>> РЕГИСТРАЦИЯ