Расхожие заблуждения в отношении организации тестирования

Давайте отложим на минутку автоматизацию и поговорим немного о тестировании :smile:
Я написал небольшую заметку в нашем корпоративном блоге. Выкладываю её здесь.

Хотелось бы услышать критику/поддержку/дополнения/собственный опыт и т.д., в общем пофилософствовать, подискутировать и т.д.

А кому-то, возможно, и просто будет полезно почитать. Особенно тем, кто считает, что в автоматизации тестирования слово автоматизация важнее, чем слово тестирование :smile: Что называется, помни о цели.

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

  1. простое добавление тестирования после разработки позволяет добиться качественного результата. То есть считается, что этого достаточно
  2. чем больше багов находит тестирование, тем лучше. Перефразируя, можно сказать, что цель тестирования в таком случае формулируется как “найти как можно больше багов”
    Попробуем разобраться почему это не совсем так.

##Простое добавление тестирования после разработки позволяет добиться качественного результата

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

Чем плохо позднее обнаружение проблем:

  1. меньше времени на её исправление
  2. разработчик, сделавший баг, уже забыл как оно там работает, надо заново вникать, поэтому времени требуется больше, что вступает в противоречие с первым следствием и приводит к переработкам и, соответственно, удорожанию исправления
  3. при большом количестве поздно обнаруженных дефектов, всё только усугубляется

###Как же надо?
Более правильным подходом будет раннее обнаружение проблем. А продвинутым - выстраивание всего процесса разработки таким образом, чтобы ошибиться (допустить дефект) было сложнее.
Какие меры для этого применяются:

  • тестирование на более ранних стадиях
    • на стадии постановки задач заказчиком
    • на стадии анализа входящих требований с целью их приоритезации и переиспользования уже имеющегося в системе функционала оптимальным образом для удовлетворения требования
    • на стадии разработки - TDD + ранняя демонстрация реализованного требования постановщику задачи для получения ранней обратной связи
    • на стадии тестирования
  • тестирование не только выделенными тестировщиками. Тестировщики выделены только на стадии тестирования, на всех остальных тестируют обычно другие
  • правильная приоритезация задач - то что важно для заказчика, делается в первую очередь. Здесь важно помнить, что производственные мощности ограничены, поэтому решение задач происходит в основном последовательно
  • ограничение одновременно выполняемой работы. В Канбан весь процесс построен вокруг этого принципа, видимо не спроста. Совместно с предыдущей мерой это позволяет “заточить” команду на быстрое выполнение важных задач
  • разделение целей, поставленных перед разработкой, между разными командами. Выпуск регулярных фич, выпуск хотфиксов, выпуск патчей - под это выделяются независимые ресурсы, чтобы у всех были четкие приоритеты

##Чем больше багов находит тестирование, тем лучше
Казалось бы, что тут может быть неправильного? И действительно, совсем неправильным этот тезис назвать нельзя, но как водится, во всём нужен разумный подход и истина лежит где-то посередине :smile: Так чем же плохо большое количество найденных багов?

Если задача стоит именно найти как можно больше багов, и например, KPI тестировщика определяется их количеством, то:

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

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

###Как же надо?
Надо прежде всего помнить о цели тестирования. И не формулировать её только количественной метрикой. Цель тестирования не в том, чтобы обнаруживать как можно больше багов.

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

Каким образом это достигается:

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

##Выводы
Качество ПО с момента обнаружения пользователями первого бага в программе и до наших времен беспокоит умы миллионов инженеров и менеджеров. И мысль не стоит на месте. Все эти новомодные TDD, BDD, ATDD и прочие Скрамы и Канбаны - все призваны не только для того, чтобы быть в тренде, но прежде всего, чтобы достигать такой простой и понятной цели как производство качественного ПО быстро и дешево :smile:

Но тем не менее, большинство проектов проходят по всем возможным граблям на пути к эффективному процессу. Понятно, что чем короче этот путь, тем лучше, но осилит его, в любом случае, только тот, кто идёт по нему, а не топчется по одним и тем же граблям :smile:

1 лайк

Добавлю кое-что от себя…

Любой QA, будь то manual или automation, прежде всего должен рассматривать тестирование, как объективную оценку качества ПО. Где качество отражает степень соответствия разумным ожиданиям пользователя. Оценка предполагает использование средств измерений. Объективность намекает, что оценка не зависит от личности / статуса ее проводящих.

Тестирование не может заключаться просто в поиске багов. Что нам, к примеру, даст цифра в 20 найденных багов за спринт? Это много или мало? Стало ли наше ПО качественней от того, что мы их нашли? Какой северити у найденных дефектов? Каково у нас тестовое покрытие? Какова статистика плотности дефектов во времени? Делаем ли мы что-либо, чтобы ее снизить? Какова эффективность устранения дефектов? У любого хорошего руководителя в голове всплывут все эти, и еще множество других вопросов. Будучи QA-инженерами, мы должны уметь на них отвечать, дабы тестирование не превращалось в спектакль дилетантов.

Помимо всего прочего, не стоит забывать также и об основных принципах тестирования. Так или иначе, мы ежедневно с ними сталкиваемся. Почитать о них, и многих других интересных аспектах тестирования, можно в книге Foundations of Software Testing, рекомендованной к прочтению для прохождения ISTQB сертификации.

2 лайка

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