Тесты в Apple: как добиваются качества в известнейшей в мире компании?

Сергей Бронников, консультант по тестированию программного обеспечения, рассказал о том, как в компании Apple тестируют продукцию, чтобы добиться максимального качества устройств.

В Apple, в отличие от многих других компаний, всё, что касается рабочего процесса, — запретная тема, табу для обсуждения. Крупные компании не скрывают своей внутренней кухни, и часто можно найти материалы о разработке и тестировании ПО в тех же Google или Microsoft. Про тестирование в Apple нет не только книг, но также нет ни докладов на конференциях, ни каких бы то ни было интервью от членов команды Quality Assurance в Apple Inc. На вопросы журналистов о процессах Quality Assurance представители Apple отвечать отказываются.

Сергей Бронников рассказывает, что, руководствуясь профессиональным любопытством, он попробовал собрать всю информацию, которая касается тестирования продуктов Apple Inc.

"Сразу оговорюсь, что информации из этой статьи нельзя верить безоговорочно (как, впрочем, и любому тексту в интернете). Всё написанное здесь собрано из различных источников, немного основано на догадках и логичных выводах", — уточняет эксперт.

Что же лежит в основе "яблочного" качества?

В книге Inside Apple автор даёт общее описание технологического процесса создания продукта:

Согласно философии Apple, продукты начинаются с дизайна. Конкуренты могут лишь восхищаться тем, какое высокое положение занимают дизайнеры в компании. "В большинстве фирм сначала составляют план, проводят анализ рынка, намечают ориентиры, а уже потом дают указания дизайнерам", — говорит Ив Беар (Yves Behar), руководитель калифорнийской художественной студии Fuseproject. В Apple всё с точностью до наоборот: дизайнер излагает свою концепцию, которая для остальных является руководством к действию. "Если он говорит: "нужно использовать такой-то материал", коллектив молча кивает в ответ, — поясняет Беар. — Везде производственный отдел диктует свою волю дизайнерскому, в Apple — наоборот".

Как только в дизайнерском отделе Apple закипает работа, подключаются остальные подразделения компании; два из них — снабженцы и инженеры — отвечают за конечный продукт. Начинается процесс создания новинок Apple — Apple New Product Process, или ANPP. Такое название носит пошаговая инструкция для внутреннего пользования. Сказать, что ANPP — изобретение Apple, нельзя: в конце 1970-х — начале 1980-х годов аналогичные документы существовали в Xerox, Hewlett-Packard и некоторых других компаниях. Один из бывших инженеров Apple назвал процесс производства Macintosh смесью искусства с наукой.

При этом цель ANPP — "идеально отладить научную составляющую, чтобы осталось время на занятия искусством". В документе чётко указаны этапы разработки, исполнители, распределены задачи между функциональными подразделениями и установлены сроки выполнения поставленных целей.

Перед тем как готовый продукт покинет стены лаборатории, инициативу в свои руки берут два человека — главный инженер и главный логист. Первый определяет, каким должен быть продукт, и руководит работой технических специалистов. Он наделён такой огромной властью, что вселяет страх в сердца сотрудников: у них даже в ходу название "инженерная мафия". Главный логист отвечает за глобальные цепочки поставок; в его ведении созданный Тимом Куком операционный отдел; логист решает, где достать материалы, необходимые для создания продукта. Эти двое руководят всем: подбором поставщиков, закупками и производством. Правда, бывают ситуации, когда им совсем непросто договориться. "В Apple достаточно сказать: "Так будет лучше для продукта", затем привести убедительные аргументы, чтобы спор прекратился и решение было принято в твою пользу", — рассказывал в середине первого десятилетия нового века один из инженеров компании.

Несмотря на то, что место работы инженеров и логистов — офис в Купертино, большую часть времени они проводят в Китае. Там на контрактной основе корпорация производит свои компьютеры и мобильные устройства. Другие компании на месте Apple разрабатывали бы продукты в офисе, а потом отправляли готовый проект внешним производителям — так дешевле. Но Apple выбирает едва ли не самый затратный путь: проектирует продукт в офисе, а затем производит и тестирует опытный образец на заводе-изготовителе.

Чтобы добиться нужного результата, зачастую приходится воспроизводить всю цепочку несколько раз: снова разрабатывать, изготавливать и тестировать продукт. По выражению бывшего инженера, в Apple существует "открытый цикл": каждые 4–6 недель на китайской фабрике встречаются основные участники проекта. Обычно главный инженер, который сводит вместе специалистов по "железу" и софту, принимает свежий опытный образец и везёт в Купертино на суд вышестоящего начальства. Потом опять садится в самолёт и летит обратно. Так повторяется снова и снова.

Про тестирование в этом отрезке нет ни слова, но появляется некое понимание общего процесса.

В книге "Jony Ive: The Genius Behind Apple's Greatest Products" процесс описывается чуть более подробно

В течение нескольких месяцев после запуска iMac команда "A" довела до совершенства новую методику разработки. Она была названа Apple New Product Process ("Процесс разработки нового продукта Apple"), сокращённо ANPP, и стала одним из ключей к успеху Apple. Неудивительно, что в реальности Стива Джобса ANPP быстро превратился в хорошо продуманный процесс вывода новых продуктов на рынок путём детального планирования каждой стадии разработки продукта.

Принцип ANPP, воплощённый в компьютерной программе для внутренней сети компании, напоминает гигантский контрольный лист. В нем подробно расписано, что каждый сотрудник должен делать на каждой стадии. Инструкции есть для всех подразделений, начиная с отдела аппаратного обеспечения и кончая программистами, операционным, финансовым и маркетинговым отделами и техподдержкой, которая решала проблемы и занималась ремонтом продуктов после их выхода на рынок. "Процесс охватывает всё, от цепочки снабжения до магазинов, — объясняет один из бывших директоров, — и касается не только поставщиков, но и субподрядчиков. Сотни компаний. Всё, начиная с красок и винтиков и заканчивая микросхемами".

С самого начала ANPP вовлекает в процесс отделы, работа которых видна только после запуска продукта, например, маркетинг. "У нас в Apple о потребностях клиента и конкурентоспособности думают сразу, как только начинается работа над продуктом, — говорит директор по маркетингу Фил Шиллер. — Маркетологи — равноправные члены команды, они создают продукцию наряду с инженерами и операционной группой".

Система ANPP была построена с учётом лучших наработок Hewlett Packard и других компаний Кремниевой долины. Джобс задумал её ещё в NeXT и довёл до совершенства почти сразу после возвращения в Apple. Хотя такая процедура может показаться негибкой, она стала важным достижением. Один сотрудник в то время описывал её так: "Процесс очень чётко расписан, но не обременителен и не бюрократичен. Он даёт каждому возможность творить там, где это нужно, но не более того. Посмотрите на результаты! Apple — очень быстрая компания".

Система охватывала и отдел Джони, поэтому дизайнеры отныне должны были отмечать галочками все этапы от исследований и создания концепта до разработки и производства. Салли Грисдейл работала менеджером группы продвинутых технологий, которая тесно сотрудничала с группой дизайна. Она говорит, что ANPP отличался от систем в других компаниях систематическим документированием.

"Записывали всё. Это было неизбежно, ведь элементов так много, — говорит она. — Когда я работала, все процессы были прописаны. Именно поэтому в Apple было так здорово работать: у нас были буклеты о том, что и как надо делать, и это очень помогало при разработке программ и аппаратуры. Во всем была стройность и логика. Когда я перешла в другие компании, Excite и Yahoo, я столкнулась с жестокой реальностью — у них ничего подобного не было. Никто ничего не записывал. Какой процесс? Вы смеётесь? Отдали и забыли!"

Другим источником вдохновения для ANPP было "комплексное проектирование" — современная система управления технологическим процессом, благодаря которой отделы могут работать параллельно, в отличие от старой схемы, где проекты последовательно переходят от одного коллектива к другому.

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

Раньше в Apple над изделием сначала трудились инженеры, а затем оно переходило к дизайнерам для разработки оболочки. При Джобсе такая схема перестала работать из-за возросшего значения дизайн-студии. "Если вы так же амбициозны, как мы, традиционные способы разработки вам не подходят, — заметил Джони. — Задачи столь сложны, что приходится создавать продукцию в тесном сотрудничестве".

Из статьи в Блумберг можно узнать, что команда Quality Assurance состоит из примерно сотни человек. Там же описываются такие рабочие обсуждения, которые называются Bug Review Board (BRB). Это встречи, на которых инженеры Apple рассказывают о текущем прогрессе с поиском дефектов и контролируют этот процесс с помощью графика burndown.

"Руководит обсуждением Ким Воррат (Kim Vorrath), вице-президент продукт-менеджемента iOS и Mac OS (по данным Business Insider он отвечает за соблюдение сроков выпуска продуктов и за их качество перед выпуском), также в них участвует Josh Williams, который является директором департамента Quality Assurance в Apple's iOS Mobile-Software Group, и другие инженеры из Apple Software Engineering Group", — пишет Сергей Бронников.

На заседаниях совета все неисправленные дефекты ранжируются по приоритетам от P1 до P3. Где P1 — это showstopper, в случае присутствия таких дефектов продукт не может быть выпущен. P2 и P3 считаются низкоприоритетными дефектами, но работа по выпуску обновления с исправлениями этих дефектов может начаться до того, как предыдущее обновление появится у пользователей.

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

"Впрочем, тираж багов — это вполне растространенная практика. Но обычно эту роль выполняет только один человек — менеджер проекта", — говорит эксперт.

По словам бывших сотрудников, в компании Apple больше полагаются на людей, тестирующих продукты вручную, нежели на автоматические тесты. Однако и автоматические тесты для iPhone используются. Всего в разработке и тестировании iOS заняты порядка 100 человек.

В книге Inside Apple на тему Eating your own dog food описывается такой эпизод:

"Типичный пример — iPhone. Его предыстория проста: сотрудников Apple раздражалисмартфоны, которые они покупали. "В итоге решили сделать свой", — объяснял Джобс и достигал сразу двух целей. С одной стороны, рассказывал несомненно правдивую историю, с другой говорил покупателю что-то вроде: "Мы обожаем собачий корм настолько, что едим его сами. Приобретайте, не пожалеете". Интересно, как у них сейчас обстоят дела с такой практикой?".

Отдельно используется тестирование опытных образцов в обычных условиях — когда сотрудники компании используют их в повседневной жизни, чтобы выявить те дефекты и недоработки, которые сложно обнаружить в тестовой лаборатории. Это что-то между альфа-тестированием и "eating your own dog food". Недавняя статья с фотографиями Apple Watch лишний раз подтверждает использование такого подхода.

В компании существует специальная программа Bug bounty — это программа по поощрению людей, обнаруживших уязвимость в продуктах компании и сообщивших о ней компании до опубликования деталей уязвимости. Помимо этого инженеры Apple тесно сотрудничают с FreeBSD Security Team в плане анализа и выпуска патчей безопасности.

Одним из способов выявления дефектов является тестирование на пользователях, и в Apple этим также активно пользуются, выпуская бета-версии своего ПО. Судя по списку открытых вакансий, в Apple есть как команды для ручного тестирования так и автоматического. И похоже, что каждая продуктовая команда имеет свою отдельную команду тестировщиков. К примеру: Firmware, XCode, Fonts Team, Apple iAd Team, iWork Team, iTunes Team, iOS (iPhone Quality Team), Safari & WebKit, The Apple Product Documentation, Thunderbolt Software and Firmware Quality Assurance team.

В плане используемых технологий и инструментов Apple, похоже, мало чем отличается от других компаний, разрабатывающих ПО:

• Использование Сontinuous Integration в разработке;
• Тестовые фреймворки написаны на Python, Ruby, Perl и используется AppleScript для автоматизации рутинных действий;
• Используются JUnit, TestNG, Selenium и WebDriver.

Майкл Лопп, работавший в Apple на позиции старшего менеджера по разработке, делится своим впечатлением о Radar:

"Моё любимое приложение для внутреннего использования в Apple — это Radar. Это приложение, написанное на Cocoa, которое работает как система отслеживания дефектов. И если вы захотите узнать, что происходит с конкретным приложением в Apple, то вы идёте в Radar.

Многие команды в Apple едва ли не молились на Radar. Жалобы на продукт не принимались, пока не попадали в багтрекер. Если бы меня спросили: "Вы в курсе, что в вашем продукте есть такой-то баг?", я бы тут же спросил в ответ: "А в Radar он есть?" — "Нет". — "Пока его нет в Radar, нам не о чем говорить".

Существуют незыблемые правила:

• Сообщайте о любых, даже самых незначительных ошибках продукта.
• Хороший тон — указывайте как можно больше подробностей. В любом случае важно завести баг.
• Также хороший тон — убедитесь, что такой проблемы ещё нет в базе. В любом случае важно завести баг.
• Когда сообщают, что проблема исправлена, проверьте, так ли это. Часто оказывается, что нет, или что возникла схожая проблема.
• Несоблюдение данных правил влечёт за собой немедленное напоминание о них.

Для команд, которые всегда следовали этим правилам, Radar стал мощным инструментом и надёжным источником сведений о продукте. Благодаря ему, на вопрос: "Как поживает продукт?" можно было ответить не раздражающе размыто: "Да так, потихоньку", а нормально: "Чиним критические баги, по одному на инженера в день. В команде 14 инженеров, заведено 308 багов. Без учёта новых, справимся за 22 дня. А новых багов уже приходит по семь штук в день, и дальше будет только больше. В общем, вот тебе фильтр по багтрекеру, и не трать моё время".

Мои слова полны раздражения. Причина в том, что я всё время сталкиваюсь с людьми, которые искренне верят, что заводить баги — работа QA-инженеров. Но, фактически, качество — это ещё одна "фича" продукта, а потому, нравится это вам или нет, все мы отчасти инженеры QA-отдела".

Итак, ключевые особенности разработки продуктов в Apple:

• Во главе разработки стоит отдел дизайнеров, а не разработчиков.
• Все найденные дефекты моментально появляются в баг-трекере.
• Процесс разработки строго регламентируется чеклистом (ANPP), который описывает все стадии разработки продукта.
• За производство и финальное тестирование опытных образцов отвечают два человека: главный инженер и главный логист, которые наделены практически безграничными полномочиями внутри компании.
• Бета-тестирование продуктов.
• Тестирование опытных образцов продукта в обычных условиях сотрудниками Apple.
• Использование принципа: "eating your own dog food".
• Программы bug bounty.
• Коллективное обсуждение критичности найденных дефектов (Bug Review Board).
• Активное использование ручного тестирования, несмотря на автоматические тесты.
• Разработка ведётся трёхнедельными спринтами: две недели разработка новой функциональности и одна неделя багфиксинг.