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

Работаю тестировщиком. Почти в свободном полёте, бюрократией занимаюсь редко.
Но в то же время она есть (то что вокруг происходит, считаю таковой), и ею занимаются коллеги (не по своей воле, как мне думается).

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

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

И лично меня не особо это касается. Но вижу как обстановка напрягается. Считаю, что текущий механизм не помогает работе. В нём нет крайностей и каких-то переборов, механизм как механизм, просто он мне не очень нравится.

Поделитесь, что помогает вашей работе? Какие организационные, психологические, технические и другие моменты используются, чтобы решить сходную задачу.
Если сейчас пойду и скажу, что то, что вижу мне не нравится. Спросят меня: "А как ты предлагаешь?". Прошу помочь (также готов быть переубеждённым, если толково кто-то объяснит достоинства такого подхода по сравнению с другими, если другие подходы вообще применяются).

Из описанного могу сделать вывод, что такая постановка процесса меняет цель от выпуска хорошего продукта к формированию персональных положительных показателей. Да ещё и обостряет конфронтацию между разработчиками и тестировщиками. Описанный процесс это не мотивация, а стимуляция.
Мне в первую очередь помогает, когда тестированием занимается вся команда, т.е. тестирование это не то, что только тестировщики делают, а это многослойный процесс. Во-вторых, для мотивации важно, чтобы результат работы был кому-то нужен, интересен и востребован. Но вообще, тему сложно описать в двух словах, могут быть и другие сильные мотиваторы.

И, да, бегите оттуда.

Спасибо за ответ, Валерий.

Модель разработки у нас и не итеративная и не каскадная, смешанная. Скорее всего, делается так, как описано в PMBOK. А методология близкая к RUP, но от руководителей не слышал, что именно такая. В целом - не Agile, и разработчики от тестировщиков отделены. Бывает конечно, что выпускается специальная версия, которая активно ведёт отладочные логи и так далее (плодотворное взаимодействие), но бывает это в рамках исправления конкретного важного замечания, а не всегда.

Но поняв мысль, понял наши недостатки. Когда разработчики сделают изменения в ядре и надо протестировать. При этом на изменённую часть ядра мало документации (описание изменений бывает больше по объёму, чем описание требований и функционала, или описание изменений - всё что есть). Мало прикладной логики, работоспособность которой и на старой и на новой версии гарантировала бы то, что изменения не сломали систему. В таких ситуациях сложно, приходится становится прикладным разработчиком и писать много прикладного кода (получится или нет, на стадии подготовки к тестированию ещё не ясно). И ладно если всё упадёт на первом-втором тесте (быстрая отдача - признак успешности курса). А если не упадёт, то остаётся метод научного тыка, при котором и неясно, правильно ли делаешь, или полного перебора, на который может не хватить времени.

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

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

Согласен. Бывает удивляюсь, когда за время быстрого тестирования делаешь больше работы, чем за время долгого, и с большим интересом. Быстрое тестирование такое, на которое отведено три часа или день/ночь, с пометкой очень надо, когда приходят сразу с советом - сделай вот так и вот так, и сразу начинаешь делать (почти без подготовки). И сразу принимают результат.
А долгое тестирование это когда надо проверить всё, всё расписано, срок 2 недели (или больше), когда из 100 тестов только 10 сбойных, и тестирование прошло, а ничему не научился. Когда главный вопрос по завершении касается только отклонений от плана. При таком тестировании требуют отсутствие отклонений, а остальное - на твоей совести.

И, да, бегите оттуда.

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

Если меня спросят: "А как ты предлагаешь?", - то скажу, что:

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

Ещё раз спасибо. Если есть ещё советы, или замечания к сделанным мною выводам, буду рад выслушать.

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

И, да, бегите оттуда.

Поддерживаю

А дефекты всё равно найти надо

В чем цель тестирования? Кто ваш заказчик? Кто конечный потребитель?

