Test Planning - KU-SKE17/Software-Process GitHub Wiki

Information included in a Test Plan?

  • Scope
  • Schedule
  • Test Env -> equipment, software, servers
  • Resources -> people, equipment, software, servers
  • Requirement Traceability Matrix -> trace requirements to tests, test to requirements
  • What is not tested
  • Test cases and scripts -> separate documents

Pro of test plan

  • Improve communication
  • Organize, Schedule, and manage test effort
  • List of what outputs are expected: tools, test artifacts, and reports the testers will create
  • Help measure software quality
  • Know when to stop
  • Gain management understanding and support

Test Plan Activities

  • Write only what is needed, but be complete
  • List what cannot test
  • Have the plan reviewed
  • Use a Test Plan template
  • Make it a living document
    • keep it up to date & relevant
    • part of the project "information radiator" [Scrum and XP from]
    • online

State for Testing

  • Unit Test
    • Unit Test Plan, included RTM
    • create the test code -> when is test code written? (TDD?)
    • running unit tests (test plan: how to run tests?)
    • automate -> use C.I. -> have result sent to your "information radiator"
  • Design Verification Test
    • Integration tests: verifies that components work together as intended
    • Functional tests: done by test team (&developers). The largest part of testing
    • DVTn & Teats Cases
  • System Validation Test
    • System Tests (E2E testing)
    • Non-functional
      • usability, reliability, scalability(load testing services)
      • performance
      • security
  • Customer Acceptance Testing
    • Test plan is written by test group with involvement of customer
    • Requires agreement by customer, management, and other "stakeholders"

5 Main Defect Reporting Activities

  • Analysis
    • verify it's really a defect
    • find the root cause(test wrong? app executed wrong? product wrong?)
    • determine if it is reproducible or repeatable (logs are keys)
      • how to reproduce
    • find the minimum steps to reproduce
    • attempt to isolate the issue
    • additional info the could be useful to developers
  • Report
    • step1: Ensure it is not duplicate
    • step2: Talk with the developers
    • step3: Enter it into the system (defect tracker)
    • step4: Make sure it gets fixed -> what must be done so defect report is noticed?
  • Track (make sure developers notice it and act on it)
  • Retest
    • when? The status of defect is changed by developers
    • results
      • fixed
      • tests still fails
      • fixed but new defect is discovered [regression tests]
  • Close
    • who does it? Depend on team!
      • tester
      • Defect Review Board deices

Risk Associated

  • Lack of management support
  • Lack of customer involvement

Defects are added to a Defect Tracking System

  • Searchable
  • Defect Reports

Defect Report

  • ID or Number
  • Submitter
  • Submit Date
  • Program or applies to. Component.
  • Product version
  • Platform
  • Title -> be brief and descriptive, try be useful for search
  • Overall report status: open|close|re-open
  • Severity: High(critical), Medium, Low(can be worked around), Trivial
  • Priority: P1, P2, ...
  • Resolution status: (is someone working on this? is it fixed? will it ever be fixed?)
  • Notes
  • Miscellaneous
  • Supporting Information
    • Error output
    • Screenshots
    • test case (code)
    • "flash drive with data or files"
    • trace files, error logs, etc.