Добрый день коллеги!

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

Есть "два вида списков задач"

 

Читайте. Надеюсь в этой статье дан ответ на ваш вопрос.

 

И учите теорию. Теорию вариаций и теорию систем.

Интересно было почитать

Всем спасибо за ответы. Приму к сведению информацию и поищу ещё доп. материалы.

1. Новичкам полезно изучать историю. Если баги закрыты, то отфильтруйте их и пусть хоть по диагонали прочитают.
2. Что у вас за текучка, что столько новичков на проекте и нет времени на полноценное знакомство с проектом?

На самом деле текучки особо нет, но сотрудники периодически прибавляются, меняются и т.д.

 

 

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

Есть фильтр, не 100% точный, но позволяет избавиться от части лишней работы. Это групповой рабочий чат, куда каждый должен отправлять заголовки заведенных багов. И "старожилы" часто узнают, если такой баг уже был, или если им хорошо известно, что подобные ошибки никого не волнуют.

 

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

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

 

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

 

 

 

и новые сотрудники открывают баги, которые были очень давно затрешены

если баг известный и затрешенный - то и не надо его открывать

 

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

 

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

То есть, приходит новый сотрудник, начинает знакомиться с сервисом. В процессе находит багу и фиксирует. Понятно, что сотрудник, может сделать выборку затрешеных задач по сервису, с которым работает и со всеми сидеть знакомиться, но задач может быть 1, а может и 1000 и даже если за сотрудником закреплен наставник на первом этапе, то и он может не помнить всех моментов + тест-кейса, повторяющего действие приводящее к ошибке, может и не быть и найти его в баг-трекере также не получится. Сотрудник всё сделал правильно, "пришел, увидел, победил", но итог, снова тривиальный баг в бэклоге. А при ревью баг трешится и всё ок. 

 

 

 

 

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

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

 

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

 

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

Привет всем. 

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

От сюда вопрос, кто-то использовал в работе практику ревью заведенных багов. Если да, то как это было организовано? С какими трудностями столкнулись при организации процесса?

Я вижу это примерно так. Выделяется раз в неделю день (или n-е количество часов), когда ответственный разгребает бэклог по задачам. Ответственный - это вероятно более опытный тестировщик или лид команды тестирования, который проверяет именно баги и + аналитик, который разгребает заведенные таски.