Thursday, 1 December 2011

Tips to Decide What Test Cases to Automate

It is impossible to automate all testing; the first step to successful automation is to determine what test cases should be automated first.

The benefit of automated testing is correlated with how many times a given test can be repeated. Tests that are only performed a few times are better left for manual testing. Good test cases for automation are those that are run frequently and require large amounts of data to perform the same action.

You can get the most benefit out of your automated testing efforts by automating:

  •       Repetitive tests that run for multiple builds
  •    Tests that are highly subject to human error
  •      Tests that require multiple data sets
  •        Frequently-used functionality that introduces high risk conditions
  •        Tests that run on several different hardware or software platforms and configurations
  •        Tests that take a lot of effort and time when doing manual testing

Success in test automation requires careful planning and design work. Start out by creating an automation plan. This plan allows you to identify the initial set of tests to automate, and serve as a guide for future tests. First, you should define your goal for automated testing and determine which types of tests to automate. There are a few different types of testing, and each has its place in the testing process. For instance, unit testing is used to test a small part of the intended application. Load testing is performed when you need to know how a web service responds under a heavy workload. To test a certain piece of the application’s UI, you would use functional or GUI testing.

After determining your goal and which types of tests to automate, you should decide what actions your automated tests will perform. Don’t just create test steps that test various aspects of the application’s behavior at one time. Large, complex automated tests are difficult to edit and debug. It is best to divide your tests into several logical, smaller tests. This structure makes your test environment more coherent and manageable and allows you to share test code, test data and processes. You will get more opportunities to update your automated tests just by adding small tests that address new functionality. Test the functionality of your application as you add it, rather than waiting until the whole feature is implemented.

When creating tests, try to keep them small and focused on one objective. For example, use separate tests for read-only versus read/write tests. This separation allows you to use these individual tests repeatedly without including them in every automated test.

Once you create several simple automated tests, you can group your tests into one, larger automated test. You can organize automated tests by the application’s functional area, major/minor division in the application, common functions or a base set of test data. If an automated test refers to other tests, you may need to create a test tree, where you can run tests in a specific order.

No comments:

Post a Comment

Which one is right ?