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

Не знаю, сколько раз я уже отвечал на этот вопрос и как много разных вариантов ответа дал. Мои ответы постоянно меняются — чем дольше я работаю в Google, тем больше узнаю всевозможных тонкостей нашего подхода к тестированию. Меня давно посещали мысли, что стоит зафиксировать свои знания на бумаге. Когда Альберто (который часто грозит переработать все книжки по тестированию в подгузники для взрослых, чтобы они принесли хоть какую-то пользу) предложил мне написать книгу, я понял, что никуда от этого не денусь.

И все-таки я хотел подождать. Во-первых, я не считал себя самым подходящим автором. Было много людей, которые работали в Google намного дольше меня, и я хотел дать им возможность первыми написать о своем опыте. Во-вторых, я был директором по тестированию Chrome и Chrome OS (кстати, сейчас эту должность занимает один из моих бывших подчиненных), поэтому видел организацию тестирования в Google только с одной стороны. Мне нужно было узнать еще много всего о тестировании в Google.

В Google тестирование ПО — часть централизованной системы, которую мы называем направлением продуктивности разработки. Она охватывает инструменты для разработки, тестирования (от юнит-уровня до исследовательского) и организации процессов выпуска программных продуктов. Мы создаем и поддерживаем множество общих инструментов и тестовую инфраструктуру для веб-проектов поиска, рекламной платформы, мобильных приложений, видеосервисов. Короче, для всего, что Google делает в интернете. В Google решены проблемы производительности и масштабирования, что позволяет нам, несмотря на огромные размеры компании, выпускать программы со скоростью стартапа. Как верно заметил Патрик Коупленд в предисловии к книге, этой магией мы во многом обязаны именно команде тестирования.

В Google тестирование ПО — часть централизованной системы, которую мы называем направлением продуктивности разработки.

В декабре 2010-го мы выпустили Chrome OS, и я передал руководство проектом одному из своих подчиненных, а сам погрузился в работу с другими продуктами. Тогда и началась эта книга. Мой первый пост в блоге «Как в Google тестируется ПО» [5] http://googletesting.blogspot.com/2011/01/how-google-tests-software.html стал первой ласточкой, и с тех пор все закрутилось. Через полгода книга была готова, и я пожалел, что не начал писать ее раньше. За эти шесть месяцев я узнал о тестировании в Google больше, чем за два предыдущих года, а для новичков Google моя книга стала частью вводного курса.

Эта не единственная книга о том, как большие компании тестируют ПО. Я работал в Microsoft, когда Алан Пейдж, Би-Джей Роллисон и Кен Джонстон написали книгу «How We Test Software at Microsoft», и сам применял все методы, описанные в книге. Компания Microsoft тогда была лидером в тестировании. Она подняла тестирование на один уровень с разработкой. Тестировщики Microsoft были самыми востребованными спикерами конференций. Первый директор по тестированию, Роджер Шерман, привлекал в Редмонд талантливых ребят со способностями к тестированию со всего мира. Это был золотой век тестирования.

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

Я не успел поработать над этой книгой, так как пришел в Microsoft поздно, но мне выпал второй шанс. Я попал в Google в тот самый момент, когда тестирование здесь было на подъеме. Команда направления продуктивности разработки стремительно выросла с пары сотен до 1200 человек. Проблемы роста, о которых Патрик говорит в своем предисловии, мы уже преодолели, и наше подразделение было на пике своего развития. Блог тестирования Google ежемесячно собирал сотни тысяч просмотров, а конференция GTAC [6] GTAC — Конференция Google по автоматизации тестирования (Google Test Automation Conference, www.GTAc.biz). стала ведущей в индустрии тестирования ПО. Вскоре после моего прихода Патрика повысили, и теперь ему подчинялось около дюжины директоров и технических менеджеров. Если у тестирования ПО и была вторая волна развития, то центром этой стихии был Google.

Это значит, что история тестирования в Google тоже заслуживала своей большой книги. Но вот незадача — я не пишу больших книг. Да и Google славится своим простым и лаконичным подходом к разработке. Надеюсь, что моя книга получилась такой же.

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

Есть еще кое-что, и я должен это сказать. Скорее всего, организацию тестирования «как в Google» будут перенимать многие компании по мере того, как все больше программных продуктов переходит с десктопов в веб. Если вы читали книгу от Microsoft, то не думайте, что найдете здесь много общего с ней. У обеих книг по три автора, в каждой книге описана организация тестирования в крупной компании — разработчике ПО. На этом общее заканчивается. Трудно найти два подхода к тестированию, которые различались бы сильнее.

Скорее всего, организацию тестирования «как в Google» будут перенимать многие компании по мере того, как все больше программных продуктов переходит с десктопов в веб.

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

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

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