yamayka80

На некотором проекте project manager написал тестовый сценарий в 185 шагов. Это о чем-нибудь говорит?

По-моему, без контекста ни и чем не говорит...

Ну, написал... А, может, человек учится ?

с юнит тестами это понятно, что ими занят разработчик. про автотесты речи нет.
более конкретный вопрос: должен ли разработчик проводить ручное тестирование с использованием тест кейсов? если да, то в каком объеме?

С помощью тест-кейсов, которые написал тестировщик?
Нет, нет, и еще раз - нет!

Во-первых это немного противоречит предыдущему посту про смоки-тесты (их тоже вполне могли написать тестировщики).
А во-вторых -- почему всё-таки нет? Есть обоснование? Или просто "нет и всё"? :)

Алексей, обоснование есть! :)
Под тест-кейсами я понимала документ, написанный тестировщиком, по которому он и будет гонять свои тесты.
Я считаю, что каждый должен заниматься своим делом, но при этом болеть за общий положительный результат.
Несколькими постами ранее я говорила о том, что разработчики должны "убирать за собой" - то есть своими средствами проверять то, что они делают (например, те же юнит-тесты, короткий тест типа smoke). Отдавать каждый раз переломанный код - не есть уважение к коллегам по команде.
Что касается смок-тестов, то я бы их все же оставила в распоряжении тестеров (плохо представляю, что разработчик возьмет документ, и по нему будет тестировать).

И еще к разделению обязанностей: мы ведь не задаем вопрос "должен ли тестировщик исправлять баги, которые сделал разработчик (хоть некоторые )?"
Тогда почему разработчик должен тестировать вместо тестера/ совместно с ним?

с юнит тестами это понятно, что ими занят разработчик. про автотесты речи нет.
более конкретный вопрос: должен ли разработчик проводить ручное тестирование с использованием тест кейсов? если да, то в каком объеме?

С помощью тест-кейсов, которые написал тестировщик?
Нет, нет, и еще раз - нет!

Тестирование со стороны разработчиков не ограничивается только Юнит тестами. Есть также Integration & System тесты. Ну и вообще, как правило хорошего тона для разработчика должно быть не просто написание кода, проверка Unit, Integration и System тестов, но и ручной тест того, что они "наколбасили" перед выкатом, хотя бы на своей девелоперской платформе... Т.е. они, по-хорошему, должны провести свой Smoke тест до того как отдадут версию в тестирование.

Полностью согласна.
Естественно, разработчики не должны "кушать хлеб" тестировщиков, но "убирать за собой" - это, по крайней мере, правило хорошего тона, уж если речь идет о КОМАНДНОЙ работе.

Пытаюсь ответить на вопросы:
1. На мое подразделение перекинули новый инвестиционный проект, роль в котором - чистое тестирование и заключение о возможности внедрения продукта. Суть проекта - перевод существующих продуктов на новую платформу. Под эту лавочку поставлена задача постепенного забора всех тестировщиков под одно крыло. (Вот ее необходимости и не понимаю). Мое видение: для того, чтобы после завершения проекта было понятно, чем же дальше заниматься и как (т.е. типа подразделение не одноразовое).
2. Окончательное решение принимает, соответствено, директор компании.
3. Дословно задача: сформировать единый центр качества. Что, как, зачем, с какой целью - неизвестно. Все это сейчас будет долго и упорно обсуждаться, поэтому и прошу вашей помощи. Причем замечу, что концепции и планы развития необходимо писать именно мне. Поэтому добавлю еще такой момент: не смотря на то, что задачу мне поставили, я чувствую необходимость объяснять свое же собственное существование и развитие.
4. В результате должно получиться минимум: единый центр качества в виде структуры и налаженных процессов, внедрены продукты, активизирована деятельность по аутсорсингу тестирования.

Масштабность работы даже пугает, честно говоря. Это по сути нужно полностью всю структуру и процессы перелопатить. Поэтому и возник вопрос: стоит ли?

Добрый день!
Читаю я Вас и все больше склоняюсь к тому, что не "центр качества" вам нужно построить, а отдел тестирования или, как его еще модно называют - департамент тестирования. Он, в общем-то, и может заниматься аутсорсингом тестирования и свои разрабатываемые проекты тестировать.

Если говорить про "отдел качества", то из Вашего текста я его не вижу в принципе...