If you're like us here at WebDepend you will have encountered issues on numerous websites that prevented you or made it difficult to make a purchase or complete a task. Perhaps you persevered with the website or you called their customer service line or even went to their competitor instead. Why don't websites get tested properly so these issues don't occur so frequently? Well, in our experience, there are many potential barriers that can mean some websites don't get the attention they need, either they don't get tested enough, they don't get the right testing or they don't get tested at all.
Our blog series aims to highlight some of those barriers and put forward meaningful suggestions on how those barriers to QA can be overcome.
We’ll start the series with one of the most common barriers to QA; there’s not enough budget in the project to have someone test it.
This happens frequently and QA often gets squeezed out due to other areas going over budget. Perhaps more time was spent getting the design just right or development took longer than expected and so there were cost overruns. When a project manager has to balance the books, a quick fix is to reduce or eliminate QA altogether and, hey presto, the project is within budget again.
Unfortunately, this is a shortsighted approach as it makes one large assumption - there will be no bugs. In all the hundreds of projects that I’ve been involved with over the years, there has never been a project that has had no issues. Some projects have had hundreds of bugs raised during the main part of QA.
Some projects never have QA included from the start because the project budget could never stretch to include testing at all. There is an expectation that somehow everything will work out in the end and that dedicated QA will not be needed. Web projects simply don’t work in this way, there will be bugs and they need to be found, reported, fixed and verified.
Reducing or taking QA out of a project budget is a false economy, as without testing being carried out to find and report bugs there tend to be two outcomes. The first is the website suffers from quality issues and so does not go onto achieve the level of engagement with its target audience, such as enquiries or sales. A poor quality website can even damage an organisation's brand and reputation. The second outcome is having to carry out considerable rework to fix the issues that would have been picked up originally, had QA been involved.
Both of these outcomes cost money and, if there were included in a project's budget, would cost far more than having QA within the project budget in the initial instance.
So what's the solution? We believe that some testing will always be better than no testing at all. Therefore, if the project is running out of money or the budget was always tight and stretching to full QA is not an option, put something in for some testing. It will pay for itself in terms of saving costs in rework down the line.
Focus the testing on the core aspects and the most important features of the website. Concentrate on the most popular browsers and mobile devices and make sure the primary user journeys are covered in the testing.
With that in mind we developed our Mini Audit and whilst it's less expensive than our Full Audit, it still covers all the cores aspects of your website with functionality, selected browser compatibility and usability included as standard. Complimentary access to our Testing Manager application is also provided. This offers excellent value for money as our Mini CMS Audit is just £350 and our Mini Ecommerce Audit is £450.
Look out for the next post in the Barriers to QA series coming soon.