Posted by IN / 0 responses

Getting Started with Automated Testing

16 November 2015

start

Are you stuck at the starting line, surveying the landscape of automation products?

Why not automate today? Are you convinced you’ll need months of development BEFORE writing test cases?

It doesn’t have to be this way. Here’s how to avoid wasting time and money implementing automated testing in your environment!

First, try something free

I recommend open source tools like RobotFramework, Cucumber, or Selenium.

Run a pilot program

Run a short pilot program (less than 2 weeks).

Pick a team member with the right skill set to be successful. If you don’t understand what’s needed, find someone to tell you what you need (i.e. call us:984.244.2313).

Determine root cause

You should have working, maintainable test cases by the end of the pilot. If you don’t, the pilot didn’t work.

In that case, determine the root cause for the failure.

Did the person working on the pilot have the skills to succeed? Is there a technical reason this didn’t work?

Once you’ve eliminated all excuses and ensured your people have what they need to succeed in the pilot effort, run another pilot program.

When your pilot works

If you have test cases that:
• Reliably tell you the state of the system,
• Are human readable (without engineering prowess),
• Are maintainable,
• Are extensible,
• Are running periodically, then…

Your pilot worked

Expand your success within this functional area of the application by writing more tests. Make sure the tool facilitates the writing of test cases rather than hinders it. Sometimes this only becomes clear once you get into more complex test cases.

Ensure what you’ve created is credible and consistent and works all the time. Tie it into your continuous integration environment. Start running all tests often.

At this point, you may be able to run all your tests every build. That’s fine — It will help you make your system less brittle, provided you resolve framework errors in a robust way.

Break up test cases later into separate batches later, when long run times become an issue.

Clone Successes

Once you’ve determined you can succeed in one area with the tool, hand off writing test cases for the initial functional area to someone new. Now try using the tool in another functional area.

Repeat the appropriate steps above for this new functional area of testing.

When your tool doesn’t work for a functional area…

There is no tool that will work for every situation. My advice? Don’t force a square peg into a round hole.

If the tool you’ve chosen doesn’t work with a new functional area, you have choices:

  • Decide whether to hold off on this functional area until later OR
  • Try out a new tool for this area

Reporting

The only warning I’ll offer is: it is good to have ONE reporting mechanism for test outputs. Automated tests are worthless if we can’t easily find important information in reports.

Good luck and let us know how it goes!

 

About the Author

Paul Merrill

Paul Merrill is Principle Software Engineer in Test and Founder of Beaufort Fairmont Automated Testing Services. Paul works with clients every day to accelerate testing, reduce risk, and to increase the efficacy of testing processes. You’re Agile, but is your Testing Agile? An entrepreneur, tester, and software engineer, Paul has a unique perspective on launching and maintaining quality products. He also hosts Reflection as a Service, a podcast about software development and entrepreneurship. Follow Paul on Twitter @dpaulmerrill.

Leave a Reply

Your email address will not be published. Required fields are marked *