Home

Автор: Мартыненко Сергей

Оригинальная публикация: Часть 1, Часть 2.

Часть первая, рациональная

Эта часть статьи написана по мотивам доклада на первой конференции русскоязычного комьюнити тестировщиков 21 апреля 2007.

Под автоматизированным тестированием в этой статье понимается только и исключительно функциональное тестирование через GUI при помощи одного из инструментов: Rational Robot, QTP, TestComplete (священная корова, примерно соответствующая Oracle у DBA). Сделано это для того, чтобы не писать во всей статье оговорки.

Выбор  регрессионных автоматических тестов

Для предотвращения «расползания» кода и раннего обнаружения ошибок широко применяется практика ежедневного тестирования в автоматическом режиме.

В мировой практике наиболее распространены следующие виды тестов:

• Ежедневная сборка
• Тесты компонент
• Юнит тесты
• Тесты приложения через GUI (с помощью специализированного инструмента тестирования, такого как QTP, TestComplete,Rational Robot,\ и т.д.)

Ежедневная сборка. Является тестом с наибольшим ROI. Кроме того, этот тест является базисом для прочих тестов. Соответственно она будет внедряться первой.

Тесты компонент (в терминах RUP – модульные). Проводятся через API компонента и позволяют полностью проверить его функциональность.

Юнит тесты. Пишутся на методы отдельных классов или на функции. Рекомендуемое покрытие 70-80%. Данный вид тестов является скорее средством создания, отладки и рефакторинга кода, нежели собственно тестирования, но ничто не мешает использовать их для регрессионного тестирования.

Тесты приложения через GUI. Позволяют полностью протестировать приложение. К недостаткам этих видов тестов нужно отнести:

• Высокую трудоемкость создания и поддержки
• Неустойчивость к изменениям интерфейса

Это приводит к тому, что по заверениям экспертов только 5-15% ручных тестов имеет смысл автоматизировать.

Проведем простой расчет. Пусть фирма специализируется на небольших (до десяти человеколет) проектах.

• Разумные расходы на тестирование будут порядка 20-30%. Пусть 30%.
• Расходы на прогон тестов 30% (цифры озвучены Вячеславом Панкратовым) от бюджета тестирования или 9% от бюджета проекта.
• Затраты на прогон тестов, которые имеет смысл автоматизировать может достигать четверти. Или ~ 2% от бюджета проекта.
• Если в фирме, годовой бюджет всех проектов 1 000 000$, то уменьшение за счет подобной автоматизации будет касаться всего 20 000$, а выигрыш может достигнуть даже 5 000$. Это слезы. При большем бюджете подобная автоматизация уже может быть оправдана. (Вячеслав обещал привести свой расчет).

Но самое главное, существует очень много возможностей потратить эти деньги с большей отдачей. На конференции коллеги  совершенно справедливо заметили, что бюджет тестирования нельзя тратить на другие направления. Но ведь и в тестировании есть возможность потратить с большей пользой:

• Изучение продукта
• Разработка стратегии
• Создание сценариев
• Критические пересмотры дефектов
• Обучение

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

Теперь немного о личном опыте. У нас довольно большой (по меркам РФ) бюджет и он будет только расти. Проекты «долгоиграющие» и относятся, скорее, к большим, чем к средним. Однако мы столкнулись еще с одним ограничением инструментов:

• Плохая поддержка библиотек для разработки интерфейсов сторонних разработчиков. Так, на данный момент, только TestComplete поддерживает библиотеку DevExpress и то не в полном объеме. А элементы управления ArcGis не поддерживаются никем.

Последнее делает для нас нецелесообразным автоматизацию этих видов тестов. По крайней мере, сейчас.

Часть вторая, отчаянная

Эта часть статьи написана примерно год спустя, поскольку в течение года тема неоднократно обсуждалась на форуме снова и снова. И наверное будет обсуждаться несмотря ни на что и в дальнейшем.

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

