Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 13 (всего у книги 26 страниц)

Рис. 3.25. Google Feedback с фильтрацией конфиденциальной информации

Жизненный путь бага
Джеймс Уиттакер

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

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

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

А теперь пора заняться составлением баг-репорта. Как родитель, который тянется за градусником, тестировщик расчехляет свои инструменты. Родитель хочет точно диагностировать болезнь. Мать хочет убедить доктора в серьезности болезни ее ребенка. Тестировщик тоже хочет повлиять на критичность, но что еще важнее – он хочет, чтобы баг легко было исправить. Снимки экрана, записи нажатий клавиш, данные трассировки стека, дампы DOM – все это пригодится для документирования бага. Чем больше информации будет у разработчика, тем легче будет найти причину и тем выше вероятность ее исправления.

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

Этот тест становится частью регрессионного пакета приложения. Его стремятся автоматизировать, чтобы проще было ловить регрессионные баги. Или, как минимум, создают ручной тест-кейс и заносят в систему управления тестами. Так формируется иммунитет системы к будущим заражениям – подобно тому, как ребенок получает иммунитет к тому виду бактерий, от которого он когда-то заболел.

Как мы нанимаем инженеров по тестированию

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

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

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

Мы опробовали несколько стилей собеседования для инженеров по тестированию.

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

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

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

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

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

Приложения становились все более сложными, пользовательские интерфейсы становились сложнее, чем google.com, поэтому армия тестировщиков в Google росла. Пользователей становилось больше, и наши продукты стали занимать важное место в их жизни. Поэтому роль тестировщиков стала более значительной в культуре Google.

Как отличить тестировщика от разработчика в тестировании
Джейсон Арбон

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

Вам больше подходит роль разработчика в тестировании, если вы:

– Можете взять спецификацию и запрограммировать надежное и эффективное решение с чистого листа.

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

– Вы думаете, что конечный пользователь – это тот, кто вызывает функцию API.

– Вас раздражает плохо написанная документация API, но вы иногда забываете, зачем этот API вообще нужен.

– Вы с увлечением болтаете с другими людьми об оптимизации кода или о выявлении ошибок совместного доступа потоков.

– Вы предпочитаете общаться с другими человеческими существами через мессенджер или в комментариях к коммитам.

– Вы предпочитаете командную строку графическому интерфейсу и редко прикасаетесь к мыши.

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

– Вы никогда не замечали и не меняли обои своего рабочего стола.

– Вы переживаете, когда видите предупреждения компилятора.

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

– Успех для вас – это построить прекрасный низкоуровневый фреймворк юнит-тестирования, который используют все и который запускается на тестовом сервере миллионы раз в день.

– Когда вас спрашивают, готов ли продукт к выпуску, вы можете просто ответить: «Все тесты прошли».

Вам больше подходит роль инженера по тестированию, если вы:

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

– Вы лучше почитаете Slashdot или News.com, чем будете весь день читать чужой код.

– Если вы читаете недописанную спецификацию, вы сами заполняете все пропуски в документе.

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

– Вам становится плохо при виде пользовательских интерфейсов некоторых веб-сайтов. Вы не понимаете, как с ними вообще кто-то работает.

– Визуализация данных вызывает у вас радостное возбуждение.

– Вы ловите себя на желании пообщаться с людьми из реального мира.

