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.