The Process of software testing part two

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.


RELATED POST

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

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique


Operation testing technique


Compliance software testing technique

Security testing technique

No comments:

Post a Comment