Automated testing advice – making the commitment

Over the years I’ve spent a great deal of time writing test automation and I’ve learned a lot along the way. The road to successful automation has lots of steps, some small some large. I’m going to start a series of posts talking about my experience with test automation dating back to 1994 when I got my first serious taste.

Commit to automated testing

Ensure that everyone in your team who you want involved in test automation is committed to its success. If you can’t do that then you’re looking at an up hill battle that commit themselves to building and maintaining a automated test environment consider the battle lost.

Team Commitment

For automated testing to succeed you have to gain buy-in from all the involved parties and through hard work validate that automation can benefit everyone. Here are some of the initial things you’ll need to get your team to commit to:

  • Learning about software testing
  • Buying, building or finding open source tools your people can embrace for use in automation
  • Monitoring the success of the testing efforts
  • Developing a smoke test
  • Sharing the responsibility of maintaining the smoke test
  • Creating a command line build for your project(s)
  • Publishing test results

Individual Commitment

As an individual contributor if you’re not willing to commit time and effort to learn and assist with your team’s test automation efforts you’re undermining the process.

  • Always considering how your code will be tested
  • Learning the tools and techniques available to test your code
  • Writing tests for your own code
  • Run the smoke test before checking in
  • Understanding how changes you make will impact existing tests

Of course, these aren’t exhaustive but if you can’t accomplish these tasks the likelihood of succeeding will dwindle rapidly. I’ll look to expand on a number of these items.

Let’s face it, test automation can be hard and convincing people that it can save them time and effort can be equally difficult. If you’re team isn’t already on the testing bandwagon then you’re likely in a situation where you’re going to have to prove that automation can work before you’ll receive greater buy-in so be prepared to go it alone in the beginning. Committing to automated testing, in particular, convincing your clients and management may be a difficult task so be prepared.

What sort of problems have you run into getting people to commit to test automation?

4 thoughts on “Automated testing advice – making the commitment

  1. We have had many problems with management (testing need too much time), software producers (testers produce delayed payments…), developers (we introduce a "unuseful" phase before putting sw on production servers) in the last 3 years.
    Now we are called only when an application doesn’t work fine.
    They said: find what was wrong!
    I think and say always to my boss that the only wrong thing is the development cycle that hasn’t a serious testing phase.

  2. Giulio,
    I don’t think you’re alone though I’m sure that doesn’t make you feel any better. I’d probably suggest taking things one small step at a time and slowly move towards automation if you can.

  3. I agreed with most of requirements. However, to find a right tool is not that easy, specially when you talking about UI testing. I ended up writing one myself. Check it out – UI Test Automation library
    it’s not nessessary a tool for every case but did work for me and may help others.

  4. Hi Andre,
    In this post I did mention "buying, building and open source" as ways to acquire tools for UI testing and I would consider the path you’ve chosen as "building". That said, I think for testing WinForms applications I’d recommend AutomatedQA’s TestComplete as I think it’s hard to beat, is a very well established and includes a huge number of features for testing software.

Comments are closed.