Collaborative Empowerment
It can be argued the first path empowers the tester, encouraging them to be as technical as possible, while at the same time promoting cross-team collaboration through speaking a universally understood language (in that team/organisation anyway). This school of thought assumes that testers can code, in some cases better than the development team, and also communicates and write specifications equally as well. What I have just described is probably the perfect cross-functional resource, who would be able to do any role in a team and also may be considered a fulcrum of the team. This path is now known as Behavioural Driven Development (BDD) or Specification by Example (SBE). It has given rise to a raft of tools like JBehave, SpecFlow and Cucumber and was first adopted by real agile teams the world over to assist in the collaboration and produce automation as a by-product.
Organisations adopting this test automation path (whether as a goal or a by-product, preferably the latter) are generally more responsive to change and can adapt quicker. You will find these are commonplace in smaller organisations and tech companies. These companies are able to adapt quicker and deliver to market in less time than larger, more rigid companies, due to a number of reasons. It may be because of a lack of regulation in that industry, a diminished gap between the stakeholder/product owner and the software team or because of a less rigid process, which means there may be less restrictions over adopting newer processes and funnelling through change quicker.
Domain Driven Testing
Domain Driven Testing assumes the tester is a master of the business domain they are testing in and attempts to remove as much technical know-how as possible from the tester to achieve the desired automation. An example of this would be keyword driven test automation, where the tester, in theory, does not have to write realms of code to achieve the end state, but merely use keywords to create the code and drive which actions are desired to test the application under test.
There are a rising number of tools which do this and it is an easy sell, especially for anyone who has tried to hire “that perfect cross functional resource”. Undoubtedly, however, a smaller number of specialist automation resources will still be required to cater for those instances where the application under test annoyingly does not fit within the set of keywords or functions already defined within this tool.
The organisations adopting this trend tend to be more rigid and process driven than their counterparts adopting Collaborative Empowerment. Whether by regulation, distribution of resources, or lack of skilled resources they believe that to achieve their automation goal, it needs to be by having the tester focus on the testing on not being distracted by having to write lots of code. Having the tester focus on the domain at hand can have clear benefits, especially if the domain they are working in is particularly complex or specialist. It can be argued that these tools increase productivity, speed up automation implementation times and may improve return on investment quicker than the alternative.
The jury is out on which path will win the race. At the moment, anecdotal evidence suggests that more organisations are striving to adopt Collaborative Empowerment, mainly due to the benefit of promoting communication and quality in equal parts and the automation falling out as a by-product at the time of development. The trend is also that the tools supporting these methods or processes are largely open source, whilst the tools which generate automation for the tester tend to be expensive.
Domain Driven Testing can even encourage further disassociation between the software development team and testing happening at the end of the process rather than at point of development.
Source: TNO
