Для этой группы были выбраны тесты, которые по большей части просто просматривают контент. Никаких тяжелых тестов. Соответственно, эта стадия длилась 10-15 минут максимум
15-20 минут/10-15 минут/15-20 минут
А если взять соотношение 1:100, то еще дольше, но есть одна проблема: в реальности такое соотношение можно обеспечить за счет уменьшения надежности тестов, сверхскоростного сетевого соединения, минимимальной детализации проверок.
Но на проекте ситуация была иная:
Тесты бегали на виртуалках постоянно и постоянно выдавали результаты. Любой из тестов мог что-то поменять в настройках -> надо было добавлять pre и post условия, которые бы это всё обрабатывали -> это съедает время выполнения, но повышает надежность
Мы работали с Калифорнией, а сервера разбросаны по разным локациям -> время отклика больше -> приложение работает медленнее -> тест работает медленнее, много уходит на ожидание
У автотестов одно из преимуществ в том, что им все равно сколько проверок провести, одну или 100 (вопрос только времени). Соответственно, если при ручном тестировании некоторых таблиц, можно ограничиться парой-тройкой проверок (особенно на больших объемах), то автотест может сделать охват пошире
У мануальщиков всегда под рукой заготовленный набор тестовых элементов, который они могут переиспользовать. В автотестах такого нет -> требуется время на подготовку этих данных. Иначе, либо получаются зависимоти между тестами либо надо делать дамп данных и перезаливать его каждый раз перед запуском теста, что накладно.
Исходя из вышеперечисленных факторов, соотношение времени прохожения автотеста и ручного теста будет не то что 1:10, а хорошо, если 1:1. Так что это не получается сценарий-простыня. Это вполне себе рабочий тест-кейс.
Искренне удивлен, что удалось уговорить заказчика на автоматизацию с эстимацией 19 человеко-лет. Но с оценкой 1tc/d по прежнему не согласен: после написания сотни-другой (ну может 500) кейсов, все контролы приложения “обкатаны”, common методы написаны, в html-source практически не смотришь, а скриптование действия/проверки занимает не более минуты.
Никого уговаривать не пришлось. Проект реально большой и система постоянно в развитии.
Ну, вырастет производительность до 1,5 tc/d, максимум до 2. Если тесты задизайнены большими - все равно много времени уходит на их реализацию. Да и под конец остаются сценарии, которые и автоматизировать тяжелее и затрагивают более критичный функционал. А еще старые тесты перестают работать со временем после изменений ГУИ и/или функционала и чем больше тестов написано, тем больше времени на поддержку уходит -> меньше времени на написание новых тестов.
Поэтому, сама по себе универсальная оценка количества тесткейсов за определенный промежуток времени в отрыве от контекста проекта и тестируемого приложения - это нечто абстрактное и бессмысленное. Сами сценарии могут как по объемам так и по содержанию кардинально отличаться в зависимости от тестируемого приложения. Отдельные шаги еще как-то можно унифицировать по времени, так как рано или поздно их реализация сводится к одной-двум строчкам кода (как раз за счет наработки функционала). Но никак не тестов, так как их размеры могут варьироваться в пределах от нескольких шагов до нескольких десятков (то есть уже есть различие размеров на порядки).
Добавляются новые
Добавляются новые. Более высокоуровневые.
До тех пор пока не пойдут динамические элементы
До тех пор, пока не начинаются совсем тяжелые операции типа перетаскивания или работы с нестандартными контролами. И у больших тестов большое количество этих самых действий + Написать мало. Нужно еще отладить и удостовериться, что тест не просто работает, а работает стабильно. И вот эта часть всегда занимает большую часть времени.
testomat.io управление авто тестами