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

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

Конечно, так было не всегда. Путь, который прошел Google к тому, где он сейчас, не менее интересен, чем технологии тестирования, которые мы используем. Давайте переведем стрелки часов на шесть лет назад – тогда ситуация в Google слабо отличалась от ситуации в других компаниях, с которыми мы работали: дисциплина тестирования была второстепенной.

Специалисты этой области получали меньше, хотя и работали больше. Тестирование в основном было ручным, а люди, которые могли автоматизировать процесс, быстро переходили в разработчики, где они могли «приносить больше пользы». Основателям команды, которая сейчас называется направлением продуктивности разработки, пришлось продираться сквозь заблуждения о тестировании и корпоративную культуру, ставившую героические авралы на работе выше повседневной инженерной рутины. Сегодня зарплата тестировщиков Google соразмерна зарплате разработчиков, их премии и темпы карьерного роста сравнялись. То, что культура тестирования пережила непростой рост компании (по всем параметрам – количеству, разнообразию продуктов и объемам продаж) и структурные реорганизации, должно придать уверенности компаниям, которые решат следовать примеру Google. Тестирование можно организовать правильно. Добиться вменяемого отношения к нему со стороны разработчиков и руководства – реально.

Сейчас все больше компаний делает ставку на веб, поэтому технологии тестирования и организационная структура, описанные в этой книге, могут получить широкое распространение. Если вы с нами – читайте, эта книга объяснит вам, как добраться до цели.

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

Остальные главы можно читать в любом порядке. Сначала мы расскажем о роли разработчика в тестировании (Software Engineer in Test, SET), потому что с нее началось современное тестирование в Google. Разработчик в тестировании – тестировщик с высокой технической квалификацией, поэтому в этой главе много технических подробностей. Но мы постарались подать их в более общем ключе, чтобы основные концепции понял даже неподготовленный читатель. В следующей главе мы познакомимся с инженером по тестированию (Test Engineer, TE). Глава получилась большой, потому что обязанностей у инженера по тестированию много. В Google эти специалисты решают уйму разных задач на протяжении всего цикла разработки продукта. Эта роль хорошо знакома многим традиционным тестировщикам. Скорее всего, этот раздел книги будет максимально востребован, потому что он адресован самой широкой аудитории.

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

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

Об иллюстрациях

Из-за сложности рассматриваемых тем и графической природы интернет-контента некоторые иллюстрации из третьей главы дают лишь общее представление о концепциях. Они не предназначены для подробного рассмотрения. Если вы захотите просмотреть эти рисунки на своем компьютере, загрузите их по адресу www.informit.com/title/9780321803023.

Пара слов о книге

Когда Патрик Коупленд предложил мне написать эту книгу, я колебался. В конечном итоге мои сомнения подтвердились. Я боялся, что многие будут спрашивать, нет ли в Google более подходящего человека для этой работы, – и они спрашивали. Или толпы людей захотят участвовать в работе над книгой – и это тоже сбылось. Но главная причина была в том, что все мои предыдущие книги я писал для новичков. И серия «How to Break…», и моя книга «Exploratory Testing»[3] содержат законченные, цельные истории, у которых есть начало и конец. С этой книгой все иначе. Читатели, конечно, могут «проглотить» ее за один присест, но она задумана как справочник по решению реальных задач в Google, как больших, так и малых, из которых складывается наша практика тестирования.

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

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

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

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

Приятного чтения, отличного тестирования – и желаем вам всегда находить (и исправлять) те баги, которые вы ищете!

Джеймс Уиттакер

Джейсон Арбон

Джефф Каролло

Киркленд, штат Вашингтон

Благодарности

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

Мы особо выделим следующих ребят, которые тратили свои силы и даже рисковали, чтобы привести тестирование к желаемому виду: Алексис О. Торрес, Джо Мухарски, Даниэль Дрю, Ричард Бустаманте, По Ху, Джим Рирдон, Теджас Шах, Джули Ральф, Эриэл Томас, Джо Михаил и Ибрагим Эль Фар.

Спасибо нашим редакторам, Крису Гузиковски и Крису Зану, стоически переносившим наш технический жаргон.

Спасибо собеседникам, поделившимся своими взглядами и опытом в интервью: Анкиту Мехта, Джоэлу Хиноски, Линдсей Уэбстер, Эппл Чоу, Марку Стрибеку, Нилу Норвицу, Трейси Бялик, Руссу Руферу, Теду Мао, Шелтону Мару, Ашишу Кумару, Суджай Сани, Брэду Грину, Саймону Стюарту и Хунг Дан.

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

Об авторах

Джеймс Уиттакер – технический директор Google[4], ответственный за тестирование Chrome, Maps и веб-приложений Google. Перешел в компанию из Microsoft, имеет профессорскую степень. Джеймс – один из самых известных в мире специалистов в области тестирования.

