email article printer friendly

Testing in Application Lifecycle Management
Understand the five phases of the application lifecycle, and learn which tests to perform in each of them.
by Jeff Levinson

June 1, 2006

Testing should occur throughout the application lifecycle. If you test your application as a project progresses, then you'll encounter fewer bugs when you deploy. It is important to start testing in the planning phase of your project, and continue testing through the analysis and requirements, architecture and design, construction, and testing and deployment phases. These five loosely grouped phases of development represent a typical spiral or iterative lifecycle pattern (see Figure 1). You should perform various types of tests—such as business and process validation, architecture analysis, and unit, system, and integration testing—in each phase (see Table 1). In this article you'll learn what type of tests to use and how to implement them throughout your application lifecycle.

Let's examine the type of testing done in each phase:

• The planning phase requires business validation. Your business units need to determine if the business model allows for an application development process or purchase process that will lead to a more efficient environment. This validation can be a combination of resource savings, transactional speed, better customer service, and more. You do not look at technology in this phase.
• The analysis or requirements phase happens when analysts work with business users to create use cases. After the use cases are created, you complete a testing exercise to weed out unnecessary, undocumented, or incorrect steps in the process.
• The architecture and design phase varies. You can create your architecture at a high level, or at a deeper level, in this phase. From either view, the architecture must be tested. You can use a variety of methods to test your architecture.
• The construction phase happens after the detailed design and construction are finished. You can associate the type of testing in this phase with application development: unit testing and functional testing. In this phase you test the smallest unit of an application (a method); this is called white-box testing. The methods that make up a system function are also tested in this phase; this is called black-box testing. All of the unit tests, which make up your functional area, must pass before your functional tests are completed.
• The testing or deployment phase, typically handled by dedicated, expert testers, is designed to test the system, or the sum of the functions that the system performs based on functional and non-functional requirements. This is also called black-box testing. Integration testing examines whether the system works well in the overall business environment. Does the system send and receive messages from other systems correctly?

Once you finish these testing cycles, the application is deployed and evaluated. Then the process begins again. Evaluating change requests is part of the planning phase, which continues throughout the entire lifecycle. You should go through each of these testing phases with your change requests.

Security Testing
You might think it's strange that security testing sits in the middle of this process. Most lifecycle-pattern diagrams don't include security, but it's important to explain how it relates to testing. Security is not an afterthought. It is embedded in everything you do as members of a software development team.

Not long ago, Microsoft was painted as the villain in the security arena. Since then, Microsoft has established a world-class security lifecycle, similar to the one demonstrated in Figure 1—they make security the center and everything revolves around it. Other companies should follow Microsoft's lead.

Why is security a big deal? With all of the hype around security holes and zero-day vulnerabilities, security is even more critical than it has been in the past. Your company can lose their reputation and trust because of security violations. Have you heard of the Sarbanes-Oxley Act (SOX)? SOX was passed by congress in the wake of the Enron scandal, and deals with business security issues such as access, auditing and accountability.

What type of security testing do you complete in each phase of the application lifecycle? In the planning phase, your business is responsible for determining its security requirements. This process involves data classification, data access, and auditing. Your business tests these requirements as an evaluation process. The analysis or requirements phase ensures that the security requirements stated in the planning phase are enforced. You can evaluate the process through which the user interacts with the system to validate these requirements. You test in the architecture and design phase to ensure that your architecture supports the type of security your business users require. (For example, if you require a security mechanism that must authenticate users before every operation, you must ensure that the architecture supports it. If your system takes feeds from other systems, then you must also ensure the architecture can support the necessary security to accept feeds.) During the construction phase, you must create security tests to validate that your code can withstand hacking attempts. And finally, during the testing or deployment phase, you need to make sure that the overall functionality of the system is secure. You must ensure that using two modules of the system in combination doesn't open up a new security hole.

A Test Approach for Each Phase
How do you perform testing and validate the results at each phase in the software development lifecycle? Some phases are obviously easier than others from a testing standpoint. As a developer, you have a given set of parameters with which to work. You test code; you test performance; you test functionality. But, in some phases, you use more "art" than "science" to complete testing. Let's look at testing approaches for each of the phases.