Lesson 110

По теме сегодняшего урока канера.
У меня было три проекта, где я автоматизировал тестирование.

В первом автотесты за год нашли одну или две баги, три максимум. Активная разработка, поддержка.
Во втором автотесты баги находили раз в месяц. Проект на поддержке, разработка неактивная.
В третьем автоматика находила 1-2 баги в неделю. Проект в разработке.

Сейчас пытаемся настроить процесс третьего проекта так, чтоб то, что находят автотесты в трекер не попадало вообще.

Подсчитали, что тестирующая система тратит треть времени сборки на удаление объектов, созданных во время тестов. Какая, стцуко, культурная. Думаем отключить для дневных сборок.

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

Кот рядом. Скоро отпуск.

Альбом: randompics4lj

Слово Канеру:

Автоматизированные регрессионные тесты находят меньшую часть ошибок.

Неформальные исследования показали, что процент багов, найденных автоматизированными тестами удивительно низок. Проекты с серьезной, хорошо спроектированной автоматизацией говорят, что регрессионные тесты находят около 15% багов от общего количества (Marick, online).


Автоматизированные регрессионные тесты, как правило, находят больше ошибок во время разработки тестов, чем во время их дальнейшего выполнения. Однако, если вы возьмете ваши регрессионные тесты и найдете возможность запустить их на другом окружении (т. е. на другом аппаратном обеспечении, с другими драйверами), то тесты будут находить проблемы лучше. В действительности, в этом случае они не будут являться регрессионными тестами, так как будут проходить на конфигурации, не проверенной ранее. Тестировщики сообщают, что такой вид автоматизации может давать полезный выход на уровне 30-80 процентов.

Новое тестирование старых фич с большей вероятностью найдет проблемы, чем старые регрессионные тесты. У них есть дополнительное преимущество — они могут найти ошибки, которые там были с самого начала[1].

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