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

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

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

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

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

  • Ежедневная сборка
  • Тесты компонент
  • Юнит тесты
  • Тесты приложения через 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 не поддерживаются никем.

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

 

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

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