One of the three things that bring innovations, is copulation. That’s basically two already good ideas having sex with each other. I learned this from Jerry Weinberg’s Becoming a technical leader. The longer I stay in test automation and agile, though, I think this does not hold for combinations of testing tools, like a testing framework, and a UI-driver.

There are a lot of so called mash-ups of functional testing tools. For example, there Selenesse which combines Selenium with FitNesse. Last week I also heard from FitKuli, which is a mash-up of Sikuli and FitNesse. I think we should call this one rather SikNesse.

All these mash-ups have one thing in common: They bring the team an opportunity to continue working in the same old silos. Testers can work on their own on test automation through the GUI, programmers don’t have to deal with the problems they are creating by not separating the concerns of the UI from the business logic. This is not only bad, it also misses completely the purpose of good test automation, and agile acceptance testing. The main point is that your team should be collaborating on it.

But there is more. Test automation is software development. By enabling testers to come up with scenario tables that are actually extracted functions in the SLiM language of the requirements, you eventually over time create a whole lot of a mess. Since you can’t unit test these scenarios, you might as likely end up with a bunch of legacy code – in your functional testing tool. I promise you, it won’t be long until you abandon the test automation efforts, because they have become a maintenance nightmare in the long-run.

There are also other tools like RIDE and Selenium IDE. When I spoke with Adam Goucher in July this year, he mentioned that he abandoned the project on Selenium IDE largely because he was helping companies to get rid of this stuff in the long run.

One of the key points in my keynote at the Agile Testing Days last week, was that I like to be not a T-shaped team member, but a circular one. I know some stuff about coding, I know some stuff about requirements gathering, I know some stuff about database, I know some stuff about testing. Putting it all together, I feel way more comfortable to serve the project when I have to. This is a comfortable position to work from – especially in an Agile context – since I can help so many people become better at whatever they do.

Tools like testing IDEs (don’t get me started on the commercial ones) or tool mash-ups prevent you from looking for circular shaped persons to facilitate between the testing and the programming perspective. In the end, you don’t deal with the real underlying problem: That no one knows how to do good test automation. Don’t go there. Instead, find the right people to get you started in your efforts, and help the team to collaborate based upon that.