Test Planning Activity

The goal of this activity is to weigh the tradeoffs of different testing approaches in the context of your project and come up with a test plan that your team will follow.

Notate your test plan as an outline with enough detail that the current team members or hypothetical future team members can follow it. Place the test plan somewhere that the whole team can see it and the manager can share it with the instructor.

Discussion Structure

Your team’s discussion should consider the testing approaches discussed in lecture through the lens of the tradeoff between confidence gained, initial cost, and repeat cost. Below are some possible topics you can discuss.

• How important is it to test specific features?
• Is a feature particularly complicated or important to users?
• What parts of the system depend on others? Are certain parts depended on by many others?
• How likely is a feature to change? Is something still being prototyped, or is it more or less stable?
• What team resources (e.g., time, prior knowledge) do you have for different automated testing approaches?
• If your project requires a custom algorithm, how will you determine whether it works well enough?
• If there are parts of your system that are too difficult to test automatically, what manual testing protocols will you put in place? Note that "we’ll test it manually" must not be an excuse to avoid testing your software. Any manual testing needs to follow a documented protocol, be repeatable, and be repeated by the team when needed.

Documenting Your Test Plan

The term "Test Pyramid" describes a recommended proportion of unit tests, integration tests and end-to-end tests. Unit tests, being at the bottom of the pyramid, are the largest category. End-to-end tests, being at the top of the pyramid, are the smallest category.

During your discussion, brainstorm test case ideas and start to notate them in your test plan. Describe your tests as sequences of initial application state, actions, and post-action application state. Label whether the test is a unit, integration, or end-to-end test and whether any data sources need to be mocked. For example:

• Unit tests
  • "First time attending" checkbox behavior
    • The "Is it your first time attending" input starts as a blank option.
    • When the user selects "No", a required checkbox appears asking if they want to be a new person's "Buddy".
    • Mocking: Component is tested in isolation without making any API requests.

Your plan doesn't need to be exhaustive, but it should have enough detail for the team and others to follow.