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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— заказчик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— etc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— и т.д

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

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

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

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

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

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

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

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

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

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

Не бывает управления без изменения. Тестировщики как раз и выполняют такую функцию. Это основа и она ни куда не денется.

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

В самом деле, чем выше надёжность системы, тем меньше разных вариантов нештатных ситуаций и тем проще ей управлять. Но сложность, обусловленная разнообразием возможных проблем, ни куда не девается — она просто переходит в процессы управления качеством.

Как следствие, если QC достаточно уметь измерять результат, то QA должен детально разбираться в процессе, причинах возникновения отклонений и способах их компенсации. По сути такой персонаж должен обладать экспертизой уровня всей команды: разработчиков, менеджеров, архитекторов и всех остальных вместе взятых — чьи действия в своей области могут приводить к дефектам. А иначе, не обладая достаточными компетенциями, он сам станет причиной неверных решений и ошибок. Как вариант, он может решить абстрагироваться от сложных деталей, но тогда его функция становится чисто бюрократической, в роде коучинга.

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

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

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

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

Да, совершенно верно, мнение субъективное. Подача выбрана в таком формате специально, для привлечения внимания тестировщиков :)

В стать речь идет именно о понимание отличия этих двух направлений, касательно практик, там есть пару предложений, они имеет весьма «гигиенический» характер, но могут дать не плохой результат.

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

Работал с командами в которых были исключительно практики контроля качества, как это выглядит. QC не участвует, либо формально участвует в pbr, не погружается в контекст задачи, не понимает и подсвечивает команде возможные риски, сценарии тестирования и критерии успешности фичи. Спринт для такой команды выглядит обычно как waterfall модель. Разработка пишет большую половину спринта код, в конце спринта тестировщики берутся за тестирование. И тут происходит самое интересное, а именно:

— находятся критичные дефекты (так не была проведена работа по определению критичных сценариев и приемочных критериев)

— начинается расхождение того как поняли задача разработчики, тестировщики и что хотел заказчик

— выстреливают критичные риски (ну например сервис не держит нагрузку)

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

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

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

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

Касательно примера выше это было бы:

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

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

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

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

Это достаточная большая тема, кажется, что мне вновь не удается передать суть и практики. Но есть литература в которой уже описано :)

Для знакомства мог бы рекомендовать:

Agile-тестирование. Обучающий курс для всей команды Джанет Грегори, Лайза Криспин

Ну а так же все, что есть в интернете на тему shift-left testing, там можно так же подглядеть практики.

Чек-лист качества это мечта уровня философского камня, который будет превращать в золото все что угодно. Но если верить Гёделю, то будучи формальной системой, он окажется либо не полным, либо противоречивым. Со всеми вытекающими последствиями.

Давайте про безопасность. Как на практике. Желание приблизиться к полноте в таком важном вопросе, как безопасность, привела к появлению целого семейства стандартов — на разработку ISO/IEC 27000, и 15408 — на проверку. Крайне популярное и увлекательное чтиво в последнее время, покрывающее вопросы уровня огранизации, людей, физической безопасности и технологий — суммарно около 100 тем из разных областей. Вот пример классического чек-листа, затрагивающего лишь несколько из них github.com/RedHatInsights/secure-coding-checklist. Т е. если подходить к делу ответственно, то получить начальные сертификаты займет несколько месяцев, а внедрить и научиться осмысленно применять — миллионыгоды.

SAST, DAST, MPT, SCA, RE, PTasS, BAS, MAST — просто перечислить акронимы разного вида тестирования, необходимых, чтобы претендовать на соответствие стандартным требованиям — уже целое предложение.

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

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

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

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

Разумеется мы можем этого не делать и в ходе тестирования готового артефакта найти эти дефекты. Завести баги, потратить время на их исправление, ревью, мерж, сборку. Это и есть работа «тестера» сказать на сколько итоговый артефакт соответствуют явным или не явным требования, а задаче qa, провести ряд мероприятий, может быть даже и самых простых, таких как, просто сказать, «а что с ИБ?» и по возможности предотвратить дефект и помочь всей команде реализовать ожидаемую бизнесом фичу в оговоренный сроки.