И соотношение эффективности между нашими и зарубежными компаниями вполне может быть не настолько удручающе. И вообще бывают разные наши и разные зарубежные компании.

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

Я думал, что моей статьи об автоматизированном тестировании с самого нуля (см. первую часть) и замечательного доклада Дмитрия Ручко о мифах в тестировании будет достаточно для того, чтобы люди с высшим образованием могли не наступать по сотне раз на одни и те же грабли. Но видимо нет. Не достаточно. Ладно, попробуем убедить уважаемую аудиторию цифрами. Может получится. А может и нет.

Рассмотрим две не большие и не маленькие, а средние компании с разной степенью эффективности. Годовой оборот пусть будет скромные 50 млн. долларов. Для простоты компании будет исключительно софтверные. Т.е. не занимающиеся интеграцией ПК с принтерами, не оказывающие услуги по записи интернет на дискету и т.д. Компании просто разрабатывают софт. На заказ или коробочный – не важно. Оборот небольшой и в ихней компании будет работать несколько десятков человек. Для определенности пусть будет сто. В нашей компании масштаб будет другой. У нас в компании с таким оборотом может работать до тысячи человек. [1]. У нас вообще любят масштаб. Ну, пусть будет 500.

Расходы собственно на разработку (аналитика, архитектура, кодирование, тестирование, документирование, …) составят по грубой оценке до 25 млн $ в ихней компании и 10 млн $ у нас [2]. Из них на тестирование уйдет процентов 20 и 10% у нас [3]. Итого пять миллионов долларов на тестирование у них и один у нас. На прогон тестов тратится порядка 30% бюджета отдела тестирования [4]. Полтора миллиона и триста тысяч соответственно. Из этого есть некое количество прогонов, которые в принципе экономически выгодно автоматизировать. Ну, пусть половина. Итого наше операционное поле это 0.75 миллиона и 150 тысяч. Такую чистую экономию мы получим, если прилетят добрые инопланетяне и в порядке гуманитарной помощи будут всегда все делать бесплатно. Заметьте, это максимум. Т.е. в принципе максимум. Так конечно не бывает. Пусть после внедрения мы получим снижение издержек на прогон тестов в три раза. Выигрыш – 500 000 и 100 000. Чтобы посчитать ROI нам еще понадобится посчитать единовременные затраты.

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

