System testing is not a single test, but rather a whole series of possible tests you might want to run to ensure that your application is ready for prime time. In "System testing: Can your program take a lickin' and keep on tickin'?" we introduced the many aspects of system testing and took an in-depth look at one aspect of this testing phase: performance and stress testing. In my experience, those are the two areas most developers think about when they plan the system test. However, depending on your project, you can do much more to ensure that you’re ready for a live, production environment.
Let’s turn our attention to two additional system test events: security testing and requirements testing. Remember the scalability rule first. For some applications, these tests may be vitally important. For others, they may be less important. But if you are aware of the types of testing that can be performed, you can make a conscious decision about what testing makes sense for your application.
Depending on the nature of the project, developers may need to be particularly vigilant in addressing security concerns. An Internet application that processes credit cards and stores customer information needs to be secure. It can’t be mostly secure or reasonably secure. It needs to be 100 percent secure. Of course, an application that maintains a library of nonconfidential company information for all employees to view may not need a security test at all.
Know thy data
Understanding security needs starts with business requirements. You must work with your customer to understand the importance and confidentiality of the data that is read, updated, and created by your application. Then, determine the types of people who have access to the application and to the data. Picture this as a table with data categories in the columns and people in the rows. For each square in the table, determine what level of access, if any, the people should have to the data. Then, you can design and build the application to those requirements. For each type of person in the rows, test that the access is as it should be. This process entails two important steps:
- Make sure that people have the level of access they need. For instance, the accounts payable clerks may need to browse certain functions and update others.
- Make sure that it’s impossible to gain access to data or transactions in the other boxes in the table. For instance, those same accounts payable clerks may not be able to generate a payment request over $1,000.
Security testing may require some level of creativity. If you have an Internet e-commerce application, you want to make sure that your customers can process a purchase transaction, but you also need to make sure the site is secure from hackers (or are they crackers?). Your databases may be secure, but can a hacker access and deface your Web pages?
On the other hand, it’s important to remember that added security has added cost. You may decide that a breach would be a nuisance but not something you want to spend a lot of money to avoid. You may need to rely on procedures and training to help with security. You can also enforce security by generating audit reports after the fact that point out unauthorized access.
Areas to test
When you design your security tests, you want to test the obvious and the obscure. This includes:
- Sign-on procedures. Are passwords required? Do users need to reset them? Can a person access the application without going through the sign-on screen?
- Database/file security. Database access needs to be controlled, consistent with the overall rights of each user.
- Physical security. What if your application is secure but someone steals your server?
- Third-party tools. Are vendor add-ons and tools secure? Double-check firewalls and all third-party software.
- Procedures. Are the right procedures and reports in place to keep the environment secure? Are the policies reviewed periodically to ensure that they are still adequate? Do new risks require new procedures?
- Test environment. Does your test environment mimic the production environment for important security features? You can’t adequately test confidential systems in a test environment that is open to everyone.
Finally, depending on the level of security required, you may need outside expertise to evaluate your security precautions and vulnerabilities. There is a lot of expertise available—no doubt gained from the multitude of security breaches experienced in real life. These experts can help ensure that you don’t repeat these same mistakes.
The purpose of the requirements test is to validate that the system meets all business requirements. This test is relatively straightforward, but it requires that you have done a good job documenting the requirements during the analysis phase. If you don’t have written requirements, you have nothing to validate against.
A good technique is to list the business requirements in the first column of a table. In the second column, describe how you will test that the requirement is satisfied. This could include the specific test case(s) used. The third column should include an indication that the test was completed and what the results were. Remember, you are validating that all features and functions work as they should. You are not trying to break the system. Just include one or more cases that test the business requirement and make sure that the results are as planned.
In addition to the business requirements, other unstated requirements may need testing as well. These might include organizational standards, policies, auditing requirements, and so on. For example, all online screens may need to include the company logo. Although this was not a project requirement, it may be a company standard that needs to be validated.
Key points to remember
As you start evaluating whether your application meets security and business requirements, keep these issues in mind:
- Security testing is designed to prove that authorized users are granted appropriate access to the application and that any other access is denied.
- Security testing is based on an understanding of the sensitivity and confidentiality of your data. Extreme security may need to be built into applications that use or create highly confidential data. Data that is less confidential can get by with less sophisticated security.
- Requirements testing validates that the application meets all the documented business requirements. You must do a good job of documenting requirements to perform this test.
In the next two articles, we will continue with our look at the system testing process. We’ll focus on usability testing, documentation testing, training testing, interface testing, disaster recovery testing, and multiple location testing.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.