Testing And The Great Conspiracy Against On-Time Delivery

Sometimes, and I’m delighted to note that this is quite rare, I’m in contact with a project stakeholder who has a view of QA and testing as something other than a collaborative part of a successful product launch. Instead, it’s a function akin to a villain wringing their hands and muttering, “I’ll get you, my pretty! Think you’ll launch on time, eh? Well….we’ll see about THAT! And then we’ll see about that dog, Toto!”

Again, this wicked warlock of Windsor (East) confesses that it’s not a common view, but once in a while I do experience a notion someone has of QA and testing to be something to “get through”. Fellow testers will know what I’m talking about – the delays in the release of code to test without a delay in final release meaning that a project gets tossed over the fence with the urgent plea of “QA! Make go good now!”. There’s even the assurance, “Do what you can in the next few hours – we’ll test whatever’s left internally”, that comes up from time to time. I find these scenarios easy to spot by just checking websites announced on LinkedIn with great fanfare, only to find that an inexperienced QA cycle has made a new site…wanting. (Hey, give me points for diplomacy.)

I know, I know….”Get real, Sossi.” Right?

Believe me, an appreciation for deadlines and the flexibility required is common in a project’s life. Compromising testing to meet a deadline might even be something that a skilled PM or Account Director can “manage” a client through (“phase 2”, anyone?). However, care must be taken to not accept this as a “standard”. One of QA’s greatest values to an organization is to offer metrics throughout a project’s life and pinpoint solutions to these difficulties that cause delays. For example, an experienced QA review of a Requirements or a Wireframes document might allow a QA resource to point out that, “Firefox has had difficulty with integrating that third-party video tool – you might want to investigate other solutions or advise client of possible limitations”. You know, that sort of thing. Calling these things out early can help avoid fundamental repairs happening at a stage when a project should be well on its way through a testing cycle.

Make QA a part of the process – a part of the project’s life. You (and ultimately, your client) will be glad you did.