3

At this moment I write my test cases in Markdown. So they can be version-controlled (I use Git). From Markdown I can render the sources into either HTML or PDF, it can be automatized through a shell script, so it's not a problem to rebuild PDFs every time I want to fix a small typo or whatever.

These test cases are manually performed, but sometimes have corresponding autotests in either Selenium IDE or Selenium WebDriver. They are always built after a manual test is ready and checked.

I'm moving towards creating data-driven test cases, separating instructions from data (which is no more than strings and numbers). So I thought about storing data in some format, which would allow me to use the same data source both for manual tests and for autotests. This would allow me to reuse autotests with new data.

I've drawn a flowchart of how I imagine the whole system to work. Making data-driven automated tests seems like no trouble. It's easy to read either an XML or Properties (key=value) file.

But how do I make human-readable instructions from raw data?

  • Are there any ready solutions for building Markdown or any other text format?
  • What is a good practice to build human-readable instructions from raw data?
  • What are the possible flaws of the whole idea?

enter image description here

3
  • Are you sure that you want your human-readable instructions to be at the same level of detail as your Automated tests? I personally prefer my human-readable instructions to be more abstract.
    – user246
    Commented Aug 25, 2015 at 12:07
  • @user246: no, they certainly should not be as much detailed. But some data can be reused. Now I think that maybe I should have asked this separately from the automated tests. The main problem is how to automate deployment of manual tests. Commented Aug 25, 2015 at 12:17
  • 1
    Use people for what they are good at, ad-hoc exploratory testing, not rigid data entry. When they find something good, automate the test. Use automation for what it is good at, repetitive regression testing, heavy data entry testing. Commented Jun 27, 2018 at 20:25

1 Answer 1

2

This is quite an old but very interesting question which has surprisingly has no answers at all. Let me add my attempt here that will probably help someone who will face the same issue.

Personally I can see some excess elements in the provided schema. It is a good choice to store test data in XML since it allows to have a structure unlike the key-value pair format. However I do not see a lot of value in keeping Markdown format in the new schema. I would simplify the schema as follows:

enter image description here

Since XLST is a very powerful mechanism of transforming XML (that is supposed to store test data) we can just write one transformation to transform the test data to HTML and have one component between the database and the user instead of three ones.

In my example Test case templates might just store the appropriate transformation documents that are to be applied depending probably on what kind of tests we are running.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.