Hello everyone and let me first apologize. I know I promised to finish out my series on the challenges of offshore team integration with a final post suggesting magical methods for actually doing it, but something has come up. It seems there is a lot of current debates “in the community” about the efficiency of templates, frameworks, and entities called best practices. I’ve attempted to make my informed opinions known on these subjects, but realized I may need to elaborate more fully than is possible in the context of a twitter exchange, mail thread, or peer review discussion topic. Since it seems to pertain to the topic of offshore development and integration, I thought I’d take a brief detour to address the issue before launching back into team integration. If you’re eagerly awaiting the third and final part of my trilogy I would beg your indulgence. Please treat this as a passage from the Silmarillion meant to inform and give context to your future reading of The Return of the King.
Yes, I’m that much of a dino-geek as to make a Tolkien reference without in any way shape or form mentioning Peter Jackson. I also started playing D&D using the first set of rules and turned my nose up at the more cavalier second edition. If this pops any bubbles in your head, I would suggest you humbly deal with it.
Moving on, then.
I won’t spend too much time on this discussion as I feel as though this is one of those very emotional subjects you either instinctively understand or you instinctively reject. The subject is the value and appropriateness of reusable artifacts within software testing and software quality analysis. Many times these artifacts are called “templates” or “frameworks” but I’ve also heard them called everything from “processes” to “deliverables.” They can take many forms but they all have one thing in common, they are designed to direct and guide work by the studious application of scientific management principles. To put this as succinctly as I think possible, reusable artifacts are an attempt to take advantage of the same economies of scale supposedly reaped when processes are consolidated and standardized. This is where the emotional responses start to kick in. Either you believe its possible to enjoy cost reductions in design through consolidation and standardization practices (ie: Six Sigma, TQM, etc) or you don’t.
Let me wrap this up by explaining why I arrived there when templates and frameworks were my starting point. In my view, templates and frameworks are guides on how to perform your work. If we were visual artists, templates or frameworks would be a paint by numbers set. An individual handed a detailed template appropriate to the task at hand could theoretically produce predictable results with variations either accepted or corrected in later editions of said template. In other words, some one with little skill should be able to product a reasonable picture of a crying clown on black velvet by following a paint by numbers set. The more detailed and intricate the set, the more “artistic” the final product and the more skill at filling in the shapes is required. Eventually the person using the sets will gain enough skill through repetition and familiarity to create very intricate and colorful crying clowns on black velvet, and they may even gain enough skill to create original artwork of their own. Contrast this with a traditional art background where the student is taught to draw rather than simply fill in some one else’s drawing. They’re taught color theory, light and shading, drapery, and a lifetime of different techniques and tools with which they can approach a new project. The tester/SQA resource taught in this manner will approach each project as possibly unique but will have a common tool set with which they will attempt to solve the unique challenges they feel are present. It will take longer for the tester schooled in this manner to produce their first realistic crying clown on black velvet, but they will more quickly be able to paint anything else you might need with little direction or maintenance.
In other words, if you believe what we do is a repetitive process with identifiable tasks which can be optimized and improved then you will see templates as a integral part of any process improvement efforts. If instead you believe (and this is my personal view as well) what we do is a creative process with assumptions and tools that can be improved, you will view templates as a poor ROI as a medium to long term investment.
But I could be wrong in my views. Please challenge them and change my mind.
Testing in The Wild West 
I liked the analogy of paint by numbers and to a certain extent I agree. I often use the templated documents I receive – test plan, test strat, etc. – as a bit of an idiot check. If the author knows what they’re talking about the content will be pretty much what I expect and they’ve produced the doc because it’s a “project deliverable” required by some waterfall process. On the other hand, if the author is a bit of a newb or has some odd ideas or is just simply incompetent, the doc will always look just like you describe – painted by numbers. It all looks okay with everything in the right place, but it’s not really indicative of someone who knows what they’re doing. There’s nothing contextually different from any other project they’ve produced similar docs for.
I think templates do have their place however, mainly in the consulting world. For those clients that require them and need them in a Word doc, I can write a test strat from scratch for each new client and each new project. But a template helps with a rough gude. It’s more of a pencil outline of where I want to get to. The detail is up to me, the individual colours, patterns of light and shade, I add those myself.
Client side templates also have their place in giving me a bit of a heads up on how they handle certain project related information. No performance testing templates? Oh, you guys outsource it. Interesting. And then start a conversation from there. No security testing in your templates? What do you mean you hadn’t thought of it? And so on. Client side doc templates can tell me a lot about the organisation. How easy are they to find? How well maintained are they? Who maintains them? Answers to which are a guide on how serious they view the requirement to produce them.
I’m not an advocate of heavy documentation like this mind you. If I need to produce a test strat I’d rather write it myself and put it on a wiki or a google doc. The problem with Word documents is that they tend to be written and then forgotten, never to be seen or heard from again. I’m well aware that certain things need to be documented and discussed, particularly in a more traditional development methodology – what are we testing, where are we testing, what’s our scope, how are we doing it, where are we tracking defects, who’s involved, who are we reporting to, etc. etc. – but these things need to be part of a living system as they’re subject to change over the course of the project.
All of this information though is contextual: what needs to be included in one project may be completely irrelevant to another. I must admit that the people I encounter who love templates are very much of the one size fits all approach. “Every project must have document of type x, y, and z. I won’t start testing unless I have signed off requirements, regardless of the delays this may cause…” etc. Me, I just like ’em cause they make the process a little smoother. I add and delete content depending on the project and would rather not use them if the management allowed.
LikeLike
Templates are almost irreplaceable in the world of consulting, mainly for reasons of returning value for effort expended. Many times clients will be somewhat satisfied if at the end of the agreed time specified in your statement of work you have completed most of the testing tasks and also provided them with a series of document templates they can then use to outsource their further needs. And like you said, they’re also invaluable in eliciting the actual state of the requirements and prior work.
But I also agree too many people/companies rely on templates as if they were holy scripture. I recently interviewed with a company who shall remain nameless, but they recently spent millions of dollars and countless person hours researching, developing, testing, and releasing an entire product line made up of proprietary templates and process flow documentation for “agile” development artifacts. The goal was to then sell these packages to their customers.
Needless to say, my job would have primarily been selling these things so the interview ended there.
LikeLike
Excellent article! I was searching for something completely different when I came across your website. I thoroughly enjoyed and thought what you set into this writting. i will bookmark to return later.
LikeLike
I really enjoyed reading this. I think I will that a look through your other posts!
LikeLike
I think it depends on how you look at it. There’s more often than not another way.
LikeLike
Hi Sheldon,
Can you elaborate?
LikeLike
Where did you get this?
LikeLike
Incredible! can be wonderful sharing. Thank you the!
LikeLike
The partner and i normally really do not depart remarks but that for you to be this kind of! My personal bookmarked web site about reddit!
LikeLike