I was browsing online deciding on whether or not to upgrade from the Fitbit Ultra to the Fitibit Flex, when it dawned on me.  The very first product review is very rarely shared with the public.  This review comes from a test report that is used as a deciding factor onto whether or not a product is ready for the general public.

Even though QA is primarily focused on quality, they can become extremely successful when they understand the market for their product.  Traditional QA tends to look at defects and whether or not the application matches the requirements.  In this ever competing market for product success and market success, QA should start becoming subject matter experts.

To further explore this topic, I will "review" the Fitbit Flex and the Jawbone Up in what I will dub the "Park Hopper Test" cycle.  For this cycle, I will walk through the process of developing a simple test strategy and how it can be turned into a review.

1. The first is an "Intro to Selenium and Automated Testing" Workshop that I've organized with our friends at OpenDNS for Saturday, February 23rd from 10:30am-4:30pm. Led by Santiago Suarez Ordonez, chief ninja at Sauce Labs, this workshop is geared at folks who are totally new to test automation. You'll get hands-on exposure to writing and running automated test scripts and learn some basic Selenium concepts, such as identifying selectors and refactoring your code. For more info and to RSVP, visit http://seleniumworkshop.eventbrite.com/.

2. The second is on mobile acceptance testing with Frank, a popular iOS testing framework. It will be led by Pete Hodgson, the maintainer of Frank, who has this to say about it:

Is anyone out there interesting in attending an (almost) free half-day tutorial on mobile acceptance testing with an emphasis on iOS? In about a month's time I'll be hosting a mobile testing tutorial as part of mdevcon in Amsterdam. I'd like to do a practice run of this tutorial here before that.
I said *almost* free, didn't I? Well, I will be taking nominal $5 donations from attendees before the course, to be donated to a charity selected by attendees. The reason for the donation is to try and prevent a bunch of flakes from signing up and then not showing up.
The workshop would be 3.5 hours long, and I'm thinking of hosting it in San Francisco on the afternoon of Saturday March 2nd. That's not long from now, so please let me know ASAP if you're interested in attending by emailing me:  phodgson@thoughtworks.com.

In the past when asked what I did for a living, I would respond “I am a Software Quality Assurance Engineer”.  This would follow up with, what is that?  Instead of giving a detailed description, I would say “I find the bugs in my company’s software before our customer’s do.”  These days, I say “I manage a team and together, we find the bugs in our software before our customer’s do.”

The players of Farmville, a popular web game on Facebook, are a great example to my standard response.  When releasing Firefox 3.6.3, Mozilla decided that the hang up time for flash applications to respond inside of Firefox did not need to be more than 10 seconds.  As Firefox users began upgrading their browsers, Mozilla received complaints that the latest version prevented them from playing Farmville.  Firefox 3.6.4 made the farmers happy.  A professional SQA person, who understands the customer, would not have given the go ahead to release Firefox 3.6.3.

Over time, I have begun to see that there is more depth to my answer.  Not only did I want to find the defects before our customers did, I wanted to make sure the software I worked on was what the customer needed.  Now as a manager, I need to instill my two “golden rules” to my employees and peers.

1.   Find Defects Before The Customer 

A lot of planning takes place to find defects.  Test plans and test cases are developed.  Once the application is ready, SQA will execute the test cases.  They verify that the test cases pass and that no unexpected behavior occurs.   SQA will write up a defect if a test case does not pass or something unexpected occurs.  The same tests will be executed against a new “build”.  Eventually, SQA will be convinced that the software is ready to be delivered to the customer.    

2.  Understand How Customers Will Benefit From Software

Some defects are easy to spot.  The real good defects are the ones that prevent the customer from using your software.  At my company, I do not expect my team or me to have experience working as a clinician at a pharmaceutical company.  However, I expect that they understand how the customer uses the software that they test.

What I like most about my job is that I get to share my knowledge and expertise to my direct and indirect reports on a daily basis.  When an SQA Engineer finds a defect and understands why it fails and can explain it to the developer, I know I have done my job as a manager and mentor. 

 I look forward to the day when I answer “I am a Software Quality Assurance Engineer”; and don’t get a follow up question.  Maybe I’ll get a thank you for finding the defects in software before it reached them.  Of course, if the software belongs to Microsoft, that’s an entirely different post.