Автоматизированное тестирование с самого нуля. Часть 2.

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

Рецензент: Александр Лобач

Дисклаймер. Я не злой. И никого не хочу обидеть. И вообще это читать не обязательно. Ибо:
«Все истины, которые я вам хочу сообщить – гнусная ложь».

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

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

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

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

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

Рассмотрим две не большие и не маленькие, а средние компании с разной степенью эффективности. Годовой оборот пусть будет скромные 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$, я уже ничему не удивлюсь.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.