In parts 1 and
we looked at how to brief an agency and work with them. We are now skipping ahead to after you have approved the designs
and development brief to the testing phase.
This is a key phase and one that can often derail a project.
Your agency should give you an estimated build time for the site. When they have finished the build and their own internal testing they will hand it over to you to conduct your own testing and sign the system off for go live.
Have all of your content ready to enter into the system. Adding this content not only provides a good way of testing the content management system, but any other users testing the site are seeing it in as close to a live state as possible and will be able to give you more relevant feedback.
For an additional cost, your agency can write these for you or even conduct third party testing for you.
Scenarios should be written from the point of view of the user journey. You should not put too much detail in them as it can lead them towards your thinking rather than doing or thinking something naturally.
You should also consider scenarios for yourself as the site administrator.
It is important that you set time aside to test the site. This helps keep you on track and ensures that it has your complete attention.
Remind yourself what you have agreed with the agency. If you have agreed a development brief, this is one of the key ways of testing the site.
When testing turns to heartache
Sites can often get stuck in development hell during testing periods. This happens for a number of reasons:
- Did not agree a development brief before build – the site falls below your expectations and the agency have to do large pieces of
development during testing rather than fixing any bugs or issues. You thought you were getting this:
But got this:
How to avoid: Always agree what the key functionality for the site is, ideally in a document that outlines in detail how the site will work.
- Scope creep – this is often the bone of contention between clients and agencies. If the proposal and subsequent development brief are not clear and detailed about the functionality, then it is likely that additional bits get tacked on.
How to avoid: Check the documents you have received from the agency and your original brief. Is your request within reason or are you stretching it? If you are prepared to pay for extra functionality, make sure that is a necessity and not a nice to have otherwise you are stretching the testing period out unnecessarily.
The above can, unfortunately, result in a relationship breakdown between client and agency. You are told “No, it’s out of scope” or “That’s not what we discussed”. You are saying “You didn’t tell me” or “You should have anticipated this”. The more planning you do at the start of the project, the less likely this is to happen as:
- Any difficult conversations come at the beginning not towards the end when the site is built
- You both know what to expect so there are no surprises
- Any risk are more likely to have been identified and mitigated
Inevitably with web projects, there are changing requirements and there will be small things that are forgotten. The testing period should be focus on fixing these small issues and considering any changes, with the aim of keeping the project on track and preparing for the site to go live.