How Google Tests Software

Напоследок, три цитаты.

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

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

Три. Что будет потом:

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

How Google Tests Software

Еще пара цитат.

Первая:
Если ваш план не привел к созданию тестов, значит вы потратили время зря.

Вторая:
Я поступил по-гугловски: сказал, что поставлю эксперимент на паузу, но делать этого не стал

How Google Tests Software

Курсивом цитата, мои комментарии нет.

Вот общий список того, в чем тестировщик должен однозначно разбираться :
- планирование тестирования и анализ рисков
Не знаком ни с кем, кто бы этим занимался и у него получалось
- анализ спецификации, архитектуры, кода и существующих тестов
Худо-бедно, как правило не дальше спецификации. Как и все.
- исследовательское тестирование
Не знаком ни с кем, кто бы умел и применял осознанно.
- пользовательские сценарии
Здесь гораздо лучше, вроде летали и знаем, я и коллеги
- разработка тест-кейсов
На этом собаку съели, чо
- организация краудсорсинг тестирования
Не встречался, в силу специфики
- метрики использования
Знаком с тестировщиками, активно использующими, но сам нет
- работа с обратной связью от пользователей
Конечно, я бывший саппорт

How Google Tests Software

Еще пара цитат из книги.

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

Цель инженера по тестированию (Test Engineer TE) не искать ошибки в приложении, чтоб исправить их - этим занимаются разработчики, но искать ошибки, чтоб выявить их причину и помочь разработчику самостоятельно или с помощью разработчика в тестировании (Software Engineer in Test SET) - устранить эти помехи.
Я так понял, баги как таковые тестера вообще не очень интересуют, они являются инструментом выявления проблем, их признаком. Как-то так.

Цитата два:
Simon Stewart: Я пользовался процессом DDD (Defect-Driven-Development). Я объявлял WebDriver бездефектным, а когда пользователь находил баг я его исправлял и снова объявлял продукт бездефектным. так я исправлял по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.

How Google Tests Software

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

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

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

Я выписал несколько цитат, на неделе буду постить.
Первая:

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

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

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

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