Software Quality Assurance Engineer... Happiest job?!?

If you haven't seen this article, you want to read it:

http://finance.yahoo.com/blogs/secrets-toyour-success/happiest-jobs-america-173044519.html

About half way down it says:

The happiest job of all isn't kindergarten teacher or dentist. It's software quality assurance engineer. Professionals with this job title are typically involved in the entire software development process to ensure the quality of the final product. This can include processes such as requirements gathering and documentation, source code control, code review, change management, configuration management, release management, and the actual testing of the software, explains Matt Miller, chief technology officer at CareerBliss.

With an index score of 4.24, software quality assurance engineers said they are more than satisfied with the people they work with and the company they work for. They're also fairly content with their daily tasks and bosses.

These professionals "typically make between $85,000 and $100,000 a year in salary and are the gatekeepers for releasing high quality software products," Miller says. Organizations generally will not allow software to be released until it has been fully tested and approved by their software quality assurance group, he adds.

So I have a bunch of comments:

1. I guess I don't know what a "Software Quality Assurance Engineer" is -- or this Matt Miler guy doesn't. 
2. *If* anyone "ensures the quality of the final product" in software, it's a PM or higher.
3. I don't think I've met anyone with that title who smiled and told me how much they love their job.
4. I'm certain I've never met someone with that title that makes that much money. 
5. I think I'd rather shoot myself in the head than have those tasks... even at such a generous salary.

I could go on, but I'll stop.  I want to see these questions, & I want to know the demographics of the people surveyed, & I want to see the titles actually reported by respondents that got rolled up under "Software Quality Assurance Engineer." I'd also like to have a word or 73 with this Matt Miller dude... CTO to CTO, 'cause lets face it, we all know that testers wouldn't be caught dead bragging about how *happy* their job makes them, or how *satisfying* it is. Testers tend to love the act of testing, but not their jobs, or their bosses, or their companies -- and if this ain't referring to testers, I wanna know why these process people are apparently so happy about being forced to do the actual testing on top of their "real" job.


Feel free to share your thoughts, but this strikes me as "not *even* wrong" to a degree that I can't seem to even reverse-engineer a single measurement dysfunction that could account for all the ways in which this article strikes me as "just not right".

 
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
Director, Computer Measurement Group
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

"If you can see it in your mind...
     you will find it in your life."

Trust is a Cornerstone to Delivering Business Value

In my last post about Metrics I introduced the notion of trust as it relates to Business Value by stating:

"Failing to trust 'the Business' does NOT add Business Value"

I'd like to generalize that statement further to say "A lack of trust that individuals or groups involved in the project are primarily focused on helping the business succeed undermines business value".

Now, I can only imagine the reaction many testers are having while reading this. For instance "If I trust the developer when they say 'This is fine, you don't need to test it', we'll have major bugs make it to production." And anyone thinking that would be absolutely right -- because that is not the *kind* of trust I'm talking about.

When I say trust, I don't mean "Trust others to tell you how to do your job" or "Trust others to do what you believe is correct/best" or even "Trust others to be successful in accomplishing what they have been assigned to accomplish on time, on mission, on quality, and on budget"

When I say trust, I mean "Trust others to approach their role with integrity" and "Trust that others are doing the best they can to make the decisions or take the actions appropriate to their role and responsibilities based on the information they have" and "Trust that if you haven't been assigned to do or to be the decision maker about something, that task or decision is better handled by someone else -- whether or not *you* have the information necessary to make sense out of why.

Business Value of (Software Test) Metrics

I was *totally* in the middle of another blog post when I came across the latest from Cem Kaner on context-driven-testing.com and after reading it, I (cognitively speaking) had no choice, but to save that other post as a draft and write this one -- and by that I mean, there's no way I was going to be able to focus on anything else until I got this down and out.

So, click the link below and read the post... no seriously, it's required reading for what I have to say. (Ok, if you want you can start at the line prior to the 2 bullet points about half-way down the screen -- the backstory is optional reading)

Metrics, Ethics, & Context-Driven Testing (Part 2)

Did you read it? No? I mean it. Go. Read. I'll wait.

10 Take Aways from STP Summit on Agile Transitions

I had the pleasure of hosting the fourth Online Summit, delivered by Software Test Professionals: Agile Transitions.  The online summit format consists of 3 sessions each for 3 consecutive days.  The sessions for this summit were:

• What is Agile and What's it Got to do With Testing? – Scott Barber
• How "Agilists" vs. "Traditionalists" View Testing – Robert Walsh
• Keys to Transitioning to Agile Testing: Lessons Learned from the Trenches – Bob Galen
• The Secret to Successful Agile Test Automation – Lisa Crispin
• Culture & Inter-Focus Area Interactions – Selena Delesie
• Avoiding Agile Perversion – Lanette Creamer
• Excelling as an Agile Tester – Henrik Andersson
• The Lone Tester In an Agile World – Michael Larsen
• Top Take Aways  – Scott Barber  
• Speaker Panel – Scott Barber, Robert Walsh, Lisa Crispin, Selena Delesie, Henrik Andersson, Michael Larsen

One of my duties as host was to try to summarize the most valuable nuggets of information from across all of the presentations into a "top take aways" list.  This is what I came up with:

Scott's Top 10 Take Aways from:

Business Value of Testing: Find Bugs ≠ Mission

My introduction to software testing was as a performance tester. Before the completion of my first project, I had a firm understanding of the primary mission of performance testing. That understanding has changed very little to this day, though I have improved how I communicate that mission. Currently, I phrase the (generic) primary mission of performance testing as:

"To find how many, how fast, how much and for how long; to assist business w/ related technical and/or business decisions and/or; to support related improvement activities as prioritized by the business."

That certainly doesn't mean that all performance testing efforts include every aspect of that mission, but I'm hard pressed to imagine something that I'd call performance testing that includes none of the aspects of that mission. It is also true that I have experienced all manner of secondary missions as part of a performance testing effort (missions related to fail-over, and denial of service attack security, for example). Those combinations, permutations, variations and additions are all where context comes into play.

However; when I was first asked to help out with some functional testing, I quickly realized that I didn't really know what was expected of me, so I asked. As you might imagine, folks looked at me like I'd grown a second head... a green one... with scales and horns. After about the 4th time I asked the question, got a funny look, watched as it became clear I was serious and received some variant of the answer:

"Find bugs"