DOQS BEST PRACTICE GUIDES

The following Best Practice Guides are currently available:

Clarifying Project Complexity - Many information technology projects carry complexity that often goes unrecognized during the early stages of project initiation and requirements analysis. This complexity is inherent in the business system being described by the project requirements. Because such complexity has the greatest impact on the project during technical design, it is often overlooked during earlier project planning and activity. However, the complexity is a significant contributor to the effort required to build and test the system, and to the size and cost of the system. As a result, projects are more likely to conform to their schedules and budgets if these business complexities are built into the project charter and plan from the beginning. This guide describes four quality-based patterns built on the idea that any system is a mechanism for turning customer requirements into satisfactory conformance. They allow simple quality management principles to be used to quickly pinpoint areas within the project scope that will experience increased complexity, and therefore higher need for project resources. These areas can then receive increased scrutiny during project planning.

Understanding Requirements - The purpose of requirements definition is to establish a common understanding of the requirements for a system between the customers and the project team. This involves clarifying the problem and business case associated with the project, and the specification of the full functional and technical requirements to be met to solve the associated business problems. Requirements analysis seeks and documents the business problems to be solved by the project based upon the collection of concerns, issues, needs, and requests from all project stakeholders throughout the organization. This guide outlines two goals: 1) defining the business problem to be solved and the rationale that determines the importance and value of the solution to the business, and 2) describing what needs to happen in order to solve the defined problem; and the criteria that should be used to determine if the project reaches successful implementation.

Setting Test Objectives - Testing covers the broadest range of activities required to both verify and validate deliverables associated with the project efforts and the final system components delivered into production. This guide cover the two perspectives on testing: 1) verification that addresses the issues surrounding the correctness of the deliverables produced with respect to previous project deliverables and general IT standards and procedures, and 2) Validation that addresses the issues surrounding whether the deliverables produced will actually meet the needs of the user community to which they are targeted. Verification asks the question "Did we do it right?" Validation asks "Did we do the right thing?" Ultimately, validation of the results of an e-business project is the goal of this test plan. However, experience shows that deliverables that can't be verified are difficult to impossible to validate.

Developing Test Plans - Even though testing is rarely as scientific and comprehensive as we'd like it to be; it always pays to plan testing as if it were going to be very scientific and comprehensive. The reason is that it helps to put any given test case into the fullest picture of the system and the testing risk being managed. This guide defines how to create such a plan; but it only works if you write the plan down! Make sure you create a Test Plan document. Yes, it will look more rigorous than the actual process you follow during testing, but the results will be better if you take a little extra time to formalize the planning. Once documented, we can focus earliest on the parts of the system that are most likely to fail, and continuously adjust the plan accordingly.

Planning Test Strategies - The test strategy maps techniques for testing against the various types of verification and validation test types available and attempts to prioritize how testing resources will be allocated generally across the project. Each individual situation is ultimately evaluated on a case-by-case basis, but the general strategy documents the perceived risk areas being addressed by the test plan. This guide includes a general prioritizationmatrix that helps software teams plan integrated testing throughout the development process.