protest: the tester’s box


[protest]

First off, business reality dictates that as unique and individual as we all are, for someone in every company (let's pick someone in HR), the job of a tester boils down to a black box.  Job descriptions often read like a "spec" of what inputs and outputs are hooked up to the job.  Maybe this partially explains why you can often find job offers that ask for impossible combinations - like X years of experience in a technology that has only been around for X minus 3 years.  Knowing buzzwords and being able to speak fluently in the language of the black box inputs and outputs will get your foot in the door.  But is a program that builds with no compiler errors or warnings bug free?  You're unlikely to land the job without also proving your ability to solve the inner problems and deliver the expected outputs.  (That is, if you want a job with coworkers who don't regularly end up showcased on http://www.thedailywtf.com/ !)

I think it's also worthwhile to have a way to talk about what our box is so that we can understand our value offering.  The discussions at PNSQC that I'm missing this week are apparently dealing in the value software testing provides. I once heard someone very successful tell me that his job security over time was always providing more value to the company than he got back in his paycheck.  I like simple logic and that rang true for me.  Granted, he wasn't in the software industry and had a job involving billable hours so I think it it was a little more quantifiable.  But I think just mapping out our own black box and laying down a framework of the inputs and outputs at a very general level can help us think more about how to increase the business value we provide.  Here's a high level list for starters.  This is just a rough framework, there is obviously plenty of room to drill down and add in buzzwords or specifics or things you think I'm missing:

Inputs

  • training
  • tools
  • resources
  • specific objectives (ye olde SMART goal)
  • asking for feedback during 1:1

Outputs

  • highest quality deliverables possible under constraints
  • timely status to manager(s) on progress
  • feedback to manager on problems
  • technical presentations
  • present status on progress towards commitments and development plan at weekly 1:1 meetings (best way to be accountable for reporting and measuring your results seems to be via standard accessible low maintenance measuring systems -- forums #'s, blogs, work item tracking database, wiki, emails, etc)
  • cycle the feedback received during 1:1 back into this system to update it where necessary
Comments (0)

Skip to main content