Цитаты из книги «Как тестируют в Google», страница 3

Совместными командами обычно руководят менеджеры, вышедшие из среды программирования или управления, но не из среды тестировщиков. В предрелизном аврале они предпочитают выпустить функциональность полностью и закрыть как можно больше задач по «отделке», чем позаботиться об общем качестве. Внутри команды тестированию часто отводится второстепенная роль по отношению к разработке.

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

Забота о качестве — это ежедневная обязанность каждого инженера. Если это делается на совесть — уровень качества растет.

Цель тестировщиков — снизить риски, найти как можно больше багов и проблем, предоставить команде метрики и общую оценку рисков.

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

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

Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата.

Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся.

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

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