Software design errors and faults can be discovered and software designs validated by two techniques like: 1) Requirements-based test case design being the primary technique 2) Another important technique being the early design-based test case design. In design-based test case design the information for deriving them is taken from the software design documentation. Design-based test cases focus on the data and process paths within the software structures. Internal interfaces, complex paths or processes, worst-case scenarios, design risks and weak areas, etc. are all explored by constructing specialized test cases and analyzing how the design should handle them and whether it deals with them properly. In software testing effort, requirements-based and design-based test cases provide specific examples that can be used in design reviews or walkthroughs. Together they provide a comprehensive and rich resource for design based software testing. Design Testing Metrics: Increasingly, formal design reviews are adopting metrics as a means of quantifying test results and clearly defining expected results. The metrics (measures that are presumed to predict an aspect of software quality) vary greatly. Some are developed from scored questionnaires or checklists. For example, one group of questions may relate to design integrity and system security. Typical Integrity Questions can be like the following Q.1: Are security features controlled from independent modules? Q.2: Is an audit trail of accesses maintained for review or investigation? Q.3: Are passwords and access keywords blanked out? Q.4: Does it require changes in multiple programs to defeat the access security? Each reviewer would answer these questions, and their answers would be graded or scored. Over time, minimum scores are established and used as pass/ fail criteria for the integrity metric. Designs that score below the minimum are reworked and subjected to additional review testing before being accepted. Read the full article