Примеры регламент работы группы тестирования

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

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

Соответственно нужен документ, в котором описано всё, что происходит с момента передачи нам продукта. Т е написано, что сначала на основе документа xxxx проверить изменения контента, потом на основе документа yyyy проверить новый функционал и добавить их в тест план, потом провести регрессионное тестирование на основе тест плана .... и в конце составить отчёт согласно документу jjjj.

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

Заранее благодарен за помощь.

Для начала набросайте простую диаграмму (пример в аттаче).

Я в свое время воспользовалась документом, представленным компанией Aplana.
Здесь же можно описать внутренние процедуры в отделе(группе) тестирования, указать зоны ответственности и распределение/совмещение ролей.

http://www.pmprofy.r...les/581/188.asp

contestar, marli благодарю, буду изучать, результаты попробую оформить и выложить тут, может кому-то ещё понадобится

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

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

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

Это процесс ради процесса. В таком случае этот документ принесет много вреда и совсем нисколько пользы.

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

Это процесс ради процесса. В таком случае этот документ принесет много вреда и совсем нисколько пользы.

Yep. У нас регламент служит совершенно другим целям.

• Если не знаешь что делать или чем заняться - действуй по регламенту.
• Если ты накосячил - проверим, а по регламенту ли ты действовал?
• Не забыть, зачем мы здесь.
• И главная - ускорить обучение стажеров, дабы меньше они занимали времени действующих сотрудников.

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

Это процесс ради процесса. В таком случае этот документ принесет много вреда и совсем нисколько пользы.

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

Yep. У нас регламент служит совершенно другим целям.

• Если не знаешь что делать или чем заняться - действуй по регламенту.
• Если ты накосячил - проверим, а по регламенту ли ты действовал?
• Не забыть, зачем мы здесь.
• И главная - ускорить обучение стажеров, дабы меньше они занимали времени действующих сотрудников.

аналогично)

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

Дело не в размере "коллектива".
Размер - не важен. (Извините за каламбур).

Тут (помимо собственно задач) есть ещё один момент.
Дело в тем - с кем Вы работаете.
Если у Вас серьёзный партнёр, то Вы (ваша фирма)должны быть сертифицированным (например, ISO). Без подобной сертификации Вас даже не допустят к конкурсу на проект.
А, чтобы получить сертификат, ваши процессы и документация должны соответствовать.
Документ marli написан в соответствии с требованиями CMMI.
Так партнёром нашего банка служит фирма из трёх человек: 2 программиста и 1 тестировщик. Им пришлось "соответствовать".

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

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