This page is outdated

The website of current conference can be found on czechtest.com

25 - 26 June 2015 in Prague

The website of last year conference can be found on 2014.czechtest.com


Visualization of Quality (Effective QA Reporting)

QA in Agile is far behind testing - it is more about:

  • Assuring delivery of real business value…
  • … In expected quality…
  • … Based on proper requirements…
  • … When all stakeholders are satisfied…
  • … And everybody enjoys it!

 

Nice targets! But each target needs a measurement to see the progress:

  • Where are we?
  • Do we even walk in the right direction?
  • What are the next steps?
  • Are we improving?
  • Do we keep promises?

 

Reporting was quite easy on Waterfall projects because it was only about testing when testing itself is nothing more than measure. So by the end of waterfall project we prepared Reports of found defects, few pie charts, done…

Functional testing is only a small piece of QA on Agile projects so it is obvious that such approach is not sufficient. Do we even need to measure such things in Agile? Yes, we should. But there are other more important measures, metrics and areas to be focused on.

I would like to share with you the way that I am used to report on my projects from my role of QA Engineer Lead including areas like

  • User Story sizing
  • Sprint Planning
  • Avoiding Bottlenecks
  • Burn down charts
  • Iteration Cumulative charts
  • Iteration defect analysis (numbers, distributions, causes)
  • Defect trends during whole project
  • Delivery charts (Tested vs. Accepted vs. Rejected)
  • UAT reporting
  • And several others

 

There is no benefit to prepare reports nobody reads, you should build them to suite your stakeholders and to really help you to achieve your targets.

Vojtěch Barta, Vendavo, Czech Republic

Vojtěch Barta

Testing, Agile, Requirements - my work, my hobbies.

I have enjoyed doing this for 7 years already, and I am still having fun.

I lead the Vendavo test team currently focusing on Agile transformation.

I believe quality should be defined by satisfaction of all stakeholders. I found it is far behind requirements, implementation, testing, etc.

Of course, these are all still important activities but you are as good in them as you are good in other aspects Agile encourague you to do, like communication, interaction, trust, commitment, business understanding, etc.