Профессиональное: Автоматизированное тестирование: Особенности обработки результатов
Все работы по автоматизированному тестированию можно весьма грубо разделить на две большие категории.
Первая - это собственно создание автотестов, настройка тестового окружения, и прочее.
Вторая - непосредственно прогон автотестов.
Первая, безусловно, интереснее и на начальных этапах занимает 90-95 % рабочего времени.
Вторая - вещь нужная, но и весьма нудная.
Однако это смысл автоматизации тестирования - собственно тестирование продукта.
Автоматизированное тестирование штука вместе с тем ненадежная - можно ошибиться одним параметром, настройкой окружения, а потом долго гадать "шо цэ було??? мобудь НЛО!?!" глядя в абсолютно неправдоподобные результаты.
В этом отношении автоматизированное тестирование сродни лавине - если уж пошла, то до конца.
Результатом автотеста могут быть:
Это только обозначает факт наличия проблемы. Ни больше, ни меньше.
Локализация проблемы потребует как минимум еще одного прогона теста(-ов) и наблюдения за ним глазами.
Иногда на этом все и заканчивается - наблюдение человеческим глазом за ходом выполнения автотестов помогает локализовать дефект или обнаружить ошибку в автотестах.
Но бывают случаи когда для того чтобы провести локализацию дефекта необходимо присутствие еще одного наблюдателя, точнее разработчика, еще точнее - потенциального автора дефекта :).
Итак, завал теста, повторный прогон в компании разработчика, наблюдение глазками и.... дефект локализован! Ура, казалось бы.
Ан нет. Тут вот и начинается самое интересное - разработчик получает необходимую ему информацию о дефекте, тестировщик получает локализацию дефекта для описания, все казалось бы счастливы, но...
Дальше разработчик идет и фиксит баг, тестер оформляет баг и заносит его в трекер.
Вполне себе возможна ситуация когда к моменту занесения бага в трекер он уже пофиксен, закомичен и есть новая сборка продукта без бага.
То есть тестер создает дефект который за недолгие 5 минут своей жизни будет рассмотрен (скорее всего менеджером проекта) , оценен по степени его важности, передан на фикс, какому-то конкретному разработчику, который в свою очередь тут же его закроет и отправит на валидацию, скорее всего успешную.
Получается, что к моменту завершения описания дефекта он уже исправлен и смысл этого описания - не совсем ясен.
Баги не надо записывать, баги надо фиксить. (с) Макс Дорофеев (привет, Макс)
Смысл документирования бага в таком случае появляется только тогда, когда начало его фикса отложено по времени и затраты времени на его описание окупятся тем, что ситуацию можно будет воспроизвести в будущем.
Все остальные доводы типа "учет дефектов", "статистика дефектов", "метрики" - не кажутся пригодными в данном случае.
Вот такой вот нелегкий казус получается.
Как его разрешить - пока не придумал.
Если у кого-нибудь есть какие-нибудь мысли - буду рад услышать.
Первая - это собственно создание автотестов, настройка тестового окружения, и прочее.
Вторая - непосредственно прогон автотестов.
Первая, безусловно, интереснее и на начальных этапах занимает 90-95 % рабочего времени.
Вторая - вещь нужная, но и весьма нудная.
Однако это смысл автоматизации тестирования - собственно тестирование продукта.
Автоматизированное тестирование штука вместе с тем ненадежная - можно ошибиться одним параметром, настройкой окружения, а потом долго гадать "шо цэ було??? мобудь НЛО!?!" глядя в абсолютно неправдоподобные результаты.
В этом отношении автоматизированное тестирование сродни лавине - если уж пошла, то до конца.
Результатом автотеста могут быть:
- ложные положительные срабатывания (хотя и редко),
- ложные отрицательные срабатывания,
- действительные срабатывания,
- ложные срабатывания из-за неправильной конфигурации окружения.
Это только обозначает факт наличия проблемы. Ни больше, ни меньше.
Локализация проблемы потребует как минимум еще одного прогона теста(-ов) и наблюдения за ним глазами.
Иногда на этом все и заканчивается - наблюдение человеческим глазом за ходом выполнения автотестов помогает локализовать дефект или обнаружить ошибку в автотестах.
Но бывают случаи когда для того чтобы провести локализацию дефекта необходимо присутствие еще одного наблюдателя, точнее разработчика, еще точнее - потенциального автора дефекта :).
Итак, завал теста, повторный прогон в компании разработчика, наблюдение глазками и.... дефект локализован! Ура, казалось бы.
Ан нет. Тут вот и начинается самое интересное - разработчик получает необходимую ему информацию о дефекте, тестировщик получает локализацию дефекта для описания, все казалось бы счастливы, но...
Дальше разработчик идет и фиксит баг, тестер оформляет баг и заносит его в трекер.
Вполне себе возможна ситуация когда к моменту занесения бага в трекер он уже пофиксен, закомичен и есть новая сборка продукта без бага.
То есть тестер создает дефект который за недолгие 5 минут своей жизни будет рассмотрен (скорее всего менеджером проекта) , оценен по степени его важности, передан на фикс, какому-то конкретному разработчику, который в свою очередь тут же его закроет и отправит на валидацию, скорее всего успешную.
Получается, что к моменту завершения описания дефекта он уже исправлен и смысл этого описания - не совсем ясен.
Баги не надо записывать, баги надо фиксить. (с) Макс Дорофеев (привет, Макс)
Смысл документирования бага в таком случае появляется только тогда, когда начало его фикса отложено по времени и затраты времени на его описание окупятся тем, что ситуацию можно будет воспроизвести в будущем.
Все остальные доводы типа "учет дефектов", "статистика дефектов", "метрики" - не кажутся пригодными в данном случае.
Вот такой вот нелегкий казус получается.
Как его разрешить - пока не придумал.
Если у кого-нибудь есть какие-нибудь мысли - буду рад услышать.