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

Я думаю, что люди склонны что-то делать только потому, что видели, как это делают другие, или тестировать какую-то фичу потому, что точно знают — они с ней справятся. Если не спрашивать их «почему», они так и будут действовать по инерции, не объясняя себе свои действия.

— Какие же ответы на вопрос «почему» для тебя приемлемы?

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

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

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

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

— Судя по всему, тебе удалось исправить ситуацию, давай поговорим об этом. Расскажи, что ты сделал для того, чтобы рабочая среда стала комфортной?

Анкит: Когда я присоединился к проекту, команда тестирования была сосредоточена на тестах WebDriver, которые выполнялись для каждой сборки. Они проводили тесты, следили, как состояние меняется с зеленого (тесты проходят) на красный (тесты не проходят), и прикладывали титанические усилия к исправлению тестов, чтобы они не показывали ложные срабатывания. Команда разработки не сомневалась в том, что вся работа построена правильно, потому что тесты действительно обнаруживали важные проблемы, а значит, были оправданны. Однако иногда изменения затрагивали большие объемы кода, и оперативно исправить тесты не получалось. Чтобы достичь результатов, приходилось выполнять слишком большую работу. Весь процесс был ненадежным и недостаточно гибким для такого подвижного и сложного сервиса, как Gmail.

Так как я был новичком в проекте, мой взгляд не был замылен. Мне казалось, что самой серьезной проблемой Gmail были задержки. Серьезно, ведь для пользователя главный атрибут Gmail — скорость. Я решил, что если мы справимся с этой проблемой, мы сможем заслужить уважение разработчиков и они будут воспринимать нас как равных.

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

Я вместе с одним разработчиком в тестировании искал способ специально замедлить работу Gmail. Мы хотели лучше контролировать взаимодействие между клиентской частью и дата-центром, чтобы найти регрессии, влияющие на производительность. Собрав несколько старых компьютеров и лишив их всех ускоряющих компонентов, мы получили целую комнату системных блоков с 512 мегабайтами памяти, 40-гигабайтными дисками и медленными процессорами. Работа Gmail стала медленной, и мы смогли отличить сигнал от шума. Мы запустили долгосрочные тесты, которые создавали дополнительную нагрузку системе.

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