Джеймс Уиттакер - Как тестируют в Google

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

— Какое место занимает пользователь в твоей работе как тестировщика?

Линдси:Очень важное! Ведь я с самого начала стараюсь стать пользователем тестируемого продукта. Я правда не понимаю, как можно тестировать продукт, если не можешь поставить себя на место пользователя и побыть им. Вот почему тестирование — это не просто проверка работоспособности, а еще и полезный источник информации о том, насколько просто им пользоваться и соответствует ли приложение стандартам отрасли.

— Как разработчики оценивают твою работу? Если они недооценивают тестирование, как ты себя ведешь?

Линдси:Разработчики часто недооценивают мой вклад, пока не поработают со мной пару месяцев. Закончив описанный мной этап работы, я встречаюсь с командой и знакомлю их со своим процессом тестирования. Только в личном общении можно донести до разработчиков, что я отношусь к их приложению очень серьезно. Я получаю хорошие отзывы о своей работе, а они убеждаются, что попали в надежные руки.

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

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

— Расскажи немного о своем тестировании Google Sites. Как ты подошла к проекту? Какие документы ты создавала и в каком формате? Как подала свои выводы и результаты разработчикам?

Линдси:Тестирование Sites стало настоящим испытанием. Продуктом пользовалось огромное количество людей, продукт был куплен, а не разработан в Google, и к тому же существовал в Google намного дольше остальных.

Я начала работу как пользователь, осваивала продукт самостоятельно, создавая свои сайты. Заодно я связалась с людьми, которые много им пользовались. Например, ассоциация домовладения дома, где я живу, несколько месяцев назад перевела сайт сообщества на Google Sites, и я поинтересовалась, как произошел этот переезд. Документация по этому проекту вовремя не обновлялась, поэтому мне пришлось разбить продукт на блоки и задокументировать все компоненты и подкомпоненты.

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

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

Я сделала общий сайт (конечно, на базе Google Sites!), где собрала всю документацию для тестирования: пользовательские истории, информацию о среде и команде тестирования, данные по выпускам и т.д. Чтобы быстро планировать тестирование для новой сборки, я использовала простую электронную таблицу со списком всех компонентов и субкомпонентов, упорядоченных по приоритету тестирования.

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

— А можешь рассказать о самом интересном баге, который ты находила, и как это произошло?

Линдси:Меня всегда забавляло тестирование дат в тех приложениях, в которых надо вводить их вручную. Я люблю использовать даты из далекого прошлого или будущего, и мне часто удается обнаружить странные или даже смешные ошибки вычислений. Я вспоминаю один баг, который каким-то странным образом подсчитывал возраст при вводе в поле даты рождения даты из будущего. Это было довольно забавно. Можете думать обо мне все что угодно, но мне кажется, что баги — это весело!

— Как ты оцениваешь результат своей работы?

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

— Как ты понимаешь, когда тестирование пора завершать?

Линдси:Трудно сказать. Когда тестируешь новые версии, то дата выпуска и есть финишная черта проекта. А если появляется новая версия браузера или устройства, на которых открывается наше приложение, даже если оно сейчас активно не разрабатывается, то это всегда серьезная причина продолжить тестирование. О’кей, если вы уверены, что если какие-то баги и остались, то они находятся в компонентах, фичах, браузерах, устройствах, которыми пользуются очень редко, а значит, не сильно помешают пользователям, то вы можете приостановить тестирование. Руководствуйтесь приоритетами фич и окружений, которые вы поддерживаете.

— А как исправляются баги?

Линдси:Важная часть моей работы — подталкивать разработчиков исправлять баги. Я постоянно пытаюсь оторвать разработчиков от работы над новыми фичами и отправить их исправлять баги. Чем больше жалоб на баг от пользователей мне удается собрать, тем легче мне убедить разработчика, что нужно уничтожить дефект, вместо того чтобы прикручивать новую функцию. У корпоративных продуктов в Google, таких как Sites, есть специальные службы поддержки клиентов. Я обязательно работаю с ними, чтобы быть в курсе, на что чаще всего жалуются клиенты.