Зачем тесты бизнесу?

Я на миллион процентов за QA, и я на миллион процентов против отделов QA. Мы боролись с ними в 90-е, мы их победили лет на 15, и вот они возвращаются.

Кент Бек

Но что делать с бизнесом, с теми кто давит выпустить «быстрее-быстрее»?

Для начала надо определиться с тем, что мы делаем, зачем и как. Инженеров нанимают, чтобы они решали проблемы бизнеса. Нередко при этом надо писать код — тогда надо это делать быстро и качественно. И бизнес даже может нам объяснить, что в его понимании «быстро и качественно». Вот только бизнес не знает, как этого добиться. И в наши задачи входит в том числе и объяснить, почему разработчики должны тратить время на авто-тесты.

Почему бизнес сопротивляется?

Может быть масса причин, почему бизнес не хочет тратить время разработчиков на тестирование. Например:

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

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

Стоимость времени разработчиков

На тему «почему тестирование важно» сказано уже немало до меня, а потому сосредоточимся на вопросе от бизнеса «почему именно разработчики должны тестировать свой код?».

Я предлагаю вам попробовать собрать следующую статистику:

1. Сколько времени в среднем требуется, чтобы погрузить тестировщика в контекст конкретной фичи? Сколько требуется человек для этого?
2. Как часто на вашем проекте тестировщики возвращают фичу на доработку? Сколько такие доработки занимают? Включая время, которое задача просто висит в очереди.
3. На сколько уменьшается скорость поставки с каждым добавленным куском функционала?

Первые 2 пункта этого списка показывают непосредственно сколько времени тратится на передачу знаний и перекидывание задач туда-сюда между разработкой и тестированием. Тут нужно учитывать и то, как влияет на работника постоянное переключение контекстов. К моменту, когда тестировщик доберётся до фичи, разработчик уже может забыть, что и как там работает.

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

На что способны инженеры

Разработчикам, кажется, приписывают полную неспособность делать качественный продукт. Мол, если не будет тестировщиков, то разработчики будут делать неюзабельное говно. Но во-первых отсутствие тестировщиков != отсутствие тестирования. А во-вторых, команды, в которых осознанно нет тестировщиков, больше вкладываются в обеспечение качества. Именно это позволяет держать должный уровень продукта.

В нашей команде в Дойче Банке мы пришли от более-менее традиционного набора в 4 разработчика и 3 тестировщика к схеме, где у нас есть просто 7 инженеров, которые отвечают за всё. Все тестировали, все писали код. В результате мы избавились от возвратов из UAT, а количество дефектов снизили до 1 за полгода.

В компании Mindbox тестировщиков нет вовсе. Тестирование и обеспечение качества осуществляется инженерами по разработке ПО. Это не мешает компании быть одним из лидеров рынка автоматизации маркетинга.

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