While performing software testing tasks, a number of documents needs to be created/updated time to time and that seems very time consuming activity. As sometime it is important but we hardly re-use any related document after the build is released, per my experience. So, please advise if it is purposeful to spend time in maintaining such huge records or testing can be done without them.
If documentation is not specifically required by project or company process, you can try to reduce it and use just short lists of what was tested rather than full test case format.
From my experience completely ditching documentation is not a smart idea since you’ll want to have something as a reminder of what was done, especially if you work on several projects. I used to test without documenting work and now sometimes I have problems when I return to undocumented project after several months of inactivity.
If the application you are testing is only ever going to be used once by one person for a completely trivial purpose and never used again, then no documentation is required. In every other instance, some sort of documentation will be needed:
- When users report bugs in production but no-one who worked on the app is still with the company
- When version 2 needs to be developed but the guys who built version 1 have left the company
- When users need help or support in the ordinary operation of the app (traditional test scripts are actually very good for helping to create Help files or a wiki)
- When a third party (a client, a regulator, a lawyer, the police, the Government) requires evidence of tests performed or some other tangible guarantee of “quality”
- When a user blames the app for something bad happening and escalates their complaint to:
- Your CEO
- a court of law
- When something happens in real life (on a scale of 1 to 10 where 1 is “everybody is laughing at your company” and 10 is “somebody died”) and your company is blamed for it in the media.
These are the times when you will be thankful for your test documentation. I know, I’ve seen all of these (though fortunately, on the last one, my personal involvement was around a 5). Risk analysis will help companies and managers take a reasoned decision on just how much documentation is essential to create and retain. If your risk on the last one is a 10, then be prepared for a lot of printing which you hope no-one will ever look at again.
I’ve started using session sheets, which I’ve found useful. They include test methodology used, steps to reproduce any defects found etc. Hopefully they’ll help me identify things like how much time is wasted on setting up environments, configuring new features etc, so I can try and reduce time spent not actually testing. Also, if somebody is off ill etc, if someone steps into the breach, they’ll be able to continue incomplete work. It should also be a good resource for the rest of the team to be able to identify areas of testing that can be looked at in a different fashion, and provide a basis for any automated testing (I’m trying to get to grips with Selenium and have used my beautifully crafted steps to reproduce to create tests). Any defect found in session 1 (for example) and not resolved are copied and pasted into the defect section of the session 2 sheet and so on.
If it helps anyone (and maybe if anyone can make any suggestions for changes - one hand washes the other), the sheet contains the following:
Sheet name - Ticket #/session #
Name - staff member’s name
Purpose of session
Planning/Time Break Down
Session Notes - Notes on what and how things were tested. Defects are structured as DF-Ticket#Session#Defect# (eg DF-AA111001)
Defects - Defects identified (referring to reference #s above)
Issues/Debt - Anything that you haven’t been able to test, or anything that has prevented “proper” testing
I would suggest documentation is very important and main part of any testing project. Although, it seems time consuming and most of the software tester won’t like documentation as time spend on it is considered as non-productive. They feel better to spend time in exploring the functional phases of the application or product rather than sparing time in typing lengthy document.
Still any quality assurance company gives a lot of prominence to documents and considers it fundamental to an effective project. They have dedicated resources to maintain the documents at regular interval. A decent document, help guide and instruction notes etc. are considered as efficient and well-organized software testing practice and results in glitches free release.
We understand that verbal communication is quick. But, verbal miscommunication and lack of proper documentation could become reason for rejection of project proposals also, that means ultimate loss of capital and it can only be avoided with the help of effective documentation.
Some of the important documents includes:
- Software Requirement Specification should be client approved and all the product related requirements should be properly listed.
- Test Plan Documents are created to organize testing schedule, team involved, various resources required and it also covers testing scope etc.
- To perform regression testing, test data is required and if we have test data ready in a document then testing becomes easy and less time consuming.
- Test Case Specification document, bug Report Document, after release/post release document etc. are also important.
- Once the build is released per the specified requirements. The acknowledgement from the client is required in form of user acceptance document regarding, the release is accepted.
- Weekly/monthly status Report are there to maintain projects particulars like on track, delayed etc and should always be up to date.
- If daily stand up call with client is there, then to avoid any miscommunication between client and the organization MOM (minutes of meetings) should be prepared.
It does not matter how many documents are prepared but the main thing is, document should be accurate and transparent. A qualitative document is prerequisite for systematic testing approach and client satisfaction.
Hope this information is helpful for you.
Quite simply, documentation in some form is needed for a worst case scenario: What if everyone on the team won a mega lottery and quit (that’s better than the 'ole hit by a bus, train, etc. scenario)?
How would anyone know what to do, how to do it, any special consideration, where you left off, and the list goes on?
It’s also good for code reversion. Have you ever worked on a project where something was updated, then updated again because it wasn’t quite right, only to find that you had to revert back to the old way? I have. Proper documentation ensures that you know where you need to go back to and how it should work.
I could go on, and you might say that these are edge case scenarios, but they do happen in the real world.
Oh yes, I forgot the “lottery win” scenario. And I’ve seen that one, too. I once ran our team’s Lottery syndicate, and our Operations Director always smiled a nervously weak smile when he saw me collecting the stake money each week.
In a previous existence, he had been a hospital Chief Executive - and had arrived one Monday morning to find that the hospital had no midwives because their syndicate had won big time over the weekend. He lived in fear of lightning striking twice…
For me the amount of documentation needed is a product of your situation. I’ve worked in regulated domains with high requirements of tracability and in unregulated non-critical product development. You do not need to have the same level of documentation for these. Some learning from the regulated products are that the documentation you produce during testing is vastly superior to any documentation done prior. As an example a friend of mine worked on a fighter jet project, which in the latter stages had a spectacular crash in the middle of the city during a show. He was then very happy that he clearly could show that he had in fact tested the very thing that caused the crash and that it had been reported as a weakness, but was dismissed that a highly trained pilot would “never” do that. I’ve also had the experience that two different testers running the same documented test case have produced different results, i.e. one of them found some bugs where the other didn’t. They of course did not actually do the same thing during testing even if the followed the same test case. Hence the documentation that you can write while you test which aims to capture what you did is superior to the test cases for this purpose.
My suggestion is that you try to map out what your main objectives are in terms of using the documentation and then find the most suitable media for these cases. Such as if you only care about tracability during / post testing documentation is better. If you care about new people training there are some interesting options to. My favorites are guided learning and a knowledge map. The latter is sort of a catalog of who knows what, so when you need to know something you know who you need to talk to in order for you to learn about that. Another thing we have right now is a how to. If you want to know how you do a certain thing you follow the howto. This is way easier to maintain and new people can also contribute when they find any irregularities in the documentation. If you want to solve the bus factor (how many people need to be hit by a bus before you lose the knowledge), pair testing is far superior to documentation. For status reporting, test reporting there are both good options and tools that can help you.
tl;dr you documentation is can be improved by tailor make it to your situation
Documentation is another component of a software product of any self-respecting software tester firm. But not all organizations devote enough time to developing worthwhile documentation … Very often, we are not happy to deal with sensible software products and nondescript, incomprehensible and helpless documentary support.
In general, the documentation is created to be able to competently and without panic find a way out or solution to any arising problem situation for a person with the lowest knowledge of software development principles. From this principle it is necessary to make a start, thinking over the content and structure of our manuals.