Привет, друзья. Меня зовут Илья и у меня для вас плохие новости.

С текущей скоростью роста и развития продуктов в сфере IT, многие компании в обозримом будущем должны будут придти к отказу от роли тестировщика в командах.

Для кого: статья может оказаться полезной начинающим QA инженерам, тестировщикам, разработчикам, менеджерам.

Цель статьи: знакомство тестировщиков и других участников команды, с базовыми представлениями о подходах "Обеспечения и контроля качества", а также их отличиях.

В рамках статьи мы коснёмся следующих тем:

• причины, по которым, на мой взгляд, тестировщики должны начать использовать методы работы QA и перестать ассоциировать себя с “тестерами”

• отличие “Обеспечения качества” и “Контроля качества”

• о той пользе, которую может получить команда, используя подходы "Обеспечения качества"

Хочется сразу сделать несколько ремарок,  чтобы не вызывать неприятные эмоции у знакомых с этой темой инженеров, а именно: 

• в статье QA engineer, QA и “Обеспечение качества” будут являться синонимами, несмотря на то, что это описание роли и процесса

• также синонимами для нас будут QC, tester, тестировщик, тестер, "Контроль качества"

• в статье процессы сознательно разделяются только на “Обеспечение и Контроль качества”, так как это, на мой взгляд наиболее принципиальные вещи

• всё, о чём пойдёт речь, не претендует на истину, это просто мой опыт, полученный в ходе множества попыток применения академических знаний на практике

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

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

• невозможность полноценной реализации потенциала команд разработки, использующих Agile фреймворки, при отсутствии QA процессов

• слабая связанность команды разработки и менеджмента и следующая из этого низкая эффективность их работы

• субъективное убеждение, что в ближайшие n-лет, рынок должен будет перестроиться и такая профессия как “тестер” полностью исчезнет из крупных и средних компаний

Я надеюсь, полученная информация о подходах и их отличиях, окажется полезной или хотя бы нескучной и положительно скажется на профессиональном кругозоре читающего. Начнём.

Почему сто́ит начать изучать практики QA

Касательно этого вопроса я вижу две весомые причины, первая из которых достаточно простая:

1) Возможность роста профессиональных навыков и ценности в команде.

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

2) Достижение предела штата тестировщиков и его дальнейшее сокращение.

На мой взгляд, данный предел будет связан не с финансовой стороной вопроса или отсутствием возможности найти “тестировщиков” на рынке (это, разумеется также может являться причиной). Вероятнее всего, что скорость роста и развития продуктов в сфере IT, непременно будет приводить к падению уровня качества в процессах разработки ПО, за счёт усложнения продуктов, увеличения их размеров, ростом количества команд, заинтересованных лиц, коммуникаций и кодовой базы.

Основной причиной остановки роста отделов тестирования должен стать факт, невозможности увеличения уровня качества, за счёт найма тестировщиков.

Рассмотрим небольшой пример.

Существует команда, процессы разработки которой гарантируют нам около 10 дефектов за спринт. Допустим, что эти дефекты, будут приводить к регулярному срыву спринтов. В командах, не умеющих работать с качеством, это вызовет реактивный ответ, который может звучать следующим образом: “Мы постоянно не успеваем протестировать задачи! Что у нас с тестированием?”.  Рано или поздно это приведёт к мысли о необходимости увеличения штата “тестировщиков”, так как, именно тестирование не успевает завершить итоговую работу.

Но факт заключается в том что, даже удвоив количество тестировщиков, наша команда и дальше будет производит по 10 дефектов на фичу до тех пор, пока мы не начнём уделять внимание работе с качеством. Количество людей, задействованных в поиске дефектов (тестировщиков), глобально не может изменить ситуацию. Возможно, мы будем находить баги быстрые, но сам факт написания кода содержащего ошибки и сохранение множественных циклов "тест-дефект-фикс-ревью-деплой-тест" останутся.

Далее, вероятно, будут предприниматься попытки исправить ситуацию внедрением автоматизации тестирования, но в отсутствии практик обеспечения качества, это также не может помочь. Если процесс внедрения автоматизации регресса пройдёт успешно (а мы предположим, что будет именно процесс автоматизации регресса, ввиду отсутствия понимания концепции качества), то часть “тестировщиков” будет просто иметь больше свободного времени, ведь написанные скрипты, будут выполнять работу "тестировщиков", но по-прежнему никто не будет занят работой с качеством. В совокупности это одновременно увеличит и ФОТ и размер простоя ресурсов тестирования (сложно сказать, что тестировщики не заняты работой, просто это не всегда нужная работа).