У них покупаются лицензии (пусть даже QTP за $10 000), люди отрываются на пару недель от работы (очень приличная цифра, до $20 000 потерь) и оплачиваются серьезные тренинги (еще 3 000). Ну, то есть, примерно $130 000 единовременных вложений. Очень неплохой результат для зрелой фирмы. Вложить 130 тысяч, для получения ежегодной экономии в один процент от пятидесятимиллионного оборота – это очень нехило. А при более-менее стандартной норме прибыли в 20% от оборота это означает увеличении прибыли на 5%. Когда же наступит этот благословенный миг? Я полагаю, что тогда, когда более эффективные практики повышения прибыли уже выбраны. Здесь удобно воспользоваться пузырьковой диаграммой (смотри http://www.pcweek.ru/themes/detail.php?ID=103400).

Вот где-то в секторе синих пузырьков и находится «Внедрение Автоматизированного Тестирования»
Если же дополнительно воспользоваться диаграммой зависимостей, то, как справедливо отмечают коллеги, сначала обязательно нужно «Внедрить Тестирование». Пока мы не пройден «тест Гринкевича», будем считать, что процесса тестирования у нет и к автоматизации переходить бессмысленно. Кроме того необходимо, чтобы к этому моменту был наведен порядок в проектировании интерфейса, структур данных и в аналитике. Иначе вместо сокращения расходов получим бесконечную переделку тестов и, как следствие, сужение тестового покрытия. Т.е. путь непрерывных улучшений будет долог. IMHO время для «Автоматизированного Тестирования» может наступить тогда, когда пятилетние юбилеи пребывания на своем посту простых инженеров давно стали обыденностью, да и десятилетние юбилеи никого особенно не удивляют.

Для наших фирм характерным сроком работы является 1.5-2 года. А уходя, инженер уносит с собой часть компетенции фирмы и процессы приходится ставить с нуля. Получается что до автоматизированного тестирования мы вообще никогда не доберемся? Нет, что вы, у наших самураев свой путь пожирания кактусов. Закончим расчет. Напомню, нам нужно укомплектовать 20 рабочих мест и обучить 20 специалистов. Для «сокращения стоимости лицензий» нормальный пацан пойдет на горбушку и купит TestComplete или RR за десять баксов. Это позволит очень сильно сэкономить деньги на внедрении. Чтобы еще немного сэкономить, предоставим возможность тестировщикам самим разобраться с инструментарием. Книги естественно покупать тоже не будем. Таким образом, мы получим всего-навсего  отрыв от производства на три месяца, и убытки компании в $15 000 [5] на человека или $300 000 на всех. В общем, то не так и много. Вложить 300 и получать ежегодную прибыль в 100 тысяч может и не такая плохая перспектива. Я даже не буду учитывать необходимость увеличения зарплаты автоматизаторам для уменьшения текучки [6]. Но если учесть риски, то вкладываться в такой проект я бы не стал.

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

Пусть есть маленький проект. Всего на нем 2 000 тестовых сценариев. Для достижения приемлемого уровня контроля качества с заданным доверительным интервалом (90% уровень бездефектности при доверительном интервале одна сигма [7]) необходимо выполнить 12 000 тестовых прогонов. Пусть есть 200 тестов, требующих более 15 прогонов с общей суммой прогонов 6 000. Их и решено автоматизировать. После автоматизации появляется желание запускать их часто. Пусть даже каждый день. В результате вместо 6 000 прогонов получаем 60 000. Это, в принципе неплохо. Это даже может улучшить доверительный интервал до одной целой и одной десятой сигма. Но только если при этом не произойдет уменьшения числа ручных прогонов. Если в результате бесконечной переделки автоматизированных тестов произойдет уменьшение тестовых прогонов выполняемых вручную «всего» на тысячу, то у нас резко падает уровень бездефектности. Хотя формально будет выполнено больше прогонов (60 000 + 5 000 = 65 000 вместо 6000+6000=12000).
- Мы гоняем наши десять тестов  на пятнадцати тысячах конфигураций.
- Круто. А зачем?
- Так можно же.
- Можно. Но незачем выдавать количество прогонов за качество тестирования?
К сожалению, проверить качество покрытия не удосуживаются. И проверяет его уже клиент.

Можно, правда, придумать неплохой вариант отдачи от внедрения автоматизации даже в условиях абсолютного хаоса в разработке. Бывает так, что сертификаты ISO и CMMI иногда приносят прибыль сами по себе, вне зависимости внедрялись они или нет. Достаточно, да, честно говоря, и лучше, если о внедрении ISO, CMMI сотрудники узнают случайно, обнаружив на стене приемной соответствующий сертификат. А что? И клиентам нравится, и сотрудники не пострадали.

Так что если, вы получили контракт на распил стабфонда написание россейской операционной системы для МК-152 [8]. И вам срочно надо обеспечить хороший откат себе любимому увеличить эффективность работы команды. То вы находите продавца гербалайфа вендора средств автоматизированного тестирования и говорите ему: «А давай мы с тобой немного денег попилим полюбовно интенсифицируем ускорение развития прогресса улучшения эффективности труда!». И все, вы нашли друг друга! В конце концов, и вашим и его детям кушать надо. А фирма переживет, денег в стабфонде хватит.

Заключение.
Я не считаю, что автоматизированное тестирование полностью неэффективно. Но я против создания и возвеличивания «Священной коровы». Основные мысли этой статьи таковы:

• Существует множество способов повышения эффективности разработки ПО. Для их поиска можно пользоваться диаграммами Исикавы и Парето, методом пяти Why? и т.д и т.п.
• Выбирать порядок улучшений следует, в том числе и на основе расчетов экономической целесообразности. Фразы типа «автоматические тесты выполняются автоматически» или «компьютер считает в миллион раз быстрее, чем бухгалтер на счетах, и купив ПК мы увеличим производительность бухгалтера в миллион раз» за отмазку не канают. Только конкретный расчет для конкретной ситуации. В деньгах. И расчет необходимого тестового покрытия.
• Автоматизация тестирования – это проект с небольшим ROI и дает малый выигрыш в процентном отношении от бюджета организации.
• Существуют (и их много) способы вложения денег, которые дают больший выигрыш, как в процентном, так и в количественном выражении. В том числе способы вложения денег как конкретно в тестирование, так и в разработку в целом.
• И наконец. Если у вас есть проблема с качеством ПО и вы приходите консультанту, а он предлагает вам внедрить «Священную корову», то нужно стукнуть этого консультанта чем-нибудь тяжелым и начинать искать другого.

———————————————————————————-
[1] Я действительно не понимаю, почему голландская компания CityGIS, выпускает обалденный софт, имея в штате всего два с половиной десятка человек. У нас понадобилось бы минимум на порядок увеличить число сотрудников.

[2] Необходимость выкидывать деньги на сауны, откаты, шикарные кабинеты, банкеты, презентации и т.д. вместо покупки нормальных рабочих станций и серверов меня всегда смущала, но … «Это наша Родина, сынок». Смотри «Жизнь в пузыре» Ашманова.

[3] Цифры условны. Очень зависит от типа проектов. Давайте предположим, что существуют проекты, для которых это так. А разница в два раза между расходами на тестирование там и здесь возникла из простого понимания, что, почему то там качеству уделяют большее внимание. Да, и у нас есть очень неплохие продукты. Да, и у них есть отвратительные. Но, в целом, сальдо не в нашу пользу.

[4] Считается, что при ручном тестировании только треть времени тратится на прогон. Остальное уходит на разработку стратегии, плана и тестовых сценариев, фиксацию ошибок в бактрекере, верификацию ошибок, анализ результатов, …Если это сильно не так, то стоит задуматься о делах в консерватории.

[5] К убыткам компании я отношу недополученную прибыль. Сколько денег принес бы этот инженер, если бы работал, а не занимался ерундой? Один из вариантов расчетов – это умножение зарплаты на 4-5. Приведенная цифра потерь еще занижена. Реально фирма может терять от простоя специалиста тестировщика до 500 долларов за один рабочий день (Москва 2007).

[6] Не знаю почему, в нашей стране принято платить зарплаты не в зависимости от вклада в успех, а от названия должности. Так же я не совсем понимаю, откуда пошло поветрие, что опытный аналитик должен получать меньше начинающего кодера, а опытный дизайнер тестовых сценариев меньше начинающего кодера автоматических тестов. Но факт остается фактом. Изменение записи в трудовой с «инженер по качеству» на «разработчик автоматизированных тестов», вызывает желание сотрудника получать процентов на тридцать больше. В этой же фирме или в другой – это не важно.

[7] Так действительно можно считать. Но это трудоемко. Соответственно, так обычно не делают, особенно на мелких проектах. Ну, не осмечивать же строительство скворечника. Хотя если поставить производство скворечников на поток…
Если не ошибаюсь механика расчетов неплохо изложена в «6 сигм», ну, или теорвер, или финансовый аудит.

[8] Это конечно шутка. Хотя после появления нашего программируемого калькулятора, отставшего от зарубежных аналогов всего на 23 года и стоящего «всего» 250$, я уже ничему не удивлюсь.

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