...
We all learnt the waterfall model at school. I don't know about you, but in practice it is never is that clean.
It's a lot more iterative.
...
The Test Plan is written at the very end.
Bug fixes happen during implementation and testing and often result in design changes and event even requirement changes.
We endup with a bit of a messy development process.
Under deadlines what inevitably ends up happening happens is the documentation goes stale.
...
Each requirement must be designed. The details of the design can also be added to the test case.
We write the HLD (as we would normally) and can add extra test cases during the design phase as needed. The test cases would test existing requirements or add new discovered requirements we didn't think of before.
We move to implementation (either after the HLD design phase is completed or in parallel) and add extra test cases as needed. Again these test cases can test existing requirement or add new ones.
...
With this work flow the requirements, design and the test plan and the test plan implementation is are collapsed into one form: the LUTF test scripts. From the test scripts we can generate our documents.
...
The LUTF Documentation Block
Now to some LUTF details
Each test script should include a documentation block. Not all elements shown here are needed. But the more complete it is the more complete the generated document will be.
Here are the different fields in the documentation block:
| Code Block |
|---|
""" @PRIMARY: Primary Requirement ID @PRIMARY_DESC: Textual description Primaryof Requirementthe IDprimary descriptionrequirement @SECONDARY: Secondary Requirement ID if it exists @SECONDARY_DESC: description of the Secondary Requirement ID description if it exists @DESIGN: Design notes and descriptiondetails @TESTCASE: Test case descrtiptiondescription """ |
It's enclosed in """ .
The LUTF can automatically generate the bulk of the requirements, HLD and test plan documentation from the test scripts.
...
| Code Block |
|---|
suites['samples'].create_docs("samples.csv") |
This will generate two three csv files one would be the requirement document with the design and the other is the test plan.
Requirement Document
| Requirement ID | Requirement Description |
|---|---|
HLD
| Requirement ID | Design Notes |
|---|---|
Test Plan
| Primary Requirement ID | Secondary Requirement ID | Test Case Description |
|---|---|---|
NOTE: each secondary requirement in a test case should be a primary requirement in another test case. The idea here is that some test cases might touch on more than one requirement.
...
Diagrams and other mediums might be needed to explain the requirements and the design, which can not be included in the a text only test script.
However, my argument is that the above process can alleviate much of the maintenance of the documents required.
...
The first section can have the overview and diagrammatic explanations required. The second section is the table detailing all the requirements.
Updates to the second section of the document can be automatically generated from the test scripts.
Demonstration
Let's look at how all this would look like in the LUTF.
Demonstration
Let's run through this process to show how easy it is.