Who is Doing QA?
Written By: Shane Clark on September 20, 2017
QA or quality assurance is critical to being able to deliver a solid product no matter what the product is. There are many devices and browsers that all may render differently. Therefore, QA is even more critical when it comes to web development. On person should be responsible for the final sign off on a task or project. Establishing who this person is up front is critical to the project’s success.
Who is Best Suited for the Responsibility of Final Sign Off?
There is one person who understands both the client’s needs and the website. That person is best able to take responsibility if something is done right. In some business relationships, the developer is not in communication with the end client. In this case, there should always be a “third party” that takes up this responsibility. This person is the one in direct contact with the client.
Benefits of Third-Party QA.
You Don’t Alienate Your Developer.
No matter what company or part of the world a site is being worked on, stuff will always get missed. This is true in Mountain View, California (Google) as well as in Redmond, Washington (Microsoft). With each project, there is someone who could potentially be “mad” if there are errors or bugs. It is a good idea to put another person or entity between that person and the developer. It takes a lot of stress off the developer. However, if work is being sent back with obvious bugs, this will sour the relationship between development and QA.
It’s Better to Have a Second Set of Eyes.
Sometimes being too close to a project or task (as the developer would be), does not give a good perspective. This is another reason to have a 3rd party or person doing the QA and signing off. The 2nd set of eyes on a project or task is extremely beneficial to delivering a quality project. Even in smaller or one person “firms” it makes sense to have a second person doing QA. However, there may not be any third parties available. Or the ones that are, are in direct communication with the “end client”. These are the only cases where it would make sense for a developer to be doing his own QA.
The Developer Does Not Always Have All the Information.
In many cases and in almost every case for myself, I am not the one in direct communication with the “end client”. No matter how well a scope of work for a project or task is defined there will always be functionality and design quirks that are better understood by the person talking to the “end client”. The person in communication will be able to understand the full nature of the request to determine if this was what his / her client really wanted.
Familiarity with the Website.
A good argument for “third party QA” is the developer may not be seeing the site on a day to day basis. As time passes, even on the sites I have built myself, I become less familiar with the original functionality and design. Clear instruction along with screenshots goes a long way to being able to re-familiarize with the issues, but at the end of the day, the person managing the client / website is more qualified to decide that it is good than the developer.
QA is Not for Free.
The time it takes to review and QA a task or a site should be considered in addition to the actual development time. The larger the project, the truer this becomes. My default model for “freelance” work models my life as a Phoenix developer in the past. I do the development, and responsibly send it over for review to the person tasked with that duty.
In cases where it is a “retail” client or no QA is provided, I try to be as clear as possible with expectations. When I do a quote, I quote for project development and fixes based on the feedback I get from the entity responsible for QA. Meaning, on a 40-hour website build, that has been properly QA’d by an agency, another 20 hours should not come back after they have shown their client the link for review. When an agency sends back a website link for review, I expect / account for 10% remaining of the time quoted. If the agency is not aware of these end client changes, I won’t know either.
Tools For QA:
- Annotated Screenshots to a URL
I believe annotated screenshots and video are the key to clear communication. As dynamic as the web has become, I have added “annotated video” to a list of important tools needed to deliver quality work. I use Snagit by TechSmith for all my Screenshots and video casts. This is very easy to use and reasonably priced ($49.95 as of 09/20/2017). Another good tool made by the same company is Jing, which is the free version of Snagit with a few less features. Both Jing and Snagit are easy to use and will make both video and screenshots. - Browser / Device Testing
Another essential tool is a browser and device testing platform. I have looked around and I have not found anything as reliable as BrowserStack. It is a paid tool at $300 per year for a single user. While this might seem a bit pricey, you get what you pay for. Without BrowserStack, I am very limited to the browsers or devices that I can use to see any anomalies / bugs.
