Home

Автор: Michael Bolton
Перевод: Баранцев Алексей

Оригинальная публикация:
Why Is Testing Taking So Long? (Part 1),
Why Is Testing Taking So Long? (Part 2)

Часть 1

Если вы работаете в тестировании достаточно давно, вам наверняка задавали этот вопрос - "Почему тестирование занимает так много времени?" Может быть, у вас есть заготовленный ответ на этот вопрос, а может и нет. Здесь я предлагаю модель, которая, я надеюсь, поможет вам справиться с менеджерами, которые задают подобные вопросы.

Давайте проведём мысленный эксперимент. Предположим, что мы разделили наш рабочий день тестировщика на три сеанса, каждый сеанс – это приблизительно 90 минут сконцентрированной не прерываемой ничем работы. В сумме это составляет четыре с половиной часа тестирования, что выглядит вполне нормально для восьмичасового рабочего дня, прерываемого собраниями, планёрками, общением с программистами, разборами полётов, тренингами, чтением почты, болтовнёй в курилке, приставаниями начальства по разным поводам, перерывами на обед и на кофе.

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

Поэтому давайте также предположим, что каждый наш сеанс разбивается на микро-сеансы средней продолжительностью две минуты, во время которых мы выполняем какие-то действия, сфокусированные на определённом тестовом вопросе, или на оценке определённой функции продукта. Это означает, что за 90 минут мы теоретически можем выполнить 45 таких коротеньких микро-сессий, которые далее для краткости будем неформально называть "тестами". Разумеется, в жизни не всегда всё так идеально просто, тестовая идея может потребовать пару секунд для проверки, а может занять весь день. Но, не забывайте, я лишь моделирую ситуацию, делая значительные упрощения, чтобы максимально наглядно показать динамику этого процесса. (Если вы придерживаетесь реально убогой точки зрения на то, как работает опытный тестировщик, вы можете считать, что две минуты это время, необходимое для выполнения одного "тест-кейса". Но объяснение того, почему следует отказаться от использования тест-кейсов, я оставлю своему коллеге Джеймсу Баху).

Давайте предположим ещё, что мы время от времени обнаруживаем проблемы, это означает, что нужно проводить их исследование и писать баг-репорты. Разумеется, разработчикам важно, чтобы мы сделали это хорошо, но это отнимает время, мешая нам заниматься проектированием и выполнением тестов - той работой, которая наращивает тестовое покрытие. Пусть, скажем, для каждого найденного дефекта мы должны потратить дополнительно восемь минут на исследование проблемы и подготовку баг-репорта. Повторю ещё раз, это очень существенное упрощение. Исследование обнаруженной проблемы может занять целый день, а на подготовку хорошего баг-репорта может уйти не один час. А некоторые баги (грамматические или типографские ошибки в пользовательском интерфейсе) сразу бросаются в глаза и не требуют длительного исследования, так что они, конечно, потребуют меньше восьми минут. И хотя восемь минут, скорее всего, слишком заниженная оценка среднего времени, необходимого для исследования проблемы и написания баг-репорта, давайте остановимся на этом значении. При таких предположениях тест, при выполнении которого не обнаружилось проблем, занимает две минуты, а тест, который выявил проблему, занимает десять минут.

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

И вот в один прекрасный день мы приходим на работу, и видим, что на тестирование поступило три модуля.

Утренний сеанс посвящен тестированию Модуля A, разработанного Командой А. Это совершенно изумительные, гипер-компетентные специалисты. Они пишут тесты для своего кода и практикуют программирование направляемое тестами. Они тесно сотрудничают с нами, тестировщиками, чтобы спроектировать хорошие модульные тесты, тестопригодные интерфейсы, удобное логирование. Они программируют в парах, выполняют перекрестную проверку кода, критикуют работу друг друга, не переходя на личности, и адекватно реагируют на эту критику. Они регулярно выполняют рефакторинг, запускают модульные тесты перед укладкой кода в хранилище. Они чистят зубы по утрам, всегда имеют опрятный вид, и вообще замечательные во всех отношениях люди. Мы прилежно тестируем то, что они пишут, но вообще-то это простая формальность, потому что они и сами всё тестируют, и мы им в этом постоянно помогаем на всём протяжении разработки. За 90 минут сеанса тестирования мы не находим ни одной проблемы. Это означает, что мы выполнили 45 микро-сеансов, тем самым покрытие составляет 45 условных единиц.

