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

[Rifle]

Разработчики используют тестировщиков в качестве дебагера.

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

[Yury]

И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

А почему Вы задаёте такие вопросы и кем Вы работаете в этой фирме?

Если Вы работаете просто тестером, то никакая процедура Вам не поможет.
Как уже сказал Green, Вам надо просто брать и устанавливать рабочие отношения с вашими разработчтками.

[ЛаМпочка]

И кто виноват? Проводить служебное расследование по каждому пункту?

Интересно вот только , как должна выглядеть та самая процедура или инструкция, которая максимально эффективно позволила бы избегать подобные ситуации Регламент взаимодействия отделов??? Процедура фиксации ошибки? или Чернышевскийй "Что делать?"

А почему Вы задаёте такие вопросы и кем Вы работаете в этой фирме?

Если Вы работаете просто тестером, то никакая процедура Вам не поможет.
Как уже сказал Green, Вам надо просто брать и устанавливать рабочие отношения с вашими разработчтками.

Люблю встречные вопросы ))

Установка рабочих отношений не есть панацея. Если на голову разработчика или тестировщика из пары, установившей добрые рабочие отношения, падает кирпич, то приходится начинать все с нуля. А проект страдает.

А задаю я такие вопросы, потому как интересен опыт собравшихся.

[Mac]

Люблю встречные вопросы ))

Установка рабочих отношений не есть панацея. Если на голову разработчика или тестировщика из пары, установившей добрые рабочие отношения, падает кирпич, то приходится начинать все с нуля. А проект страдает.

А задаю я такие вопросы, потому как интересен опыт собравшихся.

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

Но... Капля камень точит. Собирайте простую метрику - количество reopened багов на разработчика в неделю. Если хорошие отношения с разработчиками - просто приходите к ним и вежливо интересуйтесь "Что же ты, Вася? Мы от тебя на прошлой неделе получили 20 багфиксов, которые не прошли тестирование. Ты влюбился, али мы забиваем слишком непонятные баги?". Через месяц число "плохих" багфиксов от Васи обязательно уменьшится.

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