С некоторых пор я занялся профессиональным тестированием.
По окончании 3 месячного срока знакомства с этой работой, я понял что тестирование мне нравиться. Три месяца это тот срок за который, я считаю, можно понять: человек может заниматься этой деятельностью к которой его приставили, или - пора перестать мучить и себя и человека и дать что то другое. Например сокращение :(
Спустя уже уже 2 месяца работы тестировщиком я понял, что приоритетов для багов выше третьего - нет, вернее я в них не верю, точно также как я не верю в жизнь после смерти.
Почему я не верю в жизнь после смерти? - потому что я никого не видел из тех, Кто От Туда Вернулся.
Почему я не верю в баги третьего приоритета (4,5 а то и 7!)? - такая приоритезация за собой не несет никакой пользы.
Я раньше разделял проекты (к проектам я отношу не только работу но и домашние дела - вынести мусор для меня настоящий проект) на два приоритета - сейчас и потом. Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда. Сейчас нужно накормить ребенка, потом посадить на горшок.
С тех пор я подрос и понял что кроме сейчас и потом есть еще когда будет время или когда нибудь или когда вспомним или, в самом экстремальном случае, наверное уже никогда, но для отчиски совести.... Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда, если будет время - просмотреть API новой версии Selenium RC - 1.0. Сейчас нужно покормить ребенка, потом - посадить на горшок, если будет время до прогулки - повторить с ребенком два цвета: синий и зеленый.
Приоритеты 4, 5 ... n не несут в себе никакой информации. Они просто добавляют уровень к вашей некомпетентности. Вы либо знаете что в вашем продукте имеет приоритеты:
- сейчас
- сразу-после-того-как-закончаться-баги-сейчас
- просмотреть-и-повысить-приоритеты-для-тех-которые-сразу-после-сразу-после-того-как-закончаться-баги-сейчас.
Либо вы не знаете этого.
Сложно?
Cуть в том чтобы баги приоритета 1 и 2 были бы постоянными (стараться этого достичь), а баги приоритета 3 - либо повышались либо оставались такими же. Пересмотр багов должен проводиться периодически и постоянно. Это один из процессов которые нужно внедрять. Простая мысль - управлять багами тоже нужно - но я не встречал практического применения данной мысли на практике - наверное мне "везло".
Пересмотр, повышение приоритетов, и даже (что мне не нравиться) - понижение приоритета, объединение багов в один и присваивание им приоритета на один выше - вот я думаю начальные шаги управления багами.
Есть еще такая вещь как удаление бага по прохождении некоторого заданного времени. Например год прошел и бага самоликвидировалась (как и демоны из к\ф "Иван Васильевич Меняет Профессию") - их как бы и нет. Не встречал такого подхода, но слышал - интересно посмотреть компанию, где годами не исправляют баги :).
Но что делать когда багов сотни? Тысячи? И ими (багами) управлять и пересматривать сложно! - здесь я пожалуй спрошу - а вы уверены что у вас все в порядке с процессом разработки, программистами и лично вами?
Да, наболевшие вопросы Вы подняли:)
ОтветитьУдалитьНа самом деле управление багами в проекте происходит постоянно. Их пересматривают, повышают/понижают приоритеты, переназначают на других исполнителей, откладывают и возвращают, закрывают уже неактуальные (как Вы их назвали "самоликвидирующиеся").
Кстати, для того, чтобы баг стал неактуальным не обязательно год его не фиксить. Достаточно пофиксить баг, после которого исчезнет этот баг. Например, баг№1 говорит о том, что на форме что-то не работает. Баг№2 - о том, что нужно эту форму вообще убрать или кардинально переделать. Понятно, что после исправления бага№2, баг№1 станет уже не актуальным.
И еще, когда багов сотни - это не так и страшно. У меня в проекте сейчас их 283:) При регулярном отслеживании(ежедневно пересматриваю баги каждого программиста), баги не теряются и фиксятся постепенно в порядке меняющихся приоритетов.
Но вот мне трудно представить более 400 багов:) и тем более - тысячи. Наверное такое бывает в очень большых проектах, где работают несколько команд, каждая над своим модулем...
Несколько советов:
ОтветитьУдалить1. Проверять посты spellchecker-ом перед публикацией
2. Разобраться что такое приоритет баги. Возможно, вы путаете приоритет (priority) с серъезностью (severity).
3. Разобраться почему определять приоритет баги не является компетенцией тестировщика.
Вообще, конечно, все гораздо сложнее, чем вы себе пока представляете, но это сильно зависит от размера проекта. Вам, может и хватает 3 категорий, а в каком-нибудь Мелкософте - нет. У нас, например, есть и серъезность и приоритет, но все смотрят на другой параметр - рейтинг, который является вычисляемым и зависит от многих факторов.
1) писал сразу в блоге - теперь так не делаю, спасибо. Если честно по сочинениям всегда было 5\2 (отлично - за раскрытие темы, 2 -... понятно за что)
ОтветитьУдалить2) имелось ввиду и то и другое. Мы ставим и
приоритет и важность но...
3)приоритет и важность в нашем проекте на самом деле назначается и тестером, и тест-менеджером и менеджером проекта :(. Как правило как менеджер изменит priority так ему и быть. На Severity в нашем проекте обращает внимание только тестировщик когда его назначает ;(
3) а вот рейтинг для меня что то новое - не читал. Можно подробнее? или ссылку. С метриками у меня признаться напряженка.
по поводу того что в других компаниях управление тестами ведеться - слышать отрадно. Надеюсь привить культуру и в нашем проекте.
Большое спасибо за комментарии. У нас к сожалению баги с приоритетом 4 не фиксяться, не вспоминаются и исчезают при выпуске новой версии :(. Наверное это не правильно. Сотни это не 200 или 300, сотни это когда ... ну порядка 1024 (сейчас посмотрел)