Ранняя стадия проекта

Ранняя стадия проекта

В Google нет правила, когда именно разработчики в тестировании должны присоединиться к проекту. Так же как нигде не прописано, когда именно проект становится «реальным». Типичный сценарий создания нового проекта такой: эксперимент, над которым работали в «двадцатипроцентное» время, набирается сил и становится самостоятельным продуктом Google. Именно так развивались Gmail и Chrome OS. Эти проекты начинались с неформальных идей, а со временем выросли в полноценные продукты со своими командами разработчиков и тестировщиков. Наш друг Альберто Савоя (написавший введение к этой книге) любит повторять, что «качество не имеет значения, пока ваш продукт не имеет значения».

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

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

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

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

Chrome OS — яркий пример такого подхода. На этом проекте все трое авторов этой книги работали больше года. Но задолго до того, как мы официально присоединились к работе, несколько разработчиков создали прототип. Он состоял в основном из скриптов и заглушек, но зато позволял продемонстрировать идею «чисто браузерного» приложения руководству Google, чтобы официально утвердить проект. На стадии прототипа команда концентрировалась на экспериментах и хотела доказать, что этот концепт вообще жизнеспособен. Тратить время на тестирование — или даже проектировать с оглядкой на тестируемость — было бы неразумным, особенно учитывая, что проект был еще неофициальным, а все демо­сценарии в будущем все равно заменили бы реальным кодом. Когда сценарии выполнили свое предназначение и продукт был утвержден, руководитель разработки обратился к нам за помощью в тестировании.

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

На заметку

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

7.3.3. Концепции, связанные с производственным процессом проекта Описание производственного процесса проекта

Из книги Модель зрелости процессов разработки программного обеспечения автора Паулк Марк

7.3.3. Концепции, связанные с производственным процессом проекта Описание производственного процесса проекта Является стандартным определением производственного процесса, используемого в проекте. Данный процесс представляет собой четко охарактеризованный и понятный


12.16 Описание проекта ПО

Из книги ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВСТРОЕННЫХ СИСТЕМ. Общие требования к разработке и документированию автора Госстандарт России


Создание проекта

Из книги Домашний архитектор. Подготовка к ремонту и строительству на компьютере автора Булат Виталий

Создание проекта Рассмотрим возможности программы VisiCon подробнее и разработаем небольшой дизайнерский проект квартиры.Выполните команду Файл ? Новый или воспользуйтесь комбинацией клавиш Ctrl+N. Предварительно желательно закрыть прочие проекты, если таковые были.На


Визуализация проекта

Из книги Ландшафтный дизайн на компьютере автора Орлов Андрей Сергеевич

Визуализация проекта Рассмотрим созданный проект здания в визуальном представлении, нажав кнопку 2D Designs View (2D-дизайнерское представление) на панели управления в нижней части окна программы. Здание будет представлено в цветном виде, как бы сверху (рис. 11.19). Рис. 11.19.


Завершающая стадия

Из книги AutoCAD 2009 автора Орлов Андрей Александрович

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


Сохранение проекта

Из книги ArCon. Дизайн интерьеров и архитектурное моделирование для всех автора Кидрук Максим Иванович

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


17.1.1. Ранняя история С

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

17.1.1. Ранняя история С Язык С родился в 1971 году как язык системного программирования для PDP-11-варианта Unix и основывался на раннем интерпретаторе языка В, разработанного Кеном Томпсоном. Язык В, в свою очередь, был смоделирован с базового языка общего программирования (Basic


Ранняя AS/400 (она же System/38)

Из книги Основы AS/400 автора Солтис Фрэнк

Ранняя AS/400 (она же System/38) В конце 1985 небольшая группа разработчиков из Рочестера продемонстрировала, что на System/38 можно создать среду для программного обеспечения System/36. Стоимость оборудования снизилась настолько, что мы теперь могли создавать малые модели System/38. Это


Завершающая стадия

Из книги AutoCAD 2010 автора Орлов Андрей Александрович

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


17.1.1. Ранняя история С

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

17.1.1. Ранняя история С Язык С родился в 1971 году как язык системного программирования для PDP-11-варианта Unix и основывался на раннем интерпретаторе языка В, разработанного Кеном Томпсоном. Язык В, в свою очередь, был смоделирован с базового языка общего программирования (Basic


Спонсор проекта SAP

Из книги Технология XSLT автора Валиков Алексей Николаевич

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


Форма проекта

Из книги VBA для чайников автора Каммингс Стив

Форма проекта Нам понадобится форма с тремя страничками и тремя компонентами TMemo. В первом будет показываться исходный текст преобразуемого документа, во втором — XSLT-преобразование и в третьем — результат преобразования.Приблизительный внешний вид формы показан на


2-й шаг. Реализация проекта

Из книги Виртуальная библиотека Delphi автора

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