Скорость нашей доставки, предсказуемости и качества будут оставаться прежними, вплоть до момента внедрения практик работы с качеством.

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

Короткий ответ на вопрос почему, сто́ит изучать практики QA:

• рост профессионализма и осознанности 

• повышение эффективности работы команды

• поддержание разумного отношения тестировщиков и разработчиков

• возможность оценивать качество и влиять на качество

Отличие “Обеспечения качества” и “Контроля качества”

Для знакомства с процессами “Обеспечения и контроля качества” я бы хотел прибегнуть к примерам из производства, а лишь затем провести аналогии с разработкой в IT.

Чтобы понять, что представляет тот или иной процесс, мы будем использовать модели. В роли моделей у нас выступят два завода по производству кирпичей.

Контроль качества. Завод А.

Действующие лица:

• директор завода

• заказчик

• производство 

• контроль качества

Процесс работы нашего завода:

• от заказчика поступает заказ на производство 20 паллетов кирпича

• директор оценивает, что заказ достаточно простой, ему всё понятно, завод постоянно изготавливает “красные” кирпичи, срок выполнения 10 рабочих дней

• директор формирует заказ и передаёт на производство, в заказе не указаны технические условия использования кирпичей

• производство на основании полученного заказа, изготавливает по 2 палета красных кирпичей в день и отправляет их на склад

• контроль качества дожидается, пока на склад прибудет 20 паллетов красного кирпича

• на 10-ый день, контроль качества проверяет сформированный заказ: открывает паллеты, смотрит на цельность, количество, цвет, форму и другие характеристики, которыми должен обладать красный кирпич

• в ходе проведения процесса контроля качества обнаружено, что 2 паллета имеют сколы и отличия в оттенке, продукция возвращается на исправление

• заказчик прибывает на склад для осуществления приёмки

• директор сообщает, что 2 паллета пришлось вернуть в последний момент, но заказ будет готов через 1 день

• заказчик дожидается новой поставки и проверяет выполненную работу

• все кирпичи одинаковые, но они не того размера, а также ожидалось, что будут изготовлены, серые шлакоблоки, все шлакоблоки должны были быть выполнены с учётом использования под водой

• заказ отменяется директором и формируется новый

• 18 паллетов лежат на складе и занимают место

• заказ отменён, но ещё 2 палета было произведено, так как информация об отмене пришла слишком поздно, теперь кирпичи лежат на заводе,  перевозить их на склад дорого и не имеет смысла

Что мы видим из нашей модели?

1. Производство успешно справилось с задачей, соблюдая поставленные сроки.

2. Контроль качества выполнен, все кирпичи ровные и красные, именно так, как это указано в заказе, кирпичи со сколами найдены и отправлены на исправление.

3. Заказ не выполнен, завод 2 недели делал ненужную работу.

4. Дополнительные издержки связанные с хранением продукции

Контроль качества. Завод Б.

Для простоты восприятия и чтения мы не будем повторно описывать весь процесс, но выделим мероприятия, которые могли бы помочь улучшить положение нашего завода:

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

• директор собирает бригаду, которая будет занята в производстве, обсуждает поступивший заказ и его детали

• инженеры обеспечения качества фиксируют ожидания

• бригада озвучивает дату изготовления, либо предлагает обсудить изменения требований к продукту, для уменьшения сроков

• работа и сроки согласовываются между заказчиком и заводом

• инженеры по обеспечению качества в явном виде передают производственные требования на каждым этап производства

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

• инженеры по обеспечению качества предоставляют директору/заказчику промежуточные итоги

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

Хороший пример - это дефекты, заведённые по существующим приёмочным критериям, предположим что в рамках фичи у нас 20 приёмочных критериев и 2 дефекта по этим критериям.

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

А вот для "Завода Б" это могло бы значить, что уровень качества производства и соответствия ожиданиям составляет 90%. Часть продукции также была произведена неверно, как и на "Заводе А". Но с того момента, как мы получаем возможность измерить уровень качества, у нас появятся возможность и повлиять на него. Мы в силах определить меры предотвращений ошибок, а цена их исправления, становится для нас ниже (кирпичи все еще на заводе)

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

