Software Life cycle discussion
Widget Connector | ||||||
---|---|---|---|---|---|---|
|
Slide Deck
Download the slide deck from here.
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.
...
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 needed for the requirements, high level design and test plan documents from these test casesthese 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
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 is a slide on the documentation block. I won't go over them in details now, but you can download the slide deck from the wiki.
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: 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.
The csv files can then be imported directly into the Confluence wiki or embedded in a document.