Автоматизированное тестирование с нуля. Часть 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 не поддерживаются никем.
Последнее делает для нас нецелесообразным автоматизацию этих видов тестов. По крайней мере, сейчас.