After long hours of what may have seemed to be an unending series of mockups, coding, heavy-metal music and energy drink, you’ve finally finished your project. And you did an awesome job. Your client loved it so much he wanted to marry it.

But you know that despite this swift moment of respite, you still have some things left to do and one of those is testing.

Testing your site can be disheartening despite its value. You have to look at all the pages of your site in all the browsers, and devices. If I haven’t emphasized it hard enough, I’ll say it again, all of the pages in your site.

But to at least save yourself from the troubles of confusion and chaos, you need a plan, a front-end testing website plan.

WHY PLAN?

Having a plan will help you know the devices, browsers and systems your project is supposed to cover. This will help you reduce the waste of time, money and effort.

Knowing that you’ve been meticulous enough to not let giant errors slip thru will make you sleep better at night, if you sleep at all.

Getting a sign-off from a client is one thing, but if you want more work in future you need to make sure there aren’t any gotchas waiting a few weeks down the line, because those will stop your client recommending you.

TOOLS!

Before anything else, having a collection of tools to use will surely help. Here are some choices:

PROJECT MANAGEMENT

Personally, I just love Asana because it’s easy to use, but you could also use Basecamp or Trello.

DEBUGGING

I use Chrome Developer Tools for inspecting elements, debugging, and profiling. You might also consider Fiddler, or Firebug.

SCREEN-CAPTURE

Window’s Snipping tool gives you an easy way to document and present front-end bugs. Other options include PicPick, and Skitch.

CROSS-BROWSER TESTING

Unless you can afford to buy every single operating system, desktop and mobile, you’re going to need a cross-browser testing tool. My favourite is BrowserStack, but you might also use SauceLabs, or Spoon Browser.

WHAT TO TEST FOR

Now that you’ve got your tools ready, you have to identify what you are really testing. Doing this will either lead you to bugs or to nothing. But if you ended up discovering nothing, that doesn’t mean your work is perfect. It only means that you didn’t find the problems.

Because almost all websites have some issues, if you haven’t found any issues after the first round of testing, ask yourself if you’re looking hard enough.

First, you need to know who your audience is and how will they be using your site. For this, you need to consider the following:

Popular devices used by audience

Operating systems and browsers used by your audience

ISP plans of your audience

Proficiency of your audience

You can now break down your tasks into milestones targeting your audience. You now have the idea which browsers, operating systems, and screen sizes you need to prioritize testing. You also will know on which ISP you work well and which type of audience benefits more from your site.

Learning all of this will give you an idea of what services, interface elements and functionalities you need to improve, delete or add.

RESTRICTIONS

A few factors control your project and these factors should be considered when testing:

How much? What is your rate for testing? Of course, this is important because you will be investing time and effort in this phase of the project.

How long? How long will you be working on the project? What is your deadline? When will you start?

How wide? There are a lot of devices, screen sizes and browsers in the market. Will you target each of them? No. You just find the ones your target audience use.

BUG REPORTING

Bug reports from clients are usually vague, along the lines of, “It doesn’t work.” It reports a problem, but it doesn’t identify what the problem really is. In testing, if you report a bug like that, you’ll never move in any direction, ever. So here are a few tips:

Get to the point: Summarize what the issue is. Identify the problem by stating what part of the specific page doesn’t work and what happens in it. Also, write a report for multiple bugs you found and put them in one document only.

List procedure: Make sure each step you perform is reported as to easily find out where the issue is coming from.

Be technical: By this, I mean be a technical writer. Use less pronouns and be straight to the point.

TOP TIPS

Make your plan like a to-do list. Divide it into major parts (units) and subdivide those units into smaller tasks.

Prepare your budget, resources and time properly.

List all the devices you have right now. Find devices near you using Open Device Lab.

Finish your tasks on time; no procrastination.