В чем разница между завершением и прекращением тестирования? Как выбрать стратегию тестирования и верно рассчитать трудозатраты? Своими мыслями о разных подходах к управлению тестированием поделится Александр Александров, эксперт по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов Luxoft, кандидат физико-математических наук.
В чем разница между завершением и прекращением тестирования? Как выбрать стратегию тестирования и верно рассчитать трудозатраты? Своими мыслями о разных подходах к управлению тестированием поделится Александр Александров, эксперт по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов Luxoft, кандидат физико-математических наук.
Я обдумываю эту тему последний год, и я не знаю ответа на многие вопросы. С год назад для меня было неожиданностью узнать, что не для всех очевиден тезис: «Исчерпывающее тестирование невозможно». У меня спросили: «А почему?», и я сослался на книгу Гленфорда Майерса «Надёжность программного обеспечения», где приведен пример. Другой источник для аргументов: силлабус ISTQB, где написано, что исчерпывающее тестирование невозможно. Еще один источник — следствие из определения машины Тьюринга, что алгоритмически неразрешима проблема завершения её работы (и так далее) — стандартный курс теории автоматов про это говорит. Наконец, здравый смысл: все мы тестировщики (или все, кто не тестировщики, но, очевидно, хотят ими стать, потому что другого пути развиваться у человечества, конечно, нет☺), у нас есть опыт тестирования и понимание того, что невозможно написать ВСЕ тест-кейсы и выбрать ВСЕ тестовые данные, нельзя пройти ВСЕ пути в коде и выполнить ВСЕ действия, которые может делать пользователь и так далее, и так далее.
Вроде бы абсолютная истина, но вопросы на эту тему появляются снова и снова на самых разных уровнях и особенно на уровне топ-менеджмента:
А как на эти вопросы отвечать? Они все подразумевают исчерпывающее тестирование, которое мы не можем провести. Как выходить из положения?
Возникает следующая тема: критерии тестирования. Практически любые критерии завершения тестирования должны содержать что-то вроде:
Обратите внимание на слова «затраты» и «выгода» в этом списке. В конечном итоге, если для того, чтобы исправить дефект, нам надо потратить денег — универсального мерила работы и результата — больше, чем ущерб, который нанесёт дефект, то этот дефект исправлять не надо. С этим фактом трудно смириться, потому что он имеет далеко идущие последствия.
Что это означает с точки зрения выстраивания стратегии тестирования? Тестирование нельзя завершить, его можно только прекратить, поэтому нужны какие-то критерии прекращения тестирования — они, в том числе, и экономические, а не только технологические. Я бы взял на себя наглость заявить, что они только экономические, но эта формулировка, наверное, устроит не всех. И в этом принципиальное отличие того, чем занимаемся мы, тестировщики, от того, что делают разработчики:
Разработчики могут сделать всё. Они могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» — например, два с половиной месяца. А почему? А потому, что там 18 функций, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты? А сколько времени нужно тестировщику, чтобы написать все тест-кейсы? А сколько времени нужно тестировщику, чтобы проверить всю функциональность? Никакого времени не хватит. Значит мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.
Мы должны оценить трудозатраты на тестирование, но не трудозатраты вообще, а те, которые нам нужны для достижения вполне определённого эффекта. Необходимо уметь планировать момент, когда следует остановить тестирование, и достоверно ожидать, что при этом получается с системой.
Пример: «Если потратить столько-то человеко-часов, получится приемлемое качество (не очень много дефектов останется). А если потратить меньше, то качество будет хуже (больше дефектов останется)». Это значит, что если мы потратим 5 000 ч/часов, то мы найдём 97% дефектов, а если мы потратим меньше, то мы найдём меньше дефектов. В такой формулировке мы можем говорить, как нам организовать тестирование — конечно, при определённой зрелости процессов разработки.
И тут можно было бы остановиться. Мы знаем чисто технически, на что расходуются трудозатраты на тестирование:
Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги — мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Качество.
Давайте рассмотрим анатомию процесса планирования.
Надо планировать так, чтобы затраты были реалистичными (укладывались в бюджет проекта) и эффективными (давали бы ожидаемый результат). Если мы пообещаем, что нам нужно 5 000 ч/часов, а за эти 5 000 ч/часов мы что-то протестируем, то нам головы открутят, и, естественно, извинения после этого приносить не будут. Если мы пообещаем, что мы гениальные тестировщики и за три дня найдём все дефекты, то нам тоже головы открутят, но позже, когда не обнаруженные дефекты выскочат на продакшн. И тогда зачем обещать? Ведь за свои слова надо отвечать.
Значит, необходимо пользоваться методами и моделями оценки трудозатрат на тестирование (я рассказывал об этом в 2011 году на SQA Days в Москве в докладе «Оценка трудозатрат на тестирование в проектах сопровождения»). На основании полученных оценок планируются активности по тестированию. Необходимо также отслеживать процесс тестирования, чтобы вовремя обнаружить отставание от плана и скорректировать его.
Итак, предположим, что мы оценили трудозатраты абсолютно корректно, после чего нам выделили нужное количество человеко-часов, и мы всё сделали. Но поскольку в жизни так не бывает, нам надо понять, что может быть, если что-то пойдёт не так.
Мы можем недооценить трудозатраты на тестирование. Мы можем их недооценить с самого начала. Например, мы запросили 5 000 ч/часов, а их в проекте нет, и нам предлагают — возьмите 3 500 ч/часов и как-то выкручивайтесь. Что ж, давайте крутиться. Другой пример: в проектах всегда что-то меняется, от требований до моды и платформы. Все эти изменения могут привести к ухудшению качества объекта тестирования, потому что первоначальный план у нас есть, но если он стал неактуальным, то его нет. Оценка оказалась заниженной или обстоятельства изменились — всё бывает, и всё это может привести к ухудшению качества объекта тестирования, когда не хватает возможностей протестировать всё, что планировалось, и с качеством, которое планировалось. Что и как здесь можно делать и какие нас ждут подводные камни?
Почему бывает недооценка? Например, недооценён бюджет всего проекта. Бывает, что стоимость ресурсов неожиданно высока. Например, мы закладывали в проект, что у нас начинающие тестировщики будут писать тест-кейсы. Я (и надеюсь, не только) очень хочу посмотреть на начинающего тестировщика, который умеет писать качественные тест-кейсы. Я таких людей за всю свою жизнь не видел ни разу. Ясно, что за ними придётся дописывать и переписывать.
Недооценка трудозатрат бывает также из-за отсутствующих или несовершенных процессов. У нас велика роль человеческого фактора, и выполнение нашего проекта зависит от того, кто и что будет делать. И даже если у нас будет стабильная команда — это все еще идеальный сферический конь в вакууме, ведь у человека бывает разное настроение, он может что-то решить, а потом передумать, в результате чего мы все — компания, проект, тестировщики, заказчик — становимся заложниками ситуации. Для того, чтобы надежно планировать работу, надо иметь совершенные процессы.
Недооценка трудозатрат на тестирование часто приводит не к изменению стратегии тестирования, а лишь к увеличению трудозатрат (дополнительному времени, персоналу и др.) и, как следствие, к увеличению сроков и/или стоимости проекта. Или мы недооценили трудозатраты, или нам их недооценили — что делать? «Дайте нам то, чего нам не хватает! Да, мы получили оценку в 3 500 ч/часов, но поскольку всё пошло не так, нам надо ещё. Нам надо больше людей и времени». Чем это плохо? Мы выходим за обещанные рамки, за сроки и за стоимость, а для заказчика ничего хуже этого не бывает, потому что ложка дорога к обеду. Если вы сделаете работу в срок, но плохо — это неприемлемо, если сделаете хорошо, но на полгода позже — подумайте, что хуже.
Рассмотрим несколько кейсов.
Мы участвуем в тендере. Мы оценили трудозатраты на тестирование в 500 ч/часов. Получилось дорого, поступает указание урезать трудозатраты, но разработчиков урезать нельзя! При таких трудозатратах проект продать нельзя, поэтому уменьшили тестирование до 300 ч/часов. Дальше — больше. «Непонятно, что в проекте делают тестировщики. Если они поставляют ПО с дефектами — от этого проекту только хуже. Если они тест-кейсы пишут — да кому эти тест-кейсы нужны?!». Мне приходилось эту фразу слышать от топ-менеджмента неоднократно.
Хорошо, мы согласились на 300 ч/часов. Как мы это сделаем за 300 ч/часов — мы не знаем. Но мы согласились с этой оценкой, пообещав тем самым сделать все в полном объеме со всеми артефактами. И вот эти часы исчерпались. Дальше что? Чудес не бывает: либо тестирование останавливается, что для проекта губительно с технической точки зрения, либо тестирование продолжается себе в убыток, и приходят грозные дяди из финансового подразделения и спрашивают, почему компания несёт убыток. А если к тому же компания торгуется на бирже, нам говорят «вы показываете низкую маржу, от нас побегут инвесторы». Качество проекта непредсказуемо.
Сколько раз мы говорим это заказчику? Заказчик воспринимает это буквально, и начинает требовать любой каприз за свои деньги. Проект выполняется по модели fixed price, потому что все стремятся минимизировать затраты, начинаются изменения, повторное тестирование, мы получили свои 500 ч/часов, мы их честно израсходовали, потому что мы подписались под «ваши капризы» и всё — результат печальный. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.
Мы оценили трудозатраты на тестирование в 500 ч/часов и получили согласие на эти трудозатраты. У нас есть команда, и мы начинаем тестировать, не заботясь о приоритетах и целях, мы тестируем всё, что под руку попадается, потому что всё это заказчику нужно — он же сам нам об этом сказал. Мы заказчика очень любим и хотим сделать работу хорошо, но вот 500 ч/часов исчерпались. А что происходит с приложением, когда эти 500 ч/часов исчерпались? А бог его знает. Что-то протестировано, что-то нет, где-то написаны скрипты автоматизации, которые, правда, ничего не находят, но они же написаны. Регрессионное тестирование с помощью автоматизации — это такая фишка, которая с одной стороны, может ничего не дать, а с другой стороны, деньги жрёт так, как никакая новая иномарка не сможет. Тестирование либо останавливается, либо продолжается себе в убыток. Качество проекта непредсказуемо.
Да, мы профессионалы, нас много, мы команда, мы всё можем. Все тестировщики, которые есть в компании, поставлены «под ружьё», мы выполняем тестирование так, как можем — да, не хватает квалификации для тест-дизайна, зато у нас огромное количество новичков, но они ретивые, они по выходным работают. Тестирование заканчивается в момент окончания проекта. А чем оно закончилось? А бог его знает. Как карта ляжет. Карта, как правило, ложится плохо. Качество проекта непредсказуемо.
Поговорим о том, в чём разница между 1.0 и 2.0, Версия 1.0 — это парадигма, в которой, к сожалению, мы с вами сегодня работаем. Нам дали сколько-то ресурсов, а теперь мы должны дать результат. Почему всё так устроено? А потому, что мы знаем, как эти ресурсы использовать. К примеру, мы знаем, что из 500 ч/часов 200 мы потратим на написание тест-кейсов, 100 на автоматическое тестирование и 200 на ручное — но это всё в идеальном мире, если не будут радикальных изменений, все тестировщики будут прекрасно работать, и так далее. А если мы обосновываем оценку, показываем ее реалистичность и эффективность, и будем оценивать все риски, то за эту оценку, уж извините, любой нормальный менеджер проектов открутит вам голову, ибо ему непонятно, почему тестировщики должны ошибаться — они же тестировщики! Это разработчики могут ошибаться, но, чтобы тестировщики — никогда.
В итоге у нас получается план, который «отлит в граните», и мы всё время пытаемся удержаться в рамках этого плана.
А что такое Версия 2.0? Вот мы получили оценки. Эти оценки играют роль запасного парашюта. Это то, как мы будем работать, если у нас ничего более эффективного не получится. Но Версия 2.0 говорит нам о том, что надо использовать обоснованные трудозатраты эффективно, анализируя проектную ситуацию. Мы будем писать тест-кейсы? Если будем, то какие? Какие тестовые данные мы будем использовать и где мы будем их брать? От заказчика? Свои? Какие нам нужны тестировщики — мало сильных (но дорогих) или много слабых (зато недорогих)? Нам нужна стабильная команда для данного проекта или нет? Нужна нам автоматизация вообще, и если да, то какой инструмент, какое покрытие должно быть обеспечено?
Если для Версии 1.0 критерии — это возврат инвестиций в трудозатраты (ROI), то для Версии 2.0 критерий — это максимизация выгоды. И это разные вещи.
Основные тезисы
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Часы, заказчики, тест кейсы, количество ч/часов... Как будто вернулся в outsource в начало 10-х годов.
Как насчёт подумать о качестве продукта или сервиса? Которое заключается не только в количестве найденных багов. Как насчёт нефункциональных требований? Как насчёт ответственности всей команды в обеспечении качества, при котором может не быть отдельных людей, назначенных ответственными за его обеспечение, вместо этого выстраивание процессов таким образом чтобы оно обеспечивалось с самых ранних этапов, с одной стороны, и на проде с другой стороны? Shift left, shift right, все подобное в индустрии давно не первый год.
Если это рекламная статья, то больше похоже на антирекламу.