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)
- 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.