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

Question

[u_story]

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

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

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

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

Answer 1

[morincer]

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

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

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

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

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

Comments

[u_story]

Спасибо, за развёрнутый ответ.

Вчера решили попробовать следующий вариант.
1) Есть аналитик, который на основе тз и описания юз.кейсов системы пишет интеграционные тесты на человеческом языке на какой-нибудь штуке типа specflow
2) Есть разработчик, который по команде ПМ или архитектора покрывает важные расчёты юнит тестами.
3) Есть тестировщик, который занимается ручным тестированием и на основе найденных им багов пишутся новые тесты.

как думаете с таким подходом взлетим?

[morincer]

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

[u_story]

Я правильно понял, что тест-кейсы — это некие тесты, которые пишутся глядя на план тестирования, который пишется на основе тз и спецификацию для разработчиков. Пишут их тестировщики по все системе, независимо от того, реализован данный функционал или ещё предстоит быть реализованным?

Интеграционные тесты тоже позволяют проверить, что функционал работает правильно. т.е. по сути интеграционный тест — это проверка по юз.кейсы, со своими входами и выходами из него.

[morincer]

В целом — правильно, хотя не обязательно писать тест-кейсы сразу на всю систему — главное, чтобы к моменту реализации определенного блока требований, к нему были написаны все тест-кейсы. Т.е., в идеале, необходимым (но не достаточным) критерием качества тестирования является 100%-е покрытие тест-кейсами требований (на каждое требование имеется по меньшей мере один тест-кейс, который его проверяет).

По поводу интеграционных тестов — по определению (см. например в википедию), интеграционное тестирование проверяет качество взаимодействия отдельных модулей, но при этом проводится после модульного тестирования, которое, в свою очередь, обычно проводится на тест-кейсах.

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

Т.е. интеграционное тестирование предполагает, что модули по отдельности работают корректно.

[u_story]

да, я понял вас. Спасибо.
Нужно будет всё ещё разок обдумать и переосмыслить.

Answer 2

[Fant]

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

Comments

[u_story]

Спасибо.

Answer 3

[Андрей]

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

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

основной русскоязычный сайт по тестированию — software-testing.ru

Answer 4

[3dm]

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

Comments

[Андрей]

А как же тогда тест-кейсы для новых фич? :)

вообще вариант «покрыть все кейсами!» не всегда оптимальный, особенно если много маленьких проектов.

[mrBuG]

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

[3dm]

новая фича регистрируеться как новое issue (типа enhancement ). Параллельно с имплементацией тестировщик пишет теск-кейс по «новым» требованиям. После того как дефект перешел implemented-reviewed — тестировщик проходит тест-кейс. Если ТК fails — работа над ишью уходит в rework. и так по кругу, до того как ишью не станет tested.
Разработчики могут не знать всех тонкостей продукта. То есть над проектом работают тимы отвечающие каждая за свой функционал. Все о продукте знает бизнез-аналитик, он то и должен ввести в курс дела тестировщика.

[Андрей]

3dm, это в вашей компании так сделано. У нас совершенно не так. Для u_story совершенно не факт, что этот процесс подойдет. Это во-первых.
Во-вторых, работа тестировщика — это не только тест-кейсы писать и их потом проходить.

[u_story]

А как сделано в вашей компании?
А что должен ещё делать тестировщик кроме создания тестов?

[morincer]

Тестировщик должен еще тестировать, т.е. тест-кейсы выполнять.

Answer 5

[wartur]

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