Сообщений в теме: 8

[baranceva]

Автор: Евгений Ткаченко

В современном IT мире Bug tracking системы уже не столько помогают, как мешают продуктовой команде развиваться. Когда все общение по проблемам происходит через такие системы теряется коммуникативная связь между тестировщиками, разработчиками и заказчиками. Все обсуждения в рамках задач в карточках занимают непростительно много времени, которое можно было потратить более эффективно. Да и вообще само название такого продукта как "Bug tracking система" несет негативный посыл, ведь все команды стремятся, чтобы багов в их проектах не было.

Так где же мы храним эти баги?

Джира, Багзила , Мантис, Редмайн, Берт, Трелло, Мингл, а может кто то использовал Гугл доки или Гугл таблицы для этого, думаю еще есть варианты.

Каждый из нас работает с Багтрекинг системами или когда либо работал в прошлом.

Как же мы с ними работаем?

Стандартная зарисовка из жизни:

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

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

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

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

Давайте теперь сфантазируем другую картину:



Читать дальше

[Vasiliy]

Как название перекликается с выводами статьи?

мы используем 'Trello' для наших задач и ничего особенного для багов;

"Ничего особенного" - это как? Или что это такое?
Тестировщик нашел баг, написал автотест для повторения - что дальше? Где будет храниться автотест?

[vagner_tester]

Как название перекликается с выводами статьи?

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

"Ничего особенного" - это как? Или что это такое?
Тестировщик нашел баг, написал автотест для повторения - что дальше? Где будет храниться автотест?

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

Тестировщик нашел баг, написал автотест для повторения - что дальше? Где будет храниться автотест?

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

[kitsune]

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

Я правильно понимаю, что про временные затраты на переключение между задачами Вы не слышали?

[Clauster]

мы придерживаемся принципа “нулевой терпимости к багам” (не выпускаем продукт пока в нем есть ошибки)

Спасибо, посмеялся.
А про падежи слыхали что-нибудь?

[vagner_tester]

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

Я правильно понимаю, что про временные затраты на переключение между задачами Вы не слышали?

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

[vagner_tester]

мы придерживаемся принципа “нулевой терпимости к багам” (не выпускаем продукт пока в нем есть ошибки)

Спасибо, посмеялся.
А про падежи слыхали что-нибудь?

Вам есть что - то предлложить более лучшее, что работает?
Я предлагаю наш подход, который работает.
Оригинал статьи есть здесь http://www.software-...ugs-no-problems
Там есть презентация и комментарии, которые возможно погут вам понять суть того подхода, что я предлагаю.

Можете пояснить, что Вам показалось смешным ?

[SALar]

Конечно же это не так, ведь главная цель это предотвратить ошибки, а не обнаружить их как можно больше!

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

[SALar]

Самый главный вопрос автору: "Где описание результатов?"

1. Как изменился проход на единицу операционных затрат?
2. Как изменилось время выполнения заказа?

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