Так или иначе, используя информацию выше, мы сформулируем определения “Контроля качества” и “Обеспечения качества”

Контроль качества – это процесс, сверки реализованного продукта с имеющимися к нему требованиями, фиксация результатов и предоставление обратной связи.

Важно отметить, что контроль качества, никак не влияет на само качество, а только помогает дать оценку, насколько реализованный продукт соответствует имеющимся критериям. То есть не существует разницы 5 или 10 инженеров  проверяет наши кирпичи на складе, так как они уже изготовлены неверно. В этом и заключается причина почему, контроль качества не может влиять на само качество!

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

Обеспечение качества – это ряд мероприятий, направленных на увеличение вероятности производства продукта соответствующего заявленным требованиям. Задача QA это не проверить, что кирпич красный, а выполнить все необходимые действия для того, чтобы этот кирпич был произведён красным, а также своевременно убедиться, что заказчик хотел именно этого.

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

Примером может быть Legacy система, в которую редко, но все же  требуется вносить изменения. Зачастую изменения в таких системах производятся в уже реализованном и запутанном коде и задача сводится к поиску одного-единственный метода и изменения его логики. В таком случае, сколько бы ни было потрачено времени на определение критериев успеха или другие мероприятия, всё это может оказаться бесполезно. В подобных случаях задачей QA является опознать эту ситуацию и сосредоточиться на контроле качества или других подходящих практиках.

Если по какой-то причине вы сознательно не хотите применять подходы “Обеспечения качества”, то подумайте, насколько это подходящий выбор для вашего продукта и процесса разработки, в большинстве случаев, пропуская этап QA, мы всё равно выполняем весь скоуп связанных работ, но это происходит позже, чем требуется и с увеличенными затратами. Примером могут быть такие ситуации, как:

• подготовка тестовых сценариев после тестирования/реализации

• уточнение требований на этапе тестирования

• уточнение реализации на этапе тестирования

• изменений требований на этапе тестирования

• автоматизация тестирования после проведения ручного тестирования

• подготовка к UAT

• подготовка тестовых данных

• UP's забыли про нагрузку

• etc

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

Деминг, Уильям Эдвардс

О той пользе, которую может получить команда, используя подходы QA

• делает процесс разработки более предсказуемым

• зачастую делает работу проще и осознаннее

• помогает выстраивать коммуникации и отношение сотрудничества внутри команды

• улучшает взаимодействие с бизнесом, ведёт к взаимному интересу и уважению интересов

• возможность явного управления скоупом работ, уровнем качества и ожиданиями

• ведёт к развитию процессов автоматизации (тут мы этого не касались)

Какие базовые кейсы можно решать познакомившись с подходами "Обеспечения качества":

• недостижение цели спринта по причине нехватки времени на проведение тестирования

• переезд целей спринта в рамах исправления дефектов или тестирования на следующий спринт

• отсутствие тестовой документации

• неконтролируемый рост сроков реализации фичей

• и т.д

На мой взгляд, даже беглое знакомство с отличиями в процессах, может дать представление о том насколько, в действительности процессы QA могут быть шире, полезнее и интереснее “Контроля качества”.

А тут несколько мероприятий, которые я бы предложил попробовать инженерам и командам:

• формулируйте, фиксируйте и согласовывайте ваши приёмочные сценарии или критерии приёмки вместе с менеджерами/аналитиками и разработчиками на ваших PBR

• не завершайте PBR, пока все однозначно не поймут, какого результата требуется достичь и что будет считать выполненной задачей

• проводите дополнительные встречи в формате 3 Amigo

• формируйте приёмочные тест-кейсы параллельно или до разработки, обсуждайте сценарии с командой

• передавайте тест-кейсы разработчикам и делайте это в удобной для них форме, все участники команды должны знать, что нереализованное требование/тест-кейс - это дефект

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

• проводите приёмочное тестирование вместе с заказчиком по обговорённым кейсам, вероятно вы научитесь лучше понимать друг друга, после нескольких UAT 

Главный вывод, который хочется сделать звучит просто и многим известен - "Легче предотвратить, чем исправить".

Рекомендуемая литература:

Эдвард Деминг. Выход из кризиса. Новая парадигма управления людьми, системами и процессами

Элияху М. Голдратт, Джефф Кокс. Цель. Процесс непрерывного совершенствования