Все потому, что модульное и компонентное тестирование проверит соответствие работы кода спецификациям. Но бизнес-логику, причем в том виде, в котором это будет видеть потенциальный потребитель, никакое модульное или компонентное тестирование не проверит. Не тот уровень абстракции.
Собственно, именно компонентное тестирование применяется именно для тестирования бизнес логики. В SOA на этом вообще можно построить значительную часть тестинга. И VS2005 очень неплохой инструмент для компонентного тестирования. Конечно имеет свои недостатки по сравнению с тем же nUnit. Но имеет и свои плюсы. Это примерно равные инструменты. Человек работающий на такой автоматизации должен быть очень много "немного" кодером.
Кстати, неплохая тема для статьи: "Преимущества скрамовской кроcсфункциональности по сравнению с жестким делением программист-тестер при внедрении компонентного тестирования". На порядок более полезная, чем "проблемы внедрения Rational Robot". Сам бы с удовольствием почитал.
Что-то слишком много специфических ситуаций мне попадается. Вы в указании цифр делайте поправку на регион, на приложение, которое надо тестировать и т.п.
Согласен. Действительно для тонких клиентов попроще, и уровень зарплаты важен.
Давайте так перепишу. Приведенные мной усредненные цифры верны для:
а) толстого клиента
б) уровень цен - Москва 2007
в) среднемосковского уровня зрелости софтверных компаний на 2007 год
г) малой доли конфигурационных тестов
Просто в качестве примера - есть набор тестов (штук 50), которые надо прогнать примерно на 300 конфигурациях (различные сочетания вида "браузер - ОС - СУБД - Веб Сервер"). Ставится такое тестирование пару месяцев + пара недель на обкатку, чтоб удостовериться, что все работает нормально. При этом такие тесты можно запускать параллельно. Правильный подбор средств тестирования может
резко снизить затраты на те же лицензии. А теперь посчитайте, сколько будет длиться такое конфигурационное тестирование, если его проводить вручную?
Хороший пример. Ортогональную матрицу пробовали применять?
Вручную такой тестинг действительно займет очень много времени. Дня два. Может даже неделю. Естественно только прогон, без подготовки стендов. Это если на тестинге занят только один человек. Если же на тестинге сидит несколько человек, то разумно с самого начала давать разным инженерам разные стенды, что очень серьезно сокращает затраты на конфигурационное тестирование.
Немного лирики. На прошлом проекте, я сделал именно так. Как результат - дополнительные накладные расходы мы имели только на установку стендов (этих расходов по любому не избежать). Конечно конфигураций у нас немного было. Но тем не менее. Я до сих пор горжусь качеством выпущенного продукта. Это был без всяких дураков продукт редкого качества.
Но в целом вы правы. Для Яндекса имеет смысл задумываться об автоматизации конфигурационного системного тестирования. Не обязательно внедрять, но задуматься можно. Правда у них и затраты на тестинг в год довольно приличные. И компания у них по среднероссийским меркам зрелая.
Когда объем задач начинает превышать "пропускную способность" людей, которые эти задачи выполняют, то пожалуй стоит задуматься над тем, как с них снять нагрузку. Вся эта возня с автоматизацией как раз и происходит из-за того, что людей на все задачи может нехватать, а зачастую и нехватает. И это не специфические случаи. Вот поэтому как-то и тестирование через ГУИ вспоминается и все прочее. Более низкоуровневые виды тестирования просто позволят уменьшить количество ошибок программной реализации, но не логики приложения, а вот это проверяется на более высоком уровне.
Это точно. Стоит. Задуматься. Только начинать нужно не с автоматизации. Ликвидация хаоса в управлении требованиями позволяет очень сильно разгрузить тестировщиков. Гораздо сильнее чем автоматизация. Это просто несопоставимые цифры. А уж постановка практики целеполагания приносит просто таки неприличные дивиденты.
В конце концов просто пошлите тестировщиков на курсы русского языка. Пользы в разы больше, А то будет как Александр написал
http://software-test...showtopic=10807. Четверть ошибок отклонена! Четверть! А пропущено сколько! А вы еще WR этим людям доверите. От это будет нумер. Примерно как оленевод в цехе машиностроительного завода [1].
----------------------------
[1] История не выдумана. Действительно оленевод. Без переобучения. Машиностроительный завод выпускает формы для отливки строительных блоков. Так что покупая квартиру в новостройке вспомните этого скромного труженика по разведению оленей. Может быть и в вашей квартире есть часть его труда. Счастливого новоселья!