CAST 2007: Mike Kelly, Specialists and Other Myths


The two non-tutorial days of CAST 2007 were structured like this:


Morning:



  • Keynote

  • Sessions (pick 1 of 3)

  • Lunch

Afternoon:



  • Keynote

  • Sessions (Pick 1 of 3)

  • Various evening activities

For my morning session on Monday, I chose to attend Mike Kelly's session titled "Specialists and Other Myths."


Mike started off mentioning that this presentation is a work-in-progress.  He invited the audience to question him and participate.  He started off proposing that testers in general shouldn't be intimidated or afraid to take on a specialist role.  Most specialist roles involve doing things that most good testers already do.  There was a caution: be sure to understand the consequences of failure if you are asked to move into a specialist role in an area you don't have deep experience in.  Mike talked about being asked to take on a testing job and, when asked what the consequences of failure of the project would be, was told, "rolling power blackouts over large geographical areas."


Mike presented the Universal Testing Method (from Bach & Bolton's Rapid Software Testing) as one approach.  The Universal Testing Method consists of the following activities:




  • Model the test space
    Modeling is very important to a tester.  Mike mentioned the FCCCUTSVIDS heuristic as an example approach.  Mike said, "You can all do this."  Someone in the audience countered that, in the performance testing space, Scott Barber (performance testing specialist) would obviously do a better job than a general tester.  Mike's reply: modeling isn't a technique, it's a skill.


  • Determining coveage
    Coverage should be based on risk.  You can't test it all, so what's important?  Consider not only use cases but "misuse cases."


  • Determine Oracles
    Parallell tests, performance regressions, requirements, inconsistencies with history, image, competitive product, claims, user expectations, within the product, with the purpose (HICCUPP).


  • Determine Test Procedures
    Methods and tools are what makes a specialist special.  You may not be in a position where you have to be the sole person to identify test procedures - there may already be procedures in place and you just need to evaluate them with your critical tester's eye.


  • Configure, operate, observe, and evaluate the test system
    These are what Mike calls "the guts" of testing.  You want to be in "brain on" mode (as opposed to "brain off" mode) when doing this.  When the unexpected happens, all testers are on equal footing - you're in new territory.


  • Report the Results
    (This is the last step in the Universal Test Method but Mike didn't talk about it - the discussion took on a life of its own before this item came up.)

As a specialist, you probably don't have to do it all alone - you're a member of a team.  How do people become very good?  Take an opportunity, try, learn, get better.  Becoming better in one area helps you get better in others.  Beware of excluding non-specialists from specialist roles - you won't grow any specialists.  If you're a lead or manager, delegate something new to your people.  Don't:




  • Feel you have to spend a lot of money to get a specialis (unless you really need to)


  • Exclude smart people from a job just because they're not specialists


  • Limit learning

Question from the audience: "How do I cope with my fear of incompetence?"  Ask for help.  Know inside you that people that know you will help you.  Be a part of a community.

Skip to main content