Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (16)
Similaire à QA Fest 2014. Павел Басюк. Test automation: а что на выходе?
Similaire à QA Fest 2014. Павел Басюк. Test automation: а что на выходе? (20)
Plus de QAFest
Plus de QAFest (20)
Dernier
Dernier (20)
QA Fest 2014. Павел Басюк. Test automation: а что на выходе?
- 1. TEST AUTOMATION. А ЧТО НА ВЫХОДЕ? QA FEST PAVLO BASIUK, ITERA
- 2. What is test automation outcome? System Under Test Tests inputs Tests results
- 3. What is test automation outcome? System Under Test Tests inputs Tests results Precondition data Environmental status Program start state Environmental changes Program end state Post condition data Program end state Post condition data Environmental changes
- 4. Point of view Automation engineers QA team Developers Customer, QA Manager
- 5. Test Report should be:
- 6. Requirements for report • Structured – Test-suites, test-cases, test-steps – Filters for results (to see only pass/fail/other) • Summarized – High-level overview of results, so it should take less time to understand how good results are – Summary per feature/tag/component • Rich – Screenshots, additional info (e.g. attachments, system configuration) • Detailed – With all input data used – With all actions done and all expected/actual results – Execution time (for test-suites, test-cases) • Easy to create – We don’t want to spend extra time to prepare any reports
- 7. Analyzing Results • test environment • application changes • test errors False failure • test defect • missed error False success • same error reported • dependent tests failed Duplicate failures
- 9. Hand-made Html Report Overview
- 10. Hand-made Html Report Details
- 11. ReportNG
- 16. Thucydides
- 19. Ranorex
- 20. 04.11.2014
- 22. Allure
- 23. Allure overview
- 24. Failures are groupped by assertion
- 25. Test suites
- 27. Even more details on test steps
- 28. Nice charts
- 29. Possible tweaks Test statuses Input data Special modes Resource utilization Known bugs during test run Semi-automatic defect report
- 30. Possible improvements Review (again) who is target audience What are main goals for report Were do you spend most time
- 31. References 1. AT.info http://automated-testing.info 2. ReportNG http://reportng.uncommons.org 3. QA Automation Notes http://qa-automation-notes.blogspot.com 4. Thucydides http://thucydides.info 5. Ranorex http://ranorex.com 6. Allure http://allure.qatools.ru
Notes de l'éditeur
- In this example, test automation outcome has output data (as result of test process, and test report as result from comparison process.
- Automation engineers Created all auto tests, so only need stacktrace in case of failure And in case if investigation required, then can read debug log QA team Need to reproduce failure, so should be able to accurately, step-by-step repeat automated test Can use automation test output for bug reports (screenshots, application logs, steps) Developers Need to know exact build/version/environment details Application logs, screenshots Access details if any (e.g. login/password to reproduce issue on qa env) Application snapshots (if possible) Customer, QA Manager Summary information, progress, application readiness for release
- ReportNG is a simple HTML reporting plug-in for the TestNG unit-testing framework. It is intended as a replacement for the default TestNG HTML report. The default report is comprehensive but is not so easy to understand at-a-glance. ReportNG provides a simple, colour-coded view of the test results. ReportNG generates 100% valid XHTML 1.0 files. The output can be customised by over-riding the default stylesheet with your own CSS file.
- На морде слева (см. первый скрин) список testng сьютов, обозванных по имени / версии браузера (берется из testng xml). 3) Каждый сьют кликабелен и перемещает нас к детальному отчету (см. второй скрин). 4) Помимо всего прочего, морда содержит даты запуска / завершения, длительность, результаты и pass rate. 5) Сверху можно еще найти информацию об экзекьюторе (юзер / доменное имя тачки, с которой были запущены тесты) + конфиг ее системы. 6) Из центральной части морды также можно перебраться на детализированный отчет по сьюту.
- 7) Внутренности содержат в шапке инфу о ноде (ip:port / domain name), на котором был заэкзекьючен сьют + конфигурация (ОС / браузер / версия). 8) Центральная часть содержит список всех тестов, разбитых на passed / failed + группировка по классам. Ну и базовая инфа: имя / длительность / степы с тестовыми данными пришедшими в качестве аргументов. 9) Опциональный линк на HarStorage с инфой по реквестам / респонсам теста. 10) Опциональный линк на видеозапись теста. 11) Список верификейшенов (выдранных из софт ассертов). При этом, каждый верификейшен содержит линк на релевантную стори в Jira. 12) Скрин последнего дыхания теста. 13) В случае фейла под скрином еще будет раскрывающийся линк со стек стрейсом + ID зафейлившихся верификейшенов.
- Введите 2 режима запуска тестов: Один для разработки и отладки скриптов А второй для полновесных запусков (которые могут занимать по несколько часов) Пересмотрите еще раз список статусов (результатов): А есть ли у вас статус Pending, для тестов которые уже закомичены, но еще не полностью готовы к запуску? А статус Broken, для тех тестов которые попадали не с AssertionException а с какой-то другой ошибкой? А где и как в отчете можно увидеть входные данные? А еще в отчете можно сохранять использование ресурсов (например, сколько оперативной памяти занимает тестируемое приложение). На этом можно еще и дополнительную проверку сделать, и фейлить тест если приложение начало использовать много памяти. And do you have any special handling for cases when you know for sure that bug appears? (e.g. Unhandled Exception just appears, and this is definitely a bug).