| Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 5): Test Estimation |
В этой серии статей я говорил об оценке проектов. Но я тестировщик, и вы, вероятно, тоже, раз уж читаете этот блог; ну или, по меньшей мере, вы интересуетесь тестированием. Итак, все это выглядит занятно по отношению к оценке проектов, но какое значение это имеет к оценке проектов тестирования?
Давайте действовать как тестировщики – будем задавать вопросы.
Существует ли вообще такая штука, как проект тестирования? В частности, может ли проект тестирования существовать независимо от проекта разработки?
Не бывает "проектов тестирования" абсолютно независимых от каких-либо других проектов. Всегда есть клиент, обычно есть и другие заинтересованные лица. Всегда происходит передача информации, общей или специфичной. Всегда уже выполнена некоторая работа, и кто-то хочет узнать, что получилось. Всегда есть тестировщик или несколько тестировщиков. Всегда есть какие-то временные ограничения - конец итерации в Agile, контрольная точка проекта, назначенная дата поставки или некое представление о том, когда проект должен завершиться. В очерченных временных рамках проводится минимум один, а обычно - несколько циклов тестирования. Также имеются риски, которые тестирование пытается снизить, изыскивая соответствующие данные и передавая их заинтересованным лицам. Время от времени - постоянно или в конце цикла - тестировщики сообщают заказчику обнаруженные сведения.
Проектом может быть периодический обзор продукта. Проектом может быть судебная тяжба, когда команда юристов пытается доказать, что продукт не удовлетворяет требованиям контракта. Проектом может быть научная или промышленная программа исследований, в которой ключевую роль играет ПО. В общем, проект - это некоторый вид разработки ПО (неважно, идет ли речь о массовом коммерческом ПО, об онлайновом сервисе, или об ИТ-поддержке внутри компании). Проект может модифицировать существующий продукт или включать большое количество нового кода. Неважно, о чем идет речь; тестирование само по себе - не проект, тестирование - часть проекта; часть, которая поставляет информацию проекту. Тестирование не происходит отдельно, оно часть системы. Тестирование наблюдает за результатами работы системы, частью которой оно является, и скармливает эту информацию обратно системе. И тестирование - только один из нескольких механизмов получения обратной связи в системе.
Хотя тестирование может быть организовано в виде циклов, было бы странно считать его чем-то отдельным от остального проекта, так же как было бы странно думать о наблюдении (смотрении, seeing) как об отдельной части вашего дня. Люди говорят много странного, но едва ли вы слышали, чтобы кто-то сказал: "Мне нужно закончить работу, а потом я начну смотреть"; вы почти никогда не спрашиваете: "Когда вы планируете завершить наблюдение?" Бывают моменты, когда вы уделяете глазам и наблюдению больше внимания - когда вы управляете машиной или режете овощи или наблюдаете за ребенком, играющим в захламленной комнате. Но даже когда вы сконцентрированы на наблюдении, оно происходит в контексте какой-то иной деятельности (и обслуживает эту деятельность).
Имеет ли смысл термин "фаза тестирования"?
Многие организации (например, не использующие Agile) делят проект на две обособленных части: "фазу разработки" и "фазу тестирования". Мой коллега Джеймс Бах (James Bach) заметил интересное противоречие в таком подходе.
Что происходит в "фазе разработки"? Программисты программируют. Программирование может включать в себя массу активностей, таких как исследование, проектирование, экспериментирование, создание прототипов, написание кода, блочное тестирование (unit testing) (а в случае TDD тест для блока создается до написания кода, который будет проверяться), интеграционное тестирование, отладка, рефакторинг. А что делают тестировщики во время "фазы разработки"? Тестировщики тестируют. Говоря точнее, они занимаются обзором, планированием, проектированием тестов, созданием инструментов, генерированием данных, настройкой окружения, выполнением интеграционных тестов сравнительно низкого уровня и даже выполнением высокоуровневых системных тестов. Все эти действия можно включить в категорию "тестирование".
Что происходит в "фазе тестирования"? Программисты по-прежнему программируют, а тестировщики по-прежнему тестируют. Главное отличие между этими двумя фазами - в фокусе работы программистов: они прекращают добавлять новую функциональность, а вместо этого занимаются починкой найденных проблем. В первой фазе программисты уделяют больше внимания разработке новых функций; во второй - починке. Исходя из этого, Джеймс считает, что "фазу тестирования" правильнее называть "фазой починки" (fixing phase). Если мы всерьез рассмотрим это предложение, изменится суть некоторых часто возникающих вопросов. Замените слово "тестировать" словом "чинить": "Сколько времени вам нужно на починку этого продукта?", "Когда планируется завершить починку?", "А мы можем просто автоматизировать починку?", "Стоит ли начинать починку на ранних стадиях проекта?", "Почему клиент нашел сломанную функциональность? Вы что, не чинили ее?" И должны ли мы обращаться к тестировщикам с такими вопросами?
Как отмечает Джеймс, никто никогда не откладывал выпуск продукта просто потому, что еще было что потестировать. Продукты задерживаются из опасения, что разработчикам стоило бы сделать еще что-то до релиза. Тестирование можно остановить, как только владелец продукта (product owner) убедился, что имеет достаточно информации, чтобы разрешить поставку продукта. В таком случае, вопрос к тестировщикам "Когда вы собираетесь завершить тестирование?" превращается в вопрос к владельцу продукта: "Когда я поверю, что имею достаточно данных для принятия ответственного бизнес-решения?" В такой момент владельцу продукта стоит [в разумной степени] скептически смотреть на чьи-то заявления, что они завершили тестирование.
Вопрос "Когда я получу достаточно данных" может показаться трудным. Это действительно трудный вопрос. Когда я работал программным менеджером (program manager) в коммерческой компании производящей ПО, я не мог ответить на этот вопрос, пока данные не были упорядочены. Чтобы хорошо ответить на него, нужно учесть очень много аспектов: технические данные, технические риски, покрытие тестов, качество используемых моделей, качество используемых оракулов, бизнес-данные, бизнес-риски, представление о достаточности, решительность... Большинство этих переменных нужно собрать и оценить и принять решение, и сделать все это в голове одного человека; и этот человек - не тестировщик. Этот человек - владелец продукта. Оценка переменных и готовность к поставке меняются каждый момент. Конечное состояние переменных и конечное решение о дате поставки находятся где-то в будущем. Спрашивать тестировщика "Когда вы собираетесь закончить тестирование?" все равно, что спрашивать глаза "Когда вы собираетесь закончить наблюдение?" Глаза продолжают разглядывать окружающую среду, поставляя данные одновременно с прочими органами чувств, пока мозг не примет решение. Подобным образом, тестировщики продолжают тестировать, поставляя данные одновременно с другими участниками проекта, пока владелец продукта не примет решение о поставке. Ни тестировщик, ни глаза не могут в одиночку ответить подходящим образом на вопрос "Когда вы планируете закончить?"; это не их зона ответственности. До принятия решения мозг (выборочно) учитывает массу данных, получаемых от глаз и других органов чувств. Те из нас, кто пожирал глазами стол с десертами, знают, что бывает, если разрешить глазам принимать решения. Более того, если существует проблема, едва ли глаза смогут ее решить.
Некоторые верят, что могут спрогнозировать, когда завершится тестирование, разбивая тестирование на измеримые части, такие как варианты тестирования (test cases) или шаги тестирования. По-моему, это все равно, что использовать "варианты наблюдения" или "шаги наблюдения", что приводит нас к следующему вопросу:
Можно ли измерить длительность "проекта тестирования" подсчитав "варианты тестирования" или "шаги тестирования"?
Недавно на конференции я слушал выступление, в котором докладчица представила способ оценить, когда завершится тестирование. По сути, он сводился к следующей формуле: разбейте тестирование на варианты тестирования (test cases), разбейте варианты тестирования на шаги тестирования, измерьте длительность нескольких шагов тестирования, вычислите среднее (или хоть что-то) чтобы понять, сколько времени занимает один шаг тестирования, а затем умножьте полученное время на число шагов. Вуаля! Оценка готова.
Только одна проблемка: основа вычисления не была объяснена. Что такое шаг тестирования? Это физическое действие? Похоже, докладчица предполагала, что тестировщик переходит к следующему шагу, когда он начинает подавать новые входные данные (input action). Несомненно, не все входные данные одинаковы. Что считается подачей входных данных? Клик мышкой? Движение мышкой? Ввод каких-то данных в поле? В набор полей с последующим нажатием клавиши Enter? Включается ли наблюдение (несколько наблюдений) в шаг тестирования? А оценка результата (evaluation)? Что происходит, когда человек замечает странность и начинает размышлять? Что происходит, когда во время выполнения теста тестировщик замечает опасность и решает поискать соответствующие проблемы? Что происходит с единицей измерения, когда тестировщик находит проблему и начинает исследовать и описывать ее?
Докладчица признала проблему, сказав, что шаг может занимать как пять секунд, так и половину дня. Предел погрешности 3000 к одному по отношению к шагу - элементу, на котором основана оценка, - делает надежность оценки сомнительной. Кроме того, предел погрешности, даже столь огромный, ортогонален к гораздо более серьезной проблеме с этим подходом к оценке.
Подлинное тестирование - это не монотонное и/или повторяющееся выполнение сценариев (которое в моем сообществе называют проверкой). Тестирование - это исследование кода, компьютеров, людей, ценностей, рисков и отношений между ними. Исследование включает в себя периоды изучения, эксперименты, поиск, открытия, интерпретацию результатов и обучение. Вариативность и приспособление являются сутью этого процесса. Выполнение тестов включает в себя отражение того, что только что случилось, возвращение на несколько шагов назад, повторение или изменение шагов во время формулировки проблемы или выполнения наблюдений. Исследование не может выполняться по заранее описанному. Исследование в соответствии с заранее описанными шагами - вообще не исследование.
Во время исследования многие возникающие вопросы - начиная с самого первого - могут привести к ответу, который пустит под откос все ваши предубеждения. Во время исследования нужно обнажать, оспаривать и уточнять предположения. Во время исследования ответ на последний заданный вопрос может оказаться важнее, чем все сделанное до этого. Если мы стремимся к качественному исследованию, мы не можем полагать, что самые критичные риски уже обнаружены. Если мы стремимся к качественному исследованию, нам не помогут механические действия (Если возникают "механические" вопросы, давайте ставить их перед автоматическими проверками низкого уровня. И давайте делать это умело).
Если мы не можем полагаться на подсчет вариантов тестирования, как мы можем оценить время, необходимое для тестирования?
Существует множество активностей, которые не попадают в модели, так как они неотделимы от проекта, в котором происходят. Возвращаясь к аналогии Джеймса Баха, - никто не оценивает фазу смотрения-в-окно во время автомобильной поездки. Вы можете оценить длительность поездки, но в окно вы смотрите постоянно, пока не приедете в пункт назначения. Глядя в окно, водитель оценивает, правильно ли он едет, и достиг ли он пункта назначения. Никто не оценивает фазу обслуживания клиентов во время отдыха в отеле. Вы можете оценить длительность постоя, но обслуживание клиентов (если оно хорошее) доступно непрерывно, пока вы не покинете отель. Никто не оценивает "фазу управления" проекта разработки ПО. Вы можете оценить, сколько времени уйдет на разработку, но управление (когда оно хорошее) происходит постоянно вплоть до выпуска продукта. Наблюдения и действия руководителей (руководителя разработки, руководителя техподдержки, руководителя отдела документации, и - да, руководителя тестирования) информируют владельца продукта о том, насколько продукт готов к поставке.
Оценка тестирования становится проблемой, только если кто-то ошибочно рассматривает тестирование как отдельную активность или фазу, а не как непрерывное исследование, продолжающееся в течение всего проекта.
Мой начальник говорит, что я должен предоставить оценку, что мне делать?
В начале проекта мы знаем очень мало по сравнению с тем, что мы узнаем позже. Мы не можем знать все, что нам понадобится узнать. В начале проекта мы не в состоянии узнать, будет ли проект выполняться по плану, избежав встречи с Черным Лебедем или стаей Черных Лебедей. Поэтому попробуйте мыслить не в терминах оценки тестирования, а в терминах стратегии, логистики, переговоров и улучшений.
Наша стратегия - это набор идей, на базе которых мы строим тесты. Эти идеи возникают из окружения проекта (контекста); из критерия качества, который могут оценить пользователи и другие лица; из тестового покрытия, которое мы хотим получить; из техник тестирования, которые мы выбираем. (В качестве примера основы для разработки стратегии можно рассмотреть эвристическую модель стратегии тестирования, Heuristic Test Strategy Model, которую мы используем в Rapid Testing). Логистика - это идеи, направляющие применение людей, оборудования, инструментов и других ресурсов для осуществления нашей стратегии. Сложите стратегию и логистику вместе - и получите план.
Поскольку мы работаем с - и, что важнее, для - клиента, то цели, расписание и бюджет клиента в значительной степени определяют выбор элементов нашей стратегии и логистики. Отчасти этот выбор определяется историческими данными и текущим состоянием дел. К примеру, многие проекты разрабатываются в организациях, где уже есть программисты и тестировщики; многие проекты расширяют функциональность существующих продуктов или услуг. Порой стратегия проекта основывается на прогнозах, или ожиданиях, или надеждах. Например, когда владелец продукта заранее назначает желаемую дату поставки продукта. Для построения предварительного плана тестирования мы используем всю доступную информацию. Клиенту может понравиться наш план, а может и нет. В любом случае, при эффективных взаимоотношениях ни одна из сторон не может навязывать сроки. В противном случае мы ведем переговоры. Многие наши предубеждения (и предубеждения клиента) могут оказаться неверными или измениться по ходу проекта. Это нормально; с самого начала окружение проекта, отличное тестирование, непрерывный поток отчетов и взаимодействие помогают нам выявить необоснованные допущения и новые опасные идеи. Если мы трактуем тестирование как нечто, происходящее непрерывно и одновременно с разработкой, а разработка происходит циклически, обеспечивая нечто подобное пульсу проекта, то у нас есть возможность пересматривать и уточнять наши планы.
Итак: вместо попыток оценить "фазу тестирования" договаривайтесь и уточняйте свою стратегию тестирования в контексте всего проекта. Вам в любом случае придется это делать, не так ли?
Но мое руководство любит оценки! Может, есть хоть что-то, что можно оценить?
Нет смысла оценивать затраты на тестирование вне контекста всего проекта, но мы можем оценивать их в рамках цикла разработки. Базовая идея основана на управлении сессионным тестированием - разработанном Джеймсом и Джоном Бахами подходе к планированию, оценке, управлению и измерению исследовательского тестирования в обстоятельствах, требующих высокого уровня отчетности. Ключевые факторы:
- ограниченные по времени (от 45 минут до двух часов пятнадцати минут) сессии непрерывного тестирования; нормой считаются 90-минутные сессии;
- области покрытия тестами - обычно, это функции продукта, тестированию которых мы намерены уделить некоторое время;
- активности - такие как исследование, обзор, проектирование тестов, генерирование данных, создание инструментов и перепроверка - на которые мы также намерены выделить время;
- контракт в виде одного-трех предложений, описывающих цели и задающих фокус для отдельной сессии тестирования;
- разбор, во время которого тестировщик и его начальник обсуждают результаты сессии;
- легко обозримые результаты в виде таблицы сессий, которые задают основу для разбора, могут быть проанализированы и разобраны с помощью скриптов;
и, опционально,
- снимки экранов, записанные во время сессии, если может потребоваться детальное ретроспективное исследование;
- метрики, цель которых - понять, сколько времени ушло на создание и выполнение тестов (активности, обеспечивающие тестовое покрытие), а сколько на исследование проблем и создание отчетов (активности, прерывающие создание тестового покрытия).
Ограничение по времени позволяет выполнить неточную, но достаточно верную оценку и подсчет. (В чем разница? Если я напишу, что текущее время и дата - 9:43:02.1872 утра 23 января 1953 года, то это очень точное, но абсолютно неверное вычисление времени).
Предположим, цикл разработки длится две недели, или десять рабочих дней, - это обычная длина итерации в Agile. Допустим, у нас в команде четыре тестировщика, и каждый из них может выполнить три рабочих сессии в день (остальное время занимают собрания, почта, перерывы, разговоры и другие активности, не относящиеся к сессиям)
десять дней * четыре тестировщика * три сессии = 120 сессий.
Разумно предположить, что сессии эффективны не полностью, поскольку проектирование и выполнение тестов будет прерываться настройкой и исследованием багов. Допустим, 10% времени уходит на настройку и еще 25% на исследование и описание багов. Всего - 35%, для простоты будем считать, что на это тратится треть времени.
120 сессий - 120 * 1/3 пауз = 80 сессий
Таким образом, по нашей оценке двухнедельная итерация содержит 80 цельных, эффективных, идеальных сессий, включенных в 120 реальных сессий тестирования. Это не точное значение, оно и не может быть точным. Если проектировщики и программисты очень хорошо поработают, мы обнаружим не так много багов, и эффективность покрытия вырастет для каждой сессии. Если настройки окружения неполны, то перерывы могут занять больше трети времени, и эффективность покрытия снизится, либо нам потребуется больше сессий для получения той же степени покрытия. Таким образом, как только мы начинаем получать данные о том, что на самом деле происходит в тестовых сессиях, мы начинаем использовать эти данные для уточнения оценки. Я писал об этом подробнее здесь.
Показатели прерываний и перерывов могут стать важной информацией для руководства. Но помните, что эти показатели сами по себе ничего не решают. Они и не могут этого делать. Вместо этого они поднимают вопросы. Из-за чего исследование багов заняло больше времени, чем ожидалось? Находим ли мы больше проблем, чем ожидали или тестировщики слишком долго исследуют проблемы самостоятельно, прежде чем обратиться за помощью к разработчикам? Может настройка занимает больше времени, чем должна, и клиенты тоже столкнутся с этой проблемой? Если даже проблемы с настройкой возникают только при тестировании, нет ли возможности ускорить процесс, чтобы уделить больше времени тестовому покрытию? Настоящая ценность любой метрики - в вопросах, которые она поднимает, а не в ответах, которые она предлагает.
Желающие оценить длительность цикла тестирования или необходимое количество работников могут использовать и альтернативный подход: определите желаемый уровень покрытия, добавьте известные значения переменных и вычислите остальные. Разбейте продукт на области и сопоставьте каждой из них нужное число сессий в соответствии с рисками, сложностью или любой другой комбинацией параметров, которая вам важна. Отрегулируйте эффективность и число перерывов, отталкиваясь от предположений или предыдущего опыта. Если известно число тестировщиков, вы можете вычислить, сколько времени потребуется; если вы зададите длительность, то сможете определить необходимое количество тестировщиков. Это даст вам быструю оценку.
В которой, конечно, стоит сразу усомниться. Как опыт и умения тестировщика влияют на вашу оценку? На возможные события? Если вы подумываете увеличить число тестировщиков, сможете ли вы обойти закон Брукса? Меняются ли ваши представления о рисках? Верны ли эти представления? И так далее. Хорошо выполненная оценка должна порождать большое количество вопросов. Не беспокойтесь, подлинное тестирование даст ответы на эти вопросы.
Погодите секунду. Мы отдали кучу денег за дорогой инструмент управления тестированием, мы послали всех сотрудников на недельный курс, посвященный оценке тестирования, и теперь мы тратим несколько недель, подготавливая наши оценки. И как только мы начали так делать, наши оценки стали действительно верными.
Если опыт чему-то нас и учит, так это тому, что к любому человеку или процессу, обещающему надежное предсказание будущего, следует относиться скептически. Такие обещания подвержены игровой ошибке и искажению нарратива, основам философии Черного Лебедя. Если мы уже ответили на вопрос "Когда мы собираемся закончить?", то у нас есть возможность (а часто и полномочия) превратить оценку в самоисполняющееся пророчество. Нулевой закон качества Джерри Вайнберга (Jerry Weinberg) ("Игнорируя качество, вы можете удовлетворить любые другие требования") - частный случай моего, более общего, Нулевого закона желательного исполнения: "Игнорируя некоторые параметры, вы можете достичь всего, что пожелаете". Если ваши оценки всегда соответствуют реальности, какие предположения и наблюдения вы отбросили, чтобы приспособить реальность к оценке? И если вы тратите недели на выполнение оценки, то может лучше потратить их на тестирование?
Комментариев нет:
Отправить комментарий