Do you believe that software errors occur only once and that on being fixed they never resurface? I feel that about 30% of the errors reoccur.
In this article, I want to cover how important it is to document some of the frequently encountered errors.
Below, you will find some common areas where issues are seen and a template to document them.
Hope you will find it helpful!
Code is deployed and ready for QA. John, the tester is ready with his test cases. Part way through testing, he comes across an issue. He feels it was noticed several times earlier, but John didn’t know how to resolve it.
Both John and Sheryl went to look for Smith who had seen the same error earlier and had resolved it before. Unfortunately, Smith was on leave that day.
What should John do now? Should John try to reach out to Smith to find a resolution even when Smith is unavailable?
Therefore, if an environmental issue is seen repeatedly across multiple releases, it is a good idea to document the details and place it at a shared location. This will eliminate the dependency on any one individual and helps all team members find a resolution by themselves when this happens.
John is testing a new release and comes across a known error again. This time, he knows that a defect was created for it in one of the past releases. But the question is: “how do I find the defect number and other associated details?”
In this case too, what do you think would help John?
- Search for the defect in Defect tracking tool with the description?
- Search all past defect reports?
- Approach his team lead for assistance?
These are possibilities.
But in my opinion, if such issues are well documented in a separate area and shared with the team, it adds value and saves time.
What You Will Learn:
Some of the areas with frequent errors:
1) Parameter File – Based on my experience with the Informatica tool, on many instances I have noticed the param file pointing to an incorrect DB connection. It has resulted in the same issues multiple times. The main reason was that the connection was shared between dev and QA. So, param file always had to be updated as per the needs to avoid the error.
2) URL Pointing to incorrect DB
3) Access Issues – Users run into problems when they have insufficient or incorrect access permissions to the DB or In this case, a document outlining the steps to be taken or person/persons to be contacted would be super helpful.
4) Test Data Issue – Using incorrect format or values of data will more often than not result in issues.
5) DB Issues – DB connection timed out is one such common problem. Some of the downtime is temporary, planned and sometimes, we might need DBA’s assistance. Users are notified in advance for planned maintenance but for temporary errors and resolution, the testers definitely need
Most repeated errors are generally environmental issues.
However, code issues can’t be ignored. The above discussion is generic and does not include code issues because code issues are more specific to your application, framework, programming language, etc.
A small area of defects could also be data entry or human usage mistakes.
Download Templates to track frequently encountered errors
=> Download error tracking template (World)
=> Download error tracking template (Excel)
Benefits of Documenting frequently encountered errors
1) Eliminates dependency – In Scenario 1, John was dependent Smith for resolution. Had there been a document for John’s reference that would not be the case.
2) Faster turnaround – Take scenario 2. A tester would not have to go through the entire list of already logged defects if there was a dedicated document for high-frequency problems.
3) Helps new team members be self-sufficient
4) Assists in resolving human errors
I would say it is definitely beneficial to document the more frequent problems as it would make a wonderful reference and a value-add.
It may become tedious to document while test execution is in progress, but as a best practise, rough notes can be taken during execution which can later be summarised and updated in shared documents.
Suggested reading =>> How to Document Function in Python
8 thoughts on “This Scenario Explains How Important It is to Document the Frequently Encountered Errors”
Nice information. Same I have faced during last project. mainly it will happen when there are multiple team working for same project in different location.
Very good template. Thanks for the details.
Nice article, almost everyone face this issue not only in terms of errors also in terms of finding a solution for problems. Creating proper documentation and managing on day to day basis is a real challenge but worth putting efforts in this to increase productivity
we should also have a process to minimize these errors if these are occurring again and again.
@All – Thanks for valuable comments!
nice tutorial…it will explained each and every detail about the frequently occurred errors..and also that I am so happy to finding this blog of software testing.. because before that I will totally confused about which type of testing I will prefer..but after reading that tutorial I confirmed about manual testing and then go to automation in step by step manner ..Ty for all authors of this such nice blog
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at postmaster@localhost to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Additionally, a 302 Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.4.53 (Win64) OpenSSL/1.1.1n PHP/8.1.6 Server at localhost Port 80
why is the error siir