Перейти к содержимому

Программирование на Python для тестировщиков
онлайн, начало 23 октября
Тестирование безопасности
онлайн, начало 28 октября
Школа для начинающих тестировщиков
онлайн, начало 22 октября
Автоматизатор мобильных приложений
онлайн, начало 28 октября
Фотография

К кому идти с багами?

баг жизненный цикл вопрос

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 6

#1 FestiveGrape

FestiveGrape

    Новый участник

  • Members
  • Pip
  • 69 сообщений
  • ФИО:Андреевич


Отправлено 09 июня 2014 - 11:01

Доброго времени суток.

 

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

 

Раньше работал в большой фирме (более 200 человек в местном офисе и еще отдел, который находился в другой стране и состоял еще из более 100 человек). Когда мы находили баги, то действовали следующим образом:

1) Убеждались в том, что бага - это бага, а не кривые руки

2) Делали поиск по багобазе и проверяли, что бага еще не запощена

3) Убеждались в том, что багу можно уверенно воспроизвести и она не относится к сложновоспроизводимым

4) Писали саму багу

5) Проходили по шагам, которые сами написали и еще раз убеждались в том, что бага воспроизводилась, если выполнить все действия описанные нами

6) Сабмитили багу

7) Ждали фикса или каких-нибудь комментариев от разработчиков

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

 

Нынче работаю в фирме, которая состоит из 5 разработчиков и 3 тестеров, все находимся в одном помещении, поэтому никакой бюрократии в виде переписок по е-майлу или скайпу. Удобно тем, что всегда можно на лету задать вопрос и выяснить какие-то интересующие моменты, но... Стал замечать, что последнее время каждая бага репортится по такому сценарию:

1) Нашли багу
2) Убеждаемся, что бага - это бага (применяем правило 20 минут)
3) Бежим к разработчику, который предположительно писал эту строку кода

4) Выясняем все подробности, обсуждаем багу
5) Репортим её и ждем фикса

 

Так вот... Правильно ли это, что, после первых двух шагов, тестеры идут обсуждать детали баги к разработчику? Стоит ли как-то изменить систему и поступать так, как это было принято в большой фирме? Или всё-таки стоит пользоваться такой возможностью, что все вопросы можно сразу выяснить напрямую у разработчиков?

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

 

В общем, нужен совет, а так же с удовольствием послушаю о том каков жизненный цикл баги в вашем коллективе (размер коллектива указывайте тоже).

 

С уважением и благодарностью,

Андреевич


  • 0

#2 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 832 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 09 июня 2014 - 11:22

Правильно ли это, что, после первых двух шагов, тестеры идут обсуждать детали баги к разработчику?

Неправильно! Вы отвлекаете разработчика от работы.
1. Нашли
2. Записали
3. Ждем фикса.

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

Стоит ли как-то изменить систему и поступать так, как это было принято в большой фирме?

У вас в большой фирме все очень запутано. Чем отличаются шаги 1, 3 и 5? Зачем дважды перепроверять одну и ту же ошибку?

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

У нас ЖЦ баги различается между проектами. Есть огромный бюрократический ЖЦ - там отдельная фаза анализа и работы над багом. Есть совсем краткий и в нем даже отсутствует фаза In Testing.
  • 1

#3 FestiveGrape

FestiveGrape

    Новый участник

  • Members
  • Pip
  • 69 сообщений
  • ФИО:Андреевич


Отправлено 09 июня 2014 - 11:26

Стоит ли как-то изменить систему и поступать так, как это было принято в большой фирме?

У вас в большой фирме все очень запутано. Чем отличаются шаги 1, 3 и 5? Зачем дважды перепроверять одну и ту же ошибку?

Этот подход применялся в предыдущей фирме и сделан было потому, что было очень много совсем зеленых тестеров, по чьим багам было невозможно вопроизвести описанную ими ситуацию


  • 0

#4 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 832 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 09 июня 2014 - 11:59

Понятно.
Я у себя уходил (и почти ушел) от практики вопросов разработчикам до написания бага. Это тоже характерно для новичков, кто плохо знает продукт. Как только люди погружаются в исследуемую систему вопросов становится гораздо меньше.
  • 0

#5 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 09 июня 2014 - 12:28

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

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


  • 0

"Не сломал - значит, не старался!"


#6 Dalay_LAMO

Dalay_LAMO

    Опытный участник

  • Members
  • PipPipPipPip
  • 265 сообщений
  • ФИО:Дмитрий
  • Город:Санкт-Петербург


Отправлено 09 июня 2014 - 13:00

Понятно.
Я у себя уходил (и почти ушел) от практики вопросов разработчикам до написания бага. Это тоже характерно для новичков, кто плохо знает продукт. Как только люди погружаются в исследуемую систему вопросов становится гораздо меньше.


Поддерживаю.
Опытный тестировщик, хорошо ориентирующийся в текущем проекте, должен понимать где баг, а где небаг, зачем для этого дергать разработчиков я не очень понимаю.
ТС, у вас в компании есть должность project manager'а? Если нет, то кто распределяет новые задачи, кто решает, что приоритетней - закрыть баг или запилить фичу? Если менеджер есть, то почему не использовать стандартное (на мой взгляд) воркфлоу - создаём баг, ассайним на менеджера, а он уже решает, баг/не баг, если фиксить, то когда.
  • 0

#7 lurk

lurk

    Постоянный участник

  • Members
  • PipPipPip
  • 180 сообщений


Отправлено 09 июня 2014 - 15:24

По моему, оптимально о критичных ошибках - лично извещать разработчиков.
Средние и мелкие - просто закидывать в баг-трекинг. Разработчики увидят задачи - и сами решат их дальнейшую судьбу (когда, что, кому исправлять).
О недочётах, мелких пожеланиях, косметических дополнениях - лучше собирать в отдельную категорию на багтрекинге (тетрадку, googledocs) - когда наберется их достаточная масса - можно договорится с разработчиком обсудить их все и сразу. (Не чаще, чем раз в неделю)
  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале