Обзор-конспект "Как тестируют в Google"

"Тестированию, которое мы знаем и любим, приходит конец...
Мир скоро изменится для всех тестировщиков.
Примите эти изменения и управляйте ими, чтобы не потерять свою релевантность как тестировщиков" 

Как тестируют в Google

Давно я не отмечал столько интересностей

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

Ниже будет много букв, кому побыстрее - могу рекомендовать глянуть этот пост, от Никиты Макарова (тезисы отдельно здесь).

Если еще короче - надо идти и читать. И не важно, делаете вы web-приложения, мобильные или десктопные. Советы в этой книге пригодятся всем: разработчикам, и тестировщикам, а также их начальникам.

Книга, как и отмечают авторы, не для новичков. С другой стороны, совсем заскорузлые "гуру" найдут ее излишне попсовой что ли. Хотя, как можно увидеть на фото, я нашел в книжке много интересных для себя моментов.

Да, пока не забыл, огромное спасибо Алене Васюхиной, Юлии Нечаевой, которые перевели книгу.

Итак, поехали.

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

Тезисы:
"Качество ≠ Тестирование: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку...Тестирование не отдельная практика, это часть самого процесса разработки."

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

• В Google культивируется правило «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования. Именно разработчики должны принимать в нем самое непосредственное участие. Разработчики ошибаются, если считают, что тестирование - это не их работа.
• Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код - задача разработчика, а их задача - ввести тестирование в рабочий процесс разработчика. Должны создаваться условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации. 
• Ошибка инженеров в тестировании в том, что они начинают вести себя как разработчики в тестировании. Инженер по тестированию должен действовать глобально, контролировать весь продукт: смотреть на тесты с точки зрения пользователя, помогать обеспечивать эффективное использование всей тестовой инфраструктуры. Инструменты и средства диагностики, которые используют тестировщики, должны влиять на весь продукт.

Виды тестов

• В Google тесты различают по размеру того, что тестируется. И условно делятся три группы: малые (это, например, юнит-тесты), средние (например, тесты для проверки взаимодействия компонентов) , большие (это когда проверяются реальные пользовательские сценарии). 
• Малые тесты направлены на проверку качества кода, а средние и большие - на проверку качества всего продукта.
• На каждый вид тестов действует ограничение по времени выполнения и то, с чем они могут взаимодействовать. Тип теста должны быть обозначен в свойствах теста. От этого зависит поведение системы автоматического запуска тестов: максимальное время выполнение каждого типа отличается и система просто рубанет якобы "зависший" тест.
• Рекомендуемое соотношение количества тестов разных типов: 70 - 20 -10% (малые-средние-большие). Малые всегда автоматизируются, средние и большие - it depends.

Тест-сертификация
Система заданий по тестированию, которые должна выполнить команда, чтобы стать сертифицированной. Отличная тема, позволяющая оценить профессионализм команды разработчиков в общем то игровой форме. Тема достойна отдельного поста.
Могу ошибаться, но мы у себя в команде работаем по уровню 3-4 и даже выполняем часть 5 уровня. Но есть к чему стремиться.

Про поиск правильных людей
В книге много рекомендаций по тому, как найти правильных людей на ту или иную роль.
Также есть неплохая анкета позволяющая отличить тестировщика от разработчика в тестировании. Правда у меня получилось, что по анкете я больше тестировщик :) Но на последующее тестовое задание ответил плохо. И кто я в итоге? :) Гусары, молчать ))

Еще интересно: "Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование"

Интересно про оценку и повышение:
"Решения о повышении основываются на том, какое влияние специалист оказал на свой проект. Во время ежегодных отчетов менеджеров просят описать ценность вклада своих подчиненных и перечислить, на что это повлияло. Мы ожидаем, что при движении по карьерной лестнице сотрудник влияет на все большее количество вещей".
Используются ежеквартальные и годовые OKR (Objectives and Key Results) - список целей и оценка успеха в достижении этих целей. "Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны".

Хорошая (на мой взгляд разработчика) глава про навыки тест-менеджера.
Одним из полезных навыков является способность работы в условиях дефицита (людей). Дефицит приносит ясность и умножает чувство ответственности у всех участников проекта. "Когда ресурсов не хватает, приходится оптимизировать весь процесс. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности".

Есть в книге и про тест-план, как его делать, что он из себя должен представлять. В основе лежит ACC-анализ
Основные принципы ACC-анализа (Attribute Component Capability)

• Избегайте повествования, пишите списки. 
• Оставьте продажи в покое. Тест-план — это не маркетинговый документ.
• Не лейте воду. 
• Если какой-то пункт не важен и не требует действий, не включайте его в план.
• Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать. 
• Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования.
• Итогом должны стать тест-кейсы. 

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

Про автоматизацию

• Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
• Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.

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

Про умирание кода
"При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов".

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

Кстати, неожиданный инсайт из другого источника, все что описано  работает в таких вот условиях: "one monolithic C++ codebase, 4000+ engineers working on it, 30,000 commits a day"- по материалам конференции CppCon 2014. Для меня это действительно показатель.