ICS 121: QA Plans

Overview

Who, What, and Why?

QA Plan Contents

Aspects to address

QA Activities > Reviews

QA Activities > Testing Approaches

Exploratory testing
Just get the product and poke around. Useful if QA team needs to gain familiarity before forming a detailed plan. Useful for verifying that a product is ready for testing by QA team.
Ad hoc testing
Manually exercise the product to just see if you can break it. Ideas from test case design can be applied "on the fly."
Structured testing
More systematic manual testing. Testers work through a detailed manual test suite.
Automated testing
  • Record-and-playback: test through the GUI or web interface with a simulated user
  • Programmatic testing: write test code to run against product code

Black box / specification-based testing
Test only the visible UI or specified API, do not make use of any knowledge of the implementation. Try to cover every specified requirement.
White box / implementation-based testing
Design the test suite using knowledge of the product implementation. Try to cover every part of the implementation.

Regression testing
Verify that solved problems remain solved. And, testing that fixes do not introduce unintended changes. Usually automated.
Smoke testing / Quick tests / Nightly tests
Automated test of selected features that can be run often. E.g., run by developers before they do a commit.

User acceptance testing
Final, high-level test of the entire system to see if it is acceptable to users. Think in open-ended, real-world terms.
Beta testing
Usually ad hoc testing by limited outside people. Beta test programs must be managed to get many results.
Early access
Actual usage by a broader group of outside people

QA Activities > Testing scopes

Unit testing
Test one function, method, or class at a time. Try to isolate that element from the rest of the product. Each test is very simple. Assigning blame is obvious. Can be started very early in development.
Integration testing
Test specific combinations of components. Other components may need to be replaced with stubs or drivers. Test cases focus on interactions between components. Can be started during development.
System testing
Systematic testing of the entire system. Test cases get larger and more complex. Harder to assign blame. Can only be started after entire system is implemented.
Staging
System testing in something very close to the system's intended operating environment. Usually done with actual user data. Can only be done just before deployment.

QA Activities > Testing specific quality goals

QA strategy

example use case templatesample test plan templateProject plan template