Почему я не верю в жизнь после смерти или баги выше третьего приоритета

С некоторых пор я занялся профессиональным тестированием.

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

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

Почему я не верю в жизнь после смерти? - потому что я никого не видел из тех, Кто От Туда Вернулся.

Почему я не верю в баги третьего приоритета (4,5 а то и 7!)? - такая приоритезация за собой не несет никакой пользы.

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

С тех пор я подрос и понял что кроме сейчас и потом есть еще когда будет время или когда нибудь или когда вспомним или, в самом экстремальном случае, наверное уже никогда, но для отчиски совести.... Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда, если будет время - просмотреть API новой версии Selenium RC - 1.0. Сейчас нужно покормить ребенка, потом - посадить на горшок, если будет время до прогулки - повторить с ребенком два цвета: синий и зеленый.

Приоритеты 4, 5 ... n не несут в себе никакой информации. Они просто добавляют уровень к вашей некомпетентности. Вы либо знаете что в вашем продукте имеет приоритеты:
- сейчас
- сразу-после-того-как-закончаться-баги-сейчас
- просмотреть-и-повысить-приоритеты-для-тех-которые-сразу-после-сразу-после-того-как-закончаться-баги-сейчас.
Либо вы не знаете этого.

Сложно?

Cуть в том чтобы баги приоритета 1 и 2 были бы постоянными (стараться этого достичь), а баги приоритета 3 - либо повышались либо оставались такими же. Пересмотр багов должен проводиться периодически и постоянно. Это один из процессов которые нужно внедрять. Простая мысль - управлять багами тоже нужно - но я не встречал практического применения данной мысли на практике - наверное мне "везло".

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

Есть еще такая вещь как удаление бага по прохождении некоторого заданного времени. Например год прошел и бага самоликвидировалась (как и демоны из к\ф "Иван Васильевич Меняет Профессию") - их как бы и нет. Не встречал такого подхода, но слышал - интересно посмотреть компанию, где годами не исправляют баги :).


Но что делать когда багов сотни? Тысячи? И ими (багами) управлять и пересматривать сложно! - здесь я пожалуй спрошу - а вы уверены что у вас все в порядке с процессом разработки, программистами и лично вами?