DEV Community

loading...

My approach to testing documentation

elcotu profile image Daniel Coturel ・2 min read

Hi everyone,

I was thinking, in the last couple of weeks, about a good testing workflow for non automated tests. Mainly, acceptance tests, since a big part of my team's workflow consists in testing with users after the development is ended.
So, I have a little software in-house software that I use to keep track of activities with customers. Requirements, living contracts, tickets, etc..
So some months ago, I developed a place to record tests. There you record the customer, the contract, the customer's accountable for that test, the bussiness transaction under test, and then you log:

  1. Test cases under test
  2. Issues detected related to each case

Then, the issues have a follow up workflow.

This is currently in use, but I kept wondering if this is a good approach, since it is basically plain text stored in a structured fashion, in a relational database.

This is a little screen-capture of a test:

Alt Text

So, as I was saying, I was wondering if I could improve this record in order to give it some more structure, and specially, the ability to provide validations for the user working and for my bussiness. So, I linked this manual practice with automated testing, and figured it out.

I was not mapping anywhere my assertions. So, I think the right approach, or at least a better one, would be:

  1. Each test still has information about the customer, the contract, the customer's accountable for that test, the bussiness transaction under test

  2. In the following step of the test design, you declare the assertions that reflect the acceptance criteria of the test

  3. Then you start logging each test case. For each test case and assertion combination, you declare if it passes or doesn't pass

  4. If a test case and assertion doesn't pass, then you add one or several issues

I have this in mind:

Test case 1 Test case 2 Test case 3
Assertion 1
Assertion 2 X
Assertion 3 X
Assertion 4 X

And then the test document has the list of issues detected.

Have you ever seen something like this in action? To be honest, I developed this but for a boiler certification small bussines, several years ago. It runs in tablet. It is about now that I realize that pattern is useful for software implementation.

Saludos,

P.S.: I'm not an english speaker, so if the text is hard to read please let me know and I'll try to make it clearer.

Discussion

pic
Editor guide