Agile Test Automation – Learning to fly by jumping and letting go (of my previous assumptions)


I started working on an automation project in a company where they recently adopted a strong and healthy agile development approach.  One of the first things they did was to distribute the once-unified testing team and incorporate the testers as part of the organic development teams; up to now all good and fine.

The VP R&D, who I know from a previous company we both worked together ages ago, brought me in to solve a problem that started when each of the teams began developing their test automation, all in their own separate ways, and each one started running into different issues halting their progress almost simultaneously.

I will be sincere and say that in my own egocentric way I thought the answer would be trivial and based on the models I had used in the past, where you create a central team in charge of automation and they provide services to the rest of the teams in the most professional and effective way.

Sounds logical, right?  At least it did to me.
So here is where I came (to save the day!?!?!).

The first thing I did was to set expectations.
I am only a Testing Guy with some experience, not a Magician, Miracle Worker, or a Messiah that will solve all the issues by imploring the help of any Testing Deity above (or even bellow).  The best I can do is try to use some of my experience and a lot of common sense (both mine and theirs) to find the way to work correctly.  I hope they understood this, if not the road is going to be really bumpy…

The second thing I did was to list the stakeholders within each team and across the company that I should talk to in order to get a good and balanced image of was is going on.

Here is where it started getting interesting, as things usually do when you start going deep into the bits and bites and asking some interesting questions.  BTW, for this I really recommend using an approach based on the 5 Y’s.


I quickly realized 2 main things, a bad one and a very good one, that were happening in the teams.

The bad thing(/s):
Since the automation had suddenly become a tasks of the Development Team Leaders, and since the Company did not have a single person who had ever been part of a Test Automation Process, they were running into all sorts of “rookie automation” issues.

  • Wrong test organization
  • Teams not sharing or even aware of the tests being developed by the other teams
  • Lack of a proper test management or execution platform
  • Lack of test development experience
  • Tests that were not written in a modular way
  • Tests that, when they fail, don’t give enough information about the nature of the error
  • etc.

Just think about all the possible “simple” mistakes in the book, and most probably they were there in one team or another.


The (very) positive thing I saw was that the Team Leaders, who are all R&D managers in one way or another, really took ownership of the testing tasks and their automation.  Not only did they take ownership, but gave it a very high priority within the tasks of their teams, so much so that they were even giving automation development tasks to their brightest developers and team members.

Here is where I realized that I needed to let go of the traditional approach I had in mind.

Even though my initial feeling was to go by the traditional way and solve the issue by creating a centralized team to handle the test automation, I decided that this approach would very much eliminate the involvement of the Team Leaders who had really done the mental switch to adopt testing as part of their core responsibilities.

So, this week when I came back to the VP R&D with my analysis and recommendations I actually presented him a proposal that will take me out of my “known & comfort zone” but will allow us to leverage the great agile spirit currently present in the company.  Instead of creating a team that will develop automation, I will start working with each of the teams in order to solve their issues, and we will create an “informal” automation forum that will be in charge of correlating, sharing, and levering the automation process between the teams.


We will start working in the next 2 weeks so wish me luck!
I’ll keep posting updates and interesting stuff as they will surely become available.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

6 Responses to Agile Test Automation – Learning to fly by jumping and letting go (of my previous assumptions)

  1. Yaniv Iny February 11, 2010 at 2:10 pm #

    We both know what will solve all of their problems, right? switching to 1 great test management tool 😉

    I really like the fact that you help organizations with their QA methodology and still keep totally objective regarding the tools they use.

  2. Devon Smith February 11, 2010 at 5:20 pm #

    I really look forward to hearing more, as I have been working at setting up a more formal QA process at my company. Good luck!

  3. Mithun Ashok February 11, 2010 at 6:29 pm #

    All the Best,.. Please do Post on the progress.. Thanks for the Share.

  4. Joel Montvelisky February 11, 2010 at 7:50 pm #

    Thanks for the warm wished 🙂
    Will keep posting to share on what we learn along the process.



  1. Who Should be Afraid of Agile Testing? - QA Intelligence - May 25, 2016

    […] by Joel on Agile testing you might like: Agile Thinking instead of Agile Testing Agile Test Automation – Learning to fly by letting go Every Tester needs to be an Agile Tester Switching to Agile Testing, not as simple as changing your […]

  2. Letter to a starting tester - QA Intelligence - July 20, 2017

    […] the halls” is that testers could eventually become obsolete with the increased implementation of automated QA, Agile practices and so on.  This can be a deterring factor for less experienced testers wondering […]

Leave a Reply