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

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

Интервью с инженером по тестированию Google Docs Линдси Уэбстер

Линдси Уэбстер — инженер по тестированию проекта Google Docs в нью-йоркском офисе Google. В компании ее знают как инженера-практика, способного привести в порядок процедуру тестирования в любой команде разработчиков. Ее подход к работе и умение влиять на команду и качество продукта сделали ее символом инженеров по тестированию в Google.

Недавно авторы пообщались с Линдси, чтобы узнать о ее методах работы.

— Как ты начинаешь работу с новым проектом? Какие первые вопросы ты задаешь? Что ты делаешь в первую очередь?

Линдси:Когда я приступаю к новому проекту, прежде всего я смотрю на него глазами пользователя. Если возможно, я сама начинаю им пользоваться через свой аккаунт и свои данные. Я пытаюсь испытать те же чувства, которые появляются у пользователя при работе с продуктом. Взгляд на программу полностью меняется, когда вы видите в ней свои личные данные. Освоившись, я начинаю изучать продукт «от»и «до». Если есть проектная документация, то я изучаю ее, а если есть отдельные описания основных фич, я и за них возьмусь. Дайте мне документ, и я его прочитаю.

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

— Число багов на разработчика или на всю команду?

Линдси:На всех! Если честно, чтобы достигнуть максимальных результатов, команду надо знать как свои пять пальцев.

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

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

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

Спрашивая про ожидания от тестировании, я очень много узнаю о том, что команда разработки не тестирует.

— Нам даже думать тяжело о такой работе. Хорошо, что у нас есть такие тестировщики! Итак, ты расправились с документами и командой, но что-то же осталось на десерт? Само приложение?

Линдси:Точно! Как только я получаю необходимые данные, наступает пора заняться делом. Обычно я разбиваю приложение на функциональные куски. Нестрашно, если между ними будет небольшое перекрытие. Моя главная задача — создать не слишком подробную, но и не слишком общую картину, чтобы я могла перечислить все компоненты и фичи.

Когда я разделила приложение на функциональные части, я могу их приоритизировать по очередности тестирования. Какие части приложения я могу назвать самыми рискованными?

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

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

Как только у меня есть список тестов, я начинаю искать пробелы в покрытии, заново просматривая баги и приложение. Да, работа тестировщика часто циклична. И эта часть не исключение — я снова перебираю разные виды тестирования, от интеграционного тестирования до проверки нагрузки, и изучаю их покрытие.

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

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

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

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

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