После ланча мы принимаемся за модуль, разработанный Командой B. Члены этой команды весьма прилежны. Большинство организаций с радостью приняли бы их на работу к себе. Подобно команде А, они пишут модульные тесты и практикуют направляемое тестами программирование, они тоже делают обзоры кода, работают в парах и сотрудничают с тестировщиками. Но они простые люди. Когда мы тестируем созданные ими продукты, мы время от времени обнаруживаем дефекты, скажем, один раз за сеанс. Тест, который выявляет проблему, занимает две минуты, ещё восемь минут требуется для исследования проблемы и написания баг-репорта. Итого десять минут. В оставшееся время мы никаких проблем не обнаруживаем, то есть за 80 минут успеваем выполнить 40 тестов. Давайте сравним с теми результатами, которых мы достигли в утреннем сеансе.

После небольшого перерыва мы приступаем к тестированию модуля, разработанного Командой C. Это сущий бардак. Команда C состоит из замечательных ребят, полных благих намерений, но их уровень квалификации оставляет желать лучшего. Они вообще не сотрудничают с нами, и сами тоже не тестируют свои продукты. В парах они не работают, обзоры кода не делают. Команда C считает, что если программа скомпилировалась, то её можно отдавать тестировщикам. Модуль C кишмя кишит багами и мы их натыкаемся на них буквально повсюду. Предположим, что за 90 минут сеанса тестирования мы обнаруживаем восемь дефектов.

Каждый такой тест обходится нам в 10 минут, так что на эти восемь багов уходит 80 минут. Несколько выполненных тестов всё таки завершаются успешно, не выявляя никаких ошибок. (Да-да, даже dBase IV иногда работала правильно).

Результаты нашей работы за день выглядят следующим образом:

Из-за обилия багов за 90 минут мы сумели выполнить всего лишь 13 тестов для Модуля C. Тринадцать, тогда как для других модулей мы сумели сделать 45 и 41. Из-за того, что мы потратили кучу времени на исследование проблем и написание баг-репортов, осталось не выполнено 32 микро-сеанса, 32 условных единицы покрытия не были достигнуты для этого модуля. Если мы решим, что нам необходимо выполнить все эти тесты (а качество модуля везде будет таким же низким), нам придётся выполнить ещё по меньшей мере три сеанса тестирования, чтобы достичь нужного покрытия. Либо мы можем на этом прекратить тестирование, но есть немалая вероятность того, что наиболее серьёзные проблемы остались как раз там, в непокрытых частях модуля.

Итак, вот первый вывод, который мы можем сделать из наших наблюдений:

Наличие большого количества багов вызывает либо уменьшение покрытия, либо замедление тестирования, либо и то и другое сразу.

Но есть и ещё кое-что не менее интересное. Если наша работа оценивается по количеству найденных багов (а именно такую метрику зачастую пытаются использовать менеджеры, не понимающие сути тестирования), то Команда А выставляет нас в невыгодном свете - ведь мы не находим у них ни одного бага. Напротив, тестируя продукты Команды С, мы выглядим великолепно с точки зрения руководства. Мы обнаруживаем массу дефектов! Это же классно! Что тут может быть плохого?

С другой стороны, если нас оценивают по достигнутому за день тестовому покрытию (а именно такую метрику используют менеджеры, которые любят подсчитывать тест-кейсы, и эта модель тестирования, пожалуй, даже более разрушительна, чем та, которую используют менеджеры, упомянутые в предыдущем абзаце), тогда мы выглядим ужасно, работая с продуктами Команды С. "Вы бездельники! Вы могли выполнить за день 45 тест-кейсов для Модуля C, а выполнили всего 13!" Да, кстати, не забывайте о том, что мы исходили из предположения, согласно которому мы гарантированно обнаруживаем ошибку, если она есть. То есть для всех трёх модулей нет никакого различия между тестировщиками или способами тестирования, такое огромное расхождение результатов вызвано исключительно различным состоянием тестируемых продуктов.

На этом первая часть нашего мысленного эксперимента закончена. Посмотрим, что принесёт нам завтрашний день.

Часть 2

В первой части этой статьи описан мысленный эксперимент, в котором мы разделили рабочий день на три 90-минутных сеанса тестирования. Было также сделано упрощающее предположение о том, что всю работу по тестированию можно разбить на двухминутные фрагменты, каждый из которых эквивалентен одной условной единице тестового покрытия (мы согласились называть эти фрагменты микро-сеансами, или просто "тестами"). Исследование выявленной проблемы и подготовка баг-репорта занимает восемь минут, так что простое выполнение теста занимает две минуты, а если при этом обнаруживается проблема, то на такой тест расходуется в общей сложности десять минут.

И вот в нашем эксперименте наступил новый день. Вчера мы тестировали три модуля. При этом мы обнаружили несколько дефектов. К сегодняшнему дню все выявленные проблемы устранены, выпущены новые версии модулей, в которых мы должны проверить исправления.

Давайте предположим, что проверка исправления одного дефекта занимает шесть минут. (Это ещё одно значительное упрощение, но без упрощений нам никак не обойтись в нашем мысленном эксперименте). Мы должны не только выполнить заново тот микро-сеанс, в котором была обнаружена проблема, нужно сделать ещё кое-что дополнительно. Нам нужно убедиться, что проблема устранена, а в дополнение к этому мы хотим выполнить небольшое дополнительное исследование, расширяющее исходный микро-сеанс, чтобы проверить, не проявляются ли аналогичные проблемы в других похожих местах, и не вызвало ли это исправление каких-нибудь новых проблем.

Команда B поработала вчера вечером примерно час сверхурочно. Они исправили баг, который мы нашли, сами протестировали исправление и выпустили новую версию. И попросили нас, чтобы мы перепроверили её сегодня. Это отнимает шесть минут от общего времени сеанса, остаётся ещё 84 минуты. Вчерашняя тенденция продолжается - хотя Команда B и весьма хороша, они всё таки обычные люди, так что сегодня мы находим ещё один баг. Выполнение теста занимает две минуты, исследование проблемы и написание баг-репорта ещё восемь, итого десять. За оставшиеся 74 минуты мы успеваем выполнить 37 микро-сессий. То есть всего мы сегодня получаем 38 новых тестов - один выявил проблему и 37 выполнились успешно. Результат за два дня для Модуля B - 79 микро-сеансов.

Команда C трудилась вчера до полуночи. И даже немного больше. Они знали, что это необходимо. Вчера мы нашли у них восемь дефектов, и они решили остаться на работе, пока не исправят их все. (Возможно именно поэтому в их коде так много проблем, ведь они не высыпаются как следует, поэтому делают ещё больше багов, из-за этого им снова приходится работать допоздна, и они снова не высыпаются...) Как бы то ни было, они выдали новую версию, в которой исправлены все восемь дефектов, поэтому мы начинаем сегодняшний сеанс с проверки исправлений. Восемь проверок по шесть минут каждая занимают 48 минут. И если посмотреть на прирост покрытия, становится ясно, что сегодняшняя 90-минутная сессия не задалась с самого начала, потому что 48 минут (а это больше половины времени сессии) ушло на проверку исправлений, то есть потрачено бездарно. У нас осталось 42 минуты для выполнения новых микро-сеансов, этих коротких двухминутных кусочков, которые мы используем как метрику покрытия. Для Модуля C тоже сохраняется вчерашняя тенденция, поэтому мы обнаруживаем четыре проблемы, требующие исследования и подготовки баг-репортов. На это уходит 40 минут из тех 42, которые остались в нашем распоряжении. Ну и ещё по ходу дела удалось выполнить один двухминутный тест, который не выявил никаких проблем.

Подведём итоги сегодняшнего дня:

За два дня для Модуля C мы сумели достичь только 20% тестового покрытия по сравнению с тем, что мы сумели сделать для Модуля A. И менее четверти по сравнению с покрытием для Модуля B.

Вчера мы с вами вывели такой закон:

Наличие большого количества багов вызывает либо уменьшение покрытия, либо замедление тестирования, либо и то и другое сразу.

Сегодняшние результаты позволяют сделать ещё один вывод:

Если вы нашли баги, значит впоследствии вам придётся проверять их исправление, что ещё сильнее уменьшает тестовое покрытие, или замедляет тестирование, или делает и то и другое сразу.

Так почему же тестирование занимает так много времени? Одна из основных причин такова:

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

Или, в более общем виде:

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

Для менеджеров, которые задают вопрос "Почему тестирование занимает так много времени?", типично использование модели тестирования, в которую не включаются элементы, находящиеся вне сферы контроля тестировщиков. Глядя на описанные выше два дня тестирования, можно видеть, что различие в качестве продуктов, выпущенных Командой A и Командой C, имеет колоссальнейшее влияние на то, какой объём работы по проектированию и выполнению тестов мы в состоянии выполнить. Наличие дефектов в Модуле C приводило к прерыванию наращивания покрытия, в результате чего (в нашей упрощенной модели) мы смогли посвятить проектированию и выполнению тестов только пятую часть времени. После первого дня мы уже сильно отставали, а после двух дней отставание ещё увеличилось. И, заметьте, мы были весьма оптимистичны. Как вы думаете, с командой типа Команды С, какая часть исправлений будет сделана правильно, так чтобы это не вызвало новые проблемы, также требующие дополнительного времени на исследование и описание?

Ещё раз повторю - если менеджеры используют описанные выше ошибочные модели, это приводит к искажениям или дисфункциям. Если качество тестирования измерять количеством найденных багов, тогда те, кто тестирует Модуль C, будут выглядеть хорошо, а те, кто тестируют модуль A, будут выглядеть ужасно. Но если качество тестирования оценивать по достигнутому покрытию, тогда тестировщики Модуля A будут выглядеть ударниками производства, а тестировщики Модуля С кандидатами на увольнение. Но ведь различия в результатах, описанные выше, не имеют вообще никакого отношения к качеству тестирования, они полностью определяются исключительно различным качеством тестируемых продуктов.

