Перейти к содержимому

mmeriin

Регистрация: 10 окт 2003
Offline Активность: 09 июл 2018 16:24
-----

Мои сообщения

В теме: Взаимодействие отделов тестирования и разработки

10 января 2014 - 07:17

Уважаемый Пучок (не знаю настоящего имени :) )
Вы так и не поняли, к чему тут уборщицы? :) Да к тому, что их никто не спрашивает! Глупо спрашивать разработчиков о тестировщиках и глупо спрашивать тестировщиков о разработчиках. Естественно, речь не об оценке 360, а об оценке работы.
На этом объяснения завершу, не тот формат ...
owasp-у:
Скажите:
1. У Вас проектная организация, линейная или матричная?
2. Каковы ожидания от тестирования (инфа от заказчиков)
3. Есть ли цели у организации и у подразделения?

В теме: Взаимодействие отделов тестирования и разработки

01 января 2014 - 21:23

Господи, и откуда берутся такие менеджеры, которые так строят процесс?
У нас в мужском туалете уборщицы, я думаю, не очень довольны теми, кто посещает это заведение, даже если в нем достаточно чисто ...
К чему это я?
Конечно, ничего плохого от оценки программистами тестовой модели, не будет. И здорово, если программисты делают это, и делают не формально.
НО. Программисты не руководители тестировщиков. Это как заставить классного водопроводчика проверить электрический дизайн, сделанный электриком.
Ну бред же? Ведь никому не приходит это в голову?
Так можно докатиться до того, что наказывать только тестировщиков за пропущенные в продуктив дефекты.

Тестировщики и разработчики должны иметь хорошие деловые отношения. Как и все другие. И дело тут не в том, кто какой человек. Деловые отношения.
Тогда водопроводчик и электрик сделают каждый свою работу.

А как сделать так, чтобы это было хорошо - дело их руководителя.
Однозначно не расскажешь, как. Только БЕГИ ОТТУДА, скорее всего не поможет. Слишком много таких медеджеров вокруг, на новом месте тоже вляпаешся.
Тут на форуме много всяких показателей предлагают. Но прежде всего руководитель должен понимать стратегическую цель. То, для чего он это делает.
Если хочет получить минимум дефектов - это одно
Наименьший time to market - другое
Наименьшие затраты :) ...

Сначала нужно понять цель, а потом строить под нее процесс. Поверьте, он (процесс)будет разным...
Извините, так и не ответил :(

В теме: Измерение "качества" итерации

01 января 2014 - 21:02

Если доступен код от разработчиков, то я бы попробовал посчитать плотность ошибок по каждой тушке разработчика.
Т.е. примерно такая табличка:

ФИО разраба; Кол-во ошибок на 100 (1000, 10 000 ...) строк кода
Иванов; 97
Петров; 315
Сидоров; 914

Т.о. Вы примерно будете представлять, что от кого ждать, и будите примерно знать, когда заканчивать тестирование.

Ну и какчество считается отсюда же :)

Плюс у вас есть дополнительная ксива для новоумных менеджеров, которые думают, что тестировщики должны найти все дефекты и т.д.
Оччччень полезная статистика...