Automated Software Testing Life Cycle: Part I

Posted by Lisa Corkren in Automation | October 27, 2010

There are many cycles in software development, so where should the automated life cycle begin? The first step is to scope the project. There are many questions to consider before choosing to automate, for example:

  • What is the current communication process between the testers, test advocate (lead), developers, and project managers?
  • Is the environment web-based, mainframe, or client-server?
  • How does your testing currently take place? (Ex. does the lead/advocate give test assignments daily, weekly, etc?)
  • How often during active testing do you have defect meetings?
  • What is the average amount of test cases currently being completed by a tester on a daily basis?
  • What third-party licenses of automated testing software do you currently have available?
  • Is the licensed testing software currently being utilized?
  • What is the ratio of your onsite testing between manual and automated? (Ex. Manual 60% and Automated 40%)

The next step is to perform a Proof of Concept (POC). It is a good idea to utilize a POC before purchasing an automated software tool. During the POC phase, you have the opportunity to look at the software and determine which automated tool is best for your project. This time also gives the automation tester an opportunity to get to know the software, review the application's functionality and the environment under test, and to learn the business functions, user interfaces, and navigations.

Automated Software Testing Life Cycle

After determining an automated tool to use, you are ready to plan the project. This process involves gathering all supporting documents such as Business Requirements (BRS), System Requirements (SRS), Component Requirements (CRS), and any others associated with the project (e.g. manual test cases in cases of script conversion).

Consider the tests to be automated by asking these questions: How many test cases are currently being used? Are the test cases ready to automate? Do the test cases need to be refactored into an automated format? Which tests will be automated and which tests will be designated as manual tests? After determining which tests are suitable for automation, the next step is setting up a test suite that reflects the order in which the tests need to be performed. Set up a test data file for input and expected results.

Next, determine the features that are not to be tested and thus are not going to be included in the project. The features that can be excluded from the testing phase should be listed in the project failures section of your analysis report with detailed reasons why they will not be included in the automation. Features that are out of the scope of testing, like incomplete modules or those with low severity, should be listed here.

The beginning of the automated software testing cycle is a test within a test. The conclusion of the Proof of Concept will conclude the first step in the automated software testing cycle. The POC implements Test Planning, Test Analysis, and Test Design. The remaining steps in the automated software testing cycle are Construction and Verification, Testing Cycles, Final Testing and Post Implementation.

The second part of this article is located here.

About the Author: Lisa Corkren is a certified technical lead for DeRisk IT Inc. She specializes in automated testing strategies and project management. She has worked on numerous platforms of both Manual and Automated Testing. Her automated software proficiencies include SmartBear's TestComplete.

Note: DeRisk IT is now known as DeRisk QA.