Подключение тестировщиков к команде разработке?
=================================================

 Здравствуйте. Получилась следующая ситуация: стал руководитель отдела разработки, в отделе идёт работа над несколькими проектами, по сути часть из них идёт по Agile, вторая идёт по итерационной модели.   
  

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

Сейчас есть желание начать нанимать тестировщиков, чтобы повысить качество продуктов. Но перед тем как нанимать людей, нужно чётко описать процесс их работы. Т.е. когда подключать их к проекту, как писать тест план, какие виды тестов, когда использовать и т.д.  
  

Скажите, с чего начать данную работу? Какие книжки, статьи, сайты почитать? 

 Если говорить на основании собственного опыта в попытке применить к Вашему случаю.  

В Вашем случае, скорее всего, вам стоит применять несколько ключевых видов тестирования:  

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

  

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

  

Еще есть дымовое тестирование (smoke testing), нагрузочное тестирование, интеграционное тестирование — их применимость следует оценивать, исходя из реалий проектов (Вы дали слишком мало информации).   

  

Соответственно, видятся три основных роли:  

 — Тест-аналитик (он же тестплан-девелопер, он же, иногда, тест-менеджер)  

 — Ad-hoc тестировщик  

 — Тестировщик  

  

Тест-аналитик подключается, как только требования готовы к передаче в разработку. Ad-hoc — как только разработка начала выдавать результат на «пощупать». Тестировщик — как только закончена разработка блока требований. 

 Много сказали полезного, добавлять на тему того что тестировать, как тестировать (всякие ТДД, юнит тесты, интеграция, черные коробки и тп) не буду. Добавлю лишь то, что приняв на работу тестировщиков, вы наконец получите ответственного за качество продукта перед выпуском в продакшн. Сейчас у вас ответственность поделена между всему участниками команды и никто не отвечает за качество, уж простите меня за такую фразу) Это важно осознать и отталкивать в построения процесса работы. И пусть аналитик пишет что-то для тестирования, программист тоже, но должна быть одна голова! 

 Выясните, каким образом вы хотите «повысить качество». Тестировщики будут вам сообщать об ошибках, но просто их появление качество не повысит.  

Определите круг обязанностей тестировщика  

  

Если у вас нет опыта в тестировании, то вы все равно не сможете написать, какие тесты и когда использовать, поэтому предпочтительно нанять уже опытного.  

  

основной русскоязычный сайт по тестированию — [software-testing.ru](http://software-testing.ru) 

 По сути в данный момент роль тестировщика у вас выполняет аналитик. То есть набранных тестировщиков в курс дела должны ввести именно аналитики. А процесс работы примерно такой — Написание регрессионных тест-кейсов, которые покрывают требования к ПО (основной функционал) + создание теск-кейсов на проверку найденных дефектов(которые собираются в тестсет и тесткейс проходиться на билде, в котором дефект устранен) + endless exploratory testing. 

 В качестве способа, предлагаю перейти на разработку через TDD, посложнее, но очень железобетонно. С другой стороны я пока не решаюсь на это действие, слишком как мне кажется сложно.