No matter what the origin of your CM software, improper installation, poor training, and program defects can lead to disaster. This article discusses how to make the most of your current CM tools, and how to ensure that your CM system will do what it's supposed to do.
This article makes three points. First, errors happen. Second, systems can encourage errors. Third, a basic understanding of the kinds of errors humans make can help us design better systems. Here are some suggestions to help avert trouble.
You have a Y2K effort in place, and it's all about preparation for an event you know is coming. What have you overlooked that’s going to bite you? This article will help give you 20-20 foresight to anticipate potential "gotchas."
If you're paying the bill for all the graphics, glitz, and applets, you're going to want to have some evidence that thousands of potential customers have actually seen your Web site. Here is a step-by-step recipe for testing system, network, and Internet reporting systems.
A use case is a sequence of actions performed by a system, which combined together produce a result of value to a system user. Use cases describe the "process flows" through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Here is an example of how a use case is used to derive and prioritize test cases.
Rapid application development means you have to accept that the things you build will need to change. Approach development in a way that makes it easy to transform yesterday’s code into what you need tomorrow. This article explains how testing works in the world of Extreme Programming.
Many of the culprits responsible for security breaches found on corporate networks and the Internet today have used buffer overrun problems as the main way to exploit the system. Here is an examination of buffer overrun bugs and how to prevent them.
Test coverage is about insuring that test plans and test cases include information vital for successful testing of the program in the areas of functionality, performance, and the overall quality of the software. This article shows how to create a plan of attack to provide strong test coverage, determine the scenarios for the test plan, and manage the changes made to information used by testing.
Management and testers may not often speak the same language. This article takes an unvarnished look at the communication gap between quality advocates and management and offers ways to open a dialogue and gain credibility.