Newsletters

Ten Steps to Building Software Test Automation That Works

Design Your Test Automation and Transition Process

Traditional Software Development Environment

Diagram one shows a traditional software environment where the bulk of development is completed prior to delegating the application to the testing team. This team is often made up of volunteers, subcontractors, or borrowed personnel from other departments in the organization. The crash exercise is performed just before the product is released to the field. The test team does whatever it takes to ensure a smooth automation process. This may require working double shifts, week-ends and holidays. Defects are recorded and fixes are provided for the defects found. The lack of time allows, at best, a quick verification of the fixes. However, there never seems to be time to retest the entire product to determine if the fix affected any other function in the software. The sad reality is that clients end up finding many of the problems.

Automated Test Environment

In an automated testing environment as shown in Diagram two, the product is tested whenever there is a new build or, ideally, daily. The frequency is often increased as the release date approaches. This is dependent on the development method being deployed. Defects are posted, fixed, and re-tested on a daily basis. The complete test is run to flush out any problems introduced by the fixes.

The end result is that product quality is not compromised by the inability and lack of time to perform adequate testing.

Where does your process fit in the examples above?

The first step in the transition process is to determine where you are today based on the diagrams above. Making the transition to an automated test environment requires change not only to the way testing is performed, but to the development processes as well.

The 3 major areas of change are to:

  1. People
  2. Processes
  3. Technology

People
The roles and responsibilities of the people will change. The fear of the unknown is minimized as you begin to define future changes.

Processes
Automating the testing will impact the overall testing processes. Laying out the high level changes to the testing processes will ease the transition process.

Technology
The new technology imposed by automating the testing may change the communication of product defects to the developers.

Go to the link below for a listing or just google the phrase: "transitioning to automated software testing."
Link

Here are several steps that can be taken to get the process started:

  1. Organize a team made up of product management, development, and quality assurance
  2. Document, at a high level, the current development and testing processes
  3. Prioritize the test cases to be automated
  4. Modify roles and responsibilities
  5. Map out transition processes realizing the change will take place over several months.

The next logical step in your transition to test automation is to select the right tools for your people, processes, and technology. Tune in for next months discussion of Tool Selection.

Please e-mail your comments to cblaylock@qasignature.com or call 617 510-6545.

Click here for a PDF copy of the complete white paper:

Proof of Concept Service

To Companies Who Want To Build QA Automation - But Can't Get Started. Take qaSignature For A Test Drive.

An effective approach to getting started with test automation is the qaSignature Proof of Concept Service. Standard test automation produces limited results and is difficult and costly to maintain. The qaSignature methodology is different. We'll prove it. Give us your most difficult automation challenge. We will:

  • Recommend the optimal automation tool (or use yours)
  • Build the automation as a proof of concept and show you how our methodology works
  • Let you change the code, we will update the test and rerun
  • Show you the results in our easy to follow test logs
  • Prioritize areas for automation based on results from a cost benefit analysis
  • Give you a fixed price estimate for a fast start program

Here's what our clients had to say.

"The amount of automation that they were able to develop in a couple of days including fact finding was impressive. Their competition could not even begin the process without first learning the application."
Keith Hillyard, Custom Engineering SQA Manager, Kronos

"The qaSignature proof of concept is a "no brainer." They delivered much more than we expected. The process helped us map out our QA Automation Framework."
Frank F. Frazier Jr., Senior Program Manager, ZANTAZ

"The dedication, enthusiasm and passion of the qaSignature team was refreshing. I would recommend them to anyone who needs to develop QA Automation."
Paul Bradley, Systems Consultant, DAFCA Inc.

"The proof of concept demonstrated the applicability of applying the qaSignature QA Automation Methodology to our Agile Development Process."
Keith Hillyard, Custom Engineering SQA Manager, Kronos

"I was impressed by qaSignature's objectivity. They recommended the right tool for the job even though it wasn't their standard offering. They really know QA Automation."
Larry Leonard, Director of Development, SmartTime

Call us now @ 617 510-6545

Click on the link below for details:

Proof of Concept

«« Back to qaSignature Newsletter Archive