There is a strong opinion among the testers that if defects are difficult to reproduce, no need to spend a lot of time on it, but it will be more true to go further and check something else.
Also read: automation testing
And there is a group of QA specialists who spend a lot of time looking for causes of bugs like that, just leaving the testing process that is paused. But is there a middle ground for all this?
First of all, everything depends on the current situation. It is possible to distinguish both reasons to continue the hunt for disabilities, and the reason for delaying such a situation for later.
Critical and small defects
Critical and small defects
Reason for
1. When a defect occurs, it's bad
Maybe you, as a tester, check the software, where everything is configured and functions correctly correctly. But if there is a defect, the system is only damaged, or important information disappears. Such things are not permitted in any way. Even if the error is reproduced in just 2% of the test case, it is very important to understand what really happened, because one small mistake can be a catalyst for the entire system failure.
Also read: qa testing
2. Floating bugs, but it happens very often
Let's say we have software that will only be used systematically (irregularly). When authorization, the product receives data entered in 50% of cases, and does not receive the remaining 50%.
Agree, this is a rather unpleasant situation. No one wants their products to be criticized, ranked poor, and converted to a competitorial offer several times after use.
In other words, any bug, even if it is not always visible, it is still worth repairing to eradicate a potentially negative attitude.
3. Bugs related to technical problems and important problems
Maybe software under tests function properly with some test users, but when it becomes a public available, massive technical disorders begin. No need to go through things like that with the words "everything works for me".
Also read : test automation tools
Such defects fluently indicate the fact that software has certain problems when working with a burden. This can be a problem with memory leakage, or the request to the server is calculated at a long time interval and errors are exacerbated by increasing number of requests.
But regardless of the real reasons, it is very important to find bugs and edit it until real users begin to interact with the product.
The reason "oppose"
1. The test has been going on for a long time, but the bug is only reproduced once
Software is an unstable thing and of course it is not ideal in its functions. This can lead to the most unexpected oddities and technical problems (decrease in power, problems with internet connections, etc.).
Defects that have been considered only once can be attributed to anything. Keep in mind about it, but deliberately looking for it most likely no. Now, if he meets again, then yes, you have to ask him to fix it.
Also read : software testing tools
2. Short time, but you are sure that bugs found are not at risk
Agree, unpleasant situations when real users see bugs, and when asked why it was not fixed during the test, the quality control company answered that, of course, there was an error, but everyone was in a hurry and there was no time to study the problem.
But if the defect is related to something that the user will not do, and there is actually a little time, it makes sense to wait until the final release and resolve the problem only later.
Also read : framework automation
Example Illustration: The Development Department is preparing to release functionality for the user's personal account. It was checked by several testers at once and nothing critical appeared to have been found. But on the day function is released, it turns out that a personal account does not work if you enter more than 16 special characters in the field of "password". In this case, it is necessary to release functionality for widespread use and deal with this problem later.
No comments:
Post a Comment