История о маскирующемся баге.
Намедни появился в проекте баг. И еще был тест, который умел этот баг находить. Все просто?
Все остальные тесты были ну очень изолированы и этот баг обходили, используя при этом функциональность. Но благодаря багу — оставляли за собой артефакты, замедляющие работу системы.
А тест был предпоследним в последнем по алфавиту классе,
2 дня назад смотрим — ну очень долго идет сборка. Грохнули, включили логирование GC. Опять долго, OutOfMemory, в дампе норм, грохнули, добавили памяти. Один хрен — долго. Добавили вообще много памяти и перм гена накинули. Прошла сборка, и предпоследний тест в ней обнаружил пресловутый баг, с продвинутым скиллом маскировки.
Слово Канеру:
Рассмотрите ошибки, которые вы не находите во время автоматизации тестирования.
При подсчете стоимости автоматизации, мы советуем тебе сосредоточиться на упущенной выгоде. Что бы ты успел сделать за время, потраченное на автоматизацию? Какие тесты ты не провел? Какие баги не нашел (Marick 1998)?
Непосредственное воздействие многих проектов по автоматизации - задержка тестирования и задержка поиска багов. Эта проблема также является аргументом в пользу авансовых методов автоматизации, позволяющих подготовить автоматизированные тесты прежде, чем программа будет готова к тестированию. Например, стратегия тестирования, основанная на тестовых данных, позволяет подготовить входные данные заранее. В таком случае, автоматизация позволит ускорить тестирование и поиск багов.
>Непосредственное воздействие многих проектов по автоматизации - задержка тестирования и задержка поиска багов.
ОтветитьУдалитьА в чем тогда профит? (краснеющий смайлик)
Контроль изменений. Это ж целая философия.
ОтветитьУдалитьЛюбое изменение - создание нового + изменение старого.
Автоматизация с опозданием возьмет под контроль новое, но мгновенно(или никогда) заметит багу в старом.
Ручное тестирование с опозданием(или никогда) обнаружит что-то в старом, но быстро проверит новое.
Спасибо. По автоматизации я покамест ни в зуб ногой.
ОтветитьУдалить