-
Notifications
You must be signed in to change notification settings - Fork 1
Testing Plan
"Anything that can go wrong will go wrong." - Murphy’s Law
Below is an example of a test template. There’s quite a lot of information to gather for a single test but in doing so we will be able to have a clear well defined understanding of the system and its functionality.
[INSERT IMAGE HERE]
- Description: This is a vague word used to describe that area. For workflow as an example I have expanded this into 2 columns: workflow step and step field. Mould it to suit the needs of those tests.
- Test: Should be a description of the functionality the user should be able to complete
- Expected: This is the expected result of the user carrying out the functionality described in the test column.
- Follow On: Can be used for additional information required to complete the test (this might get removed in favour of expected containing the information instead)
- Pass/Fail: Pass or Fail should be put into this field. If the test passed, set the background to green and red for fail.
- Actual Result: If the test case worked correctly, the exact same as the expected description explained. Type expected into this field. Otherwise give a detailed description of why it failed or differed from the expected.
- Comment: This can be used for questions about the test. E.g. “I expect it to do this…”, “should this not be…” or anything it’s a comment.
- Blocker?: Some failed tests can be shipped so long as they aren’t marked “Yes” in this column. All blockers must be resolved before a deployment.
- Date: Must be the date you tested the functionality.
- Version: Current version of the application you tested against.
- Feature Ticket: When implementing a new feature and the tests to go with it, place the feature request ticket inside this column alongside the test.
- Bug Ticket: If the test fails you are required to go create a new ticket specifically for that failed test. It cannot include any other failed tests.
In future as we work through the test cases and create tickets alongside them we will gather a history of when something broke, got fixed and broke again.
As we continue to make changes on dev we will keep a single test template where we will continue to make amendments and track current functionality. One source of truth for the functionality of development.
Once a new feature has been implemented. You must add test cases for every single edge case you tested against onto the Dev template and complete all the columns for it with the exception of date and version. If you don’t manage to get all your tests to pass and need to move onto something else. Create a ticket, put it in the ticket column and come back to it at a later date.
- One test template for development
- New feature equals add new tests cases to development template
- New tests must be completed
- Failed test cases must have a ticket created beside them
If you find a bug during development that isn’t related to whatever task you’re completing. Create a new test case with detailed information and create a new ticket that will be placed into the ticket column.
It’s annoying and time consuming but do it.
- Create a new test case in the dev template
- Create a new ticket to go along with the new test case
- Yes it’s annoying, do it.
Once we reach a point where we’re happy with the current state of development and everyone is finished making new features and additions to the Dev template.
We will create a copy of the Dev template as it stands, keeping the original so work can continue and clear out all test results on the copied template. Only clear information from Pass/Fail and Actual Result. You must date the template for when it was copied and add a version if available but the date is important for the history of tests.
This should leave the description, test, expected, comments and ticket unchanged. Date and version shouldn’t be filled in on the Dev templates.
- All work should be finished on the template (Features and Test Cases)
- Create a copy of the Dev template
- Date the copied Dev template
- Clean up fields completed during Dev testing (Pass/Fail and Actual Result)
- Maintain columns description, test, expected, comments and ticket.
When beginning to test staging. You will have confirmed that staging is now in a code freeze with the developers. Only major fixes will be allowed during the freeze.
There will be a new staging testing doc with a date attached. Confirm with developers what the correct testing doc is you should be using.
It will be worth individuals taking control over a specific test sheet inside the google sheet. For example one person will be in control of testing an entire workflow sheet. Keep your team in the loop of what you're testing (you’ll see each other's activity on the test doc).
- Confirm staging is in a code freeze with the developers
- Only major fixes during the code freeze
- Confirm the staging test doc with developers
- One person should take control of a specific test sheet inside the larger google sheet
- Keep team up to date with what your testing
In the likely event you find a new bug you must create a new test case inside the staging test doc for the specific actions you completed to get the bug or test to fail. In turn with this a new ticket should be created and placed alongside the new test case.
Once staging has been tested and the new test cases have been added. Developers will be required to consolidate the new test cases into the dev template. To support making this process easy please highlight the new test case with a colour that stands out.
- Create a new test case inside the staging test doc
- You should complete all the columns with detailed information
- Create a ticket and put it in beside the test case
- Highlight the new test case row with a colour that stands out
- Developers will consolidate the highlighted test cases into the dev template
- What if we have a failing test that isn’t blocking the users ability to complete the overall task
- Adding a new “Blocker?” column where you will enter “yes” or “no”
- All blockers must be resolved for a deployment to be possible