In my 6.5 years of experience, what I noticed is that 'DOCUMENTATIONS' are the biggest helping hands for testers. The more you document and communicate, the more you grow as a tester and well of course verbal communications hardly involve the whole team and yes, they are lost over time. Believe me, we tend to be lazy thinking will document later and that later hardly comes, try avoiding this and even if you are busy find out some time may be 5 - 10 minutes to do the necessary documentations. Let me analyze the need of documentations - 'what? and why?' from the angle of the pillars of the QA process:
1. Requirement Analysis
When the requirement is published and freezed, read it very thoroughly and in parallel document the analysis point that are going to affect the testing. Also if you have any doubts about some features or functionalities, put them in the document or create a separate email and send across to the team or client. Always ask for replies over email as this will help for future reference. Having communication done over email helps a lot when in future we forget what was the answer; and more when the devs or the team contradicts then you can share the answers with the team to bring everyone on the track.
I mostly create FAQs page where I document the replies that I get from the client for my queries and that helps my team as well a lot.
2. Test Plan creation
It is practice which most of the projects follow that is to have the Test Plan documented and approved. But on the contrary many people feel this as an extra "not required" effort and rather try to discuss verbally and agree upon. This is wrong. Plans should always be documented and approved by the Manager. This helps a lot at release time when you are already under pressure and suddenly some things show up. At that ti you can refer to the plan and tell that this is what was decided and now if something more needs to be added then the testing tie will change or not everything will be tested and verified.
3. Test Case Creation
This is very very important documentation which all QAs should do. In my past experience I saw that the deadlines we so close that QAs were not given time to document their test cases also and when anything went wrong they were caught. This is bad. The Test cases should be documented well and reviewed by the TL / PM in case if something is missed. If the time is less at least try to document one line and share it with the team. I have even seen people who don't document just because they are confident enough about their mental capability that their mind is big enough to store. But we forget that tomorrow if we are asked to tell what we tested, it becomes difficult to convey.
Infact if possible it is eve better to have the Test Cases approved by the client, they are the best people to add if a part is missed out.
4. Test Data preparation
This may be required for everyone and is required mostly when the data preparation is a complex task and you are sort of trained on it.
I am seeing this, in my current project where I am the only person who knows the in and out of data preparation. In my absence my team should not be blocked so I have documented the test data preparation (which is preparing data in DB - quite complex) and I keep updating it frequently and sending it to my team.
5. Testing
While testing always add notes for test cases which are complex like how to executed and were there road blocks (not defects) from which you learn something out.
6. Test Report
A very important document which gives an outline of what all was tested or left out, defects verified or not verified with reasons. Now if the PM agrees on this then in future if you are questioned you can refer to the report.
All in all these are records of your work which the team accepted and agreed upon.
We need to have all these documented as 'always' tester is the first person to be questioned that why was this missed? Indeed this is a big question for which we don't have a reason because we didn't miss this intentionally. To avoid such questions I follow the above mentioned points very strictly and stay on a safer side because I have things noted with me and over communicated.
Try this out I am sure this will help to reduce these 'Whys'. :)
