Уиттакер . - Как тестируют в Google
Мы также заложили бомбу с часовым механизмом под одну фичу, предупреждая пользователей о том, что скоро она перестанет существовать. Команда тестирования предложила отказаться от варианта с обращением к серверу для проверки глобального флага, указывающего на отключение фичи, в пользу более надежного и стабильного решения, работающего только на стороне клиента. Так нам не нужно было выпускать новую версию с выключенной функцией, а простота решения сделала работу функции более надежной.
Мы написали краткую документацию и практическое руководство по выполнению автоматизации и запуску ручных тестов. Теперь для небольшого релиза нужно было всего несколько часов одного тестировщика-контрактника. Назначили исполнителя и перенаправили свои усилия по тестированию на Chrome и облачные технологии. Все последующие инкрементальные запуски проходили и проходят до сих пор как по маслу, а продукт продолжает активно использоваться.
При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов. Поэтому при организации поддержки ставьте на первое место контроль качества, а не выявление новых проблем. Как и везде, если ресурсов много, набор тестов не всегда минимален, поэтому нужно сфокусироваться на главном и смело отсечь все лишнее.
При исключении ручных тестов мы руководствуемся следующими правилами:
— Мы ищем тесты, которые всегда проходят, или тесты с низким приоритетом. Это наши первые кандидаты на выбывание!
— Мы понимаем, что именно выбрасываем. Мы не жалеем времени и делаем несколько репрезентативных выборок тестовых данных из исключаемых областей. Мы стараемся поговорить с авторами тестов, чтобы лучше понять их цели и не выплеснуть ребенка вместе с водой.
— Освободившееся время мы используем для автоматизации, анализа высокоприоритетных тестов или исследовательского тестирования.
— Мы отсекаем автоматизированные тесты, которые давали ложные положительные срабатывания в прошлом или просто ненадежны, — они могут поднимать ложную тревогу и приводить к лишней трате сил инженеров.
Несколько советов, которые лучше бы учесть перед переходом в режим сопровождения.
— Не бросайте серьезные проблемы, исправьте их, прежде чем покинуть проект.
— Даже самый маленький автоматизированный пакет сквозных тестов может обеспечить долгосрочную уверенность при почти нулевых затратах. Сделайте такой пакет, если у вас его еще нет.
— Оставьте документ-инструкцию, чтобы любой сотрудник компании мог выполнить ваш пакет тестов. Это спасет вас от отвлекающих звонков с разнообразными вопросами в самый неподходящий момент.
— Убедитесь в том, что у вас есть схема эскалации при возникновении проблемы. Оставьте и себе место в этой схеме.
— Всегда будьте готовы оказать помощь проектам, над которыми вы когда-то работали. Это полезно для продукта, команды и для пользователей.
Переход в режим сопровождения — обязательный жизненный этап для многих проектов, особенно в Google. Мы, как инженеры по тестированию, обязаны сделать все для того, чтобы этот переход был безболезненным для пользователей и эффективным для команды разработки. Нужно двигаться дальше, не привязываясь к своему коду или прежним идеям, — научитесь отпускать их во взрослую жизнь.
Эксперимент с Quality Bots
Как изменится тестирование, если мы забудем о наших методах и инструментах , а возьмем на вооружение инфраструктуру поисковых движков? Почему бы и нет, ведь там есть бесплатное процессорное время, свободное пространство и дорогая система вычисления, работающая над алгоритмами! Давайте поговорим о ботах, а конкретнее — о Quality Bots.
Завершив множество проектов по тестированию в Google и поговорив со многими командами, мы осознали, что блестящие умы наших инженеров часто растрачиваются на ручное построение и выполнение регрессионных тестов. Поддерживать автоматизированные тестовые сценарии и вручную проводить регрессионное тестирование — дорогое удовольствие. К тому же медленное. Добавляет масла в огонь то, что мы проверяем ожидаемое поведение, — а как же неожиданное?
Регрессионные тесты обычно проходят без ошибок в более чем 95% случаев. Скорее всего, так происходит потому, что практика разработки в Google заточена на качество. Но, что важно, эта рутинная работа притупляет способности инженеров, которых мы нанимали вообще-то за любознательность и изобретательность. Мы хотим освободить наших ребят для более сложного, исследовательского тестирования, для которого, собственно, мы их и брали в команду.
Google Search постоянно сканирует веб-пространство: запоминает, что видит, упорядочивает и ранжирует полученные данные в огромных индексах, руководствуясь статической и динамической релевантностью (качеством информации), а потом выдает информацию по запросу на странице результатов поиска. Если хорошенько подумать, базовая архитектура системы поиска может быть отличным примером автоматизированной системы оценки качества. Выглядит как идеальный движок для тестирования. Мы не стали два раза вставать и построили себе версию этой системы.
1. Обход. Боты работают в вебе48 прямо сейчас. Тысячи виртуальных машин, вооруженные скриптами WebDriver, открывают в основных браузерах популярные URL-адреса. Перепрыгивая от одного URL-адреса к другому, словно обезьянки с лианы на лиану, они анализируют структуру веб-страниц, на которые приземляются. Они строят карту, которая показывает, какие элементы HTML отображаются, где и как.
2. Индексирование. Боты передают сырые данные серверам индексирования, где информация упорядочивается по типу браузера и времени обхода. Формируется статистика о различиях между обходами, например количество обойденных страниц.
3. Ранжирование. Когда инженер хочет посмотреть результаты для конкретной страницы по разным обходам или результаты всех страниц для одного браузера, система ранжирования вычисляет оценку качества. Проще говоря, система оценивает сходство страниц в процентах: 100% означает, что страницы идентичны. Соответственно, чем меньше процент сходства, тем больше различий.
4. Результаты. На информационной панели можно посмотреть сводку результатов (рис. 3.27). Подробные результаты строятся в виде простой таблицы оценок для каждой страницы с указанием сходства в процентах (рис. 3.28 и 3.29). Для каждого результата инженер может копнуть глубже и получить информацию о визуальных различиях. Они показаны с помощью наложения результатов разных проходов с указанием XPath-путей49 элементов и их позиций (рис. 3.30). Инструмент показывает средние минимальные и максимальные исторические показатели этого URL-адреса и другую подобную информацию.
Рис. 3.27. Сводка информации для разных сборок Chrome
Рис. 3.28. Типичная таблица с подробной информацией от ботов
Рис. 3.29. Таблица информации от ботов, отсортированная для выявления наибольших различий
Рис. 3.30. Анализ визуальных различий для идентичных страниц
Первый же официальный запуск проекта нашел различие между двумя канареечными сборками Chrome. Боты провели проверку автоматически. Тестировщик оценил результаты и заметил, что этот URL-адрес потерял несколько процентов сходства. Тестировщик быстро сообщил о проблеме, ссылаясь на подробную картинку (рис. 3.31) с выделенной частью страницы с различиями. Раз боты могли протестировать все версии Chrome50, инженер мог быстро справляться с новыми регрессионными багами. Каждая сборка содержала всего несколько изменений, и заливку с проблемным кодом оперативно изолировали. Оказалось, что коммит51 в репозиторий WebKit (ошибка 56859: reduce float iteration in logicalLeft/RightOffsetForLine) вызвал регрессионный баг52, из-за которого средний элемент div на этой странице стал отображаться ниже границы страницы. Тестировшик завел баг 77261: Макет страницы ezinearticles.com неправильно отображается в Chrome 12.0.712.0.
Рис. 3.31. Первый баг, обнаруженный при первом запуске ботов
Как мы прогнозировали (и надеялись), данные от ботов оказались очень похожи на данные, получаемые от их одушевленных аналогов, и во многом даже лучше. Большинство веб-страниц оказывались идентичными в разных версиях браузеров, и даже если находилось различие, инженер быстро просматривал его и понимал, есть ли что-то серьезное.
Машины теперь могли автоматически подтвердить отсутствие регрессионных багов. Это маленький шаг для машины, но огромный для всего мира тестировщиков — им больше не нужно пробираться через тернии не самых интересных страниц. Тесты теперь можно прогонять за минуты, а не за несколько дней, как раньше. Их можно проводить ежедневно, а не еженедельно. У тестировщиков наконец освободились руки и время и стало возможным заняться багами посложнее.
