Test automation in Agile and why it fails

Posted: October 15, 2014 in Uncategorized

Some really useful observations made here, logical but often overlooked!

Technical Software Testing

It’s fairly safe to say that quite a lot of test automation efforts fail. It is also very safe to say that without test automation an agile team fails. So how can you make sure that while doing agile your test automation will not fail and thus your agile team will not fail? One of the ways to answer this question is by looking at why test automation often fails within agile environments.

When I am talking about test automation within this post, I am referring to testing that is done to reduce the amount of manual regression work, the so called functional test automation or automatic regression testing.

Moving target

Test automation quite often does not receive the attention it needs and deserves, also in agile teams. Quite some test automation efforts start off too late and without the appropriate preparation, resulting in organic test automation driven by a…

View original post 838 more words

Advertisements
Comments
  1. Jim Hazen says:

    The key thing in Martijn’s post is about treating your automation code just like your application code. Automation is a software development project unto itself, period. You are creating “testware” to drive the testing of your software. Also, especially in agile, automation needs to be thought about from the first second of the project and each iteration/sprint. Yes, it is tough to automate a moving target. But the framework and early components (descriptors of a page & its objects; a basic implementation of the Page Object Model in Selenium which in other tools is called a Component) can be built and beefed up later as things become more stable. Sure the automation may be a sprint behind, but as I just said you do some of the preliminary work in the first sprint.

    Another thing to think about regarding “automation in agile” is the type of automation you’re going to be doing. Meaning will the team implement Unit Test automation at the code level, or API/Services automation at that level of the technology stack/layer, or at the GUI level itself. Each of these have different techniques and tools to accomplish the work. It takes a bit of foresight and planning to get it going right. And all-in-all the whole team will need to understand what is going on and buy-in to it.

    The number one problem with automation, agile or not, is misconceptions and false expectations of the work. Including who should be doing it, and when.

    I’ve been dealing with this for over 20 years. This is nothing new, but a constant headache that we need to detect early on and deal with before it really causes us pain.

    Regards,

    Jim Hazen

  2. sri mody says:

    We use JIRA as the agile process tool and we have just started automation. Automation coding for historic as well as new functionality, developing the correct framework may take some time to mature. Initial idea was to attach automation coding as a task in JIRA for the user story in the product backlog. in JIRA, Sprint would not close unless all User story tasks were completed. This would lead to a unclean sprint if automation coding took more than expected or alternative is to plan very few user stories per sprint leading to a late release. In this case, would it not be appropriate to consider the automation coding of the product back log user story as a ‘Tester’s user story’? This will ensure automation coding is taken up by automation team in a different sprint and tried to be completed by priority?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s