This is important prep work for Project Managers when creating QA assignments for QA engineers.
Here is an example of a completed QA Todo:
Who can do this
Anyone, but generally a project manager will do this.
What you Need
- Project to test
- Public environment for QA engineer to test against
- QA checklist for the project
- Access to the information required to fill out the To-do. (See below.)
- TextExpander (Recommended)
- Ensure the QA Engineer has access to environment you want them to test and all resources they may need to reference.
Create To-do for the QA engineer
A to-do is required for a QA engineer to test something. Not providing an accurately filled-out QA to-do will result in delays of the project that you would like to be tested.
There are two ways you can provide this:
- Automatically Generated To-Do (Recommended)
- Manually-Generated to-do
- Partial (explain)
- Please test these particular Components, Pages, or Behaviors..."
- Comp Access Granted (explain) Provide the URL or any other pertinent info
- Some features (explain)
- Full browser test
- Basic functionality test
- Some browsers or windows (explain)
- Yes. Found in 1Pass
- Yes. (provide username/password)
- You can log any issues you find in this thread
- Please list all issues in GitHub under the milestone "Public Site Ready to Launch"
- Rebecca, for now all the issues here are a part of this round: gitlab.com/cantilever/imf/issues. Could you make sure to add all issues for this round to the "Deliver to IMF" milestone?
- List any issues that you find outside of the checklist in the project's Backlog
TextExpander houses a shortcode "bcqa" that will bring up a form to fill out when assigning a QA task to your QA engineer.
Seriously. This form will provide all the information that the QA Engineer needs in order to test something. It will make your life and everybody else's life easier.
The following is a breakdown of what information you'll be providing.
You can use the list above and the breakdown below to build a to-do for your QA engineer if TextExpander is inaccessible to you for some reason:
A Link to the QA Checklist
A link to this document will provide a description of desired functional behaviors and appearances
What We Are Testing?
This defines feature-testing coverage. You have two options:
Include pertinent notes on What We Are Testing.
This includes any other notes about the testing that is not covered in the QA Checklist but may be pertinent. This is especially important for fleshing out 'partial' site tests so that the tester knows exactly what to test. Knowing where and what to test helps the tester know what not to test, thereby saving time and money.
What Are We Comparing Against?
Is this a Regression Test?
Fairly straight forward. Options include:
Browsers to Test
Let your QA engineer know what you want tested:
Note: You should also note if you need IE-11 tested since it is not commonly supported.
Environment to Test
The URL(s) to base testing out of. This may include just staging, staging and production, etc.
Note: The specific URL the environment to test should be included as the tester may not know the staging URL or there may be multiple staging URLs to test from.
Is access granted to Relevant Front-end or Back-end logins?
The second option should basically never happen since all of our passwords should be stored in 1Pass.
Where to Log Issues
Provide a URL for the project's repository or instructions on where and how the QA engineer should create a repository.
Examples of "Where to Log Issues":
Assign Issues to a Developer
Which developer will be reviewing the issues found by the QA engineer?
Provide an estimate for how long you think testing should take (or how much time you have budgeted for QA)
If you have any comments that go with your deadline, this is the place to put them.
Developers review the results and close out the QA [Project] to-do if the test is acceptable
- If the QA engineer has done their job and the test is complete, close the to-do.
- There should be a separate to-do for fixing the bugs found in the test: Do not use the original QA [Project] to-do for that.
Suggested to-do's generated for the life of a project:
- QA [Project] This task is then passed from the QA Engineer to the developer with the Review prefix tag once the initial QA testing is finished
- Fix [Project] Issues
- This is closed out once all of the issues listed in the Repository are closed out
- QA Fixes for [Project] Issues
- When tracking time for verifying fixes, the QA Engineer can either have a separate task or within Harvest the name of the to-do can be modified from the Fix [Project] Issues to-do