A well-done Proof of Concept, or PoC, can make or break a software testing project, particularly in regards to software testing outsourcing. Wikipedia defines Proof of Concept (or “Proof of Principle”) as “a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.”

In addition to testing and demonstrating a concept’s feasibility, your PoC can also be an important way to gather and pass information on to the people who need to know it most: your testing teams, the client, and the client’s in-house teams as well. It’s also how you convince prospective clients that your company is the best possible choice for the job at hand, whatever that may be, which should be reason enough to put time, effort, and resources into crafting high-quality PoCs.

In addition to testing and demonstrating a concept’s feasibility, your PoC can also be an important way to gather and pass information on to the people who need to know it most: your testing teams, the client, and the client’s in-house teams as well.

Proofs of Concept certainly pose challenges to those who are writing them, but also for those who receive the completed PoC- the client who will soon engage in a software testing project. While this post will explore the former category and provide advice to testers, keep an eye out for our next post, which will cover what to keep in mind if you are on the receiving end of a PoC.

A successful Proof of Concept is made up of:

  1. An internal assessment of whether or not your company has the means to do take on the project
  2. A separate PoC for your internal team, covering how it should be carried out, what pitfalls will be inherent, what needs to be concentrated on, and how to work through the main challenges the project poses
  3. An eye-catching, well-polished presentation for the customer; part informational, part marketing, this section should carefully outline the work you propose to do and how you will accomplish it, while also convincing them that you are totally awesome and that your awesomeness will rub off on them if they work with you
  4. A technical write-up for the client’s internal test teams, detailing what will be expected of them, what your teams will take care of (or have taken care of already), pros and cons, how to address potential problems, etc.
  5. A detailed write-up of how the project will be completed, with a timeline and potentially a projection of costs for each step

When compiling a PoC, keep in mind to:

  • Define terminology early on, and stick with it- this is true of capitalization standards, too. You don’t want to go from discussing Agile scrum to agile Scrum halfway through the document, as this could confuse readers.
  • Set clear goals and a timeline, both for the entire project and for every individual step…
  • …and stick with them! Try not to add new goals to existing or completed sections, and keep to your specified deadlines
  • Format your PoC to be inclusive of unknowns; make sure there’s enough time and funds allocated to each task that unexpected pitfalls won’t handicap the project.
  • For your external PoCs, make sure to read it over for grammar and correct word choice. There’s nothing worse than sending out a PoC, then realizing afterwards that your punctuation was incorrect, or that you used the wrong form of “there.”

For presentations to the customer, it may be helpful to think of these documents as equal parts technical and marketing. As with any tool used to convince potential customers to make use of your product, remember that you need to sell them on your company, as well as whatever process, tool, or vendor you recommend in the document itself. By the time they finish reading your PoC, you want them to come away feeling enlightened as well as converted to your mindset, and wondering what they would have even done if they’d never seen it. More broadly, however, it may help to view all facets of the PoC as plan of action: it should give testers, both in-house and outsourced, an idea of what will be expected of them and when, and inform shareholders or managers on the customer’s end of when they can expect what.

The Proof of Concept, while certainly not the most important document in the software testing process, is integral to a well-run testing life cycle because it allows for a certain cohesiveness amongst the necessary parties. So long as all parties involved meet their goals and keep their deadlines, a well thought-out PoC can lend coherence and keep everyone on the same page during the software testing life cycle, which is invaluable when considering how many different parties are usually involved.