Отлично легко читается. Полезно. Ну и просто интересно как устроено тестирование в такой компании как Google.
Что-то взял для себя и пробую внедрить на своей работе.
Конспект.
Создать процесс, в котором сложно допустить ошибку, — вот настоящая цель тестирования. Мы не можем полностью избавиться от ошибок, но можем построить работу так, что сделать сразу правильно будет легче, чем ошибиться.
Одно можно сказать точно: тестирование не должно ставить палки в колеса инновациям и разработке.
Мы следуем завету Ларри Пейджа, который сказал, что «дефицит приносит ясность», и это заставляет нас правильно расставлять приоритеты.
Тестирование должно стать неотделимым от разработки. Качество родится только тогда, когда разработка и тестирование начнут жить вместе.
Рутинная работа вокруг фичи входит в обязанности разработчика, ее нельзя переложить на какого-нибудь тестировщика-несчастливчика.
телефоны основной команды разработки почти постоянно работают на ежедневной сборке. Идея в том, что разработчики будут писать меньше кода с багами, если от этого зависит их возможность позвонить домой.
Малые тесты проверяют один программный блок в полностью имитированной среде. Средние тесты проверяют взаимодействие модулей в имитированной или реальной среде. Большие тесты проверяют любое количество модулей в реальной среде с настоящими, не имитированными ресурсами.
Выбирая между автоматизированным и ручным тестированием, мы отдаем предпочтение первому. Если это можно автоматизировать и проблема не требует человеческого внимания и интуиции, то это нужно автоматизировать.
Вся платформа Google построена на простоте и единообразии: одинаковые сборки Linux для компьютеров инженеров и машин с боевой средой, общие базовые библиотеки под централизованным управлением, общая инфраструктура хранения исходного кода, сборки и тестирования, один компилятор для каждого из языков программирования, общая спецификация сборки для всех языков. И самое важное, культура, которая уважает и поощряет поддержку этих общих ресурсов.
малые тесты становятся частью регрессионного пакета. Они должны быть всегда актуальны. В противном случае в них инициируются баги, отладка которых ничем не отличается от отладки багов основного кода. Тесты — часть функциональности, а значит, баги в тестах относятся к функциональным багам и исправляются.
Браться за качество еще до того, как концепция продукта дозрела и полностью сформирована, — это типичный пример неправильной расстановки приоритетов.
Команды разработки обращаются к тестировщикам за помощью, убеждая их в том, что проект по-настоящему интересен и перспективен.
Когда вы предлагаете команде попробовать что-то новое или усовершенствовать старое, дело пойдет быстрее, если вы выделите им человека, к которому можно обращаться за помощью.
команды могли быстро увидеть и показать другим свой прогресс. Не пытайтесь создать идеальную систему с идеальными показателями. Идеала для всех не существует. Очень важно принять приемлемое решение и двигаться вперед, не зависая на попытках достижения несбыточного идеала.
Хорошему кандидату на роль разработчика в тестировании не нужно напоминать, что написанный им код нужно тестировать. Он должен считать тестирование частью решения.
[Кандидат] Пишет четкий и легко читаемый код. Если кандидат использует побитовые операции или пишет несколько команд в одной строке — это плохой признак, даже если код работает.
Запутанный или нелогичный тестовый код — это, наверное, самое худшее в мире.
пользовался процессом DDD (Defect-Driven Development — разработка через дефекты). Я объявлял WebDriver бездефектным, а когда пользователь находил баг, я его исправлял и снова объявлял продукт бездефектным. Так я исправлял только по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.
совсем не обязательно тестировщики выполняют всю работу сами, их задача в том, чтобы работа была выполнена. Для этого они могут привлекать других людей там, где это нужно. Так или иначе, тестировщикам платят за то, чтобы они защищали пользователей и бизнес от плохого проектирования, запутанного интерфейса, багов, проблем с безопасностью, конфиденциальностью и т.д.
если тест-план не описывает, какие тесты мы должны написать, то он не соответствует главной задаче, ради которой мы его писали, — помочь в тестировании. Планирование тестирования должно привести нас в точку, где мы точно знаем, какие тесты нужно написать.
Возможности лежат на пересечении атрибутов и компонентов. То есть компоненты выполняют какую-то функцию для того, чтобы соответствовать атрибуту продукта, а результатом станет предоставление пользователю возможности.
Работа по снижению рисков может быть максимально эффективной и безо всяких трудоемких математических расчетов. Такая работа называется анализом рисков.
мы сводим все риски к двум факторам: частота сбоев и степень воздействия. Для каждой возможности в разрабатываемом продукте тестировщики присваивают этим двум факторам простые значения. Именно простые, а не идеально точные. Нам ведь нужно просто определить, какие возможности следует тестировать и в каком порядке.
Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант.
Иногда сбои приводят к разным последствиям у пользователя и компании. Допустим, перестал работать рекламный баннер. Проблема ли это для пользователя? Нет, он даже может не заметить. Проблема ли для Google? Да, конечно. Поэтому, анализируя риски, указывайте, кто пострадает.
Вместо того чтобы вдаваться в объяснения процесса и упрашивать участников нам помочь, мы просто делаем все сами и показываем им уже готовую тепловую карту. Как только они видят наше мнение, они мгновенно выплескивают свое.
Когда мы определяем риски самостоятельно, мы несомненно приходим к варианту, с которым другие участники проекта не будут согласны. Так и есть, подготавливая для них наш вариант анализа рисков, мы даем им почву для споров. В этом идея. Мы не спрашиваем их о каких-то абстрактных понятиях, мы даем им конкретные выводы, которые можно оспорить. Люди не всегда могут сказать, каким должен быть правильный ответ, но легко скажут, каким он быть не должен. Такой хитрый подход приносит нам много правдивых данных для вычисления рисков.
Создавая пользовательскую историю, мы смотрим на продукт только через пользовательский интерфейс, мы не включаем в описание технические подробности. Тогда тестировщик будет каждый раз проходить этот путь по-разному, как и разные пользователи по-разному решают одну и ту же задачу в нашем приложении — вот в чем главная идея!
Многие команды просто перестают добавлять новые фичи, когда скорость появления багов начинает превышать пропускную способность команды по их исправлению. Мы рекомендуем всем перенять эту практику, а не фокусироваться только на фичах и поставленных датах завершения. Чтобы держать число багов под контролем, сосредоточьтесь на маленьких фрагментах тестируемого кода, тестируйте инкрементально и отдавайте продукт внутренним пользователям как можно раньше.
Чтобы оценивать своих сотрудников, менеджеры в Google опрашивают всех участников команд. Результаты сравнивают между командами, чтобы выровнять их. Всех сотрудников Google оценивают раз в квартал. Мы делаем упор на то, что человек сделал за последнее время и как он повлиял на качество продукта, что он сделал для команды и для пользователей.
Наша система аттестации не позволяет сотруднику выезжать на прошлых успехах, важно постоянное развитие.
Управлять в Google — значит направлять и опекать своих людей, а не командовать ими.
При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества.
Мой совет инженерам по тестированию: если вы во что-то верите — делайте это! Мой совет менеджерам: не перекрывайте инженерам кислород, разрешите им экспериментировать, и они сотворят настоящие чудеса для вашего бизнеса и пользователей.
Работа с внешними тестировщиками может не только обнаружить неожиданные дефекты продукта, но и принести столь же неожиданную выгоду.
Функциональность приложения, которую трудно автоматизировать, создает нам столько же проблем с тестированием, сколько и любой другой компании.
наш первый совет — знайте свой продукт. Тест-менеджер должен быть готов ответить на любые вопросы по использованию своего продукта.
Второй совет — знайте ваших людей. Конечно, тест-менеджер — эксперт своего продукта и отлично понимает работу, которую нужно выполнять, но все-таки ее непосредственно выполняют инженеры по тестированию и разработчики в тестировании. Чтобы работа выполнялась быстро и эффективно, невероятно важно хорошо знать своих людей и их навыки.
Когда ресурсов не хватает, приходится оптимизировать весь процесс. Вы быстро находите свои ошибки и учитесь не повторять их.
Если кто-то не желает писать малые тесты и обеспечивать покрытие на модульном уровне, не стоит присоединяться к ним и мешать людям копать себе могилу.
Главное правило найма — никаких компромиссов. Нанять неподходящего человека всегда хуже, чем подождать идеального кандидата. Нанимайте только лучших, и точка.
— Пишите тесты на том же языке, на котором написано приложение.
— Человек, написавший функцию, должен быть ответственным за выполнение тестов для нее. Проигнорированные тесты выйдут вам боком.
— Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
— Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.
— Есть ловушки, в которые попадают инженерные команды?
Анкит: Да. Они думают, будто знают, чего хотят пользователи, и могут серьезно изменять продукт или новые фичи, не проводя экспериментов. Зачем вам хорошая тестовая инфраструктура для фичи, которую выкинут за ненадобностью? Дайте нескольким пользователям новую версию, получите обратную связь, а уж потом вкладывайтесь в грандиозную автоматизацию тестов.
Пока вы будете долго строить идеальное решение, рынок оставит вас позади. Работайте короткими итерациями, двигайтесь небольшими шагами, но двигайтесь!
автотесты должны быстро создаваться, быстро выполняться и решать узкую задачу. Если цель автоматизированного теста непонятна сразу, значит он слишком сложен.
Если на получение обратной связи уходит больше пары минут, добавьте еще машин. Время процессора стоит гораздо дешевле рабочего времени инженера. Запустить, отладить или развернуть код должно быть так же просто, как ввести команду.
Моя работа приносила максимальную пользу, когда я помогал, а не руководил, когда я делился информацией и создавал комфортные условия для моих сотрудников, чтобы они занимались любимым делом. Если мне приходилось приказывать, я чувствовал, что не развиваю ребят, не помогаю им учиться принимать решения. Надо стать не названным, а признанным лидером среди чрезвычайно умных и увлеченных инженеров.
Если фокус не на продукте — продукт всегда страдает. В конце концов, цель всей разработки — создание продукта, а не программирование, тестирование или документирование.
уже пора работать с кодом тестов так же, как и с кодом продукта: его должны писать разработчики, а управлять им должны менеджеры продукта.
BITE (Browser Integrated Testing Environment) — расширение Chrome с открытым кодом (http://code.google.com/chrome/extensions/index.html), которое помогает упростить ручное веб-тестирование (рис. В.1). Чтобы расширение заработало, нужно связать его с сервером, на который он будет отправлять информацию о багах и тестах вашей системы. Тогда через BITE можно будет регистрировать баги в контексте веб-сайта, используя подходящие шаблоны.
мы используем редактор Ace (http://ace.ajax.org/), чтобы изменять код JavaScript в реальном времени.
мы открываем исходный код Test Analytics (http://code.google.com/p/test-analytics/) — инструмент, созданный в Google для упрощения ACC-анализа.