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

[jacks_alterego]

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

Comments

[anonymous]

Pollyanna:

У нас в проекте если баг найден и разработчик сказал, что уже исправил, мы (тестировщики) делаем у себя пометки и в багтрекер не вносим. Если в следующем билде баг повторяется - вносим.
Для справки: билд на тестирование поступает раз в неделю. Заказчику пока не уходит, вся информация для нас.
Ситуации с моментальным фиксом дефектов у нас не часты, поэтому картина нашей тестировочной производительности не страдает.
Подобные небольшие уступки программистам считаю приемлимыми, поскольку ни проект, ни его участники, ни заказчик от этого не страдает. Кроме того от программистов становятся легче добиваться положительных решений по более важным спорным вопросам.

[anonymous]

Мы делаем так:
1. Если версия с пофикшенным багом будет меньше,чем через 10 минут - не открываем тикет и позволяем программисту заменить билд в текущей папке. ПРи этом все, кто должен работать с билдом, должны быть предупреждены.
2. Если 10-30 минут - после фикса создается отдельная папка с новым билдом и новым именем, соответственно. При этом,когда программист пофиксил баг, он пишет новый тестинг реквест с текстовым описанием исправленной проблемы, например "Исправлен баг с зависанием приложения при старте". Снова же, предупреждаются все участни ки процесса.
3. Если фикс занимает больше 30 минут, открываем тикет :) потому что это значит, что проблема может быть довольно серьезной, а не просто "закомментил не ту строку" или "ой, забыл поставить галочку для 64-битных систем".

GreyRain

[anonymous]

я полностью за занесение багов в тракер, поэтому в основном буду только аргументы за приводить

[sergezol]

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

[anonymous]

Перешел к этому посту по ссылке "Нужно ли записывать баги" :)
Собственно уже мысленно закатывал рукава и хотел наподдавать богохульнику, но прочитав пост немного остыл :)

В нашей фирме есть ажно три типа автотестов:
-автобилд; прогоняются при каждом билде, максимально устойчивые тесты, баг-репорты генерятся автоматически, но в баг-трекер не заносятся по понятным причинам. Воспринимаются программистами как инструмент. Собственно тут никаких проблем с баг-репортами нет.
-ночной билд; расширенные автотесты, прогоняются исключительно ночью ибо довольно долго. Очень похожи на первый тип, но перед тем, как с найденными багами станут работать программисты их проверяет тестировщик.
-автотесты с максимальным покрытием; этот тип не более чем инструмент тестировщика, собственно с результатами поступают так же, как и при ручном тестировании.

Если уж и тут есть сомнения быть аль не быть репорту, то пишите - накатаю длиннющий список на тему "а на фига?"

[alex_griffin]

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

Еще такие тикеты нужны, если есть несколько бранчей на которых параллельно идет разработка. Мало ли что в двух соседних бранчах пофиксено, либо добавлено.

[9zloy]

Вот вот вот.
Параллельные бранчи есть в любой команде, которая по фичам колбасит и гитом пользуется. А если процесс Kanban, то часто так и есть. И тогда без баг трекера херово.
Кроме того, ну не часто бывает что баг сразу фиксится после нахождения. Обычно день другой проходит. А тут уже без записи где-то ну никак, ибо память человеческая забывает все по черному, особенно что касается багов.

Так что я за коммон сэнс. Если баг будут фиксить сразу - на надо его заносить. Если нет - надо обязательно;