Video Transcript
Hello, this is Amir Shehata with another quick tip on the LUTF.
Today I'd like to express my thoughts on the software process.
Problems with the Traditional Software Development Model
We all learnt the waterfall model at school. I don't know about you, but in practice it is never that clean.
...
As we write the HLD, we find we need to role back and adjust the requirements. The Detailed design is often passed over in favour of going directly to implementation, which I can't really disagree with.
The Test Plan is written at the very end.
...
The trick is to reduce the cost of the solution and maximize the benefit.
Proposed Solution
My proposed solution is to bring the test plan development to the centre of the Software Development Process.
...
Once the feature is complete we should have a set of test scripts which represent both the requirements, test plan and parts of the design.
We can conceivably then extract all the information required for the requirements, HLD and test plan documents from these test cases.
The LUTF Involvement
Let's now imagine that all these test scripts, which include:
...
I believe this reduces the overhead and increases our chances of keeping documentation consistent with the implementation.
Caveat
Of course life is always more complicated that it appears on paper.
Diagrams and other mediums might be needed to explain the requirements and the design, which can not be included in a text only test script.
However, my argument is that the above process can alleviate much of the maintenance of the documents required.
Lets take the Requirements document as an example.
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.
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.
...
This will generate 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 |
|---|---|---|
...
Once the test plan is reviewed, updated and approved, the script logic can be written in a separate phase.
Caveat
Of course life is always more complicated that it appears on paper.
Diagrams and other mediums might be needed to explain the requirements and the design, which can not be included in a text only test script.
However, my argument is that the above process can alleviate much of the maintenance of the documents required.
Lets take the Requirements document as an example.
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.