Successfully reported this slideshow.

QA Fest 2014. Павел Басюк. Test automation: а что на выходе?

2

Share

Upcoming SlideShare
Agile testing  part6
Agile testing part6
Loading in …3
×
1 of 33
1 of 33

QA Fest 2014. Павел Басюк. Test automation: а что на выходе?

2

Share

Атоматизация бывает разной: большой и маленькой, скучной и веселой. Но каждый раз когда запускаються автотесты - есть какие-то результаты. Это могут быть красивые или не очень html отчеты, либо банальный текстовый файл с большым логом. Именно о всём разнообразии отчётов мы и пообщаемся: кто и когда их создает, а кто и зачем их читает. Рассмотрим несколько примеров реальных отчетов, и обсудим как их можно улучшить.

Атоматизация бывает разной: большой и маленькой, скучной и веселой. Но каждый раз когда запускаються автотесты - есть какие-то результаты. Это могут быть красивые или не очень html отчеты, либо банальный текстовый файл с большым логом. Именно о всём разнообразии отчётов мы и пообщаемся: кто и когда их создает, а кто и зачем их читает. Рассмотрим несколько примеров реальных отчетов, и обсудим как их можно улучшить.

More Related Content

More from QAFest

Related Books

Free with a 14 day trial from Scribd

See all

QA Fest 2014. Павел Басюк. Test automation: а что на выходе?

  1. 1. TEST AUTOMATION. А ЧТО НА ВЫХОДЕ? QA FEST PAVLO BASIUK, ITERA
  2. 2. What is test automation outcome? System Under Test Tests inputs Tests results
  3. 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. 4. Point of view Automation engineers QA team Developers Customer, QA Manager
  5. 5. Test Report should be:
  6. 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. 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
  8. 8. Examples Real-life reports
  9. 9. Hand-made Html Report Overview
  10. 10. Hand-made Html Report Details
  11. 11. ReportNG
  12. 12. ReportNG sample overview
  13. 13. ReportNG sample details
  14. 14. ReportNG real-case overview
  15. 15. ReportNG real-case details
  16. 16. Thucydides
  17. 17. Thucydides overview 04.11.2014 / 18
  18. 18. Thucydides details 04.11.2014 / 20
  19. 19. Ranorex
  20. 20. 04.11.2014
  21. 21. Allure
  22. 22. Allure overview
  23. 23. Failures are groupped by assertion
  24. 24. Test suites
  25. 25. Test case details
  26. 26. Even more details on test steps
  27. 27. Nice charts
  28. 28. Possible tweaks Test statuses Input data Special modes Resource utilization Known bugs during test run Semi-automatic defect report
  29. 29. Possible improvements Review (again) who is target audience What are main goals for report Were do you spend most time
  30. 30. 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
  31. 31. Thank you! Any questions?

Editor's Notes


  • 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).
  • ×