Quality Control is the process of testing to measure the achievement of a specified standard. Quality Control is a superset of testing, although it often used synonymously with testing. Roughly, you test to see if something is broken, and with quality control you set limits that say, in effect, if this particular element is broken then whatever you’re testing fails.
Quality control is needed for all websites, small or large. Having a site that hasn’t been thoroughly tested, and therefore likely to misbehave in certain circumstances or on particular platforms such as a mobile device or lesser known browser is consumer confidence killing, and will cost you business sales. We see all too often the pain of business owners with sites that haven’t been through proper quality control and quality assurance, failing to work on certain browsers, or mobile platforms. It’s a guaranteed method of annoying prospective customers and losing them to your completion that have invested the time and money into though testing.
A test plan is a high-level summary of the areas (functionality, elements, regions, etc.) you will test, how often you will test them, and where in the development cycle you test them. A test plan should also include time and resource information required to perform the work.
For quality control to be effective, you must test the same things the same way every time you test, yes, it’s repetitive. When you change your tests, your results become inconsistent, and thus error laden. A test plan is a must.
Each major phase/milestone of a website requires a test plan, because the focus and emphasis of testing will change over time. Testing a new website still in development is very different from testing a website that has been live for months or years. In addition, any changes to website design, HTML, code, etc whether they are small or significant requires regression test plans.
Knowing what to test and why is half of the battle. Here are some quick points to aid in deciding what should be tested for:
- What is the primary purpose of the website?
- What are the business goals behind this site?
- Who is the audience for the site? Is it tailored to them?
It’s the answers to these questions that will help decide what needs to be tested, and in developing testcases.
A large percentage of website quality control testing demands the testing the site-as-a-whole due to HTML and HTTP needing to follow certain protocols, standards, and rules of syntax. Therefore testing for broad patterns of behavior is a wise first step. Much of the below can be tested with the assistance of automated (or largely so) tools:
- basic adherence to an HTML DTD (document type definition)
- broken links
- links pointing to correct targets
- adherence to a coding style guide or standard; do graphics have ALT values? do graphics have HEIGHT and WIDTH values?
- adherence to a content style guide or standard
- correctness of graphics
- correctness of dynamic content or includes
- application functionality
- basic compatibility
- basic performance
There’s an art however to making use of automated testing aids/tools. Broad automated tests won’t give you the full picture, and manual intervention is always required to ensure proper testing has been performed. Does the search function work correctly? is it returning the correct results? Application functionality requires the creation of individual tests, based on scenarios produced to consider what the expected behaviour of a certain element should be.
It’s these scenarios that enable the development of testcases, outlining specific steps a user would follow to complete each scenario. Be sure to include every single step, and variation available for a user to achieve a certain action. It might sound tedious, but this is how thorough testing is performed, and websites can be launched with high degrees of confidence to perform well across selected environments.
The quality control process has the major shortcoming of being reactive to problems. Quality control sets standards for websites and tests for components that fail to meet those standards, however does not exist to improve the quality of web components. The strictest testing of the output will not necessarily improve the quality of the input — this challenge is met by the quality assurance process, which we will write about in another blog post for you soon.