The quality assurance (QA) phase of a web development project is the last phase before launch. While the development team has a lot of experience with QA phases, oftentimes the client team is new to the process, which can lead to stress. Let's prevent this with a little Q&A on QA.
- What is the QA phase?
- What is the difference between QA and QC?
- Is the QA phase the only time you perform QA?
- How long is the QA phase?
- When should the QA phase start?
- Can we skip or skimp on QA if our budget and/or timeline is tight?
- Who performs QA?
- Can we outsource QA testing to a third-party?
- Whose fault is this bug?
- Are development bugs common?
- How long does it take to fix a development bug?
- Do we pay for development bug fixes?
- What is a backlog?
- How do we help with QA?
- What's the best information to report when filing a bug?
- Our project is a little off the rails. Can you finish it up and do QA?
The QA phase is the last phase of a project and consists of two parts: (1) users exploring the website or web application looking for problems, and (2) the development team and content team working to fix a prioritized list of identified problems.
Quality control (QC) is the process of checking a product for defects prior to shipping. It's less nuanced than QA, which is a more holistic process. At Zivtech, QC is our Launch Checklist and requires only a few hours to complete.
No. Quality cannot be added at the last minute; it must be the focus throughout the project. At Zivtech, we first conduct QA at the ticket level. Each time a developer completes a task, it is reviewed by the lead developer on the project to ensure quality. At the end of each development sprint, general exploratory QA is performed on features recently completed. This sets the stage for a stakeholder review, which typically uncovers further QA tasks.
The length of the QA phase is roughly proportional to the length of the project. Remember that QA consists of two parts: (1) users exploring the website or web application looking for issues, and (2) the development team and content team working to fix a prioritized list of identified issues. Part (2) often requires more time in hours, but part (1) depends on stakeholder availability and might prove long in days. A four to six month project typically requires a four week QA phase.
A web development project should proceed according to a pre-determined timeline. This timeline should identify the start of the QA phase, which should be the last phase of the project.
No. Instead, you must reduce the project scope of work. Launching a website without comprehensive QA is never smart and should not be an option.
Both the development team and the client stakeholders perform QA. The two groups have different strengths. The development team has more QA experience and knows which features of the website are most complex. The stakeholders know the audience and content.
There are cases where this makes sense. As we do a lot of CMS development and many of the features are intended for the client staff to use, it is best for the client staff to test them themselves.
A bug is when you have functionality built but something about it doesn’t work right. For example, you have a login form but when you fill it out correctly you aren’t logged in. A feature request is when functionality does not exist that you want to exist. For example, you can’t log in because there’s no login form. The end result may seem similar to you (you can’t log in), but they have to be treated differently in QA. A new feature will in itself require QA, so it has to be backlogged for a later development sprint. It’s normal to realize there are new features you want during QA and you should file these requests for the future.
Bugs are an inherent part of web development. All shops are likely to come across bugs in the development process. Often they originate in the open source code being leveraged for your project. The key to tackling development bugs is to anticipate and plan for them ahead of time.
Bugs are puzzles; once a solution is discovered the bug is fixed. But this means it is nearly impossible to estimate the time required to fix a bug. The worst bugs are those that are not easily reproduced, either because they occur intermittently or only occur for one user.
Yes. Bugs are an inherent part of web development. In any budget estimate, a reasonable amount of time for bug fixes should always be included.
A backlog is a list of issues including bugs and changes to existing functional requirements. Backlog items are prioritized and added to subsequent development sprints. A site should continue to improve and be maintained after launch, which takes the form of sprints formed from prioritized backlog issues.
To help find QA issues, imagine different scenarios in which people will use the site. Then go to the site and click around, doing the kinds of things these users might do. Click on every link in the menu. Register for an account. Forget your password. Search for something. Write a comment. Share an article on Facebook. Read the little help text on the login page. As you go, take notes on everything that could be better and especially on anything that doesn't work. Look at how everything looks. Make sure you can successfully do everything you should be able to do (and no more!) and that doing so is straight-forward.
Bug reports can almost never be too thorough. We can fix more bugs faster if we don't have to come back to ask for more information. The most useful thing in the bug report is the URL where the bug occurred. Also include whether or not you were logged in, and if so which user account you had. Explain what you did to experience the bug. Explain the behavior you expected. Take a screenshot. If the bug is visual in nature, include which browser and OS you are using. We typically set up a feedback system on the site so that you submit reports directly from the site, with it recording the URL, your user account, and your browser and OS automatically and filing a ticket right into our ticketing system. If you prefer to file your bugs by emailing the project manager or by noting them on a document, you should make sure you record those items.
Yes. In the Drupal world it's all too common for an organization to build its site with an inexperienced team, whether it's an internal team tasked to build your site with little Drupal background or a bad vendor. Let's get it back on track, fix and finish everything and launch it.