False positive are the most delicate subject when talking about test automation, test automation usually give false positive when not handled properly. A proper trust-able automation code needs to be built up to avoid any false positive and affects pertaining to it.
False Positive is something when a test is executed and despite it running correctly, the test tells us there is an error, adding lots of cost and time to the scenario, however a sibling term ‘False negative’ is also there is which likewise issue causing. It can be described as when the execution of a test shows no faults even though there is a bug in the application. This, as much as the false positive, can be due to an incorrect initial state of the database or problems dealing with the test environment setting.
False positives
False positives are test instances that fail without there being a defect in the application under test, i.e., the test itself is the reason for the failure. False positives can occur for a multitude of reasons, including:
- No appropriate waiting is implemented for an object before your test is interacting with it.
- Incorrect test data
Debugging, finding out the fault which never existed , cause a lots trouble and time consuming activity.
How to get rid of the false positives, carrying out a proactive analysis of the automation code, realizing the test data checking the quality of our tests and anticipating possible errors can help to reduce or even get rid of the False positives.
Having a completely controlled environment minimizing the chances of false positive is considerably increased, the controlled environment should be only accessible through automated tests. Fixing up the test data help reducing the issues as consistently changing test data causes a difficult situation to reproduce the issue.
Finding root cause of False positives can be really annoying, taking too much time to analyze it, The minutes (hours) spent getting to the root cause of tests that fail because they’ve been poorly written would almost always have been better spent otherwise, writing a stable test and automated code helps to reduce spending these hours in a positive manner helping to reduce all the false positives.
The false positive and CI-CD deployments builds process make a more dangerous combination, keeping figuring out what caused failures is definitely a big time spoiling.
There’s also another risk associated with false positives: when they’re not taken care of as soon as possible, people will start taking them for granted. Worst are the test cases failing intermittently, simply because the root cause for their failure often cannot be easily determined, which in turn makes it hard to fix them.
False Positive & False negatives are the difficult situation for a automation code run.