Люди могут быть отличные, процессы - не очень. И наоборот. Вас хотят мотивировать и тотально контролировать. Так не бывает. Программист > Тестировщик - извините, это вообще бомба.
Много копей было сломано в обсуждениях KPI тестировщиков. Однозначный вывод на сегодня - исчисляемых сбалансированных KPI для тестировщиков не существует. Можно считать метрики, опираться на них при принятии решений, но завязывать на них финансы - самоубийство.
Косвенным образом можно посчитать сроки-качество (сроки: отклонение от baseline, качество: число критичных/блокер багов после релиза).

Спросят меня: "А как ты предлагаешь?".

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

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

Ещё немного вброса - а может все дело в руководителе отдела тестирования, который "прогнулся" под этой нелепой системой оценки? Как было уже сказано, программисты не должны и не могут оценивать труд тестировщика и тем более влиять на зарплаты, а почему не наоборот, тестеры оценивают как программеры разрабатывают софт и кто меньше косячит, тому премия, м?

Может стоит узнать у руководства зачем это все делается и затем предложить какое-то иной вариант, который бы решал проблему руководства?

http://www.managemen.../qm047-1-3.html
Смотрите пункт "3. СИСТЕМЫ АТТЕСТАЦИИ И РАНЖИРОВАНИЯ ПЕРСОНАЛА"

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

Раз уж подняли тему, owasp, расскажите, как у вас дела с этой оценкой, добились ли каких-то результатов и как? Или ушли из компании?

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

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

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

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

Извините, так и не ответил :(

mmeriin, очень хочу помочь Вам всё же ответить, для чего воспользуюсь Вашим ассоциативным рядом, - вот Вам наводящий вопрос: будут ли там у вас уборщицы наконец довольны, если сначала электрик сделает свою работу, затем сантехник канализационной трубой заденет фазу, когда в рамках понятной стратегической цели Вы будете строить под неё процесс?
Постарайтесь и наверняка получится дать умный ответ на вопрос owasp, надеюсь, только уже без использования Ваших ассоциаций с туалетом, электриками и т.д. и т.п. И на всякий случай: соблюдайте правила электробезопасности на вашем предприятии!

Если сейчас пойду и скажу, что то, что вижу мне не нравится. Спросят меня: "А как ты предлагаешь?".

owasp и всем: лично я инициативу изменить подобную ситуацию одобряю, НО за счёт коллективного разума форума не приветствую - если не доросли своим умом, то идти в "верхи" (а то и делать карьеру) с чужими идеями вряд ли этично!

Михаила понимаю и поддерживаю. Puchoсk'а не понимаю. Просьбу топикстартеру рассказать чем все кончилось - поддерживаю.

Мне кажется это неэффективным.
1) Думаю в оценку разработчиками тестировщиков будет примешиваться личное отношение и оно будет в значительной степени определять оценку. Впрочем если у тестировщиков есть возможность оспорить оценку и тем самым показать неадеквтаность оценивающего то этот пункт отменяется. У многих разработчиков есть негативное отношщение к тестировщикам, за то что они находят баги.
2) непонятно зачем разработчикам тратить свое время на оценку тестировщиков, вроде это не должно входить в их обязанности.


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

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

Много ответов, понял характер советов, большое спасибо. Давайте закроем обсуждение.
Важная ремарка про компанию: разработчики, документаторы, тестировщики, администраторы, аналитики и поддержка выкладываются ради друг друга по полной. Роли совмещаются, так как люди с вагонами знаний и опыта. Компания небольшая, правила в ней меняются часто, в лучшую сторону, и уже сменились. Зарплаты достойные, премия не играет роли (моё скромное мнение). Вероятно, такого нет больше нигде.
Любые показатели не прошедшие проверку не влияют на премию, но сохраняются и их считать надо (считал бесполезным лишь этот момент).

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

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

давайте закроем обсуждение

и

текущий сайт не нравится

Что тут - причина, а что - следствие?

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

Перевожу - вы все дураки, и на этом давайте закроем обсуждение.