What documentation in Testing do you have?

[Ronan Healy]

I want to ask about how much documentation you have to manage in your role.

Of course documentation can vary widely depending on what your role is and the type of process your company has in place.

I would assume that many testers deal with Test cases, Test plans, status reports, Bug reports and maybe project proposals but what other documents are there that you deal with on a regular basis.

Do you find documentation a benefit to your role or do you think they take up too much time?

[Mark]

I’m a test manager / test consultant in both Waterfall and Agile worlds.

I deal with a wide range of documents, particularly in Waterfall and “frAgile”,  so will start with a brain dump:

1. Test Policy
2. Test Strategy
3. Test Plan (ISTQB – not Quality Center’s definition)
4. Release Plans
5. Release Notes
6. Change Requests
7. Requirements
8. Solution Designs
9. Contract / Statement of Work
10. RAID logs
11. Operational handover details
    • schedules
    • operational instructions
    • recovery dependencies, etc
12. Emails (i.e. ad hoc change/clarification to solution)

But I have long been persuaded that some of these are never read, and do try my hardest to reduce & remove what I can. To avoid unnecessary duplication, I raise RAID items immediately into the project logs (or sometimes a testing RAID log) rather than writing them into the documents.

1.  Test Policy

Can’t say that I’ve come across one of these lately, but often a 1 page summary of the goals of the organisations testing activities & potentially appetite for risk.

2. Test Strategy

I have seen some monoliths here (and have probably written some – blush).  Because of their size, many people just don’t bother to read them & ‘sign off’ becomes practically meaningless.

My recent strategy documents have been succinct (10 pages max, including the covers, ToC & version history).

Well written and short though, a test strategy provides consistency across projects and project phases.

Could/should reduce time and effort to produce Test Plan (3).  If it doesn’t then what is it for?

3.  Test Plan

By this, I mean the scope, resourcing and plans for a particular phase of testing (Challenge 1: Do headings in IEEE 829 still hold?).  Bloat often occurs when people want these to be standalone documents, so we repeat defect management process, etc, etc.

Obviously tooling can make these even smaller (or redundant) – but they still logically exist in all but good Agile environments.

…

[Archana]

My list of documents is pretty short. As a tester, I maintain mostly the following three documents

– Test plan

– Test cases

– Defect report

[Alin]

Hello Ronan,

Currently in my testing activities I manage mainly 2 types of documentation: test cases ( including workflows, diagrams, test data etc.) and defect reports.

On other projects I have worked on I was dealing also with requirements.

From my point of view, documentation in general is nice to have but it requires a lot of time and effort. Moreover, if there is no maintenance work on that documentation and documents are not updated, then it is not very useful. Regarding automation, a good documentation I see is to add useful comments in code and scripts so that it would be easier to understand the code, tests and workflows.

Regards,
Alin

[JerryWeinberg]

A couple of general points about documentation:

1. Don’t confuse documents with documentation. There are several ways of documenting your testing, and you should consider all of them. For instance, you can make a short video describing for managers and developers and other interested parties what your testing philosophy is. You can make videos of some tests in action, which may save tons of explaining and writing. In the end, though, most of the information about your testing is carried in the heads of your testers, so be sure you have a process that points people to the right people holding knowledge, and then makes those people available and trained to communicate effectively.

2. It’s especially important to have a meta-document that sets the standards and preferences for your different types of documents. And, for each of these standards and preferences, the meta-document should tell WHY it’s there. That way, if your process or situation changes, you’ll know which standards and preferences to change.

3. And one of those standards should be that every documented test should come with a statement of WHY that test was done. If you lose track of why you’re doing what you’re doing, your work with drift into uselessness.

http://www.geraldmweinberg.com

[Author]

Posts