От дизайна до производства: Как обеспечивается качество продуктов Apple

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

#самизнаетекакиекнопки

«Это просто работает» — именно эти слова всегда ассоциировались у людей с продуктами Apple. Мы всегда ожидаем от продуктов этой компании не только инноваций, не только продуманного интерфейса, но и достойного уровня качества. Это отсутствие серьёзных дефектов в обновлениях, это выпуск обновлений с исправлением обнаруженных проблем в кратчайшие сроки, это отсутствие серьёзных проблем в безопасности программного обеспечения и сервисов Apple. Это то, за что фанаты так привержены её продуктам.

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

К сожалению в последнее время ситуация меняется не в пользу Apple — всё больше и больше проблем возникает при использовании новых продуктов: баг в HealthKit, проблема с удалением альбома U2, проблемы с iOS 8, картами и другие баги.

В то время, когда весь деловой мир держит курс на открытость, Apple окружает себя тайной. Всё, что касается рабочего процесса, — запретная тема, табу для обсуждения. Крупные компании не скрывают своей внутренней кухни, и часто можно найти материалы о разработке и тестировании ПО в тех же Google или Microsoft. Так, про тестирование в Google можно узнать из книги James A. Whittaker ‘How Google Tests Software’ или из конференций, организованных компанией. Про тестирование продуктов Microsoft из другой книжки — ‘How We Test Software at Microsoft’.

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

Обратив своё внимание на эту ситуацию вокруг продуктов Apple и руководствуясь профессиональным любопытством (я занимаюсь тестированием по долгу профессии), я попробовал собрать всю информацию, которая касается тестирования продуктов Apple Inc. Это позволит понять, как работает команда Quality Assurance в этой компании, чем обеспечивается качество их продуктов и, возможно, будет попыткой ответить на вопрос, почему качество стало снижаться.

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

В книге ‘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 недель на китайской фабрике встречаются основные участники проекта. Обычно главный инженер, который сводит вместе специалистов по «железу» и софту, принимает свежий опытный образец и везет в Купертино на суд вышестоящего начальства. Потом опять садится в самолет и летит обратно. Так повторяется снова и снова.

К сожалению, про тестирование ни слова, но общее понимание уже есть. Графически процесс ANPP выглядит так:

Изначально Apple New Product Process использовался для разработки Macintosh. Это документ, который описывает каждую стадию создания продукта, ответственных за каждую из них и когда каждая фаза должна быть закончена.

В книге ‘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 над изделием сначала трудились инженеры, а затем оно переходило к дизайнерам для разработки оболочки. При Джобсе такая схема перестала работать из-за возросшего значения дизайн-студии. «Если вы так же амбициозны, как мы, традиционные способы разработки вам не подходят, — заметил Джони. — Задачи столь сложны, что приходится создавать продукцию в тесном сотрудничестве».

Из статьи Bloomberg мы можем узнать, что команда 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 человек.

Помимо собственного Quality Assurance, которое непосредственно отвечает за качество, в компании ещё с 1980 года практикуется использование своих же продуктов. Так, президент Apple Майкл Скотт написал письмо, которое гласило, что никто более не должен использовать печатные машинки. Тем самым он хотел поставить эксперимент по избавлению от печатных машинок, чтобы убедить в их ненужности своих пользователей.

А в книге ‘Inside Apple’ на тему Eating your own dog food описывается такой эпизод: «Типичный пример — iPhone. Его предыстория проста: сотрудников Apple раздражали смартфоны, которые они покупали. «В итоге решили сделать свой», — объяснял Джобс и достигал сразу двух целей. С одной стороны, рассказывал несомненно правдивую историю, с другой говорил покупателю что-то вроде: «Мы обожаем собачий корм настолько, что едим его сами. Приобретайте, не пожалеете»». Интересно, как у них сейчас обстоят дела с такой практикой?

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

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

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

Организация команд Quality Assurance: судя по списку открытых вакансий, в 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.

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

Хотелось бы остановиться на таком инструменте в разработке и тестировании, как Radar. Radar — это внутренняя система Apple для работы с дефектами. Есть несколько различных способов получить доступ к Radar. Первый заключается в использовании веб-приложения RadarWeb, второй способ в использовании приложения для iPad и iPhone — MobileRadar, а третий — Radar for OS X. Сторонние разработчики имеют доступ к Radar только через RadarWeb с ограниченной функциональностью, в то время как сотрудники Apple имеют доступ к Radar с помощью приложения для iOS, Radar для OS X и RadarWeb с повышенными привелегиями.

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

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

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

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

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

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

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

Судя по некоторым описаниям вакансий, в командах практикуется использование Agile и Scrum методологий.

Бывший разработчик Mac OS описывает изменения в методологии разработки программного обеспечения: вместо релизов с большим количеством изменений была внедрена система спринтов — две недели на разработки функциональности и одна неделя на исправление дефектов. И, по его ощущениям, это отразилось на стабильности приложений и на предсказуемости дат релизов.

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

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

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