The two step process: Testing & Sign Off

When working on any project you need to do some quality assurance before sending it out into the world.

This often means you have to pull in work from different team members, check it over, make sure it’s fit for your audience, make any changes necessary, pass it up the chain to managers and managers’ managers, take in their occasionally half-baked thoughts, and get it all finalised.

This can often be the most painful and time sensitive part of a project, adding stress and damaging relationships. The process varies for each organisation and each project but after working with almost 100 different NGOs and charities we’ve distilled the process down to two steps and outlined them with some actionable points that might make your life easier.

This applies to tech projects particularly but also works for anything from a blog to annual report. Will it take care of any and all issues you might face? Probably not. Will it get you a long way there in a short while? We think so.

By the way, at DEV we’re complete testing nerds and always more than happy to go with a more detailed process than this but as a baseline, the following is a short guide for you on:

• How to test software (or anything else) to make sure it’s what you set out
• How to get wider input from your team and key internal stakeholders for sign off
• How to stop this being a nightmare and taking years off your life

No more nightmare test results! Read on

Step 1: Testing

Assessing the quality of the work delivered, trying to find problems which can be addressed, feeding that back and making improvements.

• Review the SoW: Reacquaint yourself with the deliverables for this project so you know what you’re testing against. No matter how closely you work to the project this is an important step to start testing with.
• Go through the project in detail: Review all the aspects and do the boring work like click on the links, read the footers, make sure all sign up forms are working and collecting data etc. Here are three kinds of test you should be doing:

1. Acceptance testing: Does it do what you need? Is the functionality agreed in place? Does it work?
2. Content testing: Is the content correct? Are the images right? Is all the copy accurate?
3. Device/Browser testing: How does it look on different devices, operating systems and browsers? Is the user experience good across all these?

• Give detail for changes: When asking for a change to be made please give as much detail as you can. If you give a vague description like ‘change button colour’ then you will either get a follow up question or run the risk of having to request another change. Both waste time.
• Give context for bugs: When fixing bugs (errors in the code) developers first have to recreate the problem so they can assess it. To help them do that please send a screenshot of the issue, say which browser and version you’re using, which device you’re on, and any other information which might help.
• Batch feedback: Collect your feedback together in one place in a common format and when you’ve completed all the testing (either the full project or the full phase/functionality you might be testing) send it through together.
• Give yourself time: Try to avoid doing this close to your deadline. Give yourself breathing room to test properly.

Step 2: Sign off

Confirming a stage/final project is completed and no other changes are needed (apart from bug fixes).

• Point person: Establish who the dedicated person is in your team that will collate all input for sign off. You can have as many people involved in sign off as you like within your team (although we recommend keeping it to a minimum) but make sure there is one person in charge of this process.
• Availability: Is your point person available for all the sign off periods as outlined in your project plan? Do they have annual leave booked or will they be at a meeting with restricted access to emails? If so, get a backup plan in place. Designated point person (will there be leave during this time?)
• Funnel: Have all sign off discussions run through this person. Let them be the central point of truth so there are no parallel or overlapping conversations.
• Try a form: Avoid long email chains about sign off as they are incredibly hard to unpick and action. Consider creating a document or Google Form and asking people to input via that. This will create a clear, common format for people’s responses.
• Try blind feedback: Avoid hierarchies or personalities dominating feedback by getting everyone to input (via a form or other) without being able to see the responses of other people. This ensures that you won’t all cohere around the first response. However if there is one person who everyone is happy to defer to, then why not make them the single point of sign off initially?
• Two types: Split your sign off into two distinct types. Make it very clear when asking people to input which type you’re looking for and remind them of what you need:
• Comment/creative: This is input on concepts or points of opinion. Here you are asking people to feed in ideas that could change and improve the project.
• Red line sign off: Does everything work and is it of a sufficient standard to go live? This is about changes that have to be made not changes people would make if they were in your shoes.
• Invite with caution: The temptation is to ask everyone you can think of to give comment/creative sign off. The most efficient process however is to have only the minimum necessary people involved.
• Give deadlines and a clear format: Give people clear instructions on what you need from them. This includes specifying which type of sign off you need but also what format of response you need and by when.
• Line up with project dates: Make sure your internal sign off schedule integrates smoothly with the project sign off schedule. If you need comment/creative input from people then you need to allow time to process, respond, and discuss this ahead of your external project deadlines. Give this due time.
• Easy wins: Do your own testing first. Preempt simple issues that might arise i.e. if there’s an obvious comma missing then you don’t need 10 separate emails telling you about that.
• Sign off is sign off: Sign off needs to be final. If you confirm with an external group that you have tested and signed off then any follow up requests you make (apart from further scheduled rounds of work) will either be bugs (errors in how it was built that need to be fixed) or new requests (new work that has to be estimated and scheduled separately). Of course if you have a good relationship with your tech partners you can probably address small changes later without too much drama but know that once you sign off, there are no guarantees.

John Dunford is the Campaigns Lead at The Developer Society, a not-for-profit digital agency, working with NGOs and groups with a progressive mission to help make the world we live in a better place.

Stay in touch by subscribing to our updates here. Follow us on Twitter too to show a bit of extra love.

And of course if you liked this article, please add a clap below and share the piece — it means the world to us at DEV.