Serious Schema Shift

2 weeks ago, if you had asked me what I thought the biggest need of my testing team was I would have responded as I imagine many other people would in my position.  With the young and inexperienced (in the world of software testing) team that I manage, I would have told you that we needed to be trained in QA best practices with more documentation and automation.  Ultimately I would have talked circles around defining the red tape I thought we needed to be a “real” QA team.

So to find out how other companies defined their red tape, I convinced Bluehost to send me to the StarWest conference.   I showed up prepared to have my head packed full of facts and techniques to wrap my team in just enough red tape so we looked like a “real” QA department.  Testing processes, automation tools, documentation, pre-packaged one-size-fits-all is exactly what I was looking for.  I knew I was going to have to think about how these tools would fit our organization, but I knew someone had to have some snake oil out there and I was ready to take it.

Now, let me explain a bit about my current team.  While they are young and relatively inexperienced in the ways of software testing, they are all highly skilled.  In our organization we have chosen employees with strong analytic and critical thinking skills to be in our small department.  Our thought being that it took a critical eye to identify problems in software.  Most of the team were already active bug reporters while performing their other duties in the company.  We are a young team, but this is not a team built of random people off the street.  We are a  skilled team that is ready to “take it to the next level”.

So, I went looking for this red tape, and guess what I found?  Exactly that!  I spent an entire day learning about the metrics and tools for measuring ROI and how to make bloated statements that grossly inflated the value of useless automated tests.  I heard all about the need to have more documented tests that run more often so our ROI is higher so we can disprove our incompetence to incompetent management (because no manager worth their salt would actually believe any of the stuff I was hearing).

Now, at this point in the conference I was quite concerned.  It seemed that the object of my desire was not what I had hoped it would be.  I was hoping for real useful information about how to set up an intelligent test plan and use that to increase the value of my team, not just how to make statements that help us appear more valuable.  I raised my concern about some of these metrics with the class and was immediately shut down not just by the presenter, but by my peers in the class.  Maybe this really is what these people think testing is about.  Maybe I came to the wrong conference.

I have more to say about this specific class, but that will have to come later.  For this post I would like to explore the decision I had to make at this point in the conference.  I could either let this useless information smother my brain in a fog of numbers and useless tests, or I could stand up for myself and challenge the information that was being fed to me.  Though you may not know it, the very fact that you are reading this post is evidence to the fact that I chose the latter.

My schema for “real” software testing was that of rigid, measurable, repeatable, test cases that were rigorously documented and covered in red tape.  I had yet to experience anything good or bad about that, so my schema persisted into this discussion at StarWest.  Here I got some additional data to attempt to sync with my schema, and I realized this was not what I wanted to implement with my team.  My schema of “real” software testing was changing.

Ultimately, I realized that our approach of hiring intelligent, critical thinkers and cognitively thinking about each test we run is a good start along the road to developing a Context-Driven Testing team.  I did learn that we have some significant steps in progressing along that road, but my schema for “real” testing now has plenty of room for the type of thinking we were already doing.

(There will be more about these schema changes in later posts.)

I hope you will join me as I share the story of how our team matures.  I hope you will be able to learn from our successes and failures.  I also want to hear from everyone that thinks I am going about this all wrong.  Through your comments and discussion we can all push ourselves to be better testers.

One Response to this post.

  1. Posted by Wade Wachs » Blog Archive » The Shifting Schema on 07.10.10 at 8:47 pm

    […] was said in “Serious Schema Shift“, my uneducated guess of what formal testing was included a plethora of documentation, […]