Джейсон Арбон – инженер по тестированию в Google, ответственный за Google Desktop, Chrome и Chrome OS. Он выступал в роли руководителя разработки многих тестовых инструментов с открытым кодом и внутренних экспериментов по персонализации. До прихода в Google работал в Microsoft.

Джефф Каролло — разработчик в тестировании, ответственный за тестирование Google Voice, Toolbar, Chrome и Chrome OS. Он консультировал десятки групп разработки Google, помогая им повышать качество кода. В 2010 году перешел в разработчики, сейчас руководит разработкой Google+ API. До прихода в Google тоже работал в Microsoft.

Глава 1. Первое знакомство с организацией тестирования в Google

Есть один вопрос, который я слышу чаще других. В какой бы стране я ни был, на какой бы конференции ни выступал, этот вопрос обязательно всплывает. Даже наши новобранцы задают его сразу же после прохождения вводного курса: «Так как же Google тестирует ПО?».

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

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

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

На заметку

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

В декабре 2010-го мы выпустили Chrome OS, и я передал руководство проектом одному из своих подчиненных, а сам погрузился в работу с другими продуктами. Тогда и началась эта книга. Мой первый пост в блоге «Как в Google тестируется ПО»[5] стал первой ласточкой, и с тех пор все закрутилось. Через полгода книга была готова, и я пожалел, что не начал писать ее раньше. За эти шесть месяцев я узнал о тестировании в Google больше, чем за два предыдущих года, а для новичков Google моя книга стала частью вводного курса.

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

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

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

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

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

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

На заметку

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

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

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

На заметку

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

С ростом Google стремительный темп работы замедлился совсем чуть-чуть. Нам потребовалось не больше года, чтобы создать операционную систему, клиентские приложения (типа Chrome) появляются ежемесячно, а уж веб-приложения меняются ежедневно. Хотя мы уже давно перестали быть стартапом, мы сохранили свойственные тому времени темпы. В таких условиях проще описать, каким тестирование не должно быть: догматичным, трудоемким, сложно выполнимым и занимающим много времени, – чем пытаться рассказать, каким оно должно быть. Хотя мы пытаемся нашей книгой сделать именно это. Одно можно сказать точно: тестирование не должно ставить палки в колеса инновациям и разработке. Второго шанса у него не будет.

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

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

Подход Google на первый взгляд парадоксален: у нас во всей компании меньше выделенных тестировщиков, чем у многих наших конкурентов в одной команде разработки. Мы не делаем ставку на миллионную армию рядовых тестировщиков. Мы – небольшой отряд элитного спецназа, успех которого зависит от превосходной тактики и современного вооружения. Как и в случае со спецназом, наш секретный ингредиент – ограниченность ресурсов. Мы следуем завету Ларри Пейджа, который сказал, что «дефицит приносит ясность», и это заставляет нас правильно расставлять приоритеты. Для всего, от описания функциональности до техник тестирования, у нас есть высокоэффективные приемы достижения поставленной цели – качества продукта. Дефицит заставляет ценить ресурсы тестирования и относиться к ним с уважением. Это помогает людям оставаться вовлеченными в развитие нашей отрасли. Когда меня спрашивают, в чем секрет нашего успеха, я всегда даю совет: «Не нанимайте слишком много тестировщиков».

На заметку

Когда меня спрашивают, в чем секрет нашего успеха, я всегда даю совет: «Не нанимайте слишком много тестировщиков».

Как Google справляется с таким маленьким штатом тестировщиков? Если бы мне нужно было ответить просто, я бы сказал, что в Google вся ответственность за качество лежит на плечах тех, кто пишет код. Качество никогда не бывает проблемой «какого-то тестировщика». Каждый, кто пишет код в Google, – уже немного тестировщик, а качество – это проблема всего коллектива (рис. 1.1). Говорить о соотношении численности «разработчики/тестировщики» в Google – то же самое, что рассуждать о чистоте воздуха на поверхности Солнца. Эту тему бессмысленно поднимать. Каждый инженер является и тестировщиком. Если в его должности есть слово «тестирование», то он помогает другим специалистам проводить качественное тестирование.

Рис. 1.1. Программисты Google предпочитают качество широте функциональности

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

Качество ? Тестирование

Фраза «тестирование не определяет качество» уже настолько избита, что просто обязана быть правдой. В любой области разработки, от автомобилей до софта, не получится отточить продукт до совершенства, если он изначально неправильно сконструирован. Спросите любого автопроизводителя, который хоть раз отзывал партию своих машин, чего стоят запоздалые попытки прикрутить качество на готовое изделие. Делайте все правильно с самого начала, не создавайте себе лишних трудностей.

Тем не менее это только звучит просто.

С одной стороны, качество и не создается тестированием, с другой – без тестирования сделать качественный продукт невозможно. Как вы узнаете, насколько качественный ваш продукт, не проводя тестирование?

Эта головоломка решается легко: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку. Напишите немного кода и протестируйте его. Затем напишите еще чуть-чуть и снова протестируйте. Тестирование не отдельная практика, это часть самого процесса разработки. Одним только тестированием качества не добиться. Рецепт получения высокого качества: смешивайте разработку и тестирование в блендере, пока они не станут единой субстанцией.

На заметку

Одним только тестированием качества не добиться. Рецепт получения высокого качества: смешивайте разработку и тестирование в блендере, пока они не станут единой субстанцией.

Вот чего мы добивались: мы хотели объединить дисциплины разработки и тестирования, чтобы одной нельзя было заниматься без другой. Немножко программируем, потом тестируем. Еще немного пишем код и снова тестируем. Здесь важно, кто тестирует. Тестировщиков в классическом понимании у нас мало. Значит, кто должен тестировать? Разработчик. Кто лучше всего протестирует свой код? Тот, кто его написал. Кто больше всех заинтересован в коде без багов? Правильно. Вот почему Google обходится таким небольшим числом тестировщиков – за качество отвечают разработчики. Если продукт сломается после выпуска, то шишки полетят в разработчика, создавшего проблему, а не в тестировщика, который ее не нашел.

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

Наш подход к созданию продуктов подразумевает слияние разработки и тестирования. Это подтверждают комментарии к коду типа «где твои тесты, чувак?», развешенные в туалетах плакаты с правилами тестирования[7] и многое другое. Тестирование должно стать неотделимым от разработки. Качество родится только тогда, когда разработка и тестирование начнут жить вместе.

На заметку

Тестирование должно стать неотделимым от разработки. Качество родится только тогда, когда разработка и тестирование начнут жить вместе.

Роли

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

Роль разработчика (Software Engineer, SWE) всем знакома и привычна. Он пишет код функциональности приложений, который поставляется пользователям. Он создает проектную документацию, определяет структуры данных и общую архитектуру, а большую часть времени пишет код и проводит код-ревью[8]. Разработчик пишет много тестового кода, например во время написания тестов для TDD и юнит-тестирования, и, как будет показано дальше в этой главе, участвует в создании малых, средних и больших тестов. Разработчик отвечает за качество всего кода, к которому он прикасается: пишет, исправляет или вносит изменения. Да, все верно: если разработчик должен изменить функцию и его изменение нарушает существующий тест или требует написания нового, он должен написать этот тест. Практически 100 % рабочего времени разработчик пишет программный код.

Роль разработчика в тестировании (Software Engineer in Test, SET) тоже связана с разработкой, но фокусируется на тестируемости кода и создании инфраструктуры тестирования. Разработчик в тестировании анализирует архитектуру, уделяет особое внимание качеству кода и рискам проекта. Он выполняет рефакторинг, чтобы сделать код тестируемым, пишет фреймворки юнит-тестирования и средства автоматизации. Разработчик в тестировании работает с тем же кодом, что и разработчик, но больше заинтересован в улучшении качества и тестового покрытия, чем в добавлении новых фич или повышении производительности. Разработчик в тестировании тоже проводит почти 100 % своего времени за написанием кода, но делает это ради повышения качества, а не для реализации фич для пользователей.

На заметку

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

Роль инженера по тестированию (Test Engineer, TE) связана с ролью разработчика в тестировании, но здесь на первом месте находятся пользователи и только на втором – разработчики. Некоторые инженеры по тестированию в Google пишут много кода для автотестов и управления сценариями использования и даже для имитации действий пользователя. Кроме того, именно они организуют работу по тестированию, которую выполняют другие инженеры, управляют выполнением тестов и интерпретируют их результаты тестов. Особенно важна их работа на поздних стадиях проекта, когда напряжение с приближением выпуска растет. Инженеры по тестированию – это эксперты продукта, консультанты по качеству и специалисты по анализу рисков. Одни пишут много кода, другие – мало[9].

На заметку

Инженеры по тестированию фокусируются на тестировании с точки зрения пользователя. Они занимаются общей организацией контроля качества, управляют выполнением тестов, интерпретируют их результаты и строят сквозную автоматизацию тестирования.

Итак, с точки зрения качества разработчики отвечают за фичи приложения и их качество отдельно от всего остального. Они ответственны за то, чтобы архитектура была устойчивой к ошибкам, приложение восстанавливалось после сбоев, отвечают за TDD, юнит-тесты и вместе с разработчиками в тестировании пишут код для тестирования фич.

Разработчики в тестировании отвечают за фичи тестирования. Они настраивают среду для изолированного выполнения кода с помощью имитации реального рабочего окружения. Для этого они создают такие компоненты, как заглушки (stubs), подставные объекты (mocks) и имитации (fakes), – мы рассмотрим их позже. Настроить очередь для управления отправкой кода в репозиторий – тоже их задача. Другими словами, разработчики в тестировании пишут код, который помогает разработчикам тестировать написанные ими фичи. Большую часть тестирования выполнит сам разработчик. Разработчики в тестировании в основном следят за тем, чтобы функциональность можно было легко протестировать, а разработчики не ленились писать тест-кейсы.

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