How Test Automation is like your Girlfriend / Boyfriend

The only fair answer to most questions on how someone should approach automated testing is ‘I don’t know’. Another person’s situation is not like yours. Even if they are testing a similar application and perhaps even within the same company! The process of selecting an approach to automated testing is not unlike selecting a girlfriend or boyfriend. Would you approve of one simply because someone else liked the person? Or because you work in a similar profession? Or because you both like bowling? Of course not, this is a complex matter and there are many more factors to consider to achieve bliss! So a more constructive reply to the above question would be some return questions on these factors. The same goes for automated testing.

In automated testing, the relevant factors can be grouped under the acronym PUPPET:
– People: What skills are available? Do testers program or can programmers automate? Etc.
– Understanding: Do people know what automation can and cannot do? What is its goal? Etc.
– Processes: Classic or Agile? Align specification using BDD or Spec by Example? Etc.
– Policies: Commercial, open source or both? Etc.
– Environment: What test environments, stubs/mocks and test data needs are there? Etc.
– Technology: What interfaces and programming languages are used? What tools are available? Etc.
(More details than the ones mentioned above will be given in the presentation.)

The importance of the PUPPET factors will be illustrated using at least 6 examples from my personal experience. These include both successful ones and not so succesful ones. It will be clear that all of the factors need to be considered to have a reasonable chance of success, especially for the longer term. And the people involved rather than a tool then are the core of the solution.

To release the potential of automated testing, you need to take it seriously. Like a girlfriend or boyfriend.

  • Speaker

  • Martin Gijsen - independent consultant,, Netherlands

    Martin Gijsen is an independent test automation architect who achieves successful automated testing the first time around in complex situations or boosts the business value of existing automation solutions. He believes test automation solution must context dependent to become and remain valuable.