How do you present documents and reports related to testing to your team and stackholders?

Hi All,

Following the agile manifesto, everyone want less amount of documentation

working software over comprehensive documentation

My questions:

  • if you want to improve the documentation process, what kind of documents you can’t ignore in your testing ?
  • how do you visualise your documents in simple way ?
  • can you share possible useful templates that you can use for different activities ?

Luckily I don’t have many demands to do this - I’m not a fan of writing documentation it’s makes me doze of… :sleeping:

I wrote a 20 page test strategy & policy document, everyone said great job but it’s just sitting in Confluence collecting dust! :sweat_smile:

For the visualizing part I use Miro to make mind maps I have a sprint summary report that I send out every two weeks, it’s just couple of graphs and pie charts on the state of testing. I include the following:

  • Number of test cases I’ve automated
  • Ratio of passed and failed tests
  • Number of user stories tests
  • Number of test cases, designed and executed
  • Statistic on defects I reported, including their priority
  • Details about automated regression runs per each product being tested
  • And lastly a few short sentences with conclusions
1 Like

if you want to improve the documentation process, what kind of documents you can’t ignore in your testing ?

  • the two core documents that we maintain is the test plan and a sprint 0 checklist.
  • Being an agency, the sprint 0 checklist is very efficient to make sure everything exists before we start Dev sprints.
  • the test plan is very important because if we shuffle our team members across projects, the test plan will act as a document that will help you get started right away. It includes things like, endpoint URLs, artifact details, build pipeline configuration, etc

how do you visualise your documents in simple way ?

  • mostly confluence to maintain transparency and easy access

can you share possible useful templates that you can use for different activities ?

  • @ailuj876 's Saucecon talk on test plan/strategy doc is highly recommended. We use a similar version.

Being a “contractor” means you are forced to formalize a lot more of the comms. It will be a push to reduce this distraction. On the contractor point I have a big question @jaswanth , how do contractors work in todays CI/CD systems where test results that come out an hour after the build button got pressed are more often less useful?

As for your original question:

  • Some document or a live/dynamic page that shows how many machines/devices/resources are “online” at any one time. To show what our test capacity is like ahead of any big crunch periods like a release, and to let us detect if hardware or network issues are about to bite us.
  • Daily test results that separate out a smoke suite, and regression suite report that breakdown for platform coverage and component coverage that is simple to read, where every failing test points to a standardised set of log files which a developer can pick up right away and then either work on a ticket or reject it.
  • Minutes from test-coverage meetings - keep the notes short, limit it to one-liner actionable things like “low coverage of feature XYZ, deemed a high risk”
  • Planning Document showing or pointing to a jira todo list that captures things we know that we will need to do “structurally” to keep improving our testing toolbox

If you cannot do anything about an aspect of your testing work that is causing a bottleneck, don’t bother to document it, use another way to change the way you deliver your message so that snag points do get addressed through language.


Good question @conrad.braam!

Whenever we have write any unit or UI or API script/test, it has a direct correlation with the test cases in our test case management tool (testrail).

After every build finishes, the test results are then pushed automatically to testrail using its APIs. That way the build test results are not wasted and used to determine the level of coverage.

Hope that makes sense. Ta


Yeah, that is cool Jas, I have not been using a test-management-system of late.

Still do find it tempting to bite that bullet, and get a system in place. But worry that it’s a one-person-100% job time-suck just to keep the API happy whenever things get renamed. I’m relying on meetings to review coverage, and the test report overview page to tell our story. I love documentation, but often healthy working code is the best documentation.

But, also, the release process document is probably another good place to describe any quality gates too.