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

Чем отличается обработка багов в Google от такого же процесса в других компаниях?

— Мы открыты. База данных багов практически полностью открыта. Любой сотрудник Google может просмотреть любой баг любого проекта.

— Перед багом все равны. Сообщения о багах могут создавать все, включая технических директоров и старших вице-президентов. Сотрудники Google заносят в систему баги в продуктах, которые они используют, даже если они не являются частью команды этого продукта. Внутренние пользователи часто атакуют приложения просто для того, чтобы причинить им пользу.

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

Рис. 3.24. Основной процесс устранения багов при работе с Buganizer

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

Мечта создать единую панель отслеживания багов преследовала нас в Google, как идея о создании философского камня — алхимиков. Каждый год кто-нибудь пытается построить общую информационную панель для багов всех проектов. Это имело бы смысл, если бы речь шла только о данных из Buganizer. Но разные команды имеют свои представления о том, какие метрики важны для выпуска и сопровождения проектов, поэтому эти начинания с треском проваливались. Может быть, эта идея могла бы сработать в более однородной компании, но в Google такие благие намерения разбиваются о великое разнообразие проектов и практик.

Команда Google Feedback44 (http://www.google.com/tools/feedback/intl/en/index.html) запустила новый подход к регистрации багов в масштабе всего Google. С помощью Google Feedback конечные пользователи сообщают о багах в некоторых сервисах Google. Идея в том, что внешние пользователи не знают, какие баги уже были заведены или исправлены, но мы хотим быстро и легко получать обратную связь от них. Соответственно тестировщики и разработчики Google сделали так, чтобы сообщение о багах осуществлялось по простому принципу «навести и кликнуть». Инженеры команды очень постарались, чтобы пользователи при отправке сообщений о багах в Google могли скрыть те части страницы, где видна их конфиденциальная информация (пример на рис. 3.25).

Команда Google Feedback здорово потрудилась над тем, чтобы наши базы данных не затопило бушующим потоком багов. Количество дубликатов могло бы просто застопорить процесс приоритизации. Они внедрили кластерные алгоритмы, чтобы автоматически группировать дубликаты и определять самые частые проблемы. За неделю после выпуска новой версии могли поступить десятки тысяч сообщений, которые в итоге сводились всего к десятку основных проблем. Это сэкономило уйму времени, и Google смог услышать своих пользователей без индивидуальной обработки каждого сообщения. Команда сейчас тестирует работу этой системы на нескольких продуктах, но собирается расширить ее на все ресурсы Google.

Рис. 3.25. Google Feedback с фильтрацией конфиденциальной информации

Жизненный путь бага

Джеймс Уиттакер

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

Если тестировщик нашел баг, дальше его путь выглядит так: тестировщик выделяет минуту-другую, чтобы насладиться находкой. Серьезно, это важный этап, его нельзя пропускать. Это не только дает нам возможность порадоваться плодам наших трудов, но и помогает понять неочевидные нюансы и обстоятельства возникновения бага. Лежит ли он на пути, по которому ходят пользователи? Насколько такой путь вероятен? Есть ли другие пути, которые приведут к нему? Есть ли побочные эффекты, которые могут повлиять на данные или другие приложения? Это может повысить критичность. Какие последствия для конфиденциальности, безопасности, производительности или доступности? Тестировщик чувствует себя как родитель, который, услышав легкий кашель своего ребенка, с ходу представляет самые опасные болезни.

Как и родитель, который звонит другу или родственнику, чтобы обсудить тревожный кашель, тестировщик должен пригласить коллегу и продемонстрировать ему больного. Поинтересоваться его мнением, поделиться своим мнением о баге — его критичности, приоритете и побочных эффектах. Ясность часто рождается в подобных обсуждениях. Родитель избавляется от ненужного вызова неотложки, а тестировщик обнаруживает, что баг, который он относил к категории P0, на самом деле тривиален и панику можно отставить.

А теперь пора заняться составлением баг-репорта. Как родитель, который тянется за градусником, тестировщик расчехляет свои инструменты. Родитель хочет точно диагностировать болезнь. Мать хочет убедить доктора в серьезности болезни ее ребенка. Тестировщик тоже хочет повлиять на критичность, но что еще важнее — он хочет, чтобы баг легко было исправить. Снимки экрана, записи нажатий клавиш, данные трассировки стека, дампы DOM — все это пригодится для документирования бага. Чем больше информации будет у разработчика, тем легче будет найти причину и тем выше вероятность ее исправления.

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

Этот тест становится частью регрессионного пакета приложения. Его стремятся автоматизировать, чтобы проще было ловить регрессионные баги. Или, как минимум, создают ручной тест-кейс и заносят в систему управления тестами. Так формируется иммунитет системы к будущим заражениям — подобно тому, как ребенок получает иммунитет к тому виду бактерий, от которого он когда-то заболел.

Как мы нанимаем инженеров по тестированию

Мы в Google серьезно подходим к найму людей. У большинства наших инженеров высшее образование в области компьютерных технологий. В очень немногих учебных заведениях учат тестированию, поэтому до сих пор есть проблемы с наймом хороших тестировщиков. Сложно найти нужное сочетание навыков программирования и тестирования.

Найти специалиста на роль инженера по тестированию особенно тяжело, потому что лучшие из них не просто технари. Тестировщики в Google разрушают привычное представление об инженерах, на котором основан процесс найма разработчиков и разработчиков в тестировании. Откровенно говоря, мы не всегда все делали правильно и приносим извинения всем тестировщикам, которые пострадали от наших опытов совершенствования процесса собеседования. Инженеры по тестированию — редкие птицы. Они технически подкованы, заботятся об интересах пользователя, понимают продукт на всех уровнях от системной архитектуры до внешнего представления. Они неунывающие и общительные, и, что самое важное, изобретательные и умеют работать в условиях неопределенности. Только чудом можно объяснить, как Google (да и любая другая компания) умудряется поймать таких редких особей.

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

Мы опробовали несколько стилей собеседования для инженеров по тестированию.

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