- Phase 4: Production and QA
- Establishing Guidelines
- Setting File Structure
- Slicing and Optimization
- Creating HTML Templates and Pages
- Implementing Light Scripting
- Populating Pages
- Integrating Backend Development
- Understanding Quality Assurance Testing
- Creating a QA Plan
- Prioritizing and Fixing Bugs
- Conducting a Final Check
- Phase 4 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding Quality Assurance Testing
You've built your site; now make sure it works. Quality assurance (QA) is one of the most often skipped steps (besides usability testing) in the development process. Not surprisingly, we highly recommend against skimping on QA. Broadway productions wouldn't go live without a full dress rehearsal with sound and lighting in place; you shouldn't launch a site without a comprehensive run-through, either.
The QA Lead
In Phase 1, we outlined various roles and responsibilities, one of which was that of the QA lead. Depending on the size of the project or the extent of your development team, you may not have the luxury of having a dedicated individual assigned to overseeing and managing quality assurance. If this is the case, chances are the project manager will have to fill this role. For project managers new to this role, we recommend a crash course in QA — some expertise in the testing and launch of any product is far more valuable than "winging it." For an excellent overview of QA principles and philosophy, go to http://www.philosophe.com.
If you are managing this task, make sure to keep client expectations in line. Educate your client as to the value of comprehensive QA and to the extent and the cost that QA can take. Make sure the client understands that "comprehensive" calls for more than one day and more than just a few thousand dollars.
We recommend shooting for a QA budget of approximately 10 percent of your total time and resources. You need this time to track and fix mistakes such as spelling errors, orphaned and rogue links, misplaced content, and so on [6.13]. But the even bigger job is bug tracking and fixing: broken tables, functional errors, browser crashes, everything that is not up to specifications. You then need the time to fix those bugs and then to crosscheck once again before the site goes live. And, if you have access to the client server, you will want to QA immediately post-launch as well.
){kind=link}
Figure 6.13. A typical, simple bug: The image isn't loading (top). A quick directory check and reupload of the image solved the problem (bottom). An example of a bigger bug would be a DHTML pull-down menu that crashes certain browsers (this is harder to get screenshots of).
However, in many projects, there is seldom time left in the budget for QA testing. More often than not, the testing and acceptance of production are slammed right up against launch. All too often, production deadlines have been pushed (usually due to late-arriving content and technical snafus), and the time allotment for QA is compromised. The extent to which you will actually be able to conduct QA will depend largely on three things: 1) how close you are to your launch date — usually a result of how well you were able to adhere to your schedule, 2) acceptance criteria, or how perfect the site needs to be prior to launch, and 3) how flexible, if at all, the launch date is.
This critical testing process can take place informally with just a few team members, or it can be a larger undertaking, done either in-house or by hiring an outside company or team. The real-world tendency is to approach this process haphazardly, but be forewarned: Without a cohesive QA plan, you are taking a big chance. And chance is never a good step to stand on, not when there is a budget at risk. Have a plan.