– Вы не понимаете, почему вам нужно ввести «i», чтобы набрать текст в одном известном текстовом редакторе. [45]45
  Речь идет о текстовом редакторе vim (http://ru.wikipedia.org/wiki/Vim), в котором нужно специально входить в режим ввода текста. – Примеч. перев.


[Закрыть]

– Успех для вас – помочь реализоваться идеям других инженеров, а потом испытать эти идеи в боевых условиях.

– Когда вас спрашивают, готов ли продукт к выпуску, вы можете сказать: «Я думаю, да».

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

Обе роли очень важны, чтобы создать великолепный продукт.

Собеседование с инженерами по тестированию

Ура, мы обнаружили необходимую комбинацию навыков и немедленно зовем кандидата на интервью. Нас часто спрашивают, как мы собеседуем инженеров по тестированию, причем это самый частый вопрос, который нам задают буквально везде. Полный список вопросов мы приводить не будем, но покажем несколько примеров, чтобы проиллюстрировать наш подход. Учтите, что после публикации эти вопросы уже неактуальны!

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

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

Рис. 3.26. Простой пользовательский интерфейс для тестового вопроса

Некоторые кандидаты бросаются с места в карьер и начинают строчить тест-кейсы. (Звучит тревожная музыка.) Скорее всего, они недостаточно подумали над задачей. Мы воспринимаем стремление к количеству, а не к качеству, как знак опасности. Мы пришли к этому с опытом. О кандидате можно многое узнать еще до того, как он справится с задачей, просто посмотрев на то, как он ее решает.

Лучший кандидат – тот, который начинает задавать уточняющие вопросы: прописные или строчные буквы? А только ли английские? А текст стирается после вычисления ответа? Как насчет повторного нажатия кнопок? И так далее.

Итак, когда все вопросы прояснились, кандидаты начинают писать тест-кейсы. Важно понять, есть ли в их безумии своя система. Пытаются ли они просто сломать программу или хотят еще проверить, что она работает? Они осознают, когда делают первое, а когда второе? Начинают ли они с очевидных и простых вещей, чтобы найти самые важные баги как можно быстрее? Могут ли они четко изложить свой тестовый план/данные? Случайный порядок строк на доске не свидетельствует о ясности мысли, а тест-планы таких кандидатов, скорее всего, будут небрежными, если они вообще позаботятся о них. Типичный список может быть примерно такой:

– «banana»: 3 (реально существующее слово)

– «A» и «a»: 1 (простой допустимый случай с положительным результатом).

– «»: 0 (простой допустимый случай с нулевым результатом).

– null: 0 (простой ошибочный случай).

– «AA» и «aa»: 2 (случай, в котором количество символов > 1, а строка состоит из одних «A»).

– «b»: 0 (простой непустой допустимый случай с негативным результатом).

– «aba»: 2 (искомый символ в начале и конце строки для выявления багов смещения на 1 в цикле).

– «bab»: 1 (искомый символ в середине строки).

– пробелы/табуляции/и т.д.: N (символы-пропуски чередуются с N символов «A»).

– длинная строка без «A»: 0

– длинная строка с «A»: N, где N равно количеству «A».

– XnX в строке: N, где N равно количеству «A» (символы форматирования).

– {java/C/HTML/JavaScript}: N, где N равно количеству «A» (символы исполняемого кода, бага или случайная интерпретация кода).

Если кандидат пропускает какие-то из перечисленных тестов, снова звучит тревожная музыка.

Лучшие кандидаты не ограничиваются конкретным выбором входных данных задачи и переходят на более глубокие уровни тестирования. Они могут:

– Исследовать оформление, цветовую палитру и контрастность: соответствуют ли они оформлению других взаимосвязанных приложений? Доступны ли они для пользователей с дефектами зрения и т.д.?

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

– Поинтересоваться возможностью запуска нескольких экземпляров этого приложения на одном сервере. Нет ли опасности пересечения данных разных пользователей?

– Спросить, сохраняются ли данные? В них могут быть адреса или другая личная информация.

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

– Спросить, достаточно ли быстро это работает? А как будет работать под нагрузкой?

– Уточнить, как пользователь будет попадать на эту страницу и легко ли ее найти?

– Ввести код HTML и JavaScript. Не сломает ли это отображение страницы?

– Спросить, должны учитываться символы «A» только верхнего или только нижнего регистра либо обоих?

– Попробовать копировать и вставлять строки.

А некоторые кандидаты идут еще дальше, их не удержать рамками поставленной задачи. Вот они – опытные и ценные инженерные кадры. Они могут:

– Понять, что если данные передаются серверу в HTTP GET-запросе с URL-кодированием, строка может быть обрезана в процессе передачи по интернету. Поэтому нет никакой гарантии, что поддерживается любая длина URL-адресов.

– Предложить параметризацию приложения. Почему мы считаем только «A»?

– Подумать о возможности подсчета «A» из других языков (например, со знаками ангстрема или умляута).

– Подумать о возможности интернационализации этого приложения.

– Подумать о написании скриптов или вручную составить выборку строк определенной длины (допустим, степеней двойки), чтобы найти предел длины строки и убедиться в том, что значения внутри пределов обрабатываются правильно.

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

– Задать вопросы: «Могут ли метод HTTP POST и параметры подвергнуться хакерской атаке? Нет ли здесь проблем с безопасностью?»

– Написать скрипт для генерации данных и проверки результатов, чтобы попробовать побольше интересных комбинаций свойств строки: длина, количество «A» и т.д.

Обратив внимание на длины строк, которые кандидат использует в своих тестах, можно понять, как он будет работать. Если он ограничивается понятием «длинная строка», а такое бывает часто, снова включается тревожная музыка. Продвинутые кандидаты обычно просят спецификацию строки, а затем прикидывают граничные тесты для нужных значений. Например, если максимальная длина строки 1000 символов, они попробуют 999, 1000 и 1001. Лучшие кандидаты возьмут еще и значение 2^32, и несколько промежуточных хитрых значений, например степени 2 и 10. Кандидаты должны понимать, какие значения важны для системы, а не просто брать случайные числа. Для этого им нужно хорошо разбираться в основных алгоритмах, языке, оборудовании и среде выполнения программ, потому что именно здесь водится большинство багов. Они попробуют варианты длины строки с учетом возможной реализации и подумают о возможности смещения счетчиков и указателей на единицу. Самые лучшие кандидаты понимают, что система может запоминать состояние и что в тестах нужно учесть значения, введенные раньше. Попробовать ввести одну и ту же строку несколько раз или проверить нулевую длину сразу после тысячи символов – важные сценарии, которые хорошо бы учесть.

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

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

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