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

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

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

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

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

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

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

Соответственно, видятся три основных роли:
— Тест-аналитик (он же тестплан-девелопер, он же, иногда, тест-менеджер)
— Ad-hoc тестировщик
— Тестировщик

Тест-аналитик подключается, как только требования готовы к передаче в разработку. Ad-hoc — как только разработка начала выдавать результат на «пощупать». Тестировщик — как только закончена разработка блока требований.
Ответ написан
Fant
@Fant
Много сказали полезного, добавлять на тему того что тестировать, как тестировать (всякие ТДД, юнит тесты, интеграция, черные коробки и тп) не буду. Добавлю лишь то, что приняв на работу тестировщиков, вы наконец получите ответственного за качество продукта перед выпуском в продакшн. Сейчас у вас ответственность поделена между всему участниками команды и никто не отвечает за качество, уж простите меня за такую фразу) Это важно осознать и отталкивать в построения процесса работы. И пусть аналитик пишет что-то для тестирования, программист тоже, но должна быть одна голова!
Ответ написан
freiman
@freiman
Тестировщик 12+
Выясните, каким образом вы хотите «повысить качество». Тестировщики будут вам сообщать об ошибках, но просто их появление качество не повысит.
Определите круг обязанностей тестировщика

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

основной русскоязычный сайт по тестированию — software-testing.ru
Ответ написан
@3dm
По сути в данный момент роль тестировщика у вас выполняет аналитик. То есть набранных тестировщиков в курс дела должны ввести именно аналитики. А процесс работы примерно такой — Написание регрессионных тест-кейсов, которые покрывают требования к ПО (основной функционал) + создание теск-кейсов на проверку найденных дефектов(которые собираются в тестсет и тесткейс проходиться на билде, в котором дефект устранен) + endless exploratory testing.
Ответ написан
wartur
@wartur
В качестве способа, предлагаю перейти на разработку через TDD, посложнее, но очень железобетонно. С другой стороны я пока не решаюсь на это действие, слишком как мне кажется сложно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы