The Complete Guide To All Error Detection And Correction!

Error Detection and Correction

One of the main tasks of testers is to report the errors of the tested work. On error reporting in PHP is also crucial for the testers. We relate the reporting method and language to the choice of the tester and the operation in the department. For example, a tool chosen by the company may provide the communication channel between the developer and the tester or reporting may be expected through certain procedures.

Therefore, in this article, we want to convey the process of error detection and correction. Error transfer can be made by assuming that the tool is not available at all or in the tools. Because we can use even a Word or an Excel sheet for reporting. But before beginning, you should know the error code and error definition as well.

What is an error in testing?

What is error fault and failure in software testing with example?

What are the types of errors identify as bugs?

What errors are commonly found during unit testing?

The errors

1. Error Number 1

The sentences used for reporting should be understandable. A sentence should be created by choosing words that are as plain and error-prone as possible. While reading, it should not create confusion in the minds of the developer.

2. Error Number 2

We should report the error scenario to the software developer step by step. And also check the accuracy and accuracy of the scenarios.

3. Error Number 3

Mistakes to be conveyed should be supported with some annexes. We can use some support both to better express and prove the problem. The most basic of these is to add a screenshot. The screenshot explaining the problem will be very helpful for the software developer to solve the problem. When taking screenshots from the web, the URL of the page, we should enter the image. There are many paid and free tools for the screenshot. The light shot plugin that helps take screenshots of the chrome browser as a free tool and even the snipping tool installed on Windows machines will help.

4. Error Number 4

When the problems experienced on the web page or mobile applications, we should share the URL of the problem.

5. Error Number 5

If possible, short videos describing the problem should be added. There is Camtasia as the video program we can recommend. We can view it from the link https://www.techsmith.com/video-editor.html. We can add voice transfer to this program. The video program that we use freely and which we use actively is IrfanView.

6. Error Number 6

We should add a log of the error. If the log of the problem coming from the backend is added. While receiving the error, the developer will solve the problem in a short time. We must make the required configuration to add a log.

Some recommended and most known programs that can be used are:

1. ZOC TERMİNAL
2. Shell NGN — Web TabanlweSSH Client
3. KİTTY
4. Putty
5. MobaXterm

7. Error Number 7

We should write whether we can repeat the error. Sometimes seen instantly; however, there may be problems that cannot be repeated. We should transfer this to the developer as a note.

8. Error Number 8

The problem should not spread to the general. For example, if a brand’s logo does not appear on the search results page of an e-commerce company, the logo name that does not appear should be written. When reporting, “logos do not appear on the listing page.” We should not use the expression.

9. Error Number 9

We should transfer the data and data to help repeat the problem. This transferred data varies according to the project. For example, when testing an e-commerce company, user information that has the problem should be written. Some problems may even belong to only one user. This user’s type, features, and information help to solve the problem.

10. Error Number 10

We should state the area where we experience the problem, should be clear. For example, we should provide device and version information for a mobile problem. In the world where there are many versions and devices, we should transfer this information to detect the problem and solve it quickly. We locate this information in the device information area in the settings section of the device. We can even add a screenshot of the page directly.

11. Error Number 11

For mobile problems, we should add version information. Whichever version of the application is experiencing problems, we should share this information with the software developer. It usually includes this information is usually in the “other” menu of the applications.

12. Error Number 12

For better detection of problems in mobile applications, the scenario can be customized by downloading and comparing the previous version or the next version. For example, if a tourism company application is being tested, we should try the problem experienced by downloading the previous version to repeat. The information about which version and where the problem started is obtained by this comparison.

13. Error Number 13

For the problems we experience in the mobile, we should state the problem where we experience in a mobile network or wi-fi. If the problem we experience is in 2G 3G or 4G, we should add the operator name.

14. Error Number 14

It should state the environment in which the problem is experienced. For example, it should be communicated whether the problem occurred in the production environment or only in the test environment.

15. Error Number 15

The terms used in the transfer language must conform to the software jargon. To explain this with an example, terms known as buttons, links, text box, radio button, the checkbox should be used during error transfer. Thanks to reporting aimed at speaking the same language with the developer.

16. Error Number 16

Transfer the errors found item by item. If there are multiple errors, we can transfer them with items to better convey the errors and to follow them easily.

17. Error Number 17

The priority of the error should be communicated to the software developer. If some errors prevent the test completely, it should inform the software developer about the resolution of the priority.

18. Error Number 18

If there is an estimate that may cause an error, we should send to the software developer as additional information.

19. Error Number 19

We should share the type of error. For example, if the error is true from a scenario not considered in fiction, we should communicate that it is a fiction bug.

20. Error Number 20

Whether the error is a known bug we should report that. But we have known some errors, live, accepted. When conveying such errors, we should inform it that we know it a bug.

21. Error Number 21

For web errors, we should try it in different browsers and share the browser and the information about the browser with the software developer. We think Jira is the most familiar program where mistakes are written, and we follow things. Using the above items, reporting can be done on Jira or all work tracking programs used.

Error Spotting

Even if all these items are made, sometimes the software developer may not repeat the transferred errors. In such cases, it is necessary to support by contacting. The easiest solution to the errors is by error detection and correction. We should never forget that the test and software are on the same ship.

Also Read: Software Testing Methodologies