Finishing a Project: Testing and Support (pt.1)

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.

The Proposal

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.

Testing

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.

Tracking bugs

I recommend using software for this feedback – not email – something like Zendesk, Freshdesk, Teamwork.com 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.

For Marketing/Advertising

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.

For Accounting

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.