Why Documentation is Important in Software Testing

This is a guest article by ‘Tejaswini patil’ – Associate QA Manager.

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 Test case, Test plan, status report, Bug report, project proposal etc.

Even I did not stress more on 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.

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 issue at Client side, which was 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 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

Software Testing 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 importance of documents.

But, if we observe then the fact is, projects that have all the documents have 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 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 importance of client and processes to individual and organization. Unless you are able to produce document that is comfortable to 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 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 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 for 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 for preventive actions
- Provide feedback for your planning cycle
- Create objective evidence of your quality management system’s performance

There are hundreds of documents used in software development and testing life cycle. 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 refer following documents:
1) Software requirement specifications
2) Functional documents

Summary:
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 safe side. Documentation will not only save you but also help 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 on you, but habit of documentation will certainly bring a systematic approach in your testing process, leaving the ad hoc testing behind.

I will soon post “Why doing it is Important” second part of this post.

About Author: Tejaswini patil
I am working with an E-learning organization as an Associate Manager QA.  I think I got very huge responsibility in very short span of my career due to my dedication towards work. I love my job and my team says I am very strict, but I feel if you want good quality you have to be. 

Over to you:
What other documents do you maintain in your daily testing activities?




Related Posts:

  • 10 Tips to Help You Achieve Your Software Testing Documentation Goal
  • Choosing Software Testing as your Career
  • Test Plan Template
  • ISTQB Foundation level exam Sample paper – III
  • ISTQB Foundation level exam Sample paper – II
  • 72 comments ↓

    #1 shruti on 03.07.10 at 6:34 pm

    Nice reading your experience. I too have faced same incidences in my career. Always keep written proofs for what you do or don’t do.

    Also having documents can help new team members to understand the project.

    #2 Ash on 03.08.10 at 4:30 am

    Its really a nice article & its very true.
    am working in a small organization of 20 people, we are only 3 tester here, so can you plz guide me which documents i should ask to development team or client ?

    #3 Hina on 03.08.10 at 5:23 am

    I strongly feel the need for same. Very nice article.

    #4 Mallikarjun.G on 03.08.10 at 5:24 am

    Hello Tejaswini, first let me say Thanks a lot to you for your effort.
    Documentation is an important not only to QA people, it is also important to Development team and organization, because it is a proof to client if we get any issues and important for future reference. Every document will have a particular piece of information. I will wait for your part II.

    #5 Sid on 03.08.10 at 5:56 am

    Nice work!
    You narrated very well about the importance of documentation. But, about the situtaion you had with your angry client, I don’t think that the proof of requirements document saved you (or QA team) from getting blamed. Almost every process oriented 0rganization maintains designing the requirements document. In your case, instead of searching through all the requirements documents, the best practice could be looking at Traceability Matrix document, through which you could easily identify if there is any such requirement from the customer and if so, have we addressed it or not.
    I also feel that, requirements document is not a work product of tester’s effort. However, tester can verify it for the correctness of same.
    As I said earlier, you did a great job on posting this article. I also agree that most of them in the team have an impression that the documentation is a free time work. To vanish this myth, tester should be more creative to prepare effective documentation. To derive effective scenarios they should speak to SMEs/BAs/Sr.Developers to understand the customers business process well. In our agile process, we use user stories in preparing test cases.

    Once again, thanks for sharing the info and keep up the good work.

    Best Regards,
    Sidhartha

    #6 Vyas on 03.08.10 at 6:03 am

    Nice and informative tejaswini.
    Thnx for the nice post and looking ahead for your next.

    But what ever you have suggested is an ideal case but in real time the actual documentation(i mn user guides, TRR etc) will be prepared only during I cuts or at the last phase of the projects, so my query here is..Can we(QA) refer to SDS and Functional specs for writing test strategy and in turn test cases documents?

    #7 Ash on 03.08.10 at 6:10 am

    Urgent opening !!

    Domain Web Development
    Technical skills required LAMP, PHP Lead, Ajax, Drupal, Joomla , Smarty, PEAR and PECL libs, HTML, XHTML

    Experience 1.0 to 2.0 Years

    Salary As per Industry standards [Negotiable]

    No. of Job Positions 06

    Role Software engineer
    Additional Skills required Good command over written & verbal ENGLISH communication.

    send your CV’s on anju_2085@rediffmail.com

    #8 Ash on 03.08.10 at 6:34 am

    Above opening is in Pune

    #9 khushboo on 03.08.10 at 7:09 am

    great article. Documetation are important as provide lot of information. For QA, documentation can be a protective cover or proofs to prevent any blaming.

    #10 Tejaswini on 03.08.10 at 7:29 am

    Hi Vyas,
    Surely we can use Functional Spec doc to write test cases, but you can cover only functional test cases from that. You need a brief workflow to understand the system.

    #11 Tejaswini on 03.08.10 at 7:31 am

    Hey Sid,

    Thanks for your reply. Appreciate your comment on the post. Yes yo are right that only requirement document can’t save us, but i must say, it’s better to have something than nothing.

    #12 Pradeep V on 03.08.10 at 7:54 am

    Hi Tejaswini,

    Great work ! Very useful article about Documenting.
    Thanks.

    #13 sripraveena on 03.08.10 at 8:19 am

    hi sid ,

    ur points looked very valid, and thnkx for the updates

    #14 Aman on 03.08.10 at 8:48 am

    good one!!

    #15 Amit Anand on 03.08.10 at 9:20 am

    HI Tejaswini,
    Nice article. Actually in CMM level companies they have document for every thing. They have defined process to follow as Sidartha mentioned above, but still we should practice it religiously. I am giving you an exmaple of my own why this habit is imp.

    When i switched to CMM level 5 from a small organization, I wasn’t much disciplined about documents. I had to work on very confidential defense project and that also was complete and about to release. I worked hard and got many defects. My team was happy with my efforts and they fixed all critical defects. Client approved our project and our software was best. (There were several other organizations in the race).

    After finishing all this when i was back in office QA people asked me to start document related process.(Actualy when i had joined i don’t had enough time to maintain all documents)

    God i found myself lost in document jungle and worst part was i had forgot half of defects i had found.
    Thankfully my team ( development team) was very helpful and QA ppl were little friendly i completed all with their help.

    So now onwards i never go without proper documents.

    #16 Sid on 03.08.10 at 10:03 am

    Just noticed the last section of your article – ‘What other documents do you maintain in your daily testing activities?’. Sorry for missing that. Ours is a SCRUM, an agile development approach. We spend very less time on documenation. We interact a lot with the developers and product owners to get the requirement details. According to those requirement details, we first prepare a TAD (Test Approach Document) in which tester describes the feature he/she is testing. Provides a brief description on the functionality before and after adding the feature, what needs to be tested, exit criteria, for what scenarios the automation scripts are covered and this document will be get verified with the developer and product owner. If they feel that everything is covered then we go ahead with testing. Or it will be adjusted with any changes they suggested.
    While preparing TAD, tester gains more functional knowledge and also user stories from the product owner helps the tester to understand the business process specific to the customer. Individuals are never blamed in our process because TAD has been reviewed by fellow testers in the team and also with the Developer and Product Owner.

    Best Regards,
    Sid

    #17 Tejaswini on 03.08.10 at 10:20 am

    Interesting. Just a query, how processes fits in Agile methodology, as i m very new to this concept, just want to know more about this.

    #18 Rajesh on 03.08.10 at 11:27 am

    Tejaswini

    Nice article really stresses the importance of the documention.

    I had also worked in a ajile project as a lone QA. I liked the term user story as did mentioned by Sid because it’s more I had came across. In my project I can say there was no SRS. Infact it was the mails from the client (technical client) & discussions over the phone. Basically our(test + dev team) clarifications & queries were answered and I just derived the test cases from from the same. At the signoff the only documented stuffs which supported the project is the test cases, bug report & test execution report. We are not dealing with the end client directly…
    My project is released by phase by phase. As I documented the defect leakage, It helps me in the comparison with next phases and just shared the same with all…

    #19 Monica on 03.08.10 at 10:45 pm

    Hi,

    Liked your article..

    I am working on an AGILE project. We maintain the requirements of a story on the twiki. This helps multifold- requirement sign-off, requirement traceability, test automation traceability.

    The thumb rule is to question yourself about the benefit of each and very documentation you or your team works on..Ask yourself Why is this required? How will the organisation/ stakeholders benefit from this? What will be it contain? How often will it be updated? Who will update it?…..

    For e.g, in AGILE we don’t document test plans as they are outdated as soon as they are documented. The test plans are made daily in the stand-up meeting..

    #20 karthiga on 03.09.10 at 4:04 am

    Hi Tejaswini

    I am fresher in testing from non IT background. your post is very helpful for people’s like me . it gives the importance of documentation

    Thank u……………………………

    #21 Nigar Sultana Kana on 03.09.10 at 4:44 am

    Dear Tajeswini Da,

    Thanks for your useful and helpful topics. I have some questions dada,
    1. When and why testing plan is necessary?
    2. Who is responsible for test plan (tester who is beginner or what level of tester) ?
    3. When test plan start and stop?
    4. What types of problem I have fetched if I dont have any test plan?

    The answer is helping me to get clear idea about test plan.

    Thanks,
    Nigar Sultana Kana

    #22 Jayashree Dhumal on 03.09.10 at 7:24 am

    Hi

    It is true that documentation is necessary as it help the tester to understand the things whenever it is needed and the way it is working and do not have to keep the same in the memory.
    I always use to maintain document for each testing phase/ testing module etc. And I used to ask my team also to do so. This document helps other team members to understand easily and in very less time. People call me strict but for maintaining good quality one has to do it.
    But I always feel if one has made the mistake the other person should not do the same mistake and let him make another mistake but it should be documented along with the solution this will achieve quality and understanding level.
    Why I said ‘Let him make another mistake’ as generally 99% of people learn from mistakes.

    #23 Madhu Krishnappa on 03.09.10 at 1:10 pm

    We generally used to send out open clarifications through emails. Our client on the other side of the globe, either answered through email replies or over the status call.

    Later when testers or BA at client side logs a ticket or makes issue out of any behaviour that is earlier being clarified, we had to search for the clarifications answered, date, person answered, etc…

    To avoid all this, now we have a single clarification excell file. Any clarifications that goes between offshore and client, vice versa is documented here. And this is our first point of reference in case of bugs\issues.

    The above is one of documents that we maintain and track.

    I see, you have missed out tracebility document. This helps us during impact analysis.

    Thanks,
    Madhu K

    #24 Shrinivas Patil on 03.10.10 at 8:20 am

    Hi Tejaswini,
    Really a nice article.
    It gives more clear idea about the documentation process which generally do not get follow in small companies like ours.
    But after going through this article it gives more clear idea why the documentation is really important.
    Keep posting up.

    #25 Tejaswini on 03.11.10 at 5:56 am

    @ Nigar Sultana Kana

    Thanks for your appreciation.

    You might get all your questions answers in my next article.

    #26 Aishwarya on 03.11.10 at 10:33 am

    Want to know about Test Strategy? how it is different from test plan? please give me details for what test strategy documents contains possible with example?
    email – aishwarya.koche@gmail.com

    #27 linu on 03.24.10 at 7:41 am

    documentation is a vital reference for the future releases as well

    #28 Shafu on 03.24.10 at 3:36 pm

    Yes, a properly documented software always get success in teh market and also saves the developer as well as the QA Person. 100% agreed

    #29 ash on 03.26.10 at 11:26 am

    vijay, why dont u block this “AROON”

    #30 manu on 03.29.10 at 9:56 am

    Hi,
    i have worked with an organization where documentation was everything but now in my new org there is nothing like that and i am very much here for everything they say “we should have done this but didn’t do” i am very new to the org and joined as a test lead don’t want to cont.. they way everything is manage here can u please suggest me what should i do

    Manu

    #31 manu on 03.29.10 at 9:59 am

    Hi,
    i have worked with an organization where documentation was everything but now in my new org there is nothing like that and for everything about documentation they say “we should have done this but didn’t do” i am very new to the org and joined as a test lead don’t want to do the same as the way everything is managed here can u please suggest me what should i do

    Manu

    #32 Advait on 03.30.10 at 7:34 am

    Hi tejashwini,
    first let me say Thanks a lot to you for your effort. You narrated very well about the importance of documentation.Few months back only I have started working as a QA engineer. Right now I am working with very small organization here we don’t prepare any documentation for testing purpose. But after reading your article, I am going to start maintaining documentation for each and every small things.

    Once again, thanks for sharing your knowledge and your experience.

    #33 Advait on 03.30.10 at 7:37 am

    Hi Tejaswini,
    first let me say Thanks a lot to you for your effort. You narrated very well about the importance of documentation.Few months back I have started working as a QA engineer. Right now I am working with very small organization here we don’t prepare any documentation for testing purpose(other than test report and bug report). But after reading your article, I am going to start maintaining documentation for each and every small things.

    Once again, thanks for sharing your knowledge and experience.

    #34 Tejaswini on 03.30.10 at 8:14 am

    @ Manu

    Thanks for your appreciation
    Take your current work and organization as challenge and start from yourself. When you could able to show the importance of processes and documents to your organization then definitely they will start using it.
    That’s what i can suggest

    #35 Tejaswini on 03.30.10 at 8:16 am

    @ Advait
    Thanks for your comments, It’s rally a nice feeling that after reading my experiences at least once person started implementing it.

    Thanks a lot

    #36 Abrar khan on 03.30.10 at 10:53 am

    Thanks for such nice explaination about testing document it will be really very helfull for me.

    even you other topic also very usefull.

    over all i would like to says that all information about software testing posted by you is accurate.

    Thanks lot..
    Abrar khan

    #37 Advait on 03.31.10 at 5:19 am

    Hi tejashwini,
    I need your help i have one query, Most of the times we wont get enough time to perform testing in detail, in that case we perform Ad-hoc testing.So while performing Ad-hoc testing which kind of documents we should maintain? Which things we should note down for further reference?

    #38 VNK on 03.31.10 at 7:47 am

    @ Tejaswini

    Dear Tejaswini,
    I am working as a Manual Tester in small organizasion. They are not providing any documents. Simply they use to explain about modules and they assign to test it. Can I know how and what are the documents can we maintain at this situation. Pls tell me the proper procedure. Thanks in advance…

    #39 rajani on 03.31.10 at 6:13 pm

    nice article about documentation.what is the first document we produce from the testing department

    #40 Tejaswini on 04.01.10 at 10:13 am

    @Advait

    While doing Ad-hoc testing i used to prepare my own document which contains the major functional part or the major areas which client/manager wants us to highlight, like, OS you used, or any major functionality part

    I hope it answers you query

    #41 Tejaswini on 04.01.10 at 10:15 am

    @VNK

    There are lists of documents you will find on softwaretestinghelp.com :)

    #42 Advait on 04.01.10 at 11:24 am

    Hello Tejaswini,
    Thank you very much. Now i got rough idea.I will try to maintain such kind of documents while doing Ad-Hoc testing. If i get any doubt while preparing such documents i will get back to you.
    I hope you will clear my doubts.

    Thanking you.

    #43 VNK on 04.02.10 at 7:52 am

    @ Tejaswini,

    Dear Tejaswini,

    I need some help from you. I want to know which is the best procedure when our organization does not have base documents. As usually I use to understand about module by exploring or interacting with developer. After that I use to prepare test cases and execute. I use to prepare bug report if I find any. Is it enough ??? or anything else??? Pls let me know.

    #44 vruti on 04.02.10 at 9:37 am

    Hello Tejaswini,
    I am working with a product based company since 6 months. I am the only tester and multiple projects are there.
    but there is complete absence of documentation, so its difficult to make test cases.and no test process has been defined.
    can you pl suggest me how do i test my projects efficently? or give some testing tips. thanks a lot in advance.

    #45 Vikas Patil on 04.03.10 at 9:00 am

    Hi,Tejaswini
    Thanks for giving information for testers,this is very good work for giving the knowlege about the testing.

    Thanking you.

    #46 Kirti Vidhani on 04.05.10 at 8:46 am

    Hello Tejaswini,

    Thanks for sharing importance of Documentation.

    This is true that it is a responsibility of the QA to create/ update all project related document.

    #47 Ningangouda patil on 04.07.10 at 2:01 pm

    Hi Tejaswini,
    A very worth reading article.Thanks for sharing

    #48 Nagaraj on 04.09.10 at 5:00 am

    Hi all,
    All your document related articles are very useful to all and especially to me.Thank you all

    I’m staying in bangalore.I’ve been worked as a java developer for 2 years then they put me in to performance tuning and testing side.I have learnt some online tools,plugins and IBM Rational performance tester tool which is related to performance testing.I have around 6-8 months in this.This is purely technical testing.Now i’m confused whether i have to continue into performance testing itself or again going to developing side.can anyone tell me which is best? Performance tester carreer is better than developer?
    Please reply as soon as possible.I’m planning to switch other company.If performance testing carrer is good then do i need to take any course.

    Waiting for your reply,
    Nagaraj
    “We won’t get anything without we try it”

    #49 Aravind on 04.14.10 at 5:42 am

    Hello Tejaswini,

    HI Tejaswini i got some important of documentation in ,manual testing .but one thing can explain the for every organization follow the same documentation or not iam still not confirm.so please explain.but your done a great job yaar. after user acceptance testing is there need any tester or not .

    #50 VNK on 04.15.10 at 5:09 am

    @ anybody

    I need some help from you. I want to know which is the best procedure when our organization does not have base documents. As usually I use to understand about module by exploring or interacting with developer. After that I use to prepare test cases and execute. I use to prepare bug report if I find any. Is it enough ??? or anything else??? Pls let me know.

    #51 vandana on 04.19.10 at 4:46 am

    Thats really a nice article.

    #52 Advait on 04.26.10 at 8:31 am

    Hi Tejaswini,
    Can you give me any brief idea about IEEE 829 test plan documentation standards?

    #53 Sanju on 04.30.10 at 7:07 am

    hi

    cool. very good ariticle. appreciate your efforts achievments

    #54 Vikas Patil on 04.30.10 at 9:29 am

    Can you give me brief description of test planning,so what is a test plan?
    What is risk management?

    #55 Tejaswini on 05.03.10 at 4:13 am

    @ Vikas Patil

    Test Plan is nothing but a brief review what we want to do in project, what methodologies we want to follow, who are the team members working and all, and do remember to update test plan if requirement changes, you can include risk assessment in Test plan itself

    #56 sarada on 05.08.10 at 12:05 pm

    Let me also join in this group

    #57 anandsai on 05.08.10 at 12:09 pm

    Hi

    It’s really interesting and seems to be motivation for testing people and like to join in this group

    #58 Mallikarjun PATIL. on 05.18.10 at 9:14 am

    HI Tejaswini,

    Nicely explained about the importance of the Testing documents, it’s true that we must require to prepare testing documentations before the testing task implementation for the successful testing.

    Regards
    Mallikarjun PATIL.

    #59 Tejaswini on 05.19.10 at 9:23 am

    @Mallikarjun

    Thank you

    #60 Raghu on 05.21.10 at 7:12 am

    Nice article. Thank u…

    #61 RKVasa on 05.21.10 at 7:35 am

    Very Nice.. Clearly Explained with an realtime example… Thanks a Lot…..

    #62 RKVasa on 05.21.10 at 7:35 am

    Very Nice.. Clearly Explained with a realtime example… Thanks a Lot…..

    #63 kyaaks on 05.21.10 at 1:08 pm

    Very Nice article….Thank You

    #64 Meher on 05.27.10 at 8:46 pm

    Hi Tejaswini
    I appreciate your effort in letting people who are working it IT know how important is documentation.
    I work for a CRO in U.S as a Test Manager in a highly FDA regulated environment. According to FDA “Nothing will be understood as being done if you haven’t produced enough documentation around it”.
    And also it is always safe and required to have appropriate documents around and about a system/software through out its life cycle for reconstruction of the scenario(s) which is in question.
    Coming to creation of documentation you have to use your due diligence to include what has been done and how.
    I think the process of Testing a system or a software is more contextual rather than what we can define in a generic way.
    I also want to acknowledge and extend my gratitude to those who took their valuable time to add their experiences which are worth knowing and amazing.
    I like to be a part of these type of eConversations as you have always much more to learn about.
    Regards
    Meher

    #65 Mayasen on 05.28.10 at 4:43 am

    Hi teja..

    Its very nice about your article. Even me too faced some bad experience in my initial projects because of lack of documentation.

    Thanks for this post.

    #66 Mayasen on 05.28.10 at 4:48 am

    Hi all,
    As teja mentioned, documentation is very must.

    # Apart from that we’ve to develop the good practice on maintaining documents.

    Eg:
    * Maintain proper folder structure,
    * Maintain consistence format in naming the files,
    * Placing the proper files in proper (related) folders, etc.

    # Version should be maintained for all documents (possible with dates/correspondence/source/etc.)

    #67 Mounesh Panchal on 06.02.10 at 4:56 am

    Awesome article and thanks a lot for sharing ur huge experiance with us

    #68 Tejaswini on 06.02.10 at 5:24 am

    Thank you all

    #69 Tejaswini on 06.02.10 at 5:25 am

    @ Meher
    Thanks for sharing your experiences

    #70 Anuradha on 06.26.10 at 3:38 am

    Very nice artical…keep on adding as much experience as u can..Thanx 4 sharing ur experience.

    #71 Bimal on 06.29.10 at 4:57 am

    Really nice article… Thanks. Throws light on the importance of documentation in testing, really useful

    #72 Prakash on 07.06.10 at 1:42 pm

    Amdocs Pune is having opening for Telecom / non telecom manual testing .. exp 1-3.5 yrs

    send me CV asap if u r interested
    pikkuvaswani@gmail.com

    Leave a Comment