I believe that if you are going to do a business with partner you should document it. I have bitter experience in business which ended into of no use because I used to have no documentation with partner. I have seen myself many times believing in words of mouth, not only in business but at many special occasions which should be documented but I did not and believed in words or mouth which ended in problems. Documentation plays an important role in many parts of life which I believe in that I should not ignore.
When I started my career with information technology industry, I have always heard documentation is important for successful implementation. I remember my first project for successful mplementation was Total Productive Maintenance and I was said by my team lead to provide him data flow diagrams for whole process.
It took me about half of month to collect information from technical people (non technical under terms of IT) in industry. Once I finished with collecting information, I sat back to chair and it took me about week or so to prepare data flow diagrams. Now the moment was to present and I got valuable appreciation from director of project.
Despite of appreciation, I followed those dataflow diagrams and I still remember TPM was the only project which was successful with respect to other ERP modules. I did not mean that I was going to suppose that TPM was only successful module, but management always wanted to say this during weekly meetings among whole ERP team.
For me it used to have many flaws which I should have covered. What I mean to say that documentation of any type plays important role and should not be ignored. Software testing is part of software development life cycle and cannot be ignored because of its importance for successful implementation.
What was becoming a big problem for me at the time of implementation were defects we were suffering with. What we was lacking in whole process was software testing depart which was creating problems for whole team.
End users tend to always complaint about defects and I always thought they were right. I highly appreciate whole team who was really cooperative from director to end users, especially many good words about development team which was cooperating with me at every critical stage to remove bugs and defects.
In software testing documentation is key to keep the things in black and white. What makes documentation without any importance for team is low budget project. Project managers are handed over with small budget projects (in our case software for test) and they tend to complete it quickly to save time and resources.
To some extent they are right and it also comes up with results, but I still believe that documentation is important even for small budget projects as well. A professional software testing company should follow documentation for small to big projects.
Let us learn by a case study how documentation is important even for a small software testing project. Let me put the characters into it as well. My project manager David Ibrahim wants me (Moses Adam) to test three pages website.
He calls me on Skype and says please manually test www.domain.com and come back to me once you are done within x hours. Please remember my project manager is not going to handover me any requirement doc, because he lacks it. I started testing it manually and found 3 functional and 2 GUI bugs with in stated x hours.
My project manager David tells client we have found 3 functional and 2 GUI bugs and are ready to fix them. Client says OK go for it, PM David informs software development project manager John and he fixes them within said time frame. Project ended and money is transferred.
After couple of days client talks to test PM David that there is still one more functional bug which has been reported to him by one end user. PM David is not ready to accept his fault and client seems to be with no satisfaction. We all understand project delivery without client satisfaction is company loss.
David calls me client has found a functional bug him/ herself. I tended to say I could find only 3 functional and 2 GUI bugs within given x hours. I am not sure about what was communication between my PM and client.
Thing which ended in such a stress is rewarded time for this job, but I could feel there is also a communication fault between client and PM. PM considered it a small project and did not tend to document requirements because of budget and client was expecting something out of the box.
What was needed to be done was ‘Requirement Doc’ which should have written down so that both the parties should have clear black and white. It is my personal experience that a small budget client wants out of the box results in small budget and PM wants to deliver project in time, which later ends into problems like stated above. I want to share famous Chinese proverb with you at this stage:
“Ink is better than best memory”
It is true is not it? What we have learned with above case study that documentation in software testing is must for small to big projects. You are offering automation testing services, functional testing services, database testing services or any other type of software testing services, documentation is must. It will be good to share the important documents we need to write down for successful implementation of software testing project:
• Test Plan
• Test Design & Test Specifications
• Test Strategy
• Test Summary Report
• Weekly Status Report
• Manuals
• User Acceptance Report
• Risk Assessment
• Bug Report
• Test Data
• Test Analysis
It seems to be a big documentation plan is not it? But we have to follow it being a professional software testing company or an individual. I believe in that maturity comes with time and learning never ends. Keep learning about software testing and will be good to join software testing forums to learn more. I do not feel myself Mr. Perfect and I think I should keep learning and learning. Do not forget to join SQA forums.
Faizan Ahmad
About the Author:
This article is posted by Faizan who is the Author and Founder of TechSenser. He is a Professional Blogger from India and a passionate writer about Technology, Gadgets, How-to-Guides, etc. You can connect him on Google+.
When I started my career with information technology industry, I have always heard documentation is important for successful implementation. I remember my first project for successful mplementation was Total Productive Maintenance and I was said by my team lead to provide him data flow diagrams for whole process.
It took me about half of month to collect information from technical people (non technical under terms of IT) in industry. Once I finished with collecting information, I sat back to chair and it took me about week or so to prepare data flow diagrams. Now the moment was to present and I got valuable appreciation from director of project.
Despite of appreciation, I followed those dataflow diagrams and I still remember TPM was the only project which was successful with respect to other ERP modules. I did not mean that I was going to suppose that TPM was only successful module, but management always wanted to say this during weekly meetings among whole ERP team.
For me it used to have many flaws which I should have covered. What I mean to say that documentation of any type plays important role and should not be ignored. Software testing is part of software development life cycle and cannot be ignored because of its importance for successful implementation.
What was becoming a big problem for me at the time of implementation were defects we were suffering with. What we was lacking in whole process was software testing depart which was creating problems for whole team.
End users tend to always complaint about defects and I always thought they were right. I highly appreciate whole team who was really cooperative from director to end users, especially many good words about development team which was cooperating with me at every critical stage to remove bugs and defects.
In software testing documentation is key to keep the things in black and white. What makes documentation without any importance for team is low budget project. Project managers are handed over with small budget projects (in our case software for test) and they tend to complete it quickly to save time and resources.
To some extent they are right and it also comes up with results, but I still believe that documentation is important even for small budget projects as well. A professional software testing company should follow documentation for small to big projects.
Let us learn by a case study how documentation is important even for a small software testing project. Let me put the characters into it as well. My project manager David Ibrahim wants me (Moses Adam) to test three pages website.
He calls me on Skype and says please manually test www.domain.com and come back to me once you are done within x hours. Please remember my project manager is not going to handover me any requirement doc, because he lacks it. I started testing it manually and found 3 functional and 2 GUI bugs with in stated x hours.
My project manager David tells client we have found 3 functional and 2 GUI bugs and are ready to fix them. Client says OK go for it, PM David informs software development project manager John and he fixes them within said time frame. Project ended and money is transferred.
After couple of days client talks to test PM David that there is still one more functional bug which has been reported to him by one end user. PM David is not ready to accept his fault and client seems to be with no satisfaction. We all understand project delivery without client satisfaction is company loss.
David calls me client has found a functional bug him/ herself. I tended to say I could find only 3 functional and 2 GUI bugs within given x hours. I am not sure about what was communication between my PM and client.
Thing which ended in such a stress is rewarded time for this job, but I could feel there is also a communication fault between client and PM. PM considered it a small project and did not tend to document requirements because of budget and client was expecting something out of the box.
What was needed to be done was ‘Requirement Doc’ which should have written down so that both the parties should have clear black and white. It is my personal experience that a small budget client wants out of the box results in small budget and PM wants to deliver project in time, which later ends into problems like stated above. I want to share famous Chinese proverb with you at this stage:
“Ink is better than best memory”
It is true is not it? What we have learned with above case study that documentation in software testing is must for small to big projects. You are offering automation testing services, functional testing services, database testing services or any other type of software testing services, documentation is must. It will be good to share the important documents we need to write down for successful implementation of software testing project:
• Test Plan
• Test Design & Test Specifications
• Test Strategy
• Test Summary Report
• Weekly Status Report
• Manuals
• User Acceptance Report
• Risk Assessment
• Bug Report
• Test Data
• Test Analysis
It seems to be a big documentation plan is not it? But we have to follow it being a professional software testing company or an individual. I believe in that maturity comes with time and learning never ends. Keep learning about software testing and will be good to join software testing forums to learn more. I do not feel myself Mr. Perfect and I think I should keep learning and learning. Do not forget to join SQA forums.
Faizan AhmadAbout the Author:
This article is posted by Faizan who is the Author and Founder of TechSenser. He is a Professional Blogger from India and a passionate writer about Technology, Gadgets, How-to-Guides, etc. You can connect him on Google+.
