Testing is something you should always try to devote extra time to. Testing is a boring job—someone has to run the code over and over again, testing different things in different modules, taking notes about its performance. But it' s got to be done. You should have at your disposal testers who are ready and willing to thoroughly run your new code through its paces.
There are several kinds of testing:
Module testing A programmer completes a module of code and needs to test it. Some modules don 't lend themselves to much module testing, because they' re designed to interface with other modules. Still, the programmer can check to make sure that variables load up correctly, that the code goes to the places it s supposed to go to depending on the input, and that memory gets cleaned up and the program exits correctly. Often developers can run their code through a checker that steps the code line by line to see how it behaves and how it loads up memory variables. The process can be at once very interesting and yet extremely frustrating, because the developer has something going wrong but can' t figure out where—all of the code appears to be doing what she wants it to do.
At this stage of the game, dynamic link libraries (ELLs) and other informational files are also tested for complete accurate content.
Unit testing Once several modules that go together have been satisfactorily tested, you can test them all at once in unit testing. The idea here is that you might test an entire printing system or a set of algorithms that calculates something. You ' re testing the functionality of pieces that have been put together to form a cohesive something. System testing Next, you test the entire system as a whole. Make sure the system flows as expected, that the user doesn ' t encounter unexpected loops or gotchas (such as "deer in the headlights" frozen screens), that the system is fast and functional, and that it delivers what the customer is expecting. System testing should take you a long time, because you thoroughly test each component and the whole.
User acceptance testing (UAT) This is the time when you actually bring in a small set of users to begin testing the deliverable. By the time you get to UAT, you should' ve worked out all bugs, speed or logic issues, and flow problems. The system should be at its best, most pristine state. This is the system you currently expect the user to utilize in production—until the UAT testers find the problems others missed.
Testing especially becomes important when you' re outsourcing some activities through a contractor or other third party such as a business partner. Since you haven't have a chance to keep an eye on third parties while they work on elements of your project, it s even more important to follow strict testing regimens.
Was this article helpful?