Video Transcript
Hello, this is Amir Shehata with another quick tip on the LUTF.
Today I'd like to propose a new way of working, which could prove advantageous.
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.
...
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 Cycle.
...
We can conceivably then extract all the information needed for these documents.
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.
...
This method provides the glue between the code and the documentation. As bugs are fixed or the feature updated, as long as the developer creates new test cases to cover the changes made and regenerate the documentation, the code and the documentation will remain in sync.
The LUTF Documentation Block
Let's continue with our documentation discussion and dive into 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.
| Code Block |
|---|
"""
@PRIMARY: Primary Requirement ID
@PRIMARY_DESC: Textual description of the primary requirement
@SECONDARY: Secondary Requirement IDs if applicable
@DESIGN: Design details
@TESTCASE: Test case description
""" |
Let's look at a concrete example.
Each test case in our sample suite has a documentation block.
The LUTF can generate documentation with the create_docs() command.
| Code Block |
|---|
suites['samples'].create_docs("samples") |
This will generate three csv files, one for the requirement document, the second for the design document and the third for the test plan document.
Requirement Document
...
HLD
...
Test Plan
...
NOTE: The secondary field lists the requirement ids which the test case might touch on.
The csv files can then be imported directly into the Confluence wiki or embedded in a document.