Todd Astroth

Quality Assurance

I've always had a talent for being particularly observant of my surroundings. As a QA Analyst, I have the chance to put this skill to good use by seeking out flaws in digital products. I also specialize in writing easy-to-follow bug reports, creating organized test cases, and suggesting usability improvements.

Below is the history of my experience working in Quality Assurance. Also, check out my Top Ten QA Tips.

Sound Devices

Sound Devices is a small business based in Reedsburg, Wisconsin that makes cutting-edge sound-recording equipment used in broadcast and music production. Their devices have been used in such big name titles as The Big Bang Theory, Game of Thrones, and Mad Max: Fury Road.

I tested several different products here, from the A10 wireless transmitter/receiver system to the MixPre II series of musician-friendly sound mixer/recorders to Scorpio: a powerhouse of production mixing and recording capabilities.

My main goal, of course, was to test all of these products alongside my top-notch test team. My specialties included testing file management, connected devices, and our visual control surface mobile apps which interface with the products. I also spent a great deal of time creating and updating detailed regression test plans for each of the products.

I also frequently collaborated with Product Designers and Customer Support to determine areas of improvement in terms of usability. To help better accomplish this, I ensured that there was a clear line of communication amongst the QA, Development, Design, and Support teams.

Pearson

Pearson is an expansive company that creates digital and print solutions for K-12 schools and higher education. I was the forerunner of the Courseware QA Team, who acted as "the last line of defense" for checking digital products for higher education.

My primary goal was to oversee the quality of our digital courseware products by implementing black box testing. When a new course was ready for testing, I would communicate with the Digital Producers and the Courseware QA Team to perform rounds of functional or regression testing on the course.

Due to the constant release of new digital textbooks and courses, the position also required proficiency in project management. If there was an abnormally large workload that the QA team could not handle, the team could also work with external QA vendors to perform some of the testing. Most of this communication was handled in JIRA.

In this unique "QA/PM" hybrid role, I enjoyed overseeing multiple projects and ensuring that all questions were answered and things were running smoothly. Since our team was growing rapidly, I also created a Process Guide which listed out all of the steps and various strategies for handling the rounds of QA.

Todd's Top Ten QA Tips

  1. Having a clear QA plan of action is important, but keep it simple. Do not get lost in endless process "red tape."

  2. Once a development/QA process has been decided on, follow up by writing simple, documentation. Having the process in writing assures that everyone is on the same page.

  3. Create an organization chart of how the development team is structured. This helps clear up confusion on how each colleague relates to the project.

  4. Write clear documentation for each project, which states goals, wireframes, specs, and the personnel involved.

  5. Define the phases of a project's development and quality assurance. In an agile model, there is often room to go back and make changes, but define when and how this will occur.

  6. Verify that everyone is indeed following the established development/QA process. If not, take the time to troubleshoot what issues need to be addressed.

  7. Check in with the development team every now and then and ask if they believe room for improvement is needed in the day-to-day maintenance of the project. Such "technical debt" should be addressed to ensure that there is not a domino effect in overall quality loss.

  8. Define a consistent priority system for defect and enhancement reports. A priority of "1" should mean the exact thing from one day to another, and from one project to another.

  9. Define which items need to be automated for testing. It is best to assign automation to standard functionality that is often seen across multiple projects.

  10. Do not spam the team with emails which do not pertain to them. This often discourages some employees from reading email at all.