Selenium vs testRigor
 |
Test Coverage
Even small changes might have ripple effects over the product. Allegedly, Walmart lost $100M within 10 minutes because of a bug in production. It happens quite rarely, but you don’t want it to happen. It is like insurance. If your coverage is 40% or less – do you trust it? Why can’t you just write 100% code coverage and be done with it? – well because it is almost impossible. Almost nobody (except you are on a major project in a major bank) have enough resources to build enough tests.
Diminishing Returns 🙁
Unfortunately, with any code, Selenium included the more code you have the more work it takes to support it. Literally. Up to a point where the whole development of new test is reduced to a crawl. Just because developers just updated their HTML structure yet again.
Speed
Speed of change is critical. It helps to move organization forward faster. What if the change is a BLOCKER level security issue and needs to be deployed ASAP? If you don’t have enough test coverage – then you just hope (not test) that you didn’t miss anything important. If your test coverage is 30% and everything else is supposed to be tested manually – what do you do?
Maintenance
N1 value that testRigor provides is it decreases maintenance hours about 200X compare to same number of tests automated with Selenium. That is chiefly because testRigor unlike any other system on the market emulates humans when going through website, desktop, or mobile app allowing you to focus on just visible available elements on the screen instead of dropping into details of the HTML structure or how it works. That also allows testRigor to introduce a number of tools to decrease test maintenance even further.
