Software testing and quality assurance is a complex process, requiring dedication, technical expertise, attention to detail, and hours of work. Testers are people who dig deep into the product and have a great impact on the end result of the project. That is why it is important for product owners not only to understand the importance of software testing, but also to understand special issues in order to communicate more effectively. This article focuses on error rendering problems that only testers understand, which are not always good for software project quality.
“Error cannot be reproduced”: Where are we doing wrong?
Many software testers sooner or later run into a problem where their client / development team cannot reproduce the reported bug, which you have spent a lot of time and effort investigating. You have tried very hard to report in a clear and concise manner, but they still insist that “cannot be reproduced”.
Conflict in communication is the leading reason why everyone on the team cannot reproduce the error. It could be a rather vague error summary or an error summary that no one wants to read
The reason why a person has difficulty reproducing an error can also be due to the tester’s actions. For example, they might have provided a vague error summary, listed uncertain steps, or attached a useless attachment, didn’t prove the error correctly, or made someone else completely unwilling to open it. Even worse, if you didn’t check for error replication before reporting it and the error is no longer present after the cache has been cleared.
In the event that you are not sure that the error was reported correctly and that the end user of the application could find it, you have no choice but to guard against it. This is achieved through communicating with stakeholders that we can investigate and correct that error in the future.
So what are the questions you should ask your QA team to find out why they are not reproducing your error?
- Do you and the development team use the same test environments (platforms, browsers, browser versions, devices, operating systems, screen resolutions)?
- What kind of Internet connection did the two parties use?
- Have they counted all the prerequisites you specified and the steps to reproduce the error?
- Are your expected results using the software consistent with these for your team as well as the expected results outlined in the project requirements?
- Do you or the development team use any third-party applications or browser extensions that may affect the software’s performance?
So, let’s consider all of these questions in more detail.
First of all, in most cases they don’t read all of your bug report. In the best case, someone is trying to reproduce your error through just the error summary and attachments. That’s why it’s not uncommon for some of the error-reporting properties to be overlooked. And this is unfortunate.
Is your test environment suitable?
You must specify the correct environment for the development team to reproduce your error.
It is assumed that when reproducing an error, the reproducibility environment is outlined in the description. Therefore, you must double-check if your colleague is trying to reproduce the error is using the same platform to do it (browser, device, operating system, screen resolution, of course if this error is environment specific) like you did.
For example: There have been cases where testers reported an error that only reproduces on an iPhone 6 but does not appear on another version. That is why this tester specified the specific environment in the error report description. One error-handling programmer that did not pay attention to detail is that the error can only be seen on a specific device (Iphone 6). This programmer is trying to reproduce the bug on the iphone 7 so he cannot reproduce the bug.
What kind of Internet connection did you and the test team use?
Mostly, such a question should be asked about the device-related errors, since the type of Internet connection (wi-fi, 3G, 4G, etc.) can affect the performance of the app or the website, This information is therefore really important and must be clarified.
Has the testing team counted all the prerequisites you specify and the steps to reproduce the error?
Coming back to the problem the test team did not pay enough attention to the bug report and its attachments, missing some important information.
Often times, competent employees tend to think that they are so well versed in project functions that they do not need to thoroughly examine the prerequisites steps and steps. That’s why it’s important to double-check exactly how the developers tried to reproduce your bugs, whether they missed a step, or didn’t take into account any prerequisites.
Are your expected results of software operations consistent with these of the team as well as the expected test results outlined in the project requirements?
You reported the error because it did not match the expected results specified in the requests, or even the errors were not specified, but you know exactly how the function will work based on experience. common standards or common knowledge. You should discuss this with your colleague. Maybe someone on the team is relying on inaccurate information about the expected results of the software operations.
Do you or your team use any third-party applications or browser extensions that may affect the software’s performance?
And the last question to discuss is the one that can be asked from the person who reported the bug. Occasionally, certain applications might conflict with each other. Naturally, this causes software bugs that the QA analysts classify as buggy. Even a VPN can interfere with work. Or, for example, if you use a virtual machine for testing, you must ensure that during fault reproduction, there are no third-party applications that could affect the performance of the tested product, as this is. May make the product less stable than the original platform or the browser itself.
The purpose of the software tester is to ensure the software functionality is stable and error free, and to try to prevent the user from detecting the error. If you find a bug and think it is a serious reason to de-release the product, and the development team is unable to reproduce it, you should definitely find the reason by asking the questions listed at on. This not only helps shape your professional reputation, but also affects the entire QA department’s image in the development team’s eyes. Needless to say about the company’s position in front of the end user – a fragile thing that is difficult to obtain but easily lost through just one mistake.