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

[chuk]

Во время создания системы качества возникли вопросы:
1. Как оценить работу самого тестера?

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

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

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

Интересно было бы узнать, как это организовано у других.

[Case]

Только присоединюсь к вопросу.

[Case]

Так как готовых решений немного - давайте разбираться сами.

Первое моё мнение - если поставленные задачи выполнены в срок (естевственно после этапа оценки и корректировки времени) - значит общий подход к работе верен.

Подача сделана - давайте развивать.

[Sandtod]

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

[chuk]

процесс полностью формализирован,
тестпланы есть, контроль еженедельный, обсуждение проблем и т.д.

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

Еще вот вопрос по сообщению от Case "если поставленные задачи выполнены в срок (естевственно после этапа оценки и корректировки времени) - значит общий подход к работе верен." - как оценивается выполнение поставленных текущих задач (не по срокам выполнения, а по качеству).?

Т.е. есть конкретная задача, допустим "формирование тесткейсов для нагрузочного тестирования", в конце срока, отведенного на эту задачу идет оценка выполнения, что именно должно оцениваться.?
Область охвата требований, качество скриптов (тоже скользкий вопрос - кто может оценить качество верно выполняемого скрипта), данные для тестирования, точки верификации и т.д. И я могу попридумывать еще кучу критериев, но это тоже работа, и нужны ли эти критерии. И таких ведь задач очень много, есть простые, есть сложные. Для каждой задачи свои критерии оценки.

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

[Case]

Я пытался формализовать общий подход, так как блоее конкретного у меня нет.
Количество риквестов к делу не пришить, тесткейсы и планы я составляю сам, люди по ним спокойно работают выбрасывая как реакцию нагора моменты которым я не уделил внимания.
То есть идея у меня такая - есть задача, есть оцененное на неё время, есть результат - не формальный - прошёл по плану 22 с половиной раза (могут и на втором проходе за день зацепить за что-то интересное), а реальный - отработал, будет работать.

Вариант тыкать человеку в пропущённую ошибку имхо ХР-шный термин "слежение", ничего кроме нервов не приносит.

[el-step]

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

Касательно тестирования в целом мне видится только один доступный способ оценки качества проделанной работы, когда процесс еще не завершен -- на основе статистики по прошлым проектам: из ранее выполненных работ выбираем похожие на нынешние (лучше не проекты в целом, а части -- change request'ы или т. п.), и на основе данных о них делаем предположения о количестве и распределении дефектов в предстоящем проекте. Зная количество найденных ошибок на момент времени, оцениваем а) степень готовности проекта; б) качество и график тестирования (отставание/опережение по отношению к расчетному и т. п.). Последнее можно оценивать как по группе/проекту в целом, так и "в разрезе" тестера или части проекта.
По крайней мере, сбор и анализ данных можно выполнять в условно свободное время между проектами.
(Если нет нужных статистических данных, можно -- от безысходности -- использовать те самые результаты "аттестации" тестеров. Т. е., зная среднее качество работы своей команды и количество найденных дефектов, можно хотя бы прикинуть сколько осталось)

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

Качество планирования -- по а) соблюдению графика выполнения задач; б) объему выполненных работ, не запланированных вовремя (а + б = примерно то, о чем говорил Case: "...если поставленные задачи выполнены в срок..." и т. д.); в) соответствию количества найденных дефектов оценочному (особенно если найдено больше).

Качество самих тест кейсов, тестов, тестовых данных -- по а) количеству ошибок, которые были найдены вне выполнения формальных тестов; б) объему исправлений и модификаций дизайна и реализации в процессе.

Формального подхода для оценки качества выполнения тестов я пока не вижу. Считаю, что Case прав -- фокусироваться на пропущенных ошибках, если только это не явное разгильдяйство, нельзя; страшное рассказывает Sandtod "в первую очередь считается время выполнения тестплана" -- гонка и нервы.. Количество найденных багов как критерий не годится -- не потому, что они бывают разные (можно учитывать "вес" ошибки), а потому что оно не зависит напрямую от качества выполнения теста. Впрочем, мы использовали этот способ для оценки работы тестеров "в свободном поиске".
Вообще, по-моему, chuk использует серьезные и основательные подходы; а то что качество выполнения задачи нельзя оценить непосредственно по окончании выполнения, так это же естественно?.. Странно было бы, если бы качество кодирования определяли до начала тестирования :)
Что же касается предметного разговора, можно рассмотреть какую-нибудь конкретную задачу, вроде той что упоминал chuk -- "формирование тесткейсов для нагрузочного тестирования"...

P.S. Пишу всегда длинно, и даже жестокие сокращения не помогают -- уж простите

[Sandtod]

Количество багов зависит от продукта, а не от тестера, имхо, ну это и так понятно; предложение el-step'a по эталонному тестплану-приложению, которое все делают, в общем-то, работает. Есть тестпланы, которые делал каждый - и тут уже тимлидер смотрит, у кого лучше получилось...
Страшного ничего нет, и гонки нет. Времени на все достаточно. Но можно все сделать быстро, а можно сидеть часами над одним кейсом, не врубаясь в его смысл... я про скорость в этом смысле говорил...

[el-step]

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

[Case]

May be по отношению к руководству применить подход планомерного внушения?
У нас в компании в отношении оценки состояния больше полагаются на слова ведущего разработчика и мои, чем на цифры выполненных/невыполненных тестов. (это имхо на плановую политику больше похоже, чем на оценку)

[el-step]

Я этим неустанно занимаюсь :)
К счастью, и у нас эта странная статистика не является определяющей при принятии решения о выпуске.
А что касается плановой политики -- так ведь и на нее не похоже... тесты разного типа, разной длительности и т. д. -- какое может быть планирование на основе только их количества? Просто один из примеров странного представления о критериях эффективности работы отдела тестирования..