The following post is related to the why of test planning. In any development cycle, testing plays a vital role and takes a large portion of the total website design time. As such, it should be given just as much consideration, if not more, as the development itself. There’s no point to a well-designed site which looks amazing, but is full of bugs. Users are likely to move on and never return. Nothing detracts from a stunning website more than a broken feature or browser incompatibilities that ruin a nice design because the site hasn’t been tested properly.
Why should you plan?
Typically, the approach taken when developing a website is not what you would call ‘cookie cutter’. You aren’t just stamping out some dough in the exact same shape every time. It’s an amalgamation of features and project planning which comes together a little at a time. What this means is that it’s rare to be able to test a site from the get go. In order to test a feature it must be mature enough to be worth looking at and there’s never a guarantee that when you get to it, it’s not still waiting on this or that to be added before it’s completed.
Writing a test plan gives you the opportunity to consider the item you’re testing from all angles in advance. Taking this step back allows you to familiarise yourself with the requirements and to put yourself into the shoes of the end user, or someone with malicious intent. This helps you nut out all possible scenarios that may occur in the real world and ensure you’re testing as thoroughly as possible against them.
Good for web design developers too.
Writing a plan in advance can also assist with development, as developers can see what has been laid out in the plan and take this into consideration when designing the solution. This can save time during development as you don’t have to send work they’ve already done back to get re-architected.
Avoid the rush and save double handling.
Pre-planning and forethought are where having a test plan laid out really comes up trumps. As with any project based industry, the unfortunate truth is that there is nearly always the last minute rush to get things over the line and meet deadlines. During this time, more and more people may be pulled in to help test the solution.
Where do they start, what should they look at and what should they look for? Working from a test plan which already has bugs and issues flagged, items which have already passed and what is yet to be tested, will save countless hours.
Anyone on the web design test team can immediately see where the testing is at and what they need to specifically check to confirm if issues have been resolved. This stops testers from looking at the same things and gives them structure and direction when it’s needed most. It also means that any regression bugs are caught as the same tests are always run with each and every iteration. If not all testers are 100% familiar with every part of the site, having a plan with everything they need to look at is a major advantage. It’s much quicker than getting everyone up to speed on every detail.
Pitfalls.
The main pitfall with test plans is that testers dive straight in and start marking things as passed or failed; following the plan to the letter. This is great to a point. Because the plan is written in advance, there is a chance that the developed application may not exactly match what’s in the plan due to software limitations or unforeseen complications with development. This needs to be considered. The test plans themselves should grow and adapt while testing. Things may come up that are worth adding or amending. After all, you’re testing; you can also test the tests. For this reason, each iteration of a test plan should be built on the previous one to ensure any additions or changes are included.
