As it turns out this appears fairly often in the testing field.
This leads into the discussion of test automation. Test automation can have a great ROI, but not always. You can end up spending hours, days, or even weeks automating low-risk and low-importance parts of your project with intricate tests that break constantly, when a manual test would have been far simpler, easier to maintain, and freed up time to grapple with more important problems.
Here's some things to keep in mind for ROI in automating a test:
- How often should the test be run? If it's a throw away test or an exploratory test, it probably shouldn't be automated (though some of the setup can be).
- What is being tested? If you're checking for text on a page, then it's almost always a good candidate for automation. If you're checking that screen elements are in their proper places, or that audio quality is where it should be, that is probably better done with human eyes.
- Are physical devices or objects required for the test? For instance, in a login, is there a One Time Password generator that has to be used? If so, you may be able to write a simulator (or disable it for some tests), but at some point, it's best to use the actual device to make sure that nothing is wrong.
- How fragile is the test? Some tests are fragile because the tested area is still under development. It may be best to re-prioritize that area for later. Other times, the tested object may have some non-deterministic quality that requires constant adjustment. In this case, visual verification may be best.
If you have any other good tips, comments, or disagreements, I'd love to see them in the comments below!