Wednesday, May 30, 2012

What Testers Need to Learn

Sunday night I attended a live webinar by James Bach entitled "What Testers Need to Learn" that was put on by Tea time with Testers. It seemed like an interesting topic so I joined (it only cost $30).

The webinar got off to a slow start thanks to some technical issues with GoToMeeting but as soon as they were resolved James jumped into his talk: his personal vision of the skills testers need to have based on his many years of experience coaching testers.

James shared his recently updated tester's syllabus (a free download from his site) and then walked through it explaining some of the areas. The syllabus he shared was actually a part of a specially created slide deck composed of existing materials but arranged for this talk. You can download the slide deck here. If you haven't seen (or downloaded) the syllabus these are the main areas:
  1. General Systems
  2. Applied Epistemology
  3. Social and Cognitive Science
  4. Mathematics
  5. Testing Folklore
  6. Communication
  7. Technology
  8. Software Process Dynamics
  9. Self-Management
A synopsis (what I remember) of the walk-through:

Saturday, May 26, 2012

Immersed Tester

I registered the domain name ImmersedTester.com on a spur of the moment decision. I was trying to brainstorm cool names / nicknames for myself as a software tester. The writers of the blogs I read often use a nickname to describe themselves or their site like the Evil Tester and TestHead and I though I should do the same.

What would make sense? I like scuba diving. I like software testing.. Hmm.. According to the Merriam-Webster dictionary immersed has a few definitions that apply really well:
1: to plunge into something that surrounds or covers; especially: to plunge or dip into a fluid
2: engross, absorb (completely immersed in his work)
I think it fits. As a scuba diver I plunge into the water and as a software tester I'm engrossed or immersed in my work. I'm an immersed tester!

Sometimes its fun to be creative and brainstorm. Sometimes it's just a waste of time and nothing comes of it. I wonder which this will be? As of now the domain just forwards here. =)

Friday, May 25, 2012

Keith Klain's 2012 Star East Keynote

Keith Klain, head of Barclay's Global Test Centre, gave a keynote presentation at StarEast 2012 in Orlando, FL entitled Bridging the Gap: Leading Change in a Community of Testers and it was really well received in the context-driven community.

The story is about how they positioned testing in the organization and how they hire someone, a process Keith refers to as their induction process. Keith also talks about Barclay's approach to testing, how they took mismanaged test teams and realigned them to produce great results and benefit the company. He places a lot of emphasis on knowing what you want from your team. I'd recommend managers take a look.

Saturday, May 12, 2012

1993 World Book definitions for Quality and Testing

According to the 1993 "The World Book Dictionary" the definition for Quality Control is
"[T]he inspection of manufactured products from the raw materials that go into them to their finished form to insure that they meet the standards of quality set by the manufacturer." (pg. 1703.)
That same dictionary didn't have any definition for the word quality assurance and had many definitions for the word quality (7 to be exact).

The most relevant definition for Tester was defined as:
"[A] person or thing that tests." (pg. 2167)
My parents still have their set of 1993 World Book encyclopedia's which came with a two book set of dictionaries.

Wednesday, May 9, 2012

Throw someone else in to help QA it faster!

“Throw someone else in to help QA it faster!”

I've heard this statement many times in my career but it happened again just recently and it got me thinking. Aside from the poor choice of words, about QAing something (is that really a verb?), why would someone say this?

This seems to happen when management realizes it will take longer to test something than they initially planned and/or some client demands a product sooner. The most recent occurrence came when management didn’t communicate the expected release date and freaked at the estimated test duration. My response was you can have the product whenever you want but let me tell you what won't be tested. This elicited the response "no we don't want to not test it, how about we... throw someone else in to help QA it faster." Clearly someone hasn’t heard of Brook’s law.

Brook’s Law is a term coined by Fred Brooks in his book The Mythical Man-Month which states “adding manpower to a late software project makes it later”. It also appears the person saying this doesn’t understand what Quality Assurance (or QA) means.

Monday, May 7, 2012

Performance Reviews

It’s that time of year at my company when we meet with our respective bosses to discuss how well we did. Review time is probably the least fun time of the year, not because I am fearful of how I might do but, because it's time to give my boss hell for our bad performance management system.

Our company has this standard form that was borrowed from some other companies inept performance management system (most companies I’ve worked for also had bad performance systems). This form has evaluation areas which don’t apply to our roles and some areas that nobody knows how to evaluate. We start by filling out a “self review” and then send it to our respective bosses for their comments and grading - a scale from “didn’t meet expectations” to “far exceeds expectations”.

According to the book The One Minute Entrepreneur there are 3 primary parts to an effective performance management system:
  1. Performance planning. This is where managers and their people get together to agree on goals and objectives to focus on. 
  2. Day to day coaching. This is where managers help their people in anyway they can so they become successful. It doesn't necessarily mean you meet up or talk about how things are going everyday rather that managers work to support their people, praising when things are going right and correcting when things go wrong. This is the stage where feedback happens - where real managing is done. 
  3. Performance evaluation. This is where managers and their people sit down and examine performance over time; also called a performance review.