Well, philk10 has been nagging me to write up last week’s SIGIST, so here goes.

Just for those who don’t know what this is, it is the British Computer Society Special Interest Group In Software Testing (heck of a mouthful, so SIGIST will do).  A one day conference is held every quarter and the quality of the speakers has improved considerably over the last few years, including some world known people.  Last week’s was well attended, especially considering there was a very important football match on that day.

The SIGIST this time had Johanna Rothman as the guest speaker.  She did three sessions, so she must have been really tired by the end of the day!

First session was entitled “Are you Hiring Yesterday’s Testers?”.  The presentation focussed on what a first class tester is and how to recognise the difference between first class and second class testers.  This is not concerned so much with the ability and skill of the individual tester, but attitude, maturity and skill of the hirer.  The following list, taken directly from the conference handouts, shows what first class testers looks like:

• Has a wide variety of testing skills
• Finds the most atrocious problems before release
• Developers enjoy working with the testers
• Learn about risks and other product information
• Can quantify the risk of a release
• Accurately predict necessary testing time and can explain why
• Understand product release is a business decision
• Supply enough information to predict rework and help projects complete on time

The following list, again taken from the handout, shows what second class testers look like:

• Routinely excluded from requirements or design meetings
• Resort to eavesdropping to hear information about the product
• Request for tools postponed or ignored
• Training budget significantly less that developer’s budget
• Interchangeable, i.e. they have such similar skills it doesn’t matter who you assign to which products
• Only work with developers on code artifacts because they either aren’t brought into the project early or they don’t know enough about the early phases to supply feedback
• Work all hours because the developers have so many defects to fix

Do you recognise any of those attributes from either list in your group?

Johanna went on to discuss how to create a first class group, which boiled down to making sure that the first class list above was achieved.

She also talked a bit about how to hire first class testers and it was a very short précis of her book “Hiring the Best Knowledge Workers, Techies and Nerds:  The Secrets and Science of Hiring Technical people”.

It was an entertaining presentation that I saw a number of people nodding their heads in agreement (no, they weren’t falling asleep!)

Johanna’s second session was a workshop entitled “How to Become a Sought-After Tester or Test Manager”.  This was a workshop designed to make you evaluate your skills and determine an action plan to improve them.  I think it would have worked well with a small group, but the group was large and it didn’t have the dynamics that a small workshop would have had.  Interesting, but not as useful as I had expected.

Johanna had the last session of the day entitled “Successful Software Management: 15 Lessons Learned”.  This was a superb presentation and I can’t do it justice here.  Basically, Johanna was going through what makes you successful as a Technical Manager.  The 15 lessons were:

1. Know what they pay you to do
2. Plan the work
3. Accept only on Number 1 priority at a time
4. Commit to projects after asking your staff
5. Hire the best people for the job
6. Preserve good teams
7. Avoid micromanaging or inflicting help
8. Treat people individually and with respect
9. Meet weekly with each person
10. Plan training time in the workweek
11. Fire people who can’t do the work
12. Emphasise results, not time
13. Admit your mistakes
14. Recognise and reward good work
15. Manage yourself

The presentation was peppered with her own experiences, mistakes and successes and whilst most managers know all these things, how many of us actually do ALL of them?

I went to two other presentations, the first was by Isabel Evans, entitled “A Balanced Scorecard Approach for Assessing Test Value and Success”.  This was interesting as I had heard of and seen the Balanced Scorecard Approach, but what Isabel has done is to adapt the approach for testing and how we can apply our metrics to show our value and success to the organisation.  I could see how it could be useful and I could also see that some of it might take a lot of time to put together, so I still have to think through how I can use what Isabel said in my own shop.  Her message is that what we report must be of use to the reader in their own language.  An example:  We are good at producing defect statistics, X raised this week, Y still open, Z closed, but what does that mean?  We should be couching our report in language that the reader is interested in, e.g. “the defect rate is such that the release will not be stable by next week”, or “the cost of rework due to the defect level is £x.  Her basic conclusions were as follows:

• Any organisation needs a balance of financial, customer, internal and innovation measures
• Test Teams exist to provide information
• Test Teams’ customers include the organisation, the project, the managers, the builders, the supporters, the users and customers and other measurement groups
• Our measurement and reporting help us
• To help our customers our measurement and reports need to reflect their goals, targets, indicators and concerns

The second presentation was by Graham Thomas, entitled “Seven key measures for Software Testing”.  This presentation took us through a horrendous example of a weekly test report that he had found, he showed the problems with it and then presented seven measures that help the weekly report become useful.  To be honest, there was nothing in the presentation I didn’t know and don’t use in one form or another, but Graham was a good speaker and made it entertaining.  His main focus was on showing test progress, script progress, risk profile, risk mitigation, Fault S-curve, Environment availability and Coverage.

The were other sessions I didn’t go to, because they clashed with the ones I did go to.

Conclusion: A good day, I learnt a lot.  This SIGIST was very test management biased whereas other SIGISTs have been very testing biased, so it made a nice change.  Oh, and England did win the football match…