testomat.io управление авто тестамиДавайте отложим на минутку автоматизацию и поговорим немного о тестировании 
Я написал небольшую заметку в нашем корпоративном блоге. Выкладываю её здесь.
Хотелось бы услышать критику/поддержку/дополнения/собственный опыт и т.д., в общем пофилософствовать, подискутировать и т.д.
А кому-то, возможно, и просто будет полезно почитать. Особенно тем, кто считает, что в автоматизации тестирования слово автоматизация важнее, чем слово тестирование Что называется, помни о цели.
Итак, какие на мой взгляд встречаются расхожие заблуждения по поводу тестирования программного обеспечения:
- простое добавление тестирования после разработки позволяет добиться качественного результата. То есть считается, что этого достаточно
- чем больше багов находит тестирование, тем лучше. Перефразируя, можно сказать, что цель тестирования в таком случае формулируется как “найти как можно больше багов”
Попробуем разобраться почему это не совсем так.
##Простое добавление тестирования после разработки позволяет добиться качественного результата
Если рассматривать тестирование в чистом виде, без QA, то это ни что иное как выявление дефектов работы системы. Не больше и не меньше. И именно в таком виде изначально тестирование и применяется на проектах, которые только начинают об этом задумываться. Просто в конце конвейера ставят тестировщика, который выявляет дефекты.
И несмотря на то, что это лучше, чем ничего, всё-таки такая организация производства далека от эффективной. Причины неэффективности заключаются в позднем обнаружении проблем.
Чем плохо позднее обнаружение проблем:
- меньше времени на её исправление
- разработчик, сделавший баг, уже забыл как оно там работает, надо заново вникать, поэтому времени требуется больше, что вступает в противоречие с первым следствием и приводит к переработкам и, соответственно, удорожанию исправления
- при большом количестве поздно обнаруженных дефектов, всё только усугубляется
###Как же надо?
Более правильным подходом будет раннее обнаружение проблем. А продвинутым - выстраивание всего процесса разработки таким образом, чтобы ошибиться (допустить дефект) было сложнее.
Какие меры для этого применяются:
- тестирование на более ранних стадиях
- на стадии постановки задач заказчиком
- на стадии анализа входящих требований с целью их приоритезации и переиспользования уже имеющегося в системе функционала оптимальным образом для удовлетворения требования
- на стадии разработки - TDD + ранняя демонстрация реализованного требования постановщику задачи для получения ранней обратной связи
- на стадии тестирования
- тестирование не только выделенными тестировщиками. Тестировщики выделены только на стадии тестирования, на всех остальных тестируют обычно другие
- правильная приоритезация задач - то что важно для заказчика, делается в первую очередь. Здесь важно помнить, что производственные мощности ограничены, поэтому решение задач происходит в основном последовательно
- ограничение одновременно выполняемой работы. В Канбан весь процесс построен вокруг этого принципа, видимо не спроста. Совместно с предыдущей мерой это позволяет “заточить” команду на быстрое выполнение важных задач
- разделение целей, поставленных перед разработкой, между разными командами. Выпуск регулярных фич, выпуск хотфиксов, выпуск патчей - под это выделяются независимые ресурсы, чтобы у всех были четкие приоритеты
##Чем больше багов находит тестирование, тем лучше
Казалось бы, что тут может быть неправильного? И действительно, совсем неправильным этот тезис назвать нельзя, но как водится, во всём нужен разумный подход и истина лежит где-то посередине Так чем же плохо большое количество найденных багов?
Если задача стоит именно найти как можно больше багов, и например, KPI тестировщика определяется их количеством, то:
- у тестировщика нет заинтересованности найти критичные баги. Он будет искать там, где проще найти
- поскольку время тратится на поиск багов там, где их проще найти, времени на поиск критичных багов остается меньше, поэтому критичные проблемы будут обнаруживаться позже
- у тестировщика нет заинтересованности подробно исследовать баг. Это означает, что исправление бага будет дороже
- большое количество мусорных, неприоритетных багов, загружает лишней работой руководителя проекта, который вынужден сортировать баги для расстановки приоритетов
- в итоге большая часть багов не будет исправлена в текущей версии и будет постоянно откладываться, наращивая “хвост” висящих проблем. И этот “хвост” надо регулярно, перед каждой следующей версией, просматривать на предмет выбора важных багов на исправление. И чем “хвост” длиньше, тем больше времени на это уходит
Итого: в ситуации, когда разработка и так загружена багами, поиск ещё большего их количества не дает полезного результата. Со временем польза от большого количества багов быстро снижается
###Как же надо?
Надо прежде всего помнить о цели тестирования. И не формулировать её только количественной метрикой. Цель тестирования не в том, чтобы обнаруживать как можно больше багов.
Цель тестирования: предоставление быстрой информации о критичных проблемах. И именно на этом надо сосредотачиваться, этому учиться и это оценивать как результат тестирования.
Каким образом это достигается:
- четким пониманием целей ближайшего релиза
- четким пониманием того, как должен работать выпускаемый функционал
- четким пониманием того, что менялось в системе и где могут быть ошибки
- применением автоматизации для тестирования на разных уровнях (как юнит, так и всего функционала)
##Выводы
Качество ПО с момента обнаружения пользователями первого бага в программе и до наших времен беспокоит умы миллионов инженеров и менеджеров. И мысль не стоит на месте. Все эти новомодные TDD, BDD, ATDD и прочие Скрамы и Канбаны - все призваны не только для того, чтобы быть в тренде, но прежде всего, чтобы достигать такой простой и понятной цели как производство качественного ПО быстро и дешево
Но тем не менее, большинство проектов проходят по всем возможным граблям на пути к эффективному процессу. Понятно, что чем короче этот путь, тем лучше, но осилит его, в любом случае, только тот, кто идёт по нему, а не топчется по одним и тем же граблям