Книга "How Google Tests Software" теперь на русском!

Для планирования тестирования используется AAC-анализ (Attribute, Component, Capability). Его автоматизированная версия называется Google Test Analytics. Суть его проста. Сначала выясняется, почему продукт важен для пользователя и для бизнеса. Для этого составляется список атрибутов (A) - это качества и характеристики продукта. Затем составляется список компонентов (С) это ключевые части кода, которые делают программу тем, чем она является. И, наконец, составляется список возможностей (С) - действий системы, которые она выполняет под руководством пользователя. Возможности лежат на пересечении атрибутов и компонентов. В результате у нас есть все для составления тест-кейсов, которые связываются с этими возможностями.

Для расстановки приоритетов тестирования возможностей используется анализ рисков. Все риски сведены к двум факторам: частота сбоев и степень воздействия. Каждая возможность оценивается по этим двум факторам рисков. Затем возможностям расставляются приоритеты по тестированию в зависимости от риска. Тестируют в порядке уменьшения рисков. 

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

Иерархия тестов в Гугл своя. Вместо юнит-, интеграционных и системных используются понятия малых, средних и больших тестов. Введено это для единообразия понятий.

В Гугл очень большое внимание уделяется автоматизации тестирования. Автоматизировано должно быть все, что только возможно. В Гугл построили общую инфраструктуру, которая отвечает за компиляцию, прогон, анализ, хранение и отчетность о тестах. Для оценки эффективности использования сочетания разных размеров тестов в проекте служит прокрытие кода. Для каждого из трех размеров тестов формируется отчет о покрытии, который должен показывать приемлиемую величину покрытия для проекта. Соотношение автоматизации обычно 70/20/10: 70% малых тестов, 20% - средних и 10% - больших. Благодаря таким объемам автоматизации приложение, поступающее к инженерам по тестированию для исследовательского тестирования - уже высокого качества.

Требования к автотестам будут нам знакомы - это

- независимость друг от друга

- приведение среды в начальное состояние после теста.

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

Ручным является в основном исследовательское тестирование. Тем же Джеймсом Уиттакером была написана замечательная книга "Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design". Туры оттуда и используются для исследовательского тестирования. Причем тестирование является целенаправленным. Анализируются изменения в сборках, и на основании этого принимается решение, что именно тестировать, вместо рысканья по всему продукту. Также показываются преимущества от тестирования ранними пользователями продукта.

В книге освещается вопрос тестирования в режиме сопровождения и дается несколько полезных советов. В частности:

- для исключения ручных тестов берутся тесты, которые всегда проходят или тесты с низким приоритетом;

- исключаются автоматизированные тесты, которые давали ложные положительные срабатывания или ненадежны;

- советуется делать комплект автоматизированных сквозных тестов;

- необходимо исправить все серьезные проблемы перед тем, как покинуть проект, и оставить после себя документ-инструкцию.

В книге перечислены ошибки в процессе тестирования, на которые, я уверена, натыкались и продолжают натыкаться многие.

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

- Тестировщики отождествляются со своей ролью, а не с продуктом. Фокус должен быть на продукте, а не тестировании.

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

В книге описана замечательная система, которые значительно упрощает жизнь инженерам по тестированию. Называется она BITE (Browser Integrated Test Environment) - тестовая среда, интегрированная в браузер. Она служит для увеличения эффективности тестирования. Среди ее возможностей можно отметить следующие:

- регистрация бага прямо с тестируемой страницы с возможностью добавления информации о выделенных пользователем элементах страницы;

- просмотр списка багов тестируемой страницы прямо над тестируемым приложением;

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

- распределение тестов по тестировщикам и ведение результатов выполнения тестов.

Также рассказывается про очень интересную систему Quality Bots, которая служит для автоматизации тестирования отображения разных страниц в браузере Google Chrome. При помощи нее большая часть ручной работы по регрессионному тестированию заменена ботами. Стоит отметить, что все созданные системы либо находятся в открытом доступе, либо планируются быть туда помещенными. Молодцы, они, гуглята :)

Ну и самое интересное в книге оставлено напоследок. Авторы размышляют о будущем отрасли и отдельных ролей в рамках отрасли и делают свои предположения. 

Если говорить об инфраструктуре тестирования, то она переместится в облако.

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