Книги: октябрь

Джеймс Уиттакер, Джейсон Арбон, Джефф Королло, «Как тестируют в Google»

О подходе Гугла к тестированию из первых рук. Для нас, неандертальцев, это, конечно, космос.

Показалось логичным, что разработчики наравне с остальными отвечают за качество и активно вовлечены в тестирование. Другие роли менее ожидаемы: «разработчик в тестировании» (полноценный разработчик, отвечающий за тестируемость продукта) и «инженер по тестированию» (анализирует риски, составляет план тестирования, смотрит на продукт со стороны пользователя).

Кусочки на память.

Когда я пожаловался своему начальнику, он сказал: «Это Google. Если ты хочешь, чтобы что-то было сделано, — сделай это».

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

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

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

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

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

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

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

Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимание на точное значение рисков.

Постоянно просите инженеров мыслить масштабно при любой работе!

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

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

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

Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных.

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

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