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

[jacks_alterego]

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

Comments

[cartmendum]

А в чем казус-то?

Ну да, иногда не имеет смысла записывать дефекты. А иногда имеет, например если тестеры от разработчиков отделены 8-ми часовыми поясами (но в этом случае потеря времени на чат с багтрекером - это еще не самая большая неприятность).

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

[jacks_alterego]

казус как раз в том что правила хорошего тона тестировщика говорят одно, а рацоинальное начало - прямо противоположное.

[cartmendum]

А что такое этот хороший тон? ;) То, что "так принято"? Типа никто не понимает зачем и для чего, но почему-то относятся к этому как к священной корове

[jacks_alterego]

Хороший тон - это когда тестировщик предоставляет объективную информацию о качестве продукта причем так чтобы ее смогли понять все и всегда (в том числе потом или никогда).

[yakov_sirotkin]

А как это разработчик закоммитит, не указав в коммите номер бага? А вот менеджеру не надо давать на рассмотрение.

[jacks_alterego]

а почему коммит должен быть привязан к номеру бага??? Это ж получается что мы не продукт пишем, а только баги фиксим =).
Тем более если разработчик увидел сам в своем коде косяк, что ж ему теперь надо баг самому на самого себя заводить, чтобы его исправить и закоммитить с указанным номером бага ?

[yakov_sirotkin]

Ладно, не баг - тикет. Не обязательно новый заводить - можно к старому закоммитить, если есть подходящий.

Но не должно быть такого, что приложение вдруг упало, а по бактреккеру никаких изменений нет.

[jacks_alterego]

>>Но не должно быть такого, что приложение вдруг упало, а по бактреккеру никаких изменений нет.

Не должно, согласен.

[w_bf]

Вставлю пять копеек от саппорта.

Неописывание, а фикс бага имеет тем больше смысла, чем меньше срок жизни\поддержки кода.

Для "искаропки" релиз которой раз в полгода и к моменту релиза идет уже не наколбас кода, а стабилизация с конечной целью - ноль багов - фиксить нужнее.

Для продуктов с непрерывными обновлениями\патчами\фиксами и прочими релизами (чем собсно отличается это наше свободное ПО) куда важнее не пофиксить баг, а знать о нем.

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

То есть тот или иной баг у клиента будет в другом случае.

Но если фиксить не описывая - клиент не узнает, в какой версии этого бага нет, не узнает, как его обойти, и т.п.х.

[jacks_alterego]

>>Для продуктов с непрерывными обновлениями\патчами\фиксами и прочими релизами (чем собсно отличается это наше свободное ПО) куда важнее не пофиксить баг, а знать о нем.

Для чего ж тогда выходят патчификсыобновления??? :)

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

[w_bf]

Клиенты - не хотят.

А саппорт - очень хочет знать какие баги у клиента есть, а каких нет. Чтоб быстро сделать клиенту хорошо (обновить\пропатчить, дать обходное), а не месяцами дебажить по переписке.

Патчи и фиксы - для исправления того, что нужно исправить и для создания новых багов.

Для понижения количества критичных клиенту багов.

А без багов софта нет.

саппорт - очень хочет знать

[jacks_alterego]

Тут насколько я смог заметить должна быть очень хорошая цепочка обратной связи от саппорта до команды разработки. Потому как саппортэто единственна точка куда приходит и фидбек и баги продукта от непосредственных пользователей.

У нас ситуация складывается так, что саппорт создает дефекты, а вот до команды они доходят с большим лагом по времени. И весьма часто бывает так, что когда дефект выкатил саппорт уже было несколько сборок после его фикса.

Но тут еще имеет значениние наш способ delivery, поэтому так.

[raterru]

Дальше разработчик идет и фиксит баг, тестер оформляет баг и заносит его в трекер.

да, тестировщик идет и пишет баг в трекер,
да, а потом он пойдет и проверить баг в следущем билде,...

тестер может верить разработчику наслово, но проверить должен, а самый лучший способ не забыть это сделать - это записать

[jacks_alterego]

безусловно.
Только в моем случае - проверять будут автотесты, они не забудут. Но это уже частности. Для незабыть - да багтрекер полезен, но это выходит за описанные 5 минут жизни дефекта,как мне кажется.

[agilizt]

+1

баг - это часть документации.
баг - это механизм управления проектом (что будем фиксить ща, что попозже) и планирования нагрузок
баг - напоминалка, которая живёт своей жизнью

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

в зависимости от первоначальной оценки времени жизни бага тестировщик просто название даст и тут же попросит пофиксить, либо если нету ресурсов обязан всё путём описать и отложить до лучших времён.

лозунг должен быть такой: "баг - это материализация работы. нету бага - нету работы."

(кстати баг = тикет = акшин айтом и т.п., оно же стикер на доске для аджайлиста). материализация, материалиазция и ещё раз материализация!

[jan_y]

видишь суслика? - нет, а ведь он там есть... :)

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

так что лучше пускай трое потратят по 5 минут, чем потом мудохаться час