пятница, 28 февраля 2014 г.

Как тестируют в Гугл. Впечатления от прочтения и краткий обзор.

"Качество родится только тогда, когда разработка и тестирование начнут жить вместе" - эта мысль красной строкой проходит сквозь всю книгу Джеймса Уиттакера "Как тестируют в Гугл". Эта книга просто перевернула мой мир. Как будто кусочки пазла собрались наконец в одну картину. Теперь я знаю, к чему стремиться. В каком направлении развиваться, как специалист. И какую организацию процесса разработки ПО считать идеальной.

В этой статье я постараюсь в краткой форме систематизировать часть знаний, полученных после прочтения этой книги.

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


Тестирование в Гугл находится в отдельном горизонтальном направлении. Тестировщиков предоставляют командам разработки продуктов во временное пользование. 

Для планирования тестирования используется 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. При помощи нее большая часть ручной работы по регрессионному тестированию заменена ботами. Стоит отметить, что все созданные системы либо находятся в открытом доступе, либо планируются быть туда помещенными. Молодцы, они, гуглята :)

Ну и самое интересное в книге оставлено напоследок. Авторы размышляют о будущем отрасли и отдельных ролей в рамках отрасли и делают свои предположения. 
Так, роль разработчика в тестировании сойдет на нет, она сольется с ролью разработчика. В случае, когда тестирование будет рассматриваться как фича продукта, такая же, как UI и др компоненты. Предлагается отдать ответственность за фичи тестирования новым участникам продукта, особенно менее опытным, чтобы они изучили весь продукт сверху донизу, от пользовательского интерфейса до API. 
Инженеры по тестированию станут проектировщиками тестов. Поскольку тестирование скорее всего перейдет к внутренним и ранним пользователям или краудсорсерам. Тестирования в работе тест-дизайнеров останется очень мало. Роль инженера по тестированию будет смещаться в сторону узкой специализации.
Если говорить об инфраструктуре тестирования, то она переместится в облако.

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

5 комментариев: