Супер!!!!

Чё за бред, правьте функцию на соседней базе, а потом реплицируйте сюда.
Должно быть как минимум две базы - разработки и тестирования.
Слышали что-нибудь про СКВ?

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

В моем пониамнии, идеальная схема проекта и роли в нем ПМ такая:
есть ПМ, желательно,человек бизнеса, не имеющий ничего общего с программированием и тестирвоанием. Он может руководить как одним проектом (если проект большой) так и несколькими маленькими. Идеальная роль для ПМ - "прокладка" между командой и заказчиком.
Далее есть QA Lead со своей командой и Технический Менеджер со своей. Желательно, чтобы между ними был Аналитик, который бы собирал требования и решал споры.
Задача ПМ - решение вопросов сроков и поддерживать здоровую рабочую атмосферу между департаментами Qa и Development. я считаю, что материальные вопросы должен решать специальный отдел.

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

компания, выпускающая софт, обычно специлизируется на одном-нескольких продуктах, и для каждого разного проекта меянется набор стандартных модулей и добавляются различные специфичные feature для данного продукта. Например, если это workflow, то для каждого проекта хоть оно и отличается, но ядро одно и то же. Я имею ввиду, что наврядли компания автора разрабатывает целиком и полностью новый продукт. Поэтому и следует ориентироваться на предыдущий опыт.
По поводу Change Request: при формулировки требований, всегда есть такой пункт, как RISK (то есть возможность изменения требований). И если он равен 100%, то увеличить цифры вдвое, если 50 - то в половину..
По поводу, 10% - вдруг больше, вдруг меньше - естесственно такое может быть.
Но как я предполагаю, этот документ - филькина граммота, никакой официальной "юридической силы", по большому счету, он нести не будет, это и понятно, потому что вероятность точного определения количество багов в системе такая же как вероятность в казино выграть джек-пот.

Мне кажется вот это еще куда не шло Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

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

Мне кажется, наиболее логичный выход - это аналитическая оценка.

А что такое аналитическая оценка? Как её проводить?

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

127 ошибок на 1000 кода. Где то была такая оценка. Только вот для какого проекта это справедливо?

А на общий вопрос: "Сколько ошибок будет в проекте?", - отвечаем так же обще: "Столько, каков пробег у автомобиля." У какого автомобиля, выражено в дюймах или парсеках - это уже не важно. Общий вопрос - общий ответ.

Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

Мне кажется вот это еще куда не шло Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

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

Мне кажется, наиболее логичный выход - это аналитическая оценка.

Поделюсь своим опытом (я руководитель отдела качества).

У нас в компании создание и тестирование новой версии основано на двух столпах:
1. Контроль версий.
2. Баг-трекинг.

Есть технический руководитель проекта (по совместительству Team Leader)
Он вместе с Top Level менеджерами осущевствляет планирование релизов нового функционала. Без одобрения QA отдела релиза быть не может. Поэтому сроки распределяются с учётом времени на тестирование. После того, как поставлен список features, которые надо зарелизить в ближайшем билде, разработчики занимаются разработкой, а QA отдел занимается подготовкой тестирования (тест-план, тест-кейсы, скрипты и т.п.). Это так, преамбула. А теперь сам процесс.

1. Разработчики проводят новую Label в системе контроля версий (у нас это Borland StarTeam).
2. Сообщают QA отделу, что можно собрать и тестировать новый функционал.
3. QA собирает новый билд по проведённой Label.
4. Устанавливает его на тестовом серваке (сносит старый и ставит новый, апдейтит, устанавливает ещё один экземпляр и т.п.)
5. Проводит Common Release Control - CRC (тестирование функционала, который обязательно должен работать в любой версии системы)
6. Проводит тестирование функционала, заявленного, как реализованный.
7. Пока QA занимается тестированием, разработчики занимаются баг-фиксингом, но все пофиксенные баги, репортятся, как баги пофиксенные в следующем билде.
8. Если QA не сообщает о критических багах в CRC, а также об отсутствии таковых в новом функционале, то билд считается стабильным и его можно передавать клиенту.
8.а. Не обязательный, но желательное дополнение к 8. это выпуск Release Notes и в первую очередь внесение в них Known Issues, то есть багов, которые есть в баг-трекинг системе, но не пофиксенных ещё. Тем самым можно снять с себя ответственность за выпуск недостаточно качественного билда, а заодно посовещаться с Top Level менеджерами, по поводу отдачи билда клиентам или нет.
9. Если билд оказался нестабильным, QA может продолжить тестирование нового функционала (если это возможно), чтобы снабдить разработчиков информацией, но в любом случае билд нельзя отдавать клиенту.

P.S. Проблема сроков, это проблема не тестировщиков или разработчиков, а проблема управления проектами. Нельзя сваливать её на QA отдел или Development отдел.

Imbecile совершенно верно рассказал, у меня есть лишь маленькие комментарии)

Во время сбора требований QA разрабатывает QA Assesment, Development - Impact assesmemt. После финализации требований QA и Development апдейтят свои Assesment (Assesment - это собственно как кодим и как тестим). 1) Затем девелоперы девелопят, тестировщики пишут тест-кейсы.
2)Затем девелоперы выдают build.
как я поняла, у вас, Imbecile, сборкой выдач занимается QA. У нас это делает специальный отдел, и так лучше, потому что принцип хорошей организации работы - четкое разделение труда.
2)Специальный отдел выдает сборку в QA.
3) Qa устанавливает сборку на свои серваки. "(сносит старый и ставит новый, апдейтит, устанавливает ещё один экземпляр и т.п.) - Imbecile, очень индивидуально, у нас процесс обновдения серваков происходит по другому. В любом случае, должен быть специальный док, который описывает действия с сервером, этот док в последствии выдается заказчику, так как правильная установка билда - очень важная часть работоспособности системы.

Далее согласна с Imbecile.
Known bugs (known issues у Imbecile) описание обязательно, если хотите сделать продукт качественным, а отношение заказхчика к вам серьезное.


То есть, со временем у Вас появятся свои наметки, но принцип один:
Программировыание/разработка документации
Сборка/выдача/установка билда
Тестирование
Багфиксинг
Внешняя выдача

При следующих внешних выдачах главное, чтобы были пофикшены критикал и хай внешние баги (то есть баги, которые нашел клиент)

1. Считаете ли вы себя профессиональным тестировщиком?
да)

2. Какое у вас образование?
высшее (программирование)

3. Когда вы решили стать тестировщиком (или вы стали им случайно?)
случайно - в институте начала подрабатывать.

4. Нравится ли вам быть тестировщиком? Если да, то почему? Если нет, то почему?
нравиться! потому что это мое)

5. Какой набор качеств/умений должен быть у хорошего тестировщика?
желание! причем, чтобы стать хорошим тестеровщиком - огромное желание! и осознание того, что "тяжело в учении - легко в бою" - не про нашу работу, мы всегда в процессе обучения))

6. Какие качества/умения отличают хорошего тестировщика?
То, что касается ручного тестирвоания:
Сейчас меня побьют :)
профессиональный тестировщик - это профессиональный идиот, "о! а что получится, если сделать так:)"
Если серьезно, то необходимы усидчивость, желание изучить продукт, хорошее знание технического английского (так как хоть российское ПО развивается стремительными темпами, но все же западные проекты более перспективны), чтобы написание писем и решение проблем не отнимало много времени, умение общаться (при общении с программистом экономит массу времени и нервов) и "любопытность"!
Для автоматизированного тестирования - смотри выше + хорошие навыки программирования

7. Опишите ваш обычный рабочий день.
по разному)

8. Какие 5 рекомендаций вы бы дали человеку, который хочет стать тестировщиком?
1)готовность учиться и думать о проекте в нерабочее время (если такое будет хи-хи)
2)начать учить английский
3)вспомнить SQL
4)познакомиться с общими принципами тестирования, жизненным циклом ПО, и вообще бизнесс-процессами.


9. На какой вопрос еще вопрос вы бы хотели ответить?
какие варианты карьерного роста у тестировщика?
1)либо в своей сфере - QALead, если контора не очень крупная, то возможно и PM.
2)Business Analyst
3)карьерный рост программиста.