Hi gang! Robb here, back at the helm for the second installment on the QA (Quality Assurance) process and digital signage.
Last week I wrote about the six golden rules for QA. Today, I’m going to write about how we do QA for each kind of product we produce.
Gadgets
First, we go over the release notes for the Gadget written by the Developer. This tells us exactly what the Gadget does, what can be modified in it, any caveats or any deviations from the Style Guide, and what it expects from user interaction and source data.
When the Developers tell us the Gadget is ready, we go through every detail to ensure adherence to our Rise Vision Style Guide. The Style Guide outlines all default options, spelling, grammar, and the general look that each Gadget must have. It’s imperative that all Gadgets conform to it since there are identical options in each Gadget.
We add the Gadget to an existing Presentation and a brand new Presentation that we create just for that Gadget. Then, we start the Unit Testing for that Gadget. If you recall from our previous QA post, Unit Testing means testing the Gadget entirely: the Gadget itself, Playlist elements such as Play Until Done and Transitions, and removing/reconnecting the Internet to see if any elements of the overall Platform are affected by the new or updated Gadget.
Another part of this test is to let the Gadget run for 24+ hours to make sure it doesn’t crash itself or the Presentation. we monitor the CPU and Memory usage, as well as Hard Disk activity to see if there are any performance issues. At the same time as testing the Gadget, we write the first draft of the help file. We use a Compatibility Matrix to cover all operating systems and browsers on both Displays and Previews. Typically, testing a Gadget takes a focused 2 days.
Presentations
Presentations are easier. We use the Compatibility Matrix to test on all operating systems and browsers, and all Presentations are tested on a touchscreen regardless of interactive elements. We let it run for 24 hours to make sure there are no issues, as well as monitor the CPU, Memory, and Hard Disk activity while each Presentation is running. This gives us an idea of how stable the Presentation will be on all sorts of hardware. While we are letting it run, we write up the help file. Depending on the complexity, testing a Presentation usually takes about a day.
The Rise Vision Platform
Rise Vision Platform testing takes two weeks and a lot of determination. This is where we do the “System Test” which goes through all elements of the entire system. We verify the versions of our browsers, operating systems, player versions, Chromium versions, and then we revisit every single item in the entire Platform.
When I say every single item, I mean every. Single. Item. Create Presentations, Companies, Users, Gadgets, Schedules, test Distributions and Timelines, Authentication Keys, Social Connections, Templates, System Messages…everything. Is it tedious? You bet. Do we find something new every time? You bet.
Throughout the testing of each Gadget, Presentation and the Platform, we log all defects in our Issues repositories, and nothing is released if there are significant bugs keeping it from working correctly. Once all bugs are fixed, they are verified and then we deploy.
This is a rather detailed outline of our QA work. I hope this is helpful and gives you insight to our process.
And if you can’t find me for a few days, don’t worry. I’m probably testing something.
Remember, you can sign up for Rise Vision for FREE or you can create an Unlimited Network for just $150 per month.
Sign up right now, or head over to our help page to learn more about Rise Vision.
[Image Credit: A200Wells]
Comments