In my previous entry, I described a conversation I had recently. A colleague asked for my opinion on how to solve a problem with maintaining automated UI tests. After hearing a few details about the situation, I told him that in my opinion, his team had a larger problem that that: they would be better off focusing first on building and running a suite of lower-level testing, such as unit tests. Once that suite was solid, then they should explore other automated testing options, such as UI tests.
The even bigger issue here is: how did they get into this situation in the first place?
I did not talk to my colleague in detail about this, but I mentioned one fact in my previous post that sheds some light on the source of the problem: this small company contracted out their testing. In their case, they used a company that provides a part-time local QA manager and a test team in Ukraine.
By separating the testing so completely from the rest of the development process, they left the test team to address automated testing by the only means available to them: the UI.
To his credit, this colleague and his coworkers realize that the outsourced testing is not suiting their needs, and they are exploring other options for testing. But it seemed clear to me that my colleague still maintained a mental separation between testing and development. He was looking for solutions to their quality problems that could be implemented within the realm of QA/testing, not solutions to more systemic problems–solutions that would involve changing the way his entire team works.