testomat.io управление авто тестамиSelenium WebDriver + Java + Grible (http://grible.org): 15 человеко-месяцев: 50% функционала покрыто solid тестами (210 штук) полного времени исполнения - 3 часа (параллельно на 6 виртуалках).
2 лайка
Java+TestNg+Webdriver+HtmlElements+LoadableComponent: 2 человеко-месяца: 5 страниц из 32 покрыто тестами (1 страница - solid coverage: 106 тестов; 4 - base: 154 тестов; всего - 213 тест методов) полного времени исполнения на локальной машине - 13 минут (последовательного запуска)
Термсы:
- страница - елемент веб юай которий разумно представить как PageObject
- solid coverage - страница почти полностью покрита тестами, с избыточными проверками
- base coverage - страница покрыта основными функциональными тестами, которые соответсвуют основным юз кейсам пользователя.
- количество тестов - количество тестов пощитаное из отчета TestNG, то есть больше количества тест методов, которые могли быть запущены несколько раз, например при разных параметрах полученых от DataProvider.
Selenide: 5 месяцев работы четырёх программистов (в двух парах) - написано и приложение, и UI-тесты. 100% страниц покрыты тестами.
2 лайка
Imho, не совсем корректно поставлен вопрос:
- Покрытие нужно считать не по “страницам”, а по мануальным тест кейсам.
- Тут мало что зависит от инструмента. Основная зависимость будет от квалификации специалиста.
Из своего опыта могу сказать, для хорошего специалиста (>2-3 лет в автоматизации) средняя эстимация 1TC/1h (опять таки вне зависимости от инструмента). Полного покрытия достичь не получится никогда, т.к. скорость написания мануальных тест кейсов в разы превышает вышеуказанную цифру, а убедить заказчика, что автоматизаторов на проекте должно быть больше, чем мануальщиков врядли удастся. В основном покрывают BAT, smoke, extended уровни. В регресии области покрываются по желанию руководства, в основном это критические области с большим кол-вом регрессионных багов, емкими комбинаторными тестами, тесты которые не рационально тратят время мануальщиков (аля алерты, рассылки, создание большого количества данных), и т.д.
Если кто-то говорит о 100% покрытии, не сомневайтесь, он лукавит 
В более-менее крупном проекте количество мануальных тест кейсов написанных за спринт может исчисляться тысячами. А в производительность >1TC/1h я не поверю.
Буду очень рад если Вы поделитесь с нами статистикой в том виде в котором Вы считаете удобным.
В шапке “со страницами” - был только пример.
Мы в любом случае сдесь не оценим все точно, на 100%, и никто сдесь и не сможет предоставить отчет на пару страниц текста с детальными указаними что сколько да как…
Цель собрать статистику - в среднем, - в среднем как по “качеству” самой статистики, так и по качеству того о чем она говорит.
Кому то это будет не нужно, а мне пока даже этого будет достаточно… Мне кажеться всегда можно будет найти зерно в этих “отчетах”…
Также мне кажеться, что будет замечательно, если мы сдесь не будем особенно критиковать людей за их отчеты… Если нам интересны детали - давайте просто “уточнять”. Например и так я думаю всем должно быть понятно что 100 процентного покрытия быть не может. Поэтому давайте наперед примем тот факт что все отчеты относительны по умолчанию:)
В любом случае спасибо за замечание. Я постраюсь дополнить “идею” в шапке, чтобы было понятней о чем идет речь…
Так то оно так… Но как по мне тоже - с учетом того - что это среднее значение за достаточно длительный промежуток времени… И иногда на старте автоматизации - статистика будет другой (в силу например использования нового инструмента).
Об этом моменте в шапке упомянуто - что особенно интересны данные о ранних стадиях автоматизации.
Также… Мне кажеться что все таки инструмент может помочь в плане еффективности… Может это действительно не так… Я склонен к такому же мнению как и у вас, о том что все зависит большей мерой от квалификации специалиста. Но думаю я так только по тому что видел. А того чего не видел - не знаю. Поэтому и спрашиваю в той мере в какой могу - сдесь в теме. А также надеюсь что где то - то ли есть инсрумент который повысит ефективность, то ли есть его “задатки” которые можно использовать и все таки создать инструмент поеффективней. В любом случае помня что лучшего инструмента под все условия не бывает.
Также в какой то мере - можно получить сравнение еффективности “готовых решений” и “самопальных велосипедов”. Уж сдесь то точно будет что сравнить… И особенно - в начале.
Не будет, если правильно расставить приоритеты: отревьювать тест кейсы и автоматизировать от “простых” (состоящих из нескольких степов) к “сложным”. Будет время и на знакомство с инструментом и из графика не выпадаешь.
Точные цифры не скажешь, численность/производительность людей постоянно меняется, как и количество мануальных кейсов. Но на практике автоматизировать более 10-20% не получалось.
Производительность не зависит от инструмента. Автоматизировали на SilkTest, QTP, TestComplite, SeleniumRC, WebDriver: что при расчете capacity, что при эстимации всегда выходили на 1tc/1h. Причем, зачастую, большая часть этого 1h тратится на уточнение/валидацию степов tc, общение с мануальщиками и т.д.
Время прохождения тоже в среднем было одинаково: IE - 1-2 минуты на tc.
Как как эти цифры были получены эмпирическим путем и проверены не на одной тысяче тест кейсов, я в них верю.
Если вникнуть в суть топика то по сути нужны только две метрики для automation tool: производительность x TC per hour, время выполнения y TC per hour, которые на практике являются константами.
Если кто-нибудь скажет, что есть СуперТула, на которой можно писать по пять кейсов за час, а в IE среднее время выполнения tc 30 секунд, я, в лучшем случае, отнесусь к этому крайне скептически.
О чем и говорю - эфективность сумарно упадет если сумировать по определенным срокам… Так например за первый например человеко-месяц - будут автоматизированы только самые простые тест кейсы… Именно это я и имел ввиду…
Ну тут мне кажется не о чем дискутировать, ведь как бы очевидно что всегда есть ‘флуктуации’…
Спасибо за вашу оценку в 1tc/1h! Будет теперь с чем сравнивать)
А вот интересную тему затронули на счет автоматизации мануальных тестов. Конечно, тут многое чего зависит от проекта, процесса, заказчика и самого автоматизатора, в общем, как это называют «от контекста». Но, я вот считаю, что строить автоматизацию на основе мануальных тестов – это в большинстве случаев не эффективно.
И тут я изложу то, что я видел в своей практике, но, конечно же, ваш опыт может отличаться, и я готов дискуссировать на эту тему.
Итак, начнем о качестве мануальных тестов.
Количество ручных сценариев должно всегда расти. Правильно ли это?
С точки зрения вида сверху-вниз, все идет очень хорошо. Каждый спринт, количество сценариев увеличивается. Тестировщики пишут новые сценарии. Месяц назад было 300, сейчас уже 400… через пол года будет уже 800… По сути, это создает ситуацию, когда ненужные сценарии нельзя удалять. Следовательно, увеличивается процент шлака: вместо того, чтобы удалять ненужные тест-кейсы (те, которые не приносят пользы), их наоборот увеличивают и… принимается решение автоматизировать этот шлак, вместо того, чтобы его вывести. Тогда метрика один тест в час, превращается в метрику один шлокотест в час.
И на противовес: автоматизировать лучше те сценарии, которые оказывают наибольшее влияние на продукт.
На меня очень повлияла вот эта презентация (я видел еще старую версию). В ней высказываются идеи, как выявить те участки продукта, которые действительно важны, и нуждаются в автоматизации:
How to Narrow Down What to Test
На своем проекте, я провел небольшое исследование и для себя выявил, что именно самые простые тест-кейсы находят наибольшее количество багов. Именно позитивные CRUD сценарии.
Но, этот показатель может зависит от специфики проекта. Собственно, у меня как-раз по большей части – CRUD приложение.
Очень полезно посчитать статистику по баг-трекеру по критичным и серьёзным багам. Именно эти области и нуждаются в автоматизации.
Кроме того, если это возможно, то лучше поставить себе первоочередную техническую цель по покрытию кода приложения. Мне помогли инструменты для C#/.NET – OpenCover; Для JavaScript – JSCover. Именно благодаря им я понял, что при помощи очень простых сценариев можно покрыть до ~80% кода (70-80%%). А это – обеспечит очень классное смоук тестирование, которое быстро находит JavaScript ошибки и крэши сервера.
Автоматизированные тесты должны писаться по мануальным, чтобы мы знали, что делают авто-тесты. Действительно, ли это так?
Кто согласен с тем, что самая большая польза от мануальных тестов, это по сути то, что они позволяют понять, что-же все таки делает автоматизация?
Действительно, проблема с тем, чтобы объяснить, что-же все таки делает автоматизация – существует по сей день, и еще нет такого решения, которое бы устраивало всех.
А решение, залинковать мануальный тест к автоматизированному – это, как бы, универсальное. И доступно практически всем, даже если ваши мануальные тесты – в Excel, а автоматизация – на QTP. Тут, мы умалчиваем, что при таком подходе – возникает проблема синхронизации: либо мануальный сценарий изменится, а автоматизированный нет – либо наоборот.
Я упомянул, что нет такого решения, которое бы устроило всех… Но, это не значит, что решений нет вовсе. Но, об этом – позже.
А пока, хотелось бы поделится еще одним докладом, прозвучавшим в бородатом 2010-м, на конференции SQA Days:
Автоматизация тестирования модели разграничения прав доступа к функционалу
Если кратко, то вначале, команда создала чисто автоматизированный сценарий, без «мануального» аналога. Но, в итоге, они столкнулись с проблемой, что как работает код автоматизации стало сложно понять, и им пришлось писать мануальные сценарии для того, чтобы объяснить, как работает автоматизация.
А почему бы не генерировать мануальные сценарии из кода автоматизации?
По сравнению с бородатым 2010-м, сейчас уже такие подходы на слуху у многих. Да, есть свои проблемы… но кто говорил, что это простой путь?
Есть известный все Cucumber, который позволяет писать тесты на языке… хм… приближенном к понятному.
Но, на основе этого инструмента, появился Relish https://www.relishapp.com и сейчас, те же люди работают над https://cucumber.pro
И для меня, генерация мануальных тестов на основе автоматизации – интересна, и я работаю над ее воплощением.
Тут я описал очень простой пример, как это может работать, с выводом текста в консоль, но никто не мешает использовать такой подход и для генерации файлов с мануальными сценариями:
How to Create an App from Scratch | AppMaster
И вот самый важный вопрос: действительно ли нам необходимы мануальные сценарии для того, чтобы строить автоматизацию? Стоит ли нам привязывать мунуальный и авто тест, как один-к-одному?
2 лайка
@dzhariy, Дима, может вынести тему “Связь Автоматизированых и Мануальных тестов” (или с другим именем) в отдельный сред?
Как по мне оба способа все равно односторонни. Можно сделать набор тестов, которые охватят 100% всех страниц, но при этом будут проверять базовые вещи. А можно написать 1000 тестов на одну страницу. Какая из этих метрик лучше укажет, хорошее покрытие или нет? И почему бы покрытие не привязывать к фичам\требованиям и прочим артефактам, которые описывают, что ожидается от системы? Ведь тестовые сценарии как раз по такому принципу привязываются к требованиям.
От возможностей инструмента тоже очень много зависит. И от его особенностей и от особенностей дизайна тестов\автотестов. Квалификация уже сказывается при прочих равных условиях.
Это зависит от самих тестов. На некоторые тесты может уйти несколько дней, а на некоторые несколько секунд.
Никогда не говори “никогда”.
- Есть системы и просто виды тестирования, которые не тестируются вручную в принципе или изначально все нацелено на автоматизацию. Это характерно для back-end систем, а также систем которые тестируют сами себя + некоторые виды тестирования изначально подразумевают автоматизацию (нагрузочное тестирование, unit-тестирование)
- Когда нехватает людей можно поработать над тем, чтобы сделать их работу более эффективной. Например, поработать над дизайном тестов таким образом, чтобы их дегче было автоматизировать в большим количестве и в кратчайшие сроки (например, сгруппировать некоторые тесты в один data-driven тест).
А зачем их должно быть больше, чем мануальщиков? Затраты выше, а выхлоп не факт, что лучше
Или вы чего-то не знаете 
Как вариант, можно попросить подтвердить это. К тому же, 100% покрытие чего? Тестов? Кода? Фич? Покрытие бывает разным и только комплексная оценка может что-то реально показывать. Во всем остальном - это лишь однобокая оценка
А может и равняться 0. И далеко не во всех крупных проектах есть спринты.
Вам нужен час для написания теста на проверку работы командной строки?
Или проверить вызов метода? Или если есть порядка 100 однотипных теста, у которых по сути различается только ряд параметров?
Не нужно быть столь категоричным. Бывает слишком много нюансов, которые надо учитывать и которыми надо уметь пользоваться.
Естественно можно из цепочки авто_тесты->мануальные_тесты->требования выбросить среднее звено, но тогда на вас ложится работа мануальщика: чтение документации, общение с фича-писателями, составление тестов и т.д., что не добавит производительности.
Речь идет о тестирование Web приложений. На этом поле все давно “пропахано” и все инструменты практически эквивалентны, и никаких революционных прорывов ждать не стоит.[quote=“KoNaN, post:14, topic:3446”]
Это зависит от самих тестов. На некоторые тесты может уйти несколько дней, а на некоторые несколько секунд.
[/quote]
Да это всем понятно, но в сумме получится тот же 1tc/1h за отчетный период времени.
Еще раз повторюсь, я говорю исключительно про автоматизацию функционального тестирования Web приложения через UI. А под покрытием подразумеваю кол-во автоматизированных мануальных тестов, отсюда можно получить покрытие в любом “разрезе” - фичи, области, требования и т.д.
Я не говорю про исключительные ситуации, я говорю про среднестатистический тест.
Мдамс… У каждого просто свой подход) Кто то будет искать улучшение производительности в том чтобы четко раделить работу мануальщиков и автоматизаторов… А у кого то будет TDD&ATDD практикуемые самими девелоперами, и автоматизаторы вообще будут не нужны в большей мере, как вот здесь:
Или же в команде все “мануальщики” будут достаточно “немануальщиками” )))) - чтобы все делать самим - и то что вы называете “ручным тестированием” и то что “автоматизированым”…
Предвкушаю тот момент когда все таки такой инструмент появиться:) А также момент когда у меня будет достаточно статистики чтобы увидеть эту “эквивалентность” на деле а не на словах) или не увидеть 
Насчет “среднестатистических 100 процентов” )))) @vmaximv @KoNaN, Ребята, мне кажеться вы говорите о схожих вещах разными словами) Просто одному не понравилось что кто то посмел упомянуть 100 процентов… А другому не понравилась категоричность первого - поэтому появились претензии даже к тому к чему не стоило)
Вобщем, все же я думаю понимают что это форум) Что понять тут друг друга часто сложно) Поэтому давайте будем снисходительны один к другому) Хе хе, хотя я конечно иногда и сам люблю “повыжигать” )
И вообще))) Развели тут демагогии)))))))))))) Давайте лучше агитировать других чтобы делились своим конкретным опытом о цыфрах)) Цифры конечно скука, но иногда бывают полезны.
Мне кажеться что некоторые вещи можна в отдельных темах пообсуждать…
Без понимания того, что нужно сделать, вы все равно не автоматизируете сценарий (разве что ну совсем детальный, который только и описывает клики). А в остальном придется вникать во всё. А если автоматизаторов привлечь к тест дизайну, то будет возможность изначально проектировать тесты так, чтобы их легче было автоматизировать, быстрее и с лучшим охватом. Дополнительно, есть куча подходов, которые призваны совместить тест-дизайн и автоматизацию. Тот же Keyword-driven и BDD подходы как раз для этого и были предназначены. У них прирост производительности со временем обеспечивается тем, что ряд ключевых слов можно переиспользовать без написания кода вообще. Суть в том, что производительность можно повышать не только экстенсивно (увеличив количество людей, что может в определенный момент сделать автоматизацию невыгодной), но и за счет повышения эффективности, когда аналогичные затраты усилий команды приносят больший результат.
Они эквивалентны только в самом факте поддержки web. На этом эквивалентность заканчивается.
Откуда так получится? Эта метрика вообще никак не учитывает специфику дизайна самих тестов и сценариев. У меня были проекты, где была согласованность по производительности 1tc/1d и это было нормально, так как все тесты были достаточно обширными, а некоторые только на запуск требовали по часу времени (есть системы со сложным flow). И это в среднем 1tc/1d на проект. Было и наоборот, что тесты могли быть автоматизированы в количестве порядка 10tc/1h за счет простоты структуры приложения, подхода к дизайну и используемым средствам. Это всегда надо учитывать. Иначе если вы будете расчитывать планы для подобных проектов исходя из среднепотолочных 1tc/1h без учета специфики проекта, то вы ошибетесь в своих оценках на порядки, что непростительно даже при грубой оценке “на глаз”
Я тоже говорю про среднестатистический тест. Только проблема в том, что он на каждом проекте разный.
Та ладно вам:) Мне кажеться вы придираетесь так же как и ваш опонент:) Суть в том, что у vmaximv солидный опыт, и много проектов, и он усреднил все по времени как в контексте одного проекта так и нескольких. 
Это понятно что всегда бывают отклонения от “нормы”. Но суть не в том что-бы говорить что - “вот типа, я не вижу смысла вашей оценке в 1т/1ч” а в том что раз уж возражать то хотя бы как то так… “да, это может быть правдой, но разве не полезно также знать что при таких и таких вот условиях продуктивность все таки будет выше”, и привести список таких конретных условий, лучше всего - как примеры из вашего опыта, чтобы другим знать чего ожидать при “попадании” в такие условия, или еще лучше - как (если возможно) самому такие условия создать, какие практики/техники/методологии/инструменты для этого использовать)
Мне вот тоже не хочеться верить в “реалистичность” такой оценки… Но сейчас сложно поставить что то в противовес:) Поэтому и “молчу” … ))))
У меня тоже
И эта оценка не значит ничего, она мало применима даже для аналогичных проектов, так как полностью игнорирует особенности текущего проекта, его состояние, внутренние процессы да и просто хотя бы размер теста. Тут сходу можно расписать с десяток факторов, влияющих на производительность, на отдельную статью хватит. И такая оценка, высказанная вне контекста, не тянет больше чем на попадание пальцем в небо. Вот об этом я и говорю.
Можно несколько вопросов?
-
Какое кол-во тест-кейсов планировалось автоматизировать?
-
Какая ,была продолжительность Build Acceptance Test?
-
Среднее время ручного прохождения тест-кейса? BAT? Тест-кейсов из п.1?
Может у меня и ограниченное воображение, но, если взять, например, время_авто_теста:время_ручного_теста = 1:10, то выходит, что один тест-кейс вручную надо проходить 10 часов. Этого я себе представить не могу, либо это уже не совсем тест-кейс, а “сценарий-простыня”.
Для того проекта, о котором я это упомянул, 5000+
Для этой группы были выбраны тесты, которые по большей части просто просматривают контент. Никаких тяжелых тестов. Соответственно, эта стадия длилась 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. Если тесты задизайнены большими - все равно много времени уходит на их реализацию. Да и под конец остаются сценарии, которые и автоматизировать тяжелее и затрагивают более критичный функционал. А еще старые тесты перестают работать со временем после изменений ГУИ и/или функционала и чем больше тестов написано, тем больше времени на поддержку уходит -> меньше времени на написание новых тестов.
Поэтому, сама по себе универсальная оценка количества тесткейсов за определенный промежуток времени в отрыве от контекста проекта и тестируемого приложения - это нечто абстрактное и бессмысленное. Сами сценарии могут как по объемам так и по содержанию кардинально отличаться в зависимости от тестируемого приложения. Отдельные шаги еще как-то можно унифицировать по времени, так как рано или поздно их реализация сводится к одной-двум строчкам кода (как раз за счет наработки функционала). Но никак не тестов, так как их размеры могут варьироваться в пределах от нескольких шагов до нескольких десятков (то есть уже есть различие размеров на порядки).
Добавляются новые
Добавляются новые. Более высокоуровневые.
До тех пор пока не пойдут динамические элементы
До тех пор, пока не начинаются совсем тяжелые операции типа перетаскивания или работы с нестандартными контролами. И у больших тестов большое количество этих самых действий + Написать мало. Нужно еще отладить и удостовериться, что тест не просто работает, а работает стабильно. И вот эта часть всегда занимает большую часть времени.