Если говорить на основании собственного опыта в попытке применить к Вашему случаю.
В Вашем случае, скорее всего, вам стоит применять несколько ключевых видов тестирования:
— Ad-hoc — т.е. «протыкивание» — когда тестировщик верифицирует принципиальную работоспособность и общую корректность работы «свежего» функционала. Результатом его работы обычно являются замечания в виде «А вот тут у тебя не работает», «Здесь работает не так», которые иногда(!) оформляются как баги. В этом случае, тестировщик выступает, де-факто, как последнее звено в команде разработки перед передачей функционала в дальнейшее тестирование и задачи ему передаются разработчиком по факту написания блока функционала.
— Тестирование по тест-кейсам — тест-аналитик на основе анализа требований пишет тест-кейсы, которые в дальнейшем выполняются тестировщиком (естественно, эти две функции можно объединять, но есть риск перегрузки человека). Когда требования уходят в разработку, эти же требования уходят тест-аналитику, который на их основе идентифицирует, а затем и описывает тест-кейсы. В данном случае, важно отладить нормальные процессы а) управления требованиями с точки зрения коммуникаций (разработчикам и тестировщикам уходят одни и те же требования, об изменении требований уведомляются и разработка, и тестирование, обеспечена трассировка требований на тест-кейсы и пр.). После передачи функционала в тестирование, тест-кейсы собираются в тест-сет (тестировщиком, тест-аналитиком, тест-менеджером или кем-то еще) и «прогоняются» тестировщиком. Результатом работы являются баги, которые возвращаются разработчикам, классифицируются (например, дефект разработки (ошибка в разработке), дефект документации (ошибка в аналитике), дефект тестирования (ошибка в тест-кейсы) и отрабатываются соотв. группой. В этом случае, группа тестирования выступает как следующее звено производственного цикла (вроде ОТК).
Еще есть дымовое тестирование (smoke testing), нагрузочное тестирование, интеграционное тестирование — их применимость следует оценивать, исходя из реалий проектов (Вы дали слишком мало информации).
Соответственно, видятся три основных роли:
— Тест-аналитик (он же тестплан-девелопер, он же, иногда, тест-менеджер)
— Ad-hoc тестировщик
— Тестировщик
Тест-аналитик подключается, как только требования готовы к передаче в разработку. Ad-hoc — как только разработка начала выдавать результат на «пощупать». Тестировщик — как только закончена разработка блока требований.