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

jumping-from-the-edge

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.

why

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.

thumbsup

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.

race_start

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.

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.

    -joel

Trackbacks/Pingbacks

  1. 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 […]

  2. Letter to a starting tester - Softwaretestingtools.com - July 23, 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

Shares