SALar Oct 15 2003, 01:09 PM:
Замечу что важность ошибки и приоритет исполнения далеко не одно и тоже. Может быть минорная бага с высшим приоритетом и наоборот.
Согласен, таким образом мы работаем с заказчикам - у него приоритеты другие и более сложные. Например, совершенно, с нашей точки зрения, пустяковая фича может быть с первый приоритетом. Тут у нас юзается другой принцип - заказчик всегда прав.
Но наши тестировщики только проверяют фиксы сделанные по этим репортам после выпуска билда
По поводу описания/классификации репортов - я считаю, что здесь ситуация достаточно стандартная, т.к. более-менее нормальная тулза для тракинги дает стандартный набор полей. А вот заполнение этих полей может быть разное и зависеть от конкретного проекта
Во многом зависит от системы которую вы тестируете, но чувствую, что проработано. А потом вы это используете как предлагалось выше? То есть строите разные выборки, чтобы поcмотреть что-то? И если не секрент что именно? Или при планировании применяете? Приоритеты ж ведь.
1. Коробочный продукт - САПР
2. Да выборки делаем. Обычно это нужно в двух случаях
- на момент планирования версии - обсуждение с заказчиком, а что ж собственно делать
- во время разработчки на стадиях Alpha, Beta, Final - анализ качества и количества багов. Например, если крашей становиться меньше, то можно предположить, что версия становиться стабильней или еще, если кол-во реквестов растет, то надо начинать говорить об изменении сроков и т.д.
3. При планировании конечно используем, но наша специфика такова, что мы чаще ограничены сроками, а там сколько успеем, столько успеем. Да и динамика такова, что репорт живет максимум 2 недели от занесения до закрытия
Поэтому, например, такая вещь как признак, что баг надо пофиксить в мифическом "Следующем релизе" для нас неактуальна
Я как проджект манаджер каждый день просматриваю пул задач и решаю, что надо делать. Т.е. девелоперам приходят только те задачи.баги, которые надо было сделать вчера и до обеда :D
