ANZTB (http://www.anztb.org/) are hosting a free half day workshop with Rex Black on Risk-based testing.  The workshop is on December 8th in Sydney and December 9th in Melbourne.  Contact Karen Haig at info@anztb.org if you’re interested in attending.  As of this morning there were 17 places left for Melbourne.

Paul Szymkowiak and I will be running a one-day workshop on tools for testers, as part of the STANZ conference. The current run on August 13th is full, but you can register your interest for future courses via SoftEd, or drop me a line.

Details of the course are at http://www.softed.com/stanz/speakersandsessions.htm#tst

I’ll have the presentation slides here on the website shortly!

If you’re looking for a course different to the usual fare, you might want to check out Rob Sabourin’s “Just in Time” testing course, which will be running in Sydney on the 12th and 13th of November, and in Melbourne on the 15th and 16th (New Zealand after that). I’ve heard good things about his presentations the last two years at the STANZ conference, and am hoping I may get to the course.

Part of the course materials include session-based testing, so if you can’t wait for Michael Bolton or James Bach to make it out here next year, this is a chance to find out more.

Details of the course are on the Softed website (http://www.softed.com)

I’ve been sadly busy, finishing a cool project with much learning, and preparing to leave my current employer Revolution IT for Aegeon. This means I get to have another crack at building an army of testing ninjas and sending them out into the world to hopefully make it a better place. Hopefully, that means less blogwebs (the digital form of cobwebs) too.

Ben Kelly, testing martial artist (literally, in this case) and recent blogger threw a question my way which I’ve answered before, but hadn’t really ever had to answer for testers in my team. It went something like this:

Ben: If quality can be described as ‘value to some person (who matters) and testing can be paraphrased as ‘questioning a product in order to evaluate it’, would you describe quality assurance as ‘interpreting the answers to said questions in order to provide information about the quality of said product to someone (who matters)’ ?

I rambled:
Quality assurance should be about ‘Is our process appropriate?’ That is, is it providing the right value to the people that matter.

Ben: Hmm, okay. Quality control is probably more appropriate then.

I rambled some more: I see your point though…One of the ways we assess the success of our development approach is by looking at testing. It’s just not the only way. It would more likely start with questions like:

- ‘What questions didn’t we ask’? That is, what problems escaped into the wild?
- ‘What didn’t we do?’
- ‘What are we doing that is a waste of time, or not helpful?’

Ben: I’m trying to condense the definitions of these terms so that they’re not overly verbose and still retain their meaning – I’m still working on that presentation

Me: So, Quality Assurance is typically assessing the whole software-producing system. Quality control is checking the output of the production process. Quality assurance is checking the process itself. That’s my model, at least.

Ben: That’s inline with what I’m working to. Maybe I don’t need to go into the definitions of these with the new guys right away. Maybe I should let them get their head around the definition of what testing is before I say ‘By the way, testing is not quite the same animal as QA or QC’

Me: It becomes relevant when test groups are called QA and think somehow that they actually do assure quality.
If your team is under that delusion, maybe it’s worth spending some time dispelling it. Testers can provide information about quality. They can’t actually force anyone to do anything with that information.

I want my testers to think:
“I am not assuring quality.”
“I cannot remove bugs.”
“I cannot stop developers creating bugs.”

This is obviously not always true, if we consider our ability to contribute to removal of requirements defects, but that’s not always an area we’re able to contribute to. If we’re not the prime owner of the requirements process, our role is still mostly about pointing out problems and making a compelling case for those problems to be addressed.

It’s potentially problematic for non-testers to think that they have this power though, and it’ s generally bad for the team if testers believe they can do it. Primarily, our role is to provide information to allow others to make good decisions.

Ben: Hmm, I might put it in to my presentation after all.

Me: Yeah, it probably belongs on a ‘What is testing’ slide. It stops your new testers beating themselves up for things that they shouldn’t. It lets your experienced testers defend their practice and not be beaten up by others. Or rather, starts your testers on the path to understanding the scope of their role and communicating that scope to others, setting clearer expectations of what to expect from a tester.

Ben: Something we could stand to do more of here. Excellent. Thanks as always for letting me bother you.

And thanks Ben for bothering me with something that I didn’t realise I needed to. Agile projects change the game a little, but for software, the primary focus of QA is on getting better at producing something that satisfies our customers, through code. Taking on the QA mantle is about telling managers, developers and analysts how to do their job better. And my super powers don’t yet extend that far. I encourage my testers to know their limits too.

James Bach is going to be in Melbourne early June, teaching his Rapid Software Testing course. If you’re in Melbourne, don’t miss out. If you’re not in Melbourne, try to get there anyway!

Details can be found at http://www.softed.com.au/Courses/rst.aspx

I was lucky enough to spend three days recently taking James Bach’s Rapid Software Testing course in Adelaide, as well as a personal pre-course one-on-one workout.

I am a regular reader of James’ blog, have read his book, and having read through the RST course slides was really, really curious to see how the exercises supported the materials. I must admit, I was also mildly curious to see how the exercise I’d worked on with Michael Bolton (and James, by proxy) had taken form in the course. A quick glance at the course outline prior to attending told me that I had tried a few of the exercises already, having been lucky enough to have Michael give me a brain-beating at the 2005 STANZ conference. I had already applied two of the exercises in in-house training sessions I had run at my previous employer, so was looking forward to learning not just about testing, but also about being a tester trainer.

What surprised me most during the course, was how the same exercises, with minor changes, could easily become exercises that tested totally different aspects of the tester skill set. Despite having seen some of the exercises before, all but one demonstrated quite different learning outcomes.

It was easy at times to feel that the exercises were ‘unfair’, particularly as I stood in front of the class with my Mysterious Black Spheres. It was easy to feel that the situations into which we were put were so devoid of context as to not reflect any real-world situation. But that was precisely their point: To provide environments in which our regular, unconscious approaches to software testing can easily let us down. The next learning step needs to take place outside the course, as we work towards making our unconscious skills part of our conscious thought, and hopefully be ready for anything.

James talks about how he encourages his friends to attack him at any moment, like Cato attacking Inspector Clouseau. After taking his course, you’ll be waiting for the testing Ninjas to leap out and test your mettle.

James should be back in Australia in June. Keep an eye on Softed’s site for future dates, or register your interest. You will almost certainly finish the course with a new perspective on testing, and what a testing career might mean. In the meantime, read the RST materials, watch James’ ‘Becoming a software testing expert’ Google video, and start taking notes about the day-to-day testing magic that you work.

In the Yahoo group supporting Cem Kaner’s Black Box Software Testing course, Anil Soni has been describing experiences organising and leading internal training, using the BBST course materials. One point in particular caught my attention:

> The major challenge is to have all the testers together in the same time
> needed for the group interaction.

In a recent role, I had trouble getting all of my testers together for study sessions. Often, the testers felt uncomfortable stopping work to come to a study session. At times, work was a genuine priority. At other times, the things testers were working on could wait an hour or two, but it was difficult for the tester to make that decision.

Sometimes I would have to make the decision for them. That is, tell them “This is more important than the work you are doing right now”. I could do this because I had management support for creating a learning environment.

Organisationally though, we were sending mixed messages. The project manager expressed the opinion “We’re not running a school here”. The development manager countered with “We absolutely are”. These two statements captured the tension between getting today’s job done now, and ensuring that tomorrow’s work can be done better or more efficiently. In one statement, is the view that employees should always be working on something that directly contributes business value. In the other statement, the view that it is vital that time be set aside during work hours expressly for improving the skills of staff and for reflection on past experience.

At this point, I don’t really want to enter into the philosophical debate around whether organisations should be learning organisations are not. However, if you’ve decided that it is important that your staff learn and improve here are a few things that I would consider.

• Make it clear how much time you expect employees to be spending on improving their skills.
• Check that they are spending the necessary time. If not, find out why.
• Keep groups small if possible. This allows scheduling to be more flexible.
• Get a clear statement (or statements) from whoever is in authority that study time is important for the organisation.
• Establish and communicate principles for when work should take priority.
• If participants are having difficulty deciding what is more important, help them.
• If you are going with a less structured informal learning approach, how will you know whether team members are using their study time for study? That is, what feedback mechanisms will you have to help understand and support your team’s learning needs?

On this last point, in one team, a thousand dollar self-education budget was available to each employee per year. They were free to spend this on anything that they wished. However, in a year and a half, almost none of the team had made use of that budget. That’s one example of a feedback mechanism, triggered by the question “Why haven’t you used your training budget?” Regular team meetings, where each team member presented some recent learning were another.

The dominant work culture is about appearing to be busy, and doing ‘real work’. Despite support at the highest level, if other management levels don’t support the company’s learning objectives, employees will be quite nervous about spending time on tasks that their close managers may consider trivialities. This is a significant cultural change, and the forces of history will be working powerfully against you.

I’ve recently come across the Informal Learning blog, and hope to write more on this subject in the future.