Estimating web development projects is hard - I know this from experience, before I became a tester I was a project manager at a digital agency. Seems a lifetime ago now.
But I do remember projects that landed in my inbox that had seemingly good budgets, £60k for a templated email marketing system for a well known chain of health clubs, £80k for the new website for a major chain of pubs, for example. And this was in the late 2000s.
For a project manager at a digital agency there are many costs to estimate - design, development, hosting or infrastructure costs, associated planning and project management, perhaps some user research and any specific skills brought in for the project. There might be training and ongoing support to also factor in.
There's often a feature or integration that nobody is quite sure how long it will take to build, or what difficulties might be encountered, better add some contingency to that part. That generous budget is looking pretty thin about now.
Obviously the client needs to be happy with the end result but the agency also needs to be happy with what they've produced. And there needs to be a profit for the agency otherwise there's little point in doing the project.
Once the draft project estimate is completed you take a look over it to make sure it has everything and leaves a small profit, assuming all goes well. Everything seems to be present and correct, looks good!
Wait a minute...there is something missing, the project needs to be tested!
We need to estimate time for QA, to test that the web development project actually works as intended, that it includes everything we said it would and doesn't have any bugs.
Estimating testing often comes near the end of the estimating process and a figure might be quickly jotted down or added to a spreadsheet. The number is squeezed into the budget, it looks inadequate but just about fits with the overall budget.
This project will be different, we think to ourselves (again), we'll build it correctly so there won't be many bugs to pick up.
There is a sense of optimism when the project finally gets underway - the project starts well enough but that optimism quickly evaporates once the problems start. We tried to keep design amends to 2 rounds but the client insisted that we hadn't listened to the brief and so another big round of design changes was the only answer. This is both a cost and time overrun.
Then, finally got into the build phase and found we had under-estimated the complexity of the integration with the CRM that we hadn't done before and there were many other little things that cropped up and needed attention. More overruns.
As the development nears completion it's time to get the testing phase prepped. Let's check what the testing time was that we estimated. Oh dear, that's not going to cut it, we've already used up more than that time with the design and build overruns.
What often happens is that testing time is reduced down because of budget overruns and also squeezed into lunch breaks and evenings due to fast approaching deadlines (caused by time overruns). On some occasions testing is skipped altogether.
The way that web projects are managed has come a long way in the last 15 to 20 years, since I was a project manager, but I do still see many examples of rushed and skipped testing. This is often due to poor estimating or no estimates for the testing at all.
Skipping and rushing testing is a false economy. Squeezing the testing time due to overruns in other parts of the project is also a false economy.
What happens is that quick checks are carried out and called 'testing' or 'QA', mostly because the amount estimated is low to start with and often gets eaten up by overruns in other parts of the project.
The project is then handed over to the client with fairly minimal testing, just whatever time the project manager and/or developers had in order to check it over.
So not enough functional testing done, practically no browser or mobile device testing, perhaps a bit of accessibility testing or performance testing.
And what happens? The client finds a bunch of bugs in their testing and sends the project back to be redone. The rework costs can be significant and cost the agency more than the testing would have cost in the first place. But not only that, now the agency's reputation has also been damaged with the client.
The client potentially also loses trust in the agency's ability to deliver further projects and so the agency loses future work as well.
All of this can happen, in part, due to not estimating testing effectively, squeezing the testing time that was estimated or otherwise rushing or skipping the testing of the project.
More effective estimates can help to solve some of these project problems. But if the agency doesn't have any testing specialists then it is still often guesswork when it comes to estimating testing.
Testing estimates might be based on an arbitrary amount, they might convenient figures to fit into a budget or they could be a percentage of the build or development costs. I've seen some agencies talk about testing estimates being based on 20% to 25% of the development costs. One agency even quoted testing estimated as being 30% of the development costs.
But for many digital agencies, estimating testing is not really based on what testing needs to be done, as there is a lack of understanding of what should to be covered in testing and how long that will typically take.
What if there was a way to put together a realistic estimate for testing a CMS or Ecommerce project and then easily refer to it throughout the project?
Well, now there is!
We've built a testing estimator tool that lives inside our Testing Manager application. Easily prepare an estimate for testing your CMS project, save it and then refer to it through the project.
The estimator tool includes all the parts of a typical CMS development project, from test planning and preparation, functional testing, browser and mobile compatibility testing as well as accessibility testing, testing integrations and further phases for bug retests and regression testing.
Interested? Contact us for a demo, we'd be glad to show you how it works.
Photo by Jakub Żerdzicki on Unsplash
