— Как ты понимаешь, когда тестирование пора завершать?
Линдси: Трудно сказать. Когда тестируешь новые версии, то дата выпуска и есть финишная черта проекта. А если появляется новая версия браузера или устройства, на которых открывается наше приложение, даже если оно сейчас активно не разрабатывается, то это всегда серьезная причина продолжить тестирование. О’кей, если вы уверены, что если какие-то баги и остались, то они находятся в компонентах, фичах, браузерах, устройствах, которыми пользуются очень редко, а значит, не сильно помешают пользователям, то вы можете приостановить тестирование. Руководствуйтесь приоритетами фич и окружений, которые вы поддерживаете.
— А как исправляются баги?
Линдси: Важная часть моей работы — подталкивать разработчиков исправлять баги. Я постоянно пытаюсь оторвать разработчиков от работы над новыми фичами и отправить их исправлять баги. Чем больше жалоб на баг от пользователей мне удается собрать, тем легче мне убедить разработчика, что нужно уничтожить дефект, вместо того чтобы прикручивать новую функцию. У корпоративных продуктов в Google, таких как Sites, есть специальные службы поддержки клиентов. Я обязательно работаю с ними, чтобы быть в курсе, на что чаще всего жалуются клиенты.
— Если бы ты могла взмахнуть волшебной палочкой и изменить один аспект твоей работы, что бы это было?
Линдси: Если я скажу «все», то мое желание не исполнится? Хорошо, если бы могла, я бы создала простые, примитивные тест-кейсы или пользовательские сценарии, которые бы не надо было документировать, потому что они чудесным образом стали бы известны каждому тестировщику. Скажем, операции создание-чтение-обновление-удаление используются везде, поэтому каждый раз описывать их для каждой новой фичи утомительно. Я думаю, переход на высокоуровневые пользовательские истории вместо формализованных тест-кейсов частично решил проблему, но я бы все равно предпочла полностью избавиться от нее.
— Как твоя работа влияет на решение о выпуске продукта?
Линдси: Я решаю, может ли фича пройти в сборку для релиза, помня об интересах пользователя. К счастью, мои команды обычно соглашаются. Я не блокирую выпуск продукта, если для этого нет веских причин. Для меня важно сохранять доверие команды, чтобы люди знали: если я настаиваю, что нужно блокировать, значит, все совсем плохо.
— Что тебе больше всего нравится или не нравится в твоей работе?
Линдси: Мои навыки дают мне профессиональную гибкость, и мне это нравится. Я — технический специалист, но моя работа — думать о пользователе. Назовите проект, в котором не нужны такие люди! Я могу быть полезной в проекте любого типа. При запуске продукта или новой фичи команды часто нервничают, а мое присутствие и работа приносят им спокойствие и уверенность. Я чувствую, что приношу пользу и позитив.
— Чем тестирование в Google отличается от других компаний?
Линдси: Независимостью. Я свободна в выборе проектов, над которыми хочу работать как в основное время, так и в «двадцатипроцентное», — это такая концепция в Google, позволяющая нам проводить один день в неделю, или 20% общего времени, работая над любым проектом. Это расширяет мой кругозор и поддерживает мой энтузиазм, когда кажется, что работа превратилась в сплошной «День сурка».
— Как разработчики в тестировании относятся к твоей работе?
Линдси: Разработчики в тестировании часто не считают важной работу с репозиторием багов и тестирование каждой версии, пока сами не увидят, как это влияет на продукт. Даже если они думают, что автоматизация покрывает все тестовые сценарии (да, как же!), кто-то должен заниматься исследовательским тестированием для разработки новых тест-кейсов. А еще этот кто-то должен отслеживать все баги, найденные автотестами, сравнивать их с более старыми и менее серьезными багами и отзывами от пользователей. Так как я поднимаю эти вопросы, то разработчики в тестировании обычно понимают ценность изменений, которые я приношу в проект. Если и есть такие, кто не очень уважительно относится к моей работе, это те, с кем мы еще не поработали. После совместной работы отношение разработчиков всегда быстро меняется.
— Как организовано твое взаимодействие с разработчиками в тестировании?
Линдси: Я определяю стратегию тестирования для всех, включая разработчиков в тестировании. Если разработчики в тестировании не знают, с чего начать программирование тестов или инструментов, я показываю им документ с приоритетами, где написано, что нужно тестировать в первую очередь, и подкрепляю информацией о багах. Еще я могу дать им обратную связь, показать на реальных данных, насколько их решение действительно предотвращает баги. Так что мое взаимодействие в основном построено на организации и обратной связи, которую я привношу в работу разработчиков в тестировании.
Интервью с инженером по тестированию YouTube Эппл Чоу
Эппл Чоу — инженер по тестированию Google Offers. До этого проекта она руководила тестированием YouTube в офисе Google в Сан-Франциско. Эппл любит сложные задачи и всегда стремится применить к ним новейшие инструменты и методы тестирования.
Недавно мы побеседовали с Эппл и попросили ее рассказать о тестировании YouTube.
— Эппл, что привело тебя в Google? Такое имя наверняка наводило на мысли о работе в другой компании?
Эппл: Ха! Адрес [email protected] выглядит очень аппетитно! Но я выбрала Google из-за разнообразия продуктов и возможности поработать с исключительными специалистами. Мне нравится менять проекты и работать на разных флангах, поэтому я решила, что Google — подходящее для меня место. Я могу влиять на работу миллионов пользователей в самых разных областях. Каждый день ставит новые задачи, и мне никогда не бывает скучно. Конечно, бесплатный массаж — тоже плюс.
— Расскажи о процессе собеседования на роли тестировщика и разработчика в тестировании.
Эппл: Google ищет разносторонних людей, которые могут учиться, расти и справляться с любыми задачами. По-моему, этот подход работает при найме инженеров по тестированию, разработчиков в тестировании и разработчиков. Во многих компаниях собеседования проводят на конкретные роли, и люди, которые проводят собеседование, потом становятся вашими коллегами. В Google другой подход к найму сотрудников — собеседования проводят люди из разных команд, поэтому мы получаем много точек зрения. Я думаю, что так мы находим людей, способных вписаться в любую нашу команду. Это важно, ведь в Google можно легко перемещаться с проекта на проект, работать в разных направлениях и менять команды. Вопрос универсальности сотрудника очень важен.
— Ты работала во многих технологических компаниях. Что оказалось самым неожиданным в организации тестирования в Google?
Эппл: Здесь многое устроено иначе. Может, я не очень объективна, потому что люблю Google, но я бы сказала, что наши тестировщики и разработчики в тестировании более подкованы технически, чем специалисты других компаний. Везде, где я работала, у нас были отдельные команды для автоматизированного и ручного тестирования. Понятно, что разработчики в тестировании в Google сами пишут код, это их работа. Но найти здесь инженера по тестированию, который не умеет программировать, сложно. Такие навыки помогают нам быть более ценными на ранних стадиях, когда до сквозного тестирования еще далеко и надо заниматься юнит-тестированием. Я думаю, что наши технические навыки объясняют наши успехи.
Еще одно отличие Google в тестировании — огромный объем автоматизации. Большинство автотестов уже проходят к тому моменту, когда на проект приходят инженеры по тестированию. Благодаря этому тестировщики получают в работу код очень высокого качества.
Третье отличие — инструменты, которыми мы пользуемся, созданы внутри компании. Мы почти не работаем с коммерческими программами. В нашей культуре очень высоко ценится разработка собственных инструментов, и многие тратят свое «двадцатипроцентное» время на такие проекты. Наши изобретения помогают нам с легкостью преодолевать рутинные и утомительные части тестирования и фокусировать усилия людей на сложных задачах, где действительно нужно участие человека.
Есть еще один важный момент: культура «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования, и в этом мы можем легко положиться на разработчиков. Мы все в Google играем на стороне качества продукта, и любой инженер может протестировать любой код с любого компьютера. Поэтому вся работа идет быстро.
— Отличия понятны, а чем тестирование в Google схоже с тестированием в других компаниях?
