How to Develop a Quality Assurance Plan for Your WordPress Site

Quality Assurance: love it or hate it, you can’t live without it. From what we learned, behind every successful website there is a significant amount of testing in order to provide for its quality. And every testing process begins with a QA plan (or also known as a Test Plan).

This short guide will explain what a QA plan is, who creates it, why it’s important to have one and the steps that need to be followed in order to create it.

What Is a Quality Assurance Plan?

The QA plan (or also known as a test plan) is a detailed document, which includes the following components:

• The testing strategy for the website
• What the testing objectives are?
• What resources are available – manpower, software and hardware tools?
• What the schedule for the tests will be?
• What the estimation for the test is?
• What needs to be delivered before, during and after the whole testing process?

Who Creates and Maintains the Test Plan?

Once a test plan is set, it’s time to decide who creates and maintains the document? The answer is simple – the test plan is created by the QA team who are directly involved in the testing process

Why Is the Test Plan so Important?

Before proceeding with how to create a test plan, let’s see why it is important to have one for your website.

• It will determine the amount and kind of work needed to validate the quality of the tested application.
• It helps people who are not part of the QA team (management team, the developers and even the customers) understand the purpose and approach of the testing process for the website.
• The test plan is like a rule book – it sets all the rules and procedures that the team needs to follow during the testing process.
• Last, but not least, the document contains some important aspects like test strategy, test scope and the estimates, which can be reviewed by the management team and reused on similar projects in the future. This way the test plan supports building stable processes and accumulating know-how.

Creating Your First Test Plan

Now that we have provided the answers to the basic questions “What”, “Who” and“Why”, the next step is to learn how to create a test plan.There are a lot of templates, on which your test plan can be based.

Some examples can be found here. The process is outlined in eight steps with an explanation provided for each of them. For the sake of convenience, during the explanation of each step, the term “project” will be used, instead of “website”, as the document is also applicable to different types of software applications.

1. Product Analysis

This one is basic: know what the product is. A starting point is to get acquainted with the project documentation – Why it was created, who’s expected to use it, how it will function, how it would look and on what environment (hardware and software) it would run. The latter is very important when you test the compatibility on different platforms – devices, web browsers, OS’ etc.

2. Develop the Test Strategy

The test strategy is a really important document, developed by the Test Manager. It defines the testing objectives along with the testing efforts and the costs for the whole process.

There are several things that need to be done here:

• Define the testing scope – You need to decide which of the tested components of your website will be “in scope” and which ones – “out of scope”. The “in scope” components will include everything that will be tested on the website, while the “out of scope” will be left out. Having a precise testing scope has two benefits:
  • Everyone will know precisely what tests will be performed.
  • All involved members of the team will have a clear understanding of what to test and what not.

To determine the scope of a testing project consider the customer requirements needed, the project budget, the product specification and last, but not least, the skills and talent of the test team..

• Identify the testing type – Based on the type of the project, the appropriate type of tests need to be selected. There’s a ton of test types out there and it’s impossible to apply them all, especially when time and money are constraints. The idea is to select the ones relevant to the project and its specific features, and set priorities.

More on the different testing types can be found here.

• Document all risks and issues for the project – This could include things like team members that lack the required skills, incorrect estimates, tight schedules. Try to foresee all potential issues and risks and suggest a course of action in order to handle those problems.
• Plan the test logistics and who will perform the tests and when that will be done.
  • How to decide who will perform the tests? Ideally, the best person would be able to understand the customer’s point of view, aims to achieve the highest quality possible, has a strong attention to detail, and is a team player.

Depending on the budget, the testing can be done in-house (by the internal QA teams) or be outsourced to a specialised agency.

• When should the test begin? Testing should begin when the specification is ready, all the human resources are available and the testing environment has been set.

3. Define the Test Objectives

Usually, the objective is to find as many software defects as possible, fix them and ensure that the tested website is bug-free before it’s release. However, producing a 100% bug-free product is close to impossible, so it all comes down to identifying and fixing all the bugs considered to be critical to the functionality of the product and then resort to post-launch updates and fixes.

In order to define the test objectives, two steps need to be done:

• List all of the features of the website that will need to be tested.
• Based on that list, define the overall goal of the tests.

4. Define the Test Criteria

Test criteria are the guidelines on which the test procedure can be based. There are two criteria types l:

• Suspension Criteria – When this criteria are met, the tests need to be suspended until the development team can resolve any issues which would cause the criteria to be met. After this is done, testing can continue. For example, if the suspension criteria is to have 45% of the test cases fail, when that failure rate is reached, the testing stops and the development team has to resolve all the issues for the failed cases.
• Exit Criteria – Meeting this criteria means that the test phase has been successfully completed. The exit criteria includes targeted test results and is needed before proceeding to the next development phase.The most common exit criteria for terminating or concluding the testing process are:
  • The deadlines are met or the budget is depleted.
  • All test cases have been executed (usually it’s mandatory) unless there is a clear reason for not achieving a 100% coverage of the tests.
  • All high priority/critical bugs have been resolved.
  • A sufficient coverage of the requirements and functionalities for the website has been provided.
  • Reaching the targeted percentage of passed test cases or the ratio between the passed tests and the total executed test cases. This is a metric which calculates the percentage of the past test cases.

The calculation is done with the following formula:

Percentage of Passed Test cases = (Number of Passes Test cases / The total number of executed Test cases)* 100

5. Planning the Resources

The resource plan is a summary of every type of resource (human, equipment, materials etc.) which would be required for the testing process. This step is of great importance as it helps with deciding the resource quantity needed for the tests and thus helps with preparing the correct schedule and estimates.

Here is how to cover the recommended resources for a project:

• Human resources – List all the team members who are going to participate in the testing process along with their role in it .
• System resources – All non-human resources needed for testing the project:servers, test tools, computer hardware, networks, the test environments etc.

6. Planning the Testing Environments

A test environment consists of all components (software, hardware, network configuration, etc.) needed to perform the required tests for your website.

A couple of examples of different types of environments:

• Test environment – For example the local setup of the website where the development team can work/test their bug fixes and code changes without worrying about breaking any functionality which would impact the user experience. Once they have finished working on a feature or a bugfix, this can be handed off to the testing team for further tests.
• Staging environment – Staging is similar to production in regards to content, set up, etc.This is where bug fixes and new features will be tested before deployment to production is performed. It is strongly recommended that staging tests are performed before deploying anything to production. , This way the testing team can find any issues that could occur in production and save everyone a headache.
• Production environment – This is what the end-user sees.

Related Article: The Anatomy Of a Good Bug Report

7. Preparing the testing schedule and time estimations

• Test estimations – This is the time needed to complete the testing process. For the sake of precision, it’s best to divide the whole process into small tasks and provide an estimate for each one. Then you can add them up to see how much time is required to finish everything.

Some best practices for doing test estimations can be found here.

• Project schedule – Having a solid schedule will help management (specifically, the Test Manager) get a clear idea of how the work on the website is progressing. There are a number of important things needed order to prepare a good schedule:
  • The deadline for the project completion – This one should come first as it will define the time-frame in which the testing schedule must fit.
  • Working days and employee availability – This helps better arrange the testing activities within the schedule.
  • Project execution estimation – How long it will take to complete all the tasks related to testing your website.
  • Project risk – Knowing the potential risks allows for the allocation of extra time to deal with them.

8. Test Deliverables

Test deliverables include all documents, tools, reports etc. which are produced and maintained in support of the tests. The deliverables are different, depending on the phase of the project:

• Deliverables, provided before the testing begins: The test plan, test cases and test design specifications
• Deliverables, provided during the testing process: Test scripts, error logs, test data etc.
• Deliverables, provided after the conclusion of the testing: Test results, defect reports, release notes, installation/test procedure guidelines

Wrapping Things Up

As it can be seen, the test plan covers important processes and contains a lot of essential information needed for testing a website. Having everything documented would make it easier to manage and follow the workflow and create best practices.