Имеется также немаловажный психологический фактор. Если мы используем подход к тестированию, основанный на идее подтверждения, с предписанными шагами, которые нужно выполнить, и предсказанными ожидаемыми результатами, мы будем проектировать наши тесты, отталкиваясь от представления о том, что продукт должен делать то-то и то-то, вести себя так-то и так-то, и в результате тестирование будет протекать в предсказуемой форме. В этом случае возможно (по крайней мере, мне так кажется), что мы будем склонны уделять большую часть внимания ожидаемому и избегать неожиданного. Если мы используем подход к тестированию, в основе которого лежит исследование и свободный поиск, мы, вероятно, всегда будем делать допущение, что мы до известной степени не знаем, что именно мы собираемся найти. Несмотря на то, что менеджеры, специалисты по количественным подходам и любители процессов хотели бы сделать тестирование и поиск багов предсказуемым, никто не знает, как сделать так, чтобы эта предсказуемость выдерживала столкновение с человеческим непостоянством и сложностью мира, в котором мы живём. Кроме того, если вы можете предсказать наличие проблемы, зачем вообще ждать, пока тестировщики её найдут? Если вы на самом деле можете предсказать это, сделайте что-нибудь прямо сейчас, чтобы этого не случилось. А иначе это получается просто игра в цифры.

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

• Мы допустили, что работу по тестированию можно разбить на независимые двухминутные кусочки, опасно приблизившись при этом к бесполезной и даже вредной модели тестирования как разработки и выполнения тест-кейсов
• Мы не говорили о том, какую роль играет этап подготовки, и какое влияние он оказывает на проектирование и выполнение тестов.
• Мы проигнорировали возможные неприятности, связанные с тем, что тестировщикам приходится ждать, когда они смогут, наконец, начать работать, если продукт не собирается или не устанавливается.
• Мы не учли время, которое тестировщики тратят на ожидание исправлений.
• Мы не включили в рассмотрение задержки, связанные с тем, что иногда дефекты блокируют некоторые возможности продукта, препятствуя тем самым тестированию части функциональности.
• Мы намеренно проигнорировали вопросы, связанные со сложностью тестируемых продуктов.
• Мы оставили в стороне всё, связанное с возможными проблемами при изучении предметной области.
• Мы сделали сильно упрощающие предположения о качестве и уместности тестирования, качестве баг-репортов, квалификации тестировщиков, и т.д.
• И ещё – я ни словом не упомянул о том, что при поиске ошибок фортуна играет не менее важную роль, чем квалификация.

Я всего лишь ставил перед собой цель показать, что:

Наличие проблем в тестируемом продукте оказывает огромное влияние на нашу возможность обеспечить хорошее тестовое покрытие для этого продукта.

Увы, даже эта крайне простая мысль оказывается выше понимания многих менеджеров. Почему так много менеджеров не замечает этого? Я думаю, одна из причин в том, что они приучились воспринимать процессы в виде линейных моделей, а не органических, об этой проблеме Джерри Вайнберг писал в книге Becoming a Technical Leader. Линейные модели "предполагают, что наблюдатель имеет полное понимание задач", пишет Джерри. Но разработка компьютерных программ не такова, и быть такой не может. По своей природе она связана с вещами, с которыми нам раньше не приходилось иметь дела (в противном случае не было бы необходимости разрабатывать новые продукты, можно было бы просто переиспользовать уже существующие). Мы постоянно имеем дело с новизной, неопределённостью, с чем-то неопробованным и неиспытанным, поэтому наше понимание неизбежно неполно. Если мы откажемся признать это, мы вряд ли сможем улучшить качество и значимость нашей работы.

Но что ещё хуже, так это то, что менеджеры, использующие линейную модель разработки и тестирования "фильтруют наши инновации, которые они ранее не встречали или не могут понять" (это вновь цитата из книги Becoming a Technical Leader). В качестве противоядия для таких менеджеров я рекомендую, например, книги Perfect Software, and Other Illusions About Testing и Lessons Learned in Software Testing. Но главным образом я бы посоветовал им просто наблюдать за тестированием. Чтобы успешно справиться с этой задачей, им может потребоваться наша помощь, а это означает, что мы сами тоже должны научиться наблюдать за своей работой. Поэтому в ближайшее время я чуть подробнее чем обычно расскажу о технике управления тестированием на основе сеансов (Session-Based Test Management), разработанной первоначально Джеймсом Бахом и Джоном Бахом, которая представляет собой мощный комплекс идей, инструментов и процессов, нацеленных на наблюдение за тестированием и управление тестированием.

Обсудить в форуме