No matter your business, finishing a project can be a challenge. Without proper testing and support plans in place, you can struggle with closing out a client’s project. Whatever your quality assurance needs, it comes down to how well you plan for and execute the testing and support aspects of the project. Part 1 of this post covers the testing aspect. Watch for part 2 on support coming soon.
Contextual Definitions of Testing and Support
“Testing” in this context can be considered proofreading a manuscript, a legal review of a contract, minor edits after a walkthrough of a written process, test cases for software development/new websites, or doublechecking your Quickbooks integrations. It applies to marketing, accounting, software development, and even building and writing processes like I do.
I consider “Support” as maintenance of your website or software, monitoring of your servers, ongoing upkeep of your banner ads or radio spots (perhaps changing out the seasons, etc.), bookkeeping for accountants, or just being available to answer questions. In other words, it’s upkeep, minor changes, and adjustments to your original work.
But, you can define these parts however you’d like in your industry by using your proposal to clarify with the client how you are going to conduct the testing and support.
As usual, I’m going to harp on how important the proposal itself is during all phases of the project. Testing and support are no different. You can read more about writing a great proposal here: Project Proposal Structure Leads to Project Success.
Define what you consider testing. Explain how you do it. Be clear on how long it will last before you move into the support agreement. Make sure the client knows there will be a support agreement. Be sure the client understands the expectations you have for his role in testing and support as well. Remember that even though you do it all the time, your clients don’t. So, the proposal is an opportunity to educate as well as sell.
Providing clients with a structure for testing allows the project to stay on the rails and manage what are bugs versus changes. My suggestion in guiding for managing the testing aspect are as follows:
For Software/Website Development
Before you even consider turning the solution over to the client for testing, you need to test it internally first. And, I don’t mean “look at the code in the back end.” I mean have a real person sit down and try to use it. User testing is imperative since your client will be using the software, not looking at the code. And also use the goals of the project as a litmus test to make sure you are meeting them.
Then, have the client test on the development server. (Many words are used for the development server – staging, testing, alpha, etc.) The important part is that it is not yet launched to the public or the client. The data in it might be old or made up. There will be bugs and tweaks. But, at this stage, the changes should be very minimal if you were properly walking the client through your work during status meetings and development. All of that needs to be explained clearly to the client when it comes time to test. I usually call this testing period the “alpha testing” stage.
I recommend using software for this feedback – not email – something like Zendesk, Freshdesk, Teamwork Desk, or any bug tracker. Please, just don’t use email.
Be sure to designate a specific time period that the testing will run. Include all bugs the client finds during that period as part of your project plan. And, you will fix them before moving to the “beta stage.”
Lastly, after you fix all the alpha bugs, you can move the solution to production (or live, final, etc.). Real data is included at this time, and beta testing begins. At this point, any bugs or tweaks should be minor and should be quickly fixed. Continue to designate a time period for this stage and, at the end of it, fix the bugs and then close the project. Now, you’re ready to move into the support stage.
In marketing or advertising, it all depends on the medium. But, regardless, the steps are the same. First, a proofreader needs to read the material. This person needs to be someone who hasn’t seen it before but understands the context and goal. The whole team should review it vs. the original creative brief to make sure it is on target. And then, you provide it to the client.
Just like in the software world, the client isn’t getting the final version first. Send them a concept first, and later, a final layout for approval before it moves to be printed, recorded or posted. I would consider presenting the concept so that you can explain how it meets the original creative brief’s goals. Then, give the client the ability to report changes needed. Changes are usually done in handwriting directly on the provided mockups, or via PDF if it is digital. If it is a less tangible deliverable (website, TV spot, radio spot), you should provide clear direction on how the feedback should be sent.
Once the original is produced and in the public eye, you can begin the support part – maintaining rotations of radio spots, fixing minor website bugs or updating print ads by season.
Accounting requires a slightly different approach, but a bit more simple. In essence, the client needs to review and understand what the accountant has produced. It needs to match the numbers expected. And, it needs to be verified that the information is accurate. After that stage, the accountant can usually turn it over to the bookkeeper for ongoing support.
Tune in next time for how to move into support agreements. If you have any suggestions on testing, we’d all love the input. Please add a comment below.
Looking forward to the next section…
Susan Fennema says
Hi Daniel- tell me what appealed to you the most here, and I will try to focus more on that in part 2. Would love to know what you found most valuable in this article and what other content you might be interested in hearing more about. Thanks for stopping by the BTC blog!
Dale Arends says
Testing in its various stages generally focusing on three things, does the product work, i.e. does it do what it is supposed to do, is the product usable or does the workflow confuse the user, and does the product meet the customer’s needs. One aspect that is often overlooked is a short, dedicated phase to find out where the product breaks. Consider that the user may not have extensive training on the product, or may have changed certain system settings (as in a software environment where a visually impaired user sets the system font to size 48 or picks a different color theme), does your product handle the unexpected cleanly? Test on different sizes and resolutions of displays to ensure that dynamically created windows are always visible. In essence, testing should not only tell you the product’s successes but also its limitations.
Susan Fennema says
Dale- Thanks for your comment. The additional information is very valuable, especially for software developers. Thanks for sharing it!