В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.

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

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

Читается — легко. Полезность — неимоверная, но не для всех. Поясню.

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

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

Вот выдержка из книги:

Мы следуем совету Ларри Пейджа, который сказал, что «дефицит приносит ясность», и это заставляет нас правильно расставлять приоритеты. <…> Дефицит заставляет ценить ресурсы тестирования и относиться к ним с уважением. <…> Когда меня спрашивают, в чем секрет вашего успеха, я всегда даю совет: «Не нанимайте слишком много тестировщиков»

Эта мысль идет лейтмотивом через всю книгу, где-то автор описывает ситуацию, что над руководителями, которые говорят, что им не хватает тестировщиков — смеются.
Черт побери, правильно делают. Пару лет назад я даже писал, что хвастаться тем, что у нас-де много тестировщиков как минимум странно. И повторял, что каждый следующий — лишний.

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

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

Еще несколько цитат из данной книги

… смысл тестирования не в улучшении качества. Качество должно быть встроено в продукт по умолчанию, а не привинчено к нему позже, поэтому качество должен обеспечивать разработчик, и точка. Итак, встречайте роковую ошибку номер один: тестировщики превратились в «костыли» для разработчиков. Чем меньше мы заставляем разработчиков думать о тестировании, чем сильнее упрощаем его для них, тем меньше они им занимаются. <…> Если тестирование выделяется в удобный сервис, о котором разработчики могут не думать, они и не будут думать.

Выделенная команда тестировщиков часто фокусируется на создании и сопровождении артефактов тестирования. <…> напоследок, пожалуй, самая показательная роковая ошибка. <…> Во всех продуктах, которые мы выпускали, при эксплуатации находились ошибки, которые не нашла команда тестирования. Мы прикидывались пользователями, а они были пользователями. Не важно, кто тестирует продукт, главное, что тестирования проводится. <…> По факту, чем меньше инженер по тестированию тестирует сам и чем больше он помогает выполнять эту работу другим, тем лучше для продукта.

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