|
|
When your enterprise application is in the design phase, you should also plan for testing. Many different ideas exist about how testing should be conducted in the life cycle of the application. Our suggestion is to continuously perform testings from unit tests up to complete scale tests. The latter type will obviously be done later in the development cycle of the application. To succeed with tests and achieve the goals you set with testing, you need to follow these seven rules:
Do not let the testing be left to the end of application development when little or no time exists. Plan the tests from the beginning and schedule tests during the whole development phase. A good practice is to have roughly the same time for tests as for development—though few projects include that much time for testing. The earlier an error is found, the less expensive it is to correct.
The tests must have realistic and clear criteria to successfully test for. The collection of measurable criteria already starts at the requirement stage. As each requirement is defined, it should be evaluated: Is the requirement correct? Is it objective, measurable, and therefore testable? It is not enough, for instance, to specify that a certain action be fast. You must establish performance criteria defining what "fast" means.
Too often have we seen unskilled persons or new developers being put into the role of testers. Testing is not a good training ground for new developers. A tester requires unique skills—not only the discipline to work through a problem systematically, but also business knowledge and programming knowledge.
Too often have we seen a test environment placed on an old server shared by a couple of other projects. The disks are nearly full and the performance of the server is bad. Although this may reflect the project environment, the major problem is often that the wrong software and/or version is installed on this "test server." Try to make the test server mirror the production server both in hardware and software. How can you otherwise be sure that the application will run in the production environment when you have tested in a test environment with different versions of DLLs and software? For a browser-based enterprise application, be sure to test the different browsers that could be used with the application under different operating systems.
The attacks on systems that are exposed to the Web will likely not lessen in the future. As Internet use continues to evolve into a mainstay of daily life, the threat from the Internet in the form of worms and viruses presents a major problem to enterprise applications. With the increase in functionality and interconnectivity available comes a corresponding increase in the necessity to build security into the code at all levels of a system.
Even if it sounds great to have a tool that can make all the dreary unit tests for you, such tools are seldom 100 percent accurate. Even if a testing tool finally manages to automatically test your code, you end up having written many pages of test code to guide the testing tool. What we are saying is that successfully introducing automated testing in a project requires time. If you are developing an enterprise application that will last for years, it can be wise to at least use some kind of automatic testing such as the free NUnit (which we cover in more detail in the next section); however, in most cases manual testing is faster than automatic testing (at least if you count the time to set up the tool and incorporate scripts in the initial testing phase). Only in the long run can the benefits of an automated testing tool be determined.
| Tip |
If you want to break this rule, see the section "Testing Tools" later in this chapter. |
If your enterprise application proves complex to test now, it will probably be even worse later when your managed enterprise application talks with unmanaged code. The solution is to arm yourself with caution and skepticism. Test your prototypes and applications for basic flaws early on, particularly in the areas of security and performance. We never believe anyone who tells us we can test later when more of the "real" application is built, and you neither should you.
|
|