Профессиональное: Автоматизированное тестирование: Особенности обработки результатов

[jacks_alterego]

Все работы по автоматизированному тестированию можно весьма грубо  разделить на две большие категории.
Первая - это собственно создание автотестов, настройка тестового окружения, и прочее.
Вторая - непосредственно прогон автотестов.
Первая, безусловно, интереснее и на начальных этапах занимает 90-95 % рабочего времени.
Вторая - вещь нужная, но и

Comments

[anonymous]

я полностью за занесение багов в тракер, поэтому в основном буду только аргументы за приводить :)
первое - используйте багтракер для автоматической генерации release notes. Если там будут описаны все изменения, происшедшие с продуктом во времени последнего релиза - от этого выиграют все пользователи. поэтому многие конторы пишут в тот же самый тракер не только баги, но и feature requests, internal improvements и любые другие гениальные изобретения девелоперов :)
второе - иногда это только кажется, что баг был пофикшен за 10 минут, а потом окажется что баг прикрыли штакетником, по пути сломав еще что-то. Тогда, как правильно говорили в предыдущих коментах - все сломалось, а нигде нет и следа описания изменений (если только у вас весь процесс не построен на анализе commit message-й). Более того, и тестер и девелопер ушли в отпуск, кого-то другого попросили, чтобы он посмотрел в чем проблема, а тот потом долго сидит и гадает зачем вообще этот код меняли.
третье - про автоматические тесты - это хорошо, но их тоже надо где-то описывать. Например, представьте тесты, написаные при помощи какой-то своей доморощеной системы. И тут решили наконец-то привести это все в порядок и перейти на boost unit tests или еще что-то интересное, в общем - поменять framework для тестов. И для этого надо чуток поменять тесты, под новую платформу. Пытаться просто переводить тесты без опоры на тервоисточник (описание бага) - чревато ошибками. Поэтому, покументировать баги и тесты к ним надо, почему бы не в баг-тракере?
еще такая ситуация, у одного из ваших пользователей немножко старенькая версия вашего продукта, как раз содержащая этот баг, который пофикшен в следующей, но никак не задокументирован. Он вам жалуется на баг, поскольку ничего не задокументировано - вы выделяете ресурс на исследование проблемы, через несколько человеко-часов выясняется, что это было уже пофикшено и вы счастливо репортите об этом клиенту, советуя проапгрейдиться, опять не делая никаких записей.
мне очень хорошо понятна склонность программиста прикрывать свою лень ворчаниями о процессуальных палках в колесах прогресса и передовой мысли, но по большей части это все от безалаберности и попытке сэкономить свое время за счет других.
решение, как я уже говорил, в умелом применении методики для решения множества проблем. Используйте багтракер для генерации release notes, недельных отчетов ваших подчиненных, совместите это все с системой учета спринтов и бэклога (если используете agile), используйте для оценки качества работы девелоперов... баг-тракер - это летопись вашего продукта. Если вы выкидываете оттуда какие-то события - она получается однобока. Однобокая история - бесполезна.

[sergezol]

это от меня коммент, прощу прощения за анонимность, забыл залогиниться :)