This Scenario Explains How Important It is to Document the Frequently Encountered Errors

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!

image source

Scenario #1 

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.

Scenario #2 

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.

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

Word Format

=> Download error tracking template (World)

Excel Format

=> 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

Conclusion

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