- 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
Conducting a Final Check
Conduct a final check with all teams involved. Make sure all systems are go. Here are the key five items to confirm:
Design check. Designers have a keen eye for detail; they might catch misalignments and incorrect graphics that a good QA team might never notice. HTML text might be placed incorrectly; a photo treatment may have been misapplied. Have the art director or designer give the site a thorough look on both Mac and PC to ensure quality control.
HTML check. Confirm that all tables, cells, and graphics are lining up properly. Your team may not have had enough time for ample tweaking. After QA is in full gear and fixes are being implemented, let the HTML team check once more that the site is visually working on both MAC and PCs. Sometimes QA fixes alter/wreck code.
Functionality/engineering check (if applicable). Confirm that all functionality is working in accordance with the technical specifications. Make sure that database integration is complete and that all transactions can be accomplished on the live server.
Content check. Confirm that the headlines are reading as headlines, that body copy reads like body copy... you get the picture. Make sure that the content formatting was appropriately applied by the production team and that everything is lining up as expected.
Client approval. Making sure the client sees and approves the entire site prior to launch might seem like an obvious check-off item. Surprisingly, it is often the case that, although the redesigned site has been signed off on by the marketing department the entire time, the CEO or advertisers who need to approve the site before it goes live may never have seen the final site. Sometimes it is appropriate to wait until the last possible moment to get the approval from the highest level; sometimes this delay causes chaos.
There are bugs and then there are big bugs (sort of the difference between a harmless little earwig and a thumb-sized Palo Verde beetle). Big bugs are showstoppers errors that simply cannot go live. These errors have to get fixed before launch (for example, the home page loads incorrectly, a pull-down menu crashes IE, the frame sets are mistargeted, and so on). As you track bugs, prioritize. What are showstoppers? What can get fixed in an iterative approach in the first week of launch? Sometimes the launch date is set in stone, and you do not have the time to fix all bugs. Prioritize and slay the showstoppers first. The rest can wait a few days.