3 ms·

This was my experience to a a T but then we hired a guy to solely manage the tests instead of having the developers do it and his tests caught a few false posit

This was my experience to a a T but then we hired a guy to solely manage the tests instead of having the developers do it and his tests caught a few false positives at the start but over time we were able to eliminate a 2-day+ crawl over the site by QA and UAT. My takeaway from this (which was the same argument I made back when we were failing at producing anything even usable let alone reliable) is: It needs to be someone's sole goal and I'll go a step further and say they should be on the outside of the team developing the main app. Being too close to the underlying code makes for a bad QA/Automated Tester IMHO. I have no problem even being the person who is managing/writing the tests but it's very hard to do both in my experiance.

ethbro 7y ago
As someone who's worked in the UI automation field for approaching 10 years, getting it to not break takes a little of (1) knowing what actual user interactions look like, (2) knowing how UIs commonly break, (3) knowing how the underlying UI framework commonly breaks / what shortcuts programmers are apt to take (e.g. simulated async in VB6), (4) knowing how events and code interact in a running system, & (5) striking the proper balance between performance and reliability. Honestly, though, 75% of automation errors are timing missteps -- automation dispatching events at a specific millisecond that a human never would.