Цитаты из книг автора «Джефф Каролло»

Роль разработчика в тестировании (Software Engineer in Test, SET) тоже связана с разработкой, но фокусируется на тестируемости кода и создании инфраструктуры тестирования. Разработчик в тестировании анализирует архитектуру, уделяет особое внимание качеству кода и рискам проекта. Он выполняет рефакторинг, чтобы сделать код тестируемым, пишет фреймворки юнит-тестирования и средства автоматизации. Разработчик в тестировании работает с тем же кодом, что и разработчик, но больше заинтересован в улучшении качества и тестового покрытия, чем в добавлении новых фич или повышении производительности. Разработчик в тестировании тоже проводит почти 100% своего времени за написанием кода, но делает это ради повышения качества, а не для реализации фич для пользователей.

Роль разработчика (Software Engineer, SWE) всем знакома и привычна. Он пишет код функциональности приложений, который поставляется пользователям. Он создает проектную документацию, определяет структуры данных и общую архитектуру, а большую часть времени пишет код и проводит код-ревью8. Разработчик пишет много тестового кода, например во время написания тестов для TDD и юнит-тестирования, и, как будет показано дальше в этой главе, участвует в создании малых, средних и больших тестов. Разработчик отвечает за качество всего кода, к которому он прикасается: пишет, исправляет или вносит изменения. Да, все верно: если разработчик должен изменить функцию и его изменение нарушает существующий тест или требует написания нового, он должен написать этот тест. Практически 100% рабочего времени разработчик пишет программный код.

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

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

Я уяснил одно: Google уважает компьютерные технологии и искусство программирования. Если тестировщики хотят влиться в эту компанию, они должны быть технически грамотными и уметь писать код. Только так остальные инженеры будут воспринимать тестировщиков равными себе.

Джеймса Уиттакера. Его основная идея в том, что тестирование должно перестать просто предоставлять информацию и начать влиять на качество.

«The Way of Testivus» и раздел «Beautiful Tests» в книге издательства O’Reilly «Beautiful Code».

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

Тестирование должно стать неотделимым от разработки. Качество родится только тогда, когда разработка и тестирование начнут жить вместе.

В итоге качество достигается предотвращением, а не выявлением багов. Качество — часть разработки, а не тестирования