Effective QA Testing: Managing Short Release Deadlines

Software quality is a vitally important issue in software development. As companies are facing increasingly shorter cycle times, and formal specifications are sometimes overlooked, it is even more critical that quality engineers maximize their time and effort to ensure project quality is not sacrificed. Today's rapid application development (RAD), the dominant approach in client-server and Internet software projects, focuses on shortened development schedules. This software development method provides early review points, delivered as "builds" or iterations of development, to ensure that requirements are met. This article outlines some strategies that can make your testing department more efficient and more effective.

Even for a short testing cycle, there are three steps that your quality engineers can take to make your company's testing more productive:

Discover the project's requirements
Define what areas of quality are most critical, to allocate appropriate levels of time and effort to different components of the project
Define a test plan, including release criteria

1. Discover the Requirements

Your quality engineers should play detective. Your project will have a variety of requirements over its lifetime, through several releases. Some requirements will be more important sooner, and others later. It is important that your Quality Assurance team focus on this release's requirements.

First and foremost, this requires data gathering. Once data is gathered, it is transformed into requirements specifics - where you really discover the product's intent.

Requirements are the reasons that drive design choices. If development has begun on a project, this indicates that design decisions were made, even if there is no formal specification. The product was built based on its requirements; otherwise, there would not be a product to test. Lots of people made lots of choices in building the software. The reasons for those choices are the requirements.

Software systems may have hundreds of requirements. The key is not to uncover them all - but to choose how much you're willing to invest in finding out what the requirements are. This stage involves a risk analysis. The fewer requirements you probe in depth, the more risk is incurred. Your company needs to meet its release deadlines, but is taking dangerous chances if your quality engineers don't learn enough about the product's requirements to decide what to test and at what depth. During this requirements gathering phase, it is also helpful for the developers to communicate with the QA team about what areas of the product they consider to be the most complex from a development standpoint. Those areas pose a high risk for the most defects, and should receive more attention from QA, particularly if they are areas critically important to the client.

There are a variety of methods the QA team can utilize to discover a product's requirements, even if there is no formal specification:

Read any documentation on the product, even if it is informal design notes. Talk to the project manager, and anyone else who might have contact with the client or who was involved at the design stage. If your QA department is not currently involved in the project planning stage in your company, encourage them to initiate involvement. The earlier QA can learn about how a product is designed and the business rules governing the design of the product, the more effective testing of that product will be.
Encourage communication between QA and developers. The more testers understand about how the code was developed, the underlying database structure of the project (if applicable), and the extent of unit testing and code reviews, the more they learn about areas of potential vulnerability in the project.
If a previous version of the project is already in production, encourage communication between customer support and QA. Those who interact with the clients directly generally have valuable information on how customers use the software on a daily basis. This information is vital to QA, since they can design more realistic testing scenarios, and may uncover test cases not previously thought of.

2. Define What "Quality" Means to This Project

Once the requirements are known, and the QA team understands what must be tested, the next step is to figure out how hard it should be tested.

The ultimate goal of a software project is to add value to your company. Testing goals must reflect this project's quality criteria. Your project quality definition helps you plan how much testing you need to do in which areas.

Not all requirements are critical to your project's success. Testers can choose how much to test each requirement based on how important each requirement is to your project. The key is to look for the combination of requirements that provides the critical set of features needed by your customer base.

3. Define a Test Plan Including Release Criteria

Once requirements and prioritization are known, QA is now able to define the test plan and the release criteria.

Testing is certainly a big part of SQA, but by no means the only part. Testing, of course, is the process of executing a computer program with the specific intention of finding errors in it. It's nearly impossible to prove that a program is correct, so instead testers do their best to make it fail. Unfortunately, many testers perform testing quite casually, without a real plan and without keeping any records of how the tests went.

Proper software testing requires a plan, or test script. It includes documentation, sample input datasets, and records of test results. Instead of being informal and ad hoc, good software testing is a systematic, reproducible effort with well-defined expectations. Consider each requirement in the context of the entire product, and plan what will and will not be tested. Use cases or scenarios should be developed to illustrate how to test each requirement or set of requirements. Project Management and QA should specify the release criteria, so everyone knows what the specific testing goals are. Make sure other people on the project review the release criteria. Confirm that they know what project quality is, and how that translates into non-negotiable ship criteria and project success. The project should be released based on the release criteria and no other criteria.

Conclusion

Once there is a test plan that corresponds to the product's requirements, the job is half done. Testing against this test plan will ensure that key areas of the project are targeted, and provide more assurance that testing is covering these critical areas. Of course the job does not end here. Defect logging, prioritizing, tracking, and retesting are necessary to communicate issues effectively. Effective defect tracking strongly contributes to enhancing software quality and reducing development project costs. Even without a formal specification and even with a tight timeline, your testing group can still maximize their effectiveness by discovering key requirements, identifying the product's quality criteria, creating a test plan based on this information, and having a structured method of defect tracking and reporting.