Хорошим примером такой работы служит Chrome OS. Мы с самого начала поняли, что сетевые подключения Wi-Fi и 3G — очень рискованная область, потому что она зависит от производителя устройства. Облачное устройство без связи с интернетом теряет свой смысл как продукт. Более того, все обновления безопасности и версий программных продуктов тоже происходят по Сети, и если возникают проблемы с передачей данных по 3G, наша работа обесценивается. Это не та вещь, которую можно оставить на откуп неспециалистам, пусть и с благими намерениями.
Когда мы только начинали работать с устройствами, своих специалистов с нужным тестовым оборудованием у нас еще не было. Впрочем, даже если бы оно было, правильно его использовать все равно никто не умел. Поэтому тестирование проводили внешние специалисты, которые вручную переключались между 20 современными роутерами Wi-Fi. За пару недель эти ребята сообщили нам о многочисленных проблемах при переключении роутеров и о снижении скорости передачи, если квартира пользователя находится в зоне действия нескольких роутеров63. Конечно, были и другие проблемы, обнаруженные тестированием, но не такие важные. Мы получили графики, которые свидетельствовали о серьезном падении скорости передачи (примерно как на рис. 3.52 и 3.53).
Мы не ожидали резких скачков интенсивности сигнала, но, как видите на рисунке, они были. Разработчики использовали эти данные для решения проблем во время внутреннего тестирования.
Рис. 3.52. Ожидаемый график зависимости скорости передачи от диапазона
Рис. 3.53. График зависимости скорости передачи от диапазона в ранних прототипах Chrome OS
Кстати, даже инженеры начального уровня в Google могут привлечь к работе внешних специалистов. Такая способность быстро решать задачи помогает нам быстро выпускать версии наших продуктов. Сейчас у нас есть все необходимое для того, чтобы выполнить работу самим, продолжая то, что начали внешние ребята. Но все же именно то, что мы смогли быстро подключить их экспертизу, стало основной причиной стабильно работающего сетевого соединения в боевых условиях к моменту запуска Chrome OS.
Работа с внешними тестировщиками может не только обнаружить неожиданные дефекты продукта, но и принести столь же неожиданную выгоду. Например, мы попросили их проверить наш список тестов пригодности оборудования. Поставщики оборудования по нашей просьбе отрабатывают эти тесты у себя перед тем, как отправить устройства в Google для дальнейшего тестирования. Такая схема работы избавляет нас от лишних пересылок оборудования туда-сюда. Итак, наши внешние специалисты заметили, что некоторые важные части в тестах были упущены. Ребята здорово помогли нам и отшлифовали наши тест-кейсы в соответствии с принятыми стандартами в этой области. В результате наши первые тесты, переданные крупным производителям компьютеров, стали полными и читались легче. Получается, что выгодно быть скромным и не стесняться обратиться за помощью в тестировании к внешним специалистам.
Интервью с инженером по тестированию Google Docs Линдси Уэбстер
Линдси Уэбстер — инженер по тестированию проекта Google Docs в нью-йоркском офисе Google. В компании ее знают как инженера-практика, способного привести в порядок процедуру тестирования в любой команде разработчиков. Ее подход к работе и умение влиять на команду и качество продукта сделали ее символом инженеров по тестированию в Google.
Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.
— Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?
Линдси: Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.
Как только все документы просмотрены, я начинаю изучать состояние проекта, а конкретно — его состояние качества. Я смотрю на количество багов, как они сгруппированы. Смотрю на типы открытых багов: какие из них открыты дольше всего, какие созданы недавно — и пытаюсь определить соотношение числа найденных и исправленных багов.
— Число багов на разработчика или на всю команду?
Линдси: На всех! Если честно, чтобы достигнуть максимальных результатов, команду надо знать как свои пять пальцев.
Еще я изучаю код в репозитории: ищу подходящие юнит-тесты для каждого класса. Проходят ли эти тесты? Насколько эти тесты содержательны и полны? Есть ли интеграционные или сквозные тесты? А проходят ли они до сих пор? Насколько успешно они проходили раньше? Это самые простые, базовые сценарии или они покрывают и частные случаи? Какие ветки в репозитории меняются чаще всего? Какие из них давно не менялись? Обычно разработчики хорошо документируют все, что они делают по тестированию.
Я исследую любые автоматизированные тесты. Есть ли они вообще? Проходят ли они до сих пор? Я изучаю код этих тестов, чтобы понять, как они проходят сквозь приложение, насколько они полны, хороши ли предположения и условия прохождения или их еще надо доработать. Бывает, что автоматизация покрывает лишь простые тесты. А иногда наборы тестов покрывают сложные пользовательские сценарии, и это хороший знак.
Как только я разобралась со всеми документами, наступает время для командной игры. Я расспрашиваю команду о том, как они общаются и чего ожидают от тестировщиков. Если они используют почтовые рассылки, то я подписываюсь на все, а если есть IRC-канал или другие способы коммуникации — я присоединяюсь к ним.
Спрашивая про ожидания от тестировании, я очень много узнаю о том, что команда разработки не тестирует.
— Нам даже думать тяжело о такой работе. Хорошо, что у нас есть такие тестировщики! Итак, ты расправились с документами и командой, но что-то же осталось на десерт? Само приложение?
Линдси: Точно! Как только я получаю необходимые данные, наступает пора заняться делом. Обычно я разбиваю приложение на функциональные куски. Нестрашно, если между ними будет небольшое перекрытие. Моя главная задача — создать не слишком подробную, но и не слишком общую картину, чтобы я могла перечислить все компоненты и фичи.
Когда я разделила приложение на функциональные части, я могу их приоритизировать по очередности тестирования. Какие части приложения я могу назвать самыми рискованными?
Когда с этой частью работы покончено, я возвращаюсь к репозиторию багов и точно так же делю их на смысловые части. Такая работа здорово упростит поиск существующих багов, а это приведет к сокращению дубликатов и подсветит повторные появления тех же самых ошибок.
Дальше я прохожусь по своему списку и создаю для каждого компонента пользовательские истории в порядке приоритетов. Для более сложных функций, требующих пошаговых инструкций, я пишу тест-кейсы и связываю их с пользовательскими историями нужного компонента. Я всегда стараюсь прикладывать снимки экранов или видеозаписи или даже ссылаюсь на самые коварные баги в этой области.
Как только у меня есть список тестов, я начинаю искать пробелы в покрытии, заново просматривая баги и приложение. Да, работа тестировщика часто циклична. И эта часть не исключение — я снова перебираю разные виды тестирования, от интеграционного тестирования до проверки нагрузки, и изучаю их покрытие.
После того как фундамент моей работы заложен, я просто стараюсь поддерживать его актуальным: обновляю все изменения в тестах, добавляю документацию для новых фич, обновляю снимки экранов и видео для компонентов, которые поменялись. Хорошо сверять тестовое покрытие с багами, которые пробрались через нашу оборону к пользователям. Это указывает на пробелы в тестовом покрытии.
— Какое место занимает пользователь в твоей работе как тестировщика?
Линдси: Очень важное! Ведь я с самого начала стараюсь стать пользователем тестируемого продукта. Я правда не понимаю, как можно тестировать продукт, если не можешь поставить себя на место пользователя и побыть им. Вот почему тестирование — это не просто проверка работоспособности, а еще и полезный источник информации о том, насколько просто им пользоваться и соответствует ли приложение стандартам отрасли.
— Как разработчики оценивают твою работу? Если они недооценивают тестирование, как ты себя ведешь?
Линдси: Разработчики часто недооценивают мой вклад, пока не поработают со мной пару месяцев. Закончив описанный мной этап работы, я встречаюсь с командой и знакомлю их со своим процессом тестирования. Только в личном общении можно донести до разработчиков, что я отношусь к их приложению очень серьезно. Я получаю хорошие отзывы о своей работе, а они убеждаются, что попали в надежные руки.
