No More Brittle
Do you know this situation? Every morning, someone unlucky is responsible for finding out whether your software really is broken or whether those failing tests are brittle and need to be repaired. Oh, and sometimes they are just flaky.
We've been there.
One of the many reasons GUI tests are unloved and capture and replay is even despised, is the brittleness of the resulting test cases. The tests break easily if something on the GUI changes and they need to be adjusted to reflect that change. This usually means:
- Finding out what changed in the SUT (e.g. a text or an internal id).
- Finding out to which new value this was set to.
- Copying the new value and pasting it into the test.
If the changes are to severe, re-recording might even be necessary. And although it is easy to quickly create many test cases, the above problems mean that test cases are a burden in terms of maintenance (also known as maintenance hell), with more test cases meaning more of a burden. This is one of the reasons of the well-known test automation pyramid.
This was the state of the art in GUI-based test automation—until now. Enter retest.
retest revolutionizes GUI testing by viewing it from a totally different angle—to solve all the problems stated above.
Instead of capturing individual pieces of information about individual components, we are collecting the complete state with redundant information. As a result, identifying components is much more robust. Because we do not only have a single piece of the puzzle, but the complete puzzle, we can assign every recorded element to every other element, making component recognition even more robust.
But this approach overall only makes sense with our innovative technique for updating/maintaining tests (patent pending). Which is … hold it … we're doing the copy and paste for you. We show you everything that has changed and you simply have to approve or decline it. Then, we update the test by inserting the new actual value. We even do this with added or skipped test steps.