Software Testing Documentation Guide:
In my Software Testing career, I never heard people talking much about software testing documentation. The general opinion about testing documentation is that anyone who has free time can do the documentation like a Test case, Test plan, status report, Bug report, project proposal etc.
Even I did not stress more about the documentation, but I can say it’s my habit to place all the data in black and white and to update others about that as well.
What You Will Learn:
Just want to share my experience with you:
We had delivered a project (with an unknown issue in that) to one of our client (angry client). And they found the issue at a Client-side, which was a very bad situation for us, and as usual, all blame was on QA’s.
The issue was something regarding compatibility of one website. When it came to me, I was having proof that I didn't get such requirement document which state I have to check compatibility of the website also. Thank god I was safe.
That was the lesson for me, I realized the importance of documentation and from that day I started to work on documents and created testing documents like Test plan, Test cases, sanity testing checklist, bug report and many.
“Ink is better than the best memory” – Chinese proverb
Test Documentation: What’s that?
We all read various articles on testing technologies and methods, but how many of us have seen articles on documentation? No doubt there are few, Is it that documents are not important? No, but its’ because we have not yet realized the importance of documents.
But, if we observe then the fact is, projects that have all the documents have a high level of maturity. Most companies do not give even a little importance to the documentation as much they give to software development process. If we search on the web then we can find various templates on how to create various types of documents. But how many of them are really used by organizations or individuals?
Fact is that careful documentation can save an organization’s time, efforts and money. While going for any type of certification, why there is stress given on documentation, it’s just because it shows the importance of client and processes to individual and organization. Unless you are able to produce a document that is comfortable to the user no matter how good your product is, no one is going to accept it.
It’s my experience, we own one product, which is having a bit confusing functionality. When I started working on that I asked for some help documents to Manager and I got the answer “No, we don't have any documents” Then I made an issue of that because as a QA I knew, no one can understand how to use the product without documents or training. And if the user is not satisfied, how we are going to make money out of that product?
“Lack of documentation is becoming a problem for acceptance” – Wietse Venema
Even same thing is applicable to User manuals. Take an example of Microsoft, they launch every product with proper documents, even for Office 2007 we have such documents, which are very explanatory and easy to understand for any user. That’s one of the reasons that all their products are successful.
In small companies, we always heard “project rejects in proposal or kickoff phase” it’s just because proposal documentation lacks concise and expressive language, and to show the capability of the organization. It’s not that small companies can't deliver good quality projects but it’s their inability to express their capability. (Me also working with a small organization of 80 employees, and I heard this many time)
I personally feel Quality is the only department that can make it possible. We are the only department, which can argue on this and can provide successful future to our organizations.
Let’s organize all discussion in few points in quality perspective:
– Clarify quality objective and methods
– Ensure clarity about tasks and consistency of performance
– Ensure internal co-ordination in client work
– Provide feedback on preventive actions
– Provide feedback for your planning cycle
– Create objective evidence of your quality management system's performance
10 Tips to Help You Achieve Test Documentation Goal
As I mentioned in my earlier post, in general, understanding about software testing documentation is “It can be done only by the person who has free time”. We need to change this mindset, and then only we can leverage documentation power on our projects.
It’s not that we don’t know how to do the documentation right. We just don’t think it’s important.
Everyone must have standard templates for all the kinds of documentation starting from Test strategy, Test Plan, Test cases, and Test data to Bug report. These are just to follow some standards (CMMI, ISO etc.) but when it comes to actual implementation how many of these documents are really used by us? We just need to synchronize our quality process with documentation standards and another process in an organization.
The simplest thing to follow all kind of documentation is to involve a person in the project from kick-off phase who understands the project dynamics, domain, objective, and technology. And who else better than a QA person for this (of course there are technical writers present to do this – but considering a general scenario of small companies where technical writers are not present).
To achieve this goal of testing and documentation I feel we need to focus on some points.
Here are the top 10 tips to help you achieve test documentation goal:
#1. QA should involve at the very first phase of the project so that QA and Documentation work hand in hand.
#2. The process defined by QA should follow by technical people, this helps remove most of the defects at a very initial stage.
#3. Only creating and maintaining software testing templates is not enough, force people to use them.
#4. Don’t only create and leave the document, Update as and when required.
#5. Change requirement is an important phase of project don’t forget to add them to the list.
#6. Use version control for everything. This will help you manage and track your documents easily.
#7. Make defect remediation process easier by documenting all defects. Make sure to include a clear description of the defect, reproduce steps, affected area and details about author while documenting any defect.
#8. Try to document what is required for you to understand your work and what you will need to produce to your stakeholders whenever required.
#9. Use the standard template for documentation. Like any excel sheet template or doc file template and stick to it for all your document needs.
#10. Share all project related documents at a single location, accessible to every team member for reference as well to update whenever required.
I am not saying that by applying steps you will get sudden results. I know this change won’t happen in a day or two, but at least we can start so that these changes start happening slowly.
After all “the documentation needs documentation”. Isn’t it?
There are hundreds of documents used in software development and testing lifecycle.
Important Software Testing Documents
Here I am listing few important software testing documents that we need to use/maintain regularly:
1) Test plan
2) Test design and Test case specification
3) Test Strategy
4) Test summary reports
5) Weekly Status Report
6) User Documents/ manuals
7) User Acceptance Report
8 ) Risk Assessment
9) Test Log
10) Bug reports
11) Test data
12) Test analysis
Also, Software testers regularly need to refer following documents:
1) Software requirement specifications
2) Functional documents
Software Testing Documents always play an important role in Project development/testing phase. So always keep things documented whenever possible. Don't rely on verbal communication. Be always on the safe side.
Documentation will not only save you but also help the organization in long run saving thousands of dollars on training and more importantly on fixing issues caused due to lack of development and testing documents.
Don’t document just to avoid finger pointing at you, but the habit of documentation will certainly bring a systematic approach to your testing process, leaving the ad hoc testing behind.
About Author: This article is written by STH team member Tejaswini. She is working as a QA manager in an organization.
What other documents do you maintain in your daily testing activities?