a discussion we had at work on documentation using this as a support

1. The Documentation
OPEN FOR DISCUSSION

2. Questions
➢ What is your opinion on software testing documentation?
➢ Do you use it in your daily work?
➢ What type of documents have you written so far?
➢ How does writing documentation apply in the Agile world?
➢ What are the benefits of writing documentation?

3. Your Opinions on Documentation
❖ It is a must and a crucial part of testing
❖It should be limited to only useful documents, adapted according to projects needs.
❖ Agile Manifesto: “working software over comprehensive documentation”
❖ Time consuming, but very useful for knowledge transfer.

4. Used in daily work?

5. QA documents – IEEE Standard
❖ Test design document
❖ Test case specification
❖ Test Procedure Specification
❖ Test Strategy
❖ Test summary reports
❖ Test Log document
❖ Test plan document
❖Bug reports document
❖ Test data document
❖ Document of Weekly Status Report
❖ Document of User Acceptance Report
❖ Test Incident or Problem Report
❖ Report of Risk Assessment
❖ Test analysis
❖User Documentation

6. Agile Context – your answers
❖ Testing has priority against documentation. But it has to be done sooner or later.
❖ Usually only what you need, when you have the time. PO's don't see documentation as a
deliverable and time is rarely book for this.
❖ Only the strictly necessary. The documentation should be concise, on the point.
❖ Forced to keep the documentation short and simple.

7. Agile Context – What You Need
❖ A test strategy that describes how the system is usually tested.
❖ A test plan for each sprint.
❖ Test specifications which contain test cases.
❖ Test Ideas for exploratory testing and test logs in which the outcome is noted.
❖ Checklists for installation testing and regression testing.

8. Benefits
❖ Gives a good project understanding
❖ A better record of the testing activity performed on
the project.
❖ Ensure internal co-ordination in client work
❖ Provide feedback for preventive actions
❖ It's needed for creating a knowledge base,
knowledge transfer.

9. Best Practices: Writing
❖ Prefer executable specifications over static documents
❖ Document stable concepts, not speculative ideas
❖ Generate system documentation

10. BP: Simplification
❖ Keep documentation just simple enough, but not too simple
❖ Write the fewest documents with least overlap
❖ Put the information in the most appropriate place
❖ Display information publicly

11. BP: What to Document
❖ Document with a purpose
❖ Focus on the needs of the actual customers(s) of the document
❖ The customer determines sufficiency

12. BP: When to Document
❖ Iterate, iterate, iterate
❖ Find better ways to communicate
❖ Start with models you actually keep current
❖ Update only when it hurts

13. Questions Time