Гойко Аджич в своем блоге пересказывает выступление директора по тестированию Google, Джеймса Уиттакера, на конференции Agile Cambridge, ну, а я перевожу его пересказ.
Джеймс Уиттакер, директор по тестированию в Google, рассказывал вчера на конференции Agile Cambridge о том, как в Google занимаются «Инжинирингом тестирования». Он сравнил тестирование программного обеспечения с медициной – в частности, с уходом за пациентами в больницах.
Уиттакер начал с того, что 20 лет назад разработка программного обеспечения была похожа на массовое производство, и стоимость исправления проблемы после выпуска был гораздо выше, чем до него. «Мы уже не делаем программное обеспечение таким способом», сказал Уиттакер, добавив: «вы можете использовать приложение Google Docs, в это же время оно будет обновляться, и вы даже не заметите этого». Уиттакер делает вывод, что время, требующееся, чтобы исправить ошибку до и после выпуска, для их программного обеспечения в настоящее время абсолютно одинаково (обратите внимание — время, но не цена).
Вместо раннего исправления ошибок и встраивания качества с самого начала, Уиттакер предлагает подойти к программному обеспечению, как к пациенту в больнице. «Тестирование, как и лечение — постоянный процесс», сказал он, добавив, что для оказания эффективной помощи врачам необходимо быстро оценивать состояние больного. Для этого они используют карту пациента, которая дает им историю болезни и лечения, и мониторы, которые позволяют наблюдать за жизненно важными показателями, такими как частота пульса.
«У меня нет карты, чтобы показать мне проблемы, и монитора жизнедеятельности», говорит Уиттакер. Для него, как у директора по тестированию, эта информация была доступна, но хранилась в нескольких база данных, запросы к которым нужно было строить вручную, поэтому он поставил своей команде задачу уменьшить количество SQL запросов.
В результате, команды разработчиков Google создали несколько инструментов, предоставляющих функциональность карты пациента и мониторов жизнедеятельности (при этом они избежали ситуации «тащите самую крутую машину, начальник идет»).
Характеристики, возможности и компоненты
Политика компании состоит в том, что любой сотрудник имеет доступ к любым тестам, не только в своем продукте. Они создали инструмент под названием Testify, который делает выводы о состоянии продукта на основе тестов и результатов их выполнения. Он также помогает собрать исторические данные диагностики.
Как выяснилось, для вывода о состоянии программного продукта, информация должна быть структурированной и упорядоченной. «Докторам проще — все их пациенты выглядят одинаково», говорит Уиттакер. Чтобы иметь возможность делать осмысленные заключения о состоянии программного обеспечения, они стали собирать желаемые характеристики своих продуктов. Например, в число желаемых атрибутов Chrome OS входят стабильность и надежность. «Всякий раз, когда продажники используют наречие или прилагательное, мы создаем характеристику», говорит Уиттакер. Эти характеристики затем собираются в облако тегов, чтобы обеспечить видимость относительной важности разных характеристик.
Для каждой характеристики собрали список программных компонентов, которые на неё влияют. Для Chrome ОС это заняло около 20 минут. После этого, собираются возможности, начиная с глаголов, которые используются при описании функциональности. Например, возможностями Chrome OS являются «подключается к Интернету», «показывает веб-страницу». Получение списка 304 возможностей Chrome ОС заняло около двух часов. Сомневаясь, что возжности на этом исчерпываются, они провели ревью списка, и получили в конечном итоге 314 возможностей.
Возможности, компоненты и характеристики «определяют нашего пациента», говорит Уиттакер. По его словам, особенность Google в том, что у них очень низкое соотношение числа тестировщиков к разработчикам. В «богатых» командах оно достигает одного тестировщика на четверых или шестерых разработчиков, типичным является соотношение один к четырнадцати, а в некоторые командах один тестировщик на двадцать восемь разработчиков. Виттакер говорит: «Если разработчикам нужно что-то протестировать, они должны попросить вежливо и быть готовым к отказу. Команде тестирования нужно понять, что тестировать, и вы должны убедиться, что весь ваш код связан с набором возможностей, связанных с компонентом, связанным с характеристикой». [Тестировщики] расставляют риски по матрице возможностей и характеристик, и риск определяет, куда направляются ресурсы тестирования. В результате, разработчики уделяют большое внимание качеству своих продуктов.
Использование «обходов» в качестве тестовых стратегий
Подобно тому, как врачи используют виды лечения (например, витаминотерапию или химиотерапию), чтобы обсудить весь комплекс действий с коллегами и пациентами, Уиттакер рекомендует использовать «обходы» (tours) для описания тестовых стратегий. Он привел несколько примеров «обходов», использующихся в Google — таких, как: проход по переулкам (посещение мест, куда до этого мало кто заглядывал), ночная экскурсия (запуск программного обеспечения в лаборатории на ночь, без выключения) и поход по шотландским пабам (охватить тестами всю систему целиком). Эти обходы служат языком паттернов высокого уровня для действий и проверок в течение тестовой сессии, без углубления в детали низкого уровня. Они помогают команде обсуждать глобальные проблемы и общаться более эффективно.
Head-Up дисплеи
Монитор в комнате больного говорит зашедшему врачу все необходимое о жизненных характеристиках пациента. Ему не нужно куда-то идти, чтобы выяснить подробности. Уиттекер считает, что видеоигры являются отличным примером того, как head-up-дисплеи представляют сложные данные на экране в очень доступной форме. «[Игрокам] не приходится писать SQL запросы во время игры», говорит Уиттакер, доказывая, что тестировщики тоже не должны писать SQL запросы, чтобы получить важные показатели программного обеспечения. Затем он показал несколько примеров систем, которые они разработали в Google для отображения основных показателей своих продуктов.
Один из экранов показывает распределение модульных тестов по модулям и по разработчикам, что позволяет быстро увидеть, кто пишет юнит-тесты, а кто нет. Как результат, тестировщики стали вознаграждать хороших разработчиков с помощью системы премирования, и стимулировать их к написанию автоматизированных тестов.
Другой экран показывает, кто исправляет ошибки, а кто нет. Они разработали подобие экрана видео-игры с аватарами разработчиков в верхней половине и насекомовидными существами, представляющими обнаруженые ошибки, в нижней. Как только дефект назначается на конкретного разработчика, соответствующий жук перемещается из нижней части экрана наверх и начинает атаковать аватар разработчика. Как только ошибка исправлена, аватар разработчика убивает жука. Такое представление позволило быстро выявить разработчиков с большим числом открытых дефектов. Вывод этой «игры» на экран, видимый разработчикам, вызвал значительное сокращение среднего срока жизни ошибки.
Значит, тестирование похоже на медицину?
Уиттакер заключает, что тестирование является «непрерывной деятельностью, подобной врачебному обходу в больнице».
Мое главное возражение против этого рассказа касается применения сомнительных метафор к разработке. Непонятно, почему разработка программного обеспечения всегда обязана быть похожей на что-то другое, и почему люди не могут практиковать её саму по себе. Подход к программному обеспечению, как к постоянно больному и нуждающемуся в присмотре не очень хорошо соотносится с моим опытом. Я видел больные системы, но также видел и много весьма здоровых — и те и другие нуждаются в тестировании. 20 лет назад я занимался разработкой из интереса, а не за деньги, так что не могу на самом деле сказать, на что это было похоже с точки зрения промышленности. Тем не менее, в моем понимании, разработка программного обеспечения никогда не была похожей на массовое производство.
Я, все же, вижу большую пользу в изучении опыта других областей, включая медицину, и применении значимых уроков оттуда в программном обеспечении. Выявление характеристик системы и обеспечение большей видимости — это, безусловно, хорошая идея.