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

Do you assume that software bugs are transient, occurring only once and are not prone to recurrence after remediation? Quite contrarily, I argue that around 30% of these glitches tend to resurface.

In this literature, my goal is to underline the importance of recording the errors that are recurrently seen.

You’ll find below some common areas where issues repeatedly occur in addition to a template for easier documentation. 

I trust you will find this resource useful!

Image source

Example #1 

After deploying the code and drawing up the test cases, John, the tester, stumbles upon an issue during the testing phase. This problem feels familiar and has surfaced on multiple occasions, but John doesn’t recall the solution.

John and Sheryl both attempted to find Smith, who previously came across and resolved the identical error. Regrettably, Smith was on holiday.

So, how should John proceed now? Should he try reaching out to Smith, even though he’s unavailable?

If an environmental issue keeps occurring across multiple releases, I highly recommend documenting the essential details and storing them in a common location. That way, you’re not relying on just one team member, and everyone is empowered to find a solution independently when such recurrent issues arise.

Example #2 

John encounters a known error once more while testing a new release. He recalls a defect for it being logged in a prior release, but the challenge lies in recalling the defect number or related details.

What support do you think would be beneficial to John in this situation?

• Search for the defect using the description in the Defect tracking tool?
• Review all the previously lodged defect reports?
• Seek guidance from his team lead?

There are various methods he could adopt.

However, in my view, logging such issues separately and sharing them with the team would be of great value and would save time.

Areas frequently prone to errors:

1) Parameter File – From my experience with the Informatica tool, I’ve noticed that incorrect DB connections specified in the parameter file often cause issues. This becomes a repetitive problem primarily due to the shared connection between development and QA environments. Consequently, periodic updates to the parameter file are necessary to circumvent such errors.

2) Incorrect URL Pointing to the DB

3) Access Issues – Users encounter challenges when they have inadequate or erroneous access rights to the DB. In such instances, having a document outlining necessary steps or contact person(s) could be incredibly beneficial.

4) Test Data Issues – Errors often stem from using incorrect data formats or values.

5) DB Problems – Common issues include timed out DB connections. While some downtimes are temporary or scheduled, others might need a DBA’s intervention. Users usually get notified in advance for planned maintenance, but documentation for handling temporary errors and fixes is a must for testers.

Regularly occurring errors often originate from environmental factors.

Simultaneously, we should also keep an eye on code issues. This discussion is general and doesn’t cover code-related glitches, which are specific to your application, framework, coding language, etc.

A small fraction of defects can also be attributed to data entry or human errors.

Download Frequently Encountered Errors Tracking Templates

In Word Format

=> Download error tracking template (Word)

In Excel Format

=> Download error tracking template (Excel)

Benefits of Documenting frequently encountered errors

1) Reduces Dependency – As illustrated in Example 1, John depended on Smith for a solution. If there was a reference document available, this dependence could be eliminated.

2) Quick Resolution – As depicted in Example 2, having a dedicated document for high-frequency issues would negate the need for testers to go through the entire list of previously logged defects.

3) Promotes Self Reliance Among New Team Members

4) Assists in Correcting Human Errors

In Conclusion

I firmly assert that the documentation of frequently occurring errors is beneficial as it can prove to be an invaluable reference tool.

While it may seem like a tedious task to document these during active test execution, it is deemed a best practice to take rough notes during the process, which can be later refined and added to the shared document.

Suggested reading =>> How to Document Functions in Python