The Most Important Person on the Team

While not being the most glamorous or high-profile position, the Quality Assurance (QA) role is the most important person on any web development team, and it doubly so here at Newfangled. Without them, our websites would be riddled with bugs, projects would never get finished on time, and everyone would generally be in a sour mood. Here, I hope to detail out what exactly these QA people do, and why I consider them the most important people in the room.

So what exactly is Quality Assurance? Wikipedia defines this as the “set of activities intended to ensure that products (goods
and/or services) satisfy customer requirements in a systematic,
reliable fashion.” At Newfangled, the QA team ensures that the developer builds the correct features, that development progresses at a pace that hits deadlines, as well reports back to the project managers and the developers on any slips to either scope or budget. With web development, projects can quickly spiral out of control and it is QA’s job to avoid this, or at least make a small impact as possible on scope or budget.

Exactly how the QAs do this involves many different skill sets and character traints, which usually are a rare combination in any one person. The first major skill is to be able to understand what you are looking at in order to see if it looks right and matches up with the client’s expectations. Web technology is constantly changing, and these changes bring in new terminology, interfaces, and tools and the QA has to have the technical acumen to understand the requirements and be able to match that up with what the developer is building. This is a challenging feat but crucial in ensuring the right product is being built.

The second major part of being a good QA is a high level of attention to detail. As with any software project, the specifications of what to build is usually novella-like in its length. Absorbing these exacting requirements and making sure that the software is built exactly how the client expecting demands a very level of precision and accuracy that few people possess. This is not a problem if the requirements are straight-forward, but usually, the requirements can be ambiguous, vague, and, worst of all, contradicting. Its up to the QA to wade through these and check back with both the project managers and the developers to make sure that they are “satisfy[ing] customer requirements.” Manually checking a punch-list 100 items long takes an attention to detail that, personally, I’m glad someone else has.

Photo by guitavares

The most important skill of any QA is tact. QA usually sits in the demilitarized zone, right between the client (via the project manager) and the developer. The client usually needs that feature done yesterday and the developer is fighting some obscure bug that is sapping away his time. Since the QA is essentially in the satisfaction business, they have to make sure that the client (once again, via the project manager) is getting reasonable feedback on progress as well as keeping the developers on task and on time. This requires an extreme amount of tact. For example, the requirements are usually in black-and-white and so whether a bug exists or a feature is implemented correctly is also a cut-and-dry call: it works, or it doesn’t. It’s difficult to have to send an email to the developer that the code he just spent the past three days writing, is not quite what the requirements spelled out (often because the requirements changed!), and then having to turn around and have to tell the project manager to tell the client that to get this software right, a day or two may need to be added to the deadline. The QA is often the bearer of bad news, and it has and go and come from two directions. Having the tact and internal fortitude to handle these two camps is something to be admired.

At the start of every project, we at Newfangled go over with the client
something we call the project anatomy. This details out the steps that
their project will take, from kickoff to go-live. One of the steps at
the end is titled “QA.” This probably should more aptly be named Quality Control, defined by Google

as the “checking the software against a set of requirements and
verifying that the software meets the predefined requirements”, but for
historical reasons, internally we call thisQA. This block of time happens at the end of the project to make sure the full product is what the client is expecting. If the QA
team and the developers have done their job, this should be a breeze,
with nothing more than checking off a bunch of successfully implemented
requirements.

I took a little poetic license in this post in regards to the relationship between the QA and the project managers here at Newfangled. If you check out our employee page, not one person has the title of Quality Assurance Engineer. This is because our project managers and their assistants pull double duty and are our QA. With a small company, people usually wear many hats and our project managers are no exception. Our PMs can be working with the developer one minute discussing the minutia of some JavaScript widget, and then turn around and be on a training call with the client on how to use their content management system. The personality split needed for these two tasks is amazing.

Make no doubt, though, that Quality Assurance is something that happens throughout the project and not just at the end. If our QA process wasn’t involved all the way through the project, the project would be late, it wouldn’t be what the client asked for, and it would no doubt be over on budget.

This post was written partly to explain the QA process is and why I think it is key role of any development project, but also to highlight the fantastic work and effort that our project managers do to not only be the face of the company to the clients, but also to be the grease that keeps the Newfangled engine running smoothly.