Content Entry and Quality Assurance

Internally, we call content entry "integration." This term works on a number of levels- the integration of content in to a functional system, as well as the integration of our clients into the working process in more significant and real way.

While we have several specific Quality Assurance (QA) steps in our process, as any development company should, I believe that content entry is one of the most effective and important QA efforts for any project. Typically, this is the point in the process when our clients are able to fully experience the reality of their site for the first time. While they have worked closely with our team on prototyping and designing the site, the process of actually creating content and then using the content management system to enter it is when all the "dots" are connected and made real, and often the first point at which expectations are clarified. You see, no matter how thorough a prototype is, sometimes there are concepts or needs that cannot be communicated until you are immersed in an actual working and producing environment.

This is similar to the "blank-slate-shopper" phenomenon: Have you ever seen a review of a book and thought that you'd like to purchase it, only to find that the next time you are actually in a bookstore you have no idea what you want or where to start? This is because we tend towards reactive rather than proactive thinking. We hear about something and react to it with, "Yes, I'd like to read that," yet when we get to the store and are surrounded by thousands of books, we react to them all by loosing focus. (Of course, if we had drawn up a list in advance, we'd be in good shape!) While we find the prototyping phase, being a proactive step, to be extremely effective and critical to our process, we use subsequent rounds of QA to catch any results of reactive thinking during a project and know that the process of content entry will also do the same.

QA does not ensure that a project will be 100% bug free. While some bugs are due to sloppiness or haste and can be prevented by thorough QA steps, others are the result of unforeseen functionality conflicts that may not become evident until a site is being used, despite the best intentions and foresight of the programmers. As with any development project, bugs like these should be expected and encountered with patience (this goes for us just as much as our clients). While we hope that our many stages of QA will mitigate the frequency of any bugs occurring, we are definitely not surprised when they show up.

Once we've gotten to a point of resolution with integration and QA, we can finally reach the finish line and go live!

In my first newsletter, You're Using RSS Now...Right?, I concluded by saying that "Though this all may seem very daunting, it's also going to be fun." I was talking specifically about keeping up with information overload using RSS, but I think I could make the same conclusion here, too.

A huge amount of work goes in to a web-development project, but not in vain! Aside from the return our clients expect on their investment, a well conceived and successful project will instill a sense of accomplishment and satisfaction in all those who are involved. It will also be a learning process, involving getting up to speed on business, technical and relational issues for everyone involved. In fact, our experience has been that during this intensive process, we also get to know and form bonds with our clients that lead to strong, productive and successful working relationships for a long time to come after the initial project is complete.