Test Spec/Outline - Why ?
● Avoids omissions and tunnel vision. Better test coverage.
● Concisely communicates testing effort: what can be, should be, and will be tested.
● Makes testing visible and respected.
● Efficiency: avoids redundancy. Organizes similar test case candidates so no overlaps.
● Knowledge capture: build in coverage elements as experience them over time.
Test Cases - What ?
● Derived from Test Spec, Functional Spec., and Detailed Design.
● Detailed to lowest level of complexity.
● Standard info: objective, setup steps, repro path, expected results.
● Test Case execution logged as pass or fail.
● Every failed Test Case must have an associated bug reported.
Test Cases - Why?
● Makes program failure obvious. How tester know whether bug exists? (Expected result)
● Best of breed: test case has been refined. Highest likelihood finding error (vs adhoc).
● Test coverage: how many cases have passed, failed, or not yet been executed.
Bug Report - What?
● Derived from planned Test Cases, or Adhoc Testing.
● Every bug must have an associated Test Case.
● Standard Info: Test Case Info., plus actual results, problem, comments, etc.
Bug Report - Why?
● Communicate bug for reproducibility, resolution, and regression.
● Track bug status (open, resolved, closed).
● Ensure bug is not forgotten, lost or ignored.
● Used to back create test case where none existed before.
Weekly Status Reports - What?
● Test Case coverage (pass, fail, not yet executed).
● Bug status summary (severity, priority, etc.)
● Task status (schedule).
● Issue list of closed and open action items.
● Risk list identifying potential problems.
● Other project metrics.
Weekly Status Report - Why?
● Communicate project status.
● Visibility for new and existing issues.
● Visibility for new and existing risks.
● Record of events.
Exit Reports - What?
● Test Release Report: Certification as to extent of coverage, and assessment of project’s readiness for release.
● Milestone Exit Report: After each phase of testing completed, this report lists test cases executed, pass/fail status, & bug find status.
Exit Reports - Why?
● Consensus that all predecessor tasks are completed and milestone can be exited.
● Act of organizing report forces critical analysis of all project components.
● Reality check if on schedule, within budget, and within acceptable quality tolerances.
● Visibility of project status to senior mgmt.
SOFTWARE QUALITY ASSURANCE AND CONTROL
SOFTWARE QUALITY AND COST ASPECT
STABLE PROCESS OF SOFTWARE TESTING
STABLE PROCESS OF SOFTWARE TESTING PART TWO
DEFECTS IN SOFTWARE TESTING
REDUCTION OF DEFECTS IN SOFTWARE TESTING
SOFTWARE TESTING AND EFFECTING FACTORS
SCOPE OF SOFTWARE TESTING
TESTING LIFE CYCLE PART ONE
TESTING LIFE CYCLE PART TWO
TESTING LIFE CYCLE PART THREE
SOFTWARE TESTING AND CONSTRAINTS WITH IN IT
TESTING CONSTRAINTS PART TWO
LIFE CYCLE TESTING
Independent Software Testing
Testing verification and validation
Functional and structural testing
Static and dynamic testing
V model testing
Eleven steps of V model testing
Execution testing technique
Recovery Testing technique
Operation testing technique
Compliance software testing technique
Security testing technique