All month we've been talking about "communication" and giving you all ideas about how you better communicate with your organizations. We've talked about how SOX teams might use policyIQ to better collect and communicate their data, how your critical policy updates can be announced throughout the organization, and even how you can keep communication open with the policyIQ support team when you have questions or ideas.
But what about us? It is high time that we let you learn about some of the ways that the policyIQ team uses our own application to better communicate with each other. Because we're approaching a new release of policyIQ (with lots of great features like custom alerts and site wide report categories!), our entire team is very busy in the final stages of testing our latest release. It seems like a good time to tell you a little bit about the Quality Assurance process - and how we use Forms to manage this final stage of software release testing.
The process:
The final stage of policyIQ release testing involves many team members - and a slew of detailed scenarios. The scenarios are created and documented in Excel spreadsheets, with every step and every mouse-click documented. For any given release, we might have more than 20 detailed scenarios that are distributed to the testing team - and we run through our testing in multiple rounds so that each scenario gets tested by a different team members each time. When the scenarios come back to the QA manager, the spreadsheets are reviewed to see at which step(s) the tester may have documented a.) critical failures in the product, b.) unclear process or screen design, or c.) suggestions for improvement in future releases.
Managing the distribution, collection, retesting, documentation - and everything else that goes along with software quality assurance requires a great deal of organization. It's a good thing we have an app for that!
The Form Template:
We have created one Form Template (named "QA Scenario") to track all of the critical pieces of data that we collect each time a scenario is tested. The fields on that Form Template that the respondent is asked to fill out are the following:
1.) Date Tested
2.) Build Tested
3.) Completed scenario worksheet
4.) Testing Notes
Additional fields are on the Form Template, but available only to the Approver to complete after the scenario has been submitted:
5.) Pass / Fail
6.) Review Notes
7.) Issues Entered
A few other notes about our Form Template:
- The QA Managers and Director of Technology are the "Approvers" on the Form Template, so that they can all see the responses and run reports as necessary to keep track of status.
- The QA Manager who is responsible for coordinating the final stage of testing, however, is added in the field "Always notify and email when submitted", so that she receives the notifications immediately.
The Form List(s):
For each round of testing, a Form List is created. Within that Form List, the "QA Scenario" Template is added to the Form List one time for EACH scenario that must be tested. If there are 25 scenarios for a specific release, there will be 25 instances of that Form Template within our Form List.
Each instance - or List Template - is then edited individually. The Name is edited to reflect a specific scenario name, and the spreadsheet for that specific scenario is added as an Attachment to the List Template. When the Form List Templates are all edited, each one is a unique scenario (including unique attachment) that can be assigned to a team member.
Before running the Form List, each List Template within the List is assigned to a team member. Because most team members are asked to test more than one scenario in any given round, we use the toolbar at the top of the table to select those scenarios that will be assigned to "Stephenie" (for example), and make our assignments.
When we Run the Form List, we set an Open and Due Date on which the scenarios need to be completed and returned, and we push out the Forms to the testing team members.
Reviewing the Responses:
The QA Manager who oversees the final round of testing receives an alert - both on her Dashboard and via email - when one of the QA Scenario forms is submitted. She can then open the form, review any initial notes - and then open and review the detailed scenario steps within the spreadsheet. After the review, she can document any Issues, include any additional notes, and determine whether or not the scenario has passed or failed.
After all of the forms are received back for a particular round, reports are generated to show which scenarios have failed, and exactly what issues have been reported.
Running the Form List Again (and Again):
When any fixes have been applied to the testing sites, scenarios are sent out once again to the team. The Form List is copied (already named and with scenarios attached properly). The QA Manager can then rename the new Form List (for example, "6.7 QA: Round 2") and reassign the scenarios to new team members.
Lather, rinse, repeat as necessary.
We expect that all departments have a lot of similar processes, requiring the distribution of forms or spreadsheets to request information back from a number of people. Perhaps this might have sparked a few thoughts for you regarding how you could apply something similar to one of your processes!
As always, we'd love to help you build a Form in policyIQ to make your work day more efficient. Contact us at support@policyIQ.com.
(Oh - and we're still working through some of our final QA testing on release 6.7 - but be on the lookout for more information coming soon! And check our earlier blog post for a sneak peek at what is coming!)