blog
Beaconfire Survey: QA Tips
April 21st, 2008 by Beaconfire BloggersEditor’s note: 
Periodically, we do a survey of Beaconfire staff to get impressions on a variety of non-profit technology issues. All opinions expressed here are solely those of their authors. We’ve either just launched or are about to launch a number of big projects lately, so we’ve been doing a significant amount of quality assurance. As a result, we wondered: What is one QA tip everyone should be aware of?
Mark, Functional Consultant: Start QA with a complete, well thought-out and usable test plan.
Jennifer, Project Manager: Always compare the deliverable against the original specs, and any subsequent change orders. Always.
Lynn, Principal Consultant: Include people on the QA that know nothing about the application or tool. They’ll be sure to interact with the tool in ways you never thought of (which is what your users are bound to do!)
Kristin, Project Manager: After our QA is done, make sure everyone is clear about acceptance of the final product.
Brad, Functional Consultant:
- The people that design the test plan should have been involved in gathering requirements. The people who conduct the testing should not have.
- When testing, TRY to break the interaction. Simply reproducing the “right” steps doesn’t prove anything.
- Writing bug tickets is an art. You should always include the page/action that produces the error, and what the expected result should have been. If possible, include the relevant spec. Bugs written in the form of “submitting the form didn’t work” are incredibly common, but not useful.
Marissa, Functional Consultant: Every day, all day, I keep as many different browsers open as the memory on my computer allow. I try to bounce through all of them equally throughout the day (although Firefox is my favorite). That keeps me constantly aware of what my work is doing in the whole slew of browsers, minimizing bugs once we get to the formalized QA process.
John Brian, Marketing Consultant: Before an email goes out, we like to run it through deliverability monitoring software to make sure major ESPs don’t see any red flags. It’s also helpful to have someone completely uninvolved in the process read the email to make sure there are no comments left in like “[Find out if this is true before we send!]”
Beaconfire includes a rigorous QA process in every project, to make sure everything works as intended before going public. Look for more posts on this topic in the future!
