Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Меня часто спрашивают об идеальном соотношении разработчиков и тестировщиков. Я всегда отвечаю, что это зависит от контекста. Хорошее соотношение тестировщиков и разработчиков определяется рядом факторов. Тут надо подумать о том, работаете ли вы с последней технологией или с давно существующим продуктом, о таланте и опыте членов команды, и об ожидаемом ритме релизов. На самом деле сработать могут самые разнообразные соотношения, но у каждого есть достоинства и недостатки. Разберем несколько примеров.

1 разработчик : 1 тестировщик

Соотношение 1:1 – отличный вариант, если разработчики мало знают о тестировании, а тестировщики – о разработке. Пара разработчик-тестировщик может совместно работать над выпуском новой фичи, а так как они сконцентрированы на ней, то с шансами найдут и исправят все баги. Однако разработчик, возможно, не будет участвовать в автоматизации тестирования, а тестировщик будет единственным, кто знает, как эту автоматизацию запускать и править. Это значит, что при будущих изменениях фичи тестировщик станет бутылочным горлом, замедляя работу.

2 разработчика : 1 тестировщик

Это соотношение хорошо в ситуациях, когда над фичей работают фронт- и бэкэнд-разработчики. Тестировщик отвечает за тестирование интеграции фронта и бэка. Как и в случае с 1:1, эта троица будет экспертами по фиче. Однако это может привести к разобщенности, когда кому-то еще позднее будет трудно помочь с работой.

2 тестировщика : команда разработчиков

Это очень распространенный сценарий. Тестировщики делят стори между собой согласно своим навыкам и загрузке. Если оба тестировщика талантливы и организованны, обычно они способны справляться и с ручным тестированием, и с автоматизацией. Они также могут меняться фичами, чтобы посмотреть, не пропустил ли коллега баг. Однако это соотношение часто приводит к бутылочным горлышкам, когда фича нуждается в большом объеме тестирования, а один из тестировщиков в отпуске.

1 тестировщик : команда разработчиков

В этом случае тестировщик становится "тренером по качеству". Он не отвечает за все тестирование и всю его автоматизацию. Он направляет и тренирует разработчиков в понимании, что нужно тестировать и автоматизировать. В этом случае за качество отвечает вся команда. Если тестировщик недоступен, разработчики смогут заполнить пробелы, создавая тест-планы и тестируя работу друг друга. Так как разработчики участвуют в создании и поддержке автотестов, автоматизация не становится узким местом.

0 тестировщиков : команда разработчиков

Возможно, кто-то сейчас передернулся от ужаса, но команда опытных разработчиков способна проводить свое тестирование. Чтобы оно было успешным, разработчики должны понимать важность исследовательского тестирования и уметь создавать тест-планы. Им надо понимать, какие типы тестов нужно автоматизировать, и они должны поддерживать код тестов так же тщательно, как и код продукта. Они будут проводить некоторое первоначальное тестирование своей работы, но также создадут тест-пары, в которых один разработчик будет тестировать работу другого. В этом случае каждая фича будет изучена двумя парами глаз, которые с шансами найдут баги.

У всех этих соотношений есть нечто общее. Во-первых – самое важное – как минимум один человек в команде – прекрасный тестировщик. Эти навыки необходимы для поиска трудноуловимых багов. Во-вторых, требуются хорошие навыки коммуникации. Тут нет места перекидыванию ПО за забор для тестирования; тестировщики и разработчики работают сообща. И, наконец, требуется желание быть командным игроком. Тестировщики и разработчики должны стремиться заняться тестированием вне зависимости от того, их ли это обязанность. Когда в команде есть все три фактора, любое соотношение будет успешным.

Обсудить в форуме