While I can’t say it was with any great regularity in my experience, I have on occasion encountered situations where a work colleague – whether a developer or designer – viewed testing as an “adversary”. There was a concern that my function was to evaluate and perhaps even embarrass them on a personal level. I always try to explain that Quality Assurance is a process, where testing is just one available metric to measure a project’s functionality, integrity, etc. but still….
I remember one particularly extreme instance where I was testing away and a recent developer hire was practically looking over my shoulder the entire time I was reviewing:
“Oh, I did that because etc. etc.”
“Oh, I must have forgotten to merge my code with etc. etc.”
“Oh, can you stop testing for a sec – I just have to etc. etc.”
When all was said and done and I submitted my variance report (sorry, but I prefer that to “bug report”) along with my high marks for where the project stood at that point in time, I was finally able to “win them over” to the realization that we had a shared goal. Think about it – a project has to move through many stages to get to the finish line: Requirements, Planning, Design, Coding, etc. Remember that kids game “broken telephone”? Where you tell a portion of a story and pass it on to someone who has to repeat and add to it, and then pass THAT on and so forth? I’m not trying to equate a sophisticated process with a children’s game, but the principle is often there to some degree. How often have we, as an individual in the process, heard:
“Oh, we changed that. Client approved”
“Oh, we redid the copy and haven’t had time to update the Copy Deck”
“We decided to replace that functionality with etc. etc.”
and so forth.
As a process, QA can weed out these procedural deficiencies and often accomplishes that in the agency world by – what else? Testing.
There was another occasion where I noted hushed conversations around me from a development team. Unbeknownst to me, they took it upon themselves to work extra hard to deliver a bug-free product to our testing server. Knowing about my “pet tests” (i.e. accented characters, truncation, hyphenated names, etc.), they scoured previous test reports and applied themselves to testing a micro-site we were building for a snack food promotion, taking advantage of a generous schedule. When it was time to test, I didn’t find a single true “bug” – only being able to make certain usability recommendations to the design team. When I congratulated the development team, there were actually a couple of members that resorted to a “A-ha! In yo’ face, QA man! Take THAT!”…but eventually realized that I was not only offering my congratulations to them personally, but was making a big deal out of singing their praises to others at the company. Perhaps there were shared drinks at a pub afterwards as well, but they realized that QA is on THEIR side!
Because I can’t bring myself to say the overused “there’s no ‘i’ in you-know-what”, let me just say that QA and testing is meant to work WITH teams and not against them. Thankfully, as I mentioned earlier, I haven’t encountered this with any alarming frequency.
But if you encounter a QA Analyst or Tester that behaves otherwise…shame on them.