Quality Assurance For Developers

When fostering a culture of quality assurance, we’ve traditionally put a lot of focus on test models and breakpoints.

Equally important are the daily habits that encourage more thoughtful production. A lot of time is spent developing a website, and there are countless decisions that are made during this process that can facilitate a better end result.

With that said, here are just a few techniques that I’ve used to help me build better websites. I’d love to hear how other people approach development with a mindset of quality assurance.

Develop in multiple browsers

While browser testing is important in its own right, it should really be happening from the get-go. My pattern is to work through each new feature or section that I’m building in Firefox, to lay the functional groundwork. I’ll then immediately switch over to a rotation of different browsers as I finish up the functionality. If I’m applying visual design, I try to constantly be changing browsers the entire time.

Doing this before moving on to the next section tends to make browser testing at the end of the project less traumatic. The actual workflow process for this will be different for everyone. Certainly, the easier the access to different browsers, the more practical this tip is. Virtual machines are great for their immediate availability, using a program like Parallels. I’ve also had success with the tool CrossBrowserTesting.

Mimic the client/user’s experience as much as possible

When building a site we have a “developer view” that allows us to access certain utilities in our CMS. While this is necessary for setting up some functionality, it can also mean that developers may never see the site exactly as the client or end user would.

This is easily remedied by using the different user variations while testing other things, like functionality or visual design. Mix it up. Make a list of all possible ways that a site can be seen (as the client in administrator mode, for instance, or as a store shipper logged-in to make an order). Mimic these states as much as possible while developing the site. This will let later test plans focus on actual user-specific functionality.

Make holding/test content contextual

Particularly in early stages of the project, a site is often build with nothing but test content and images in place. As a standard, we use “Lorem Ipsum” holding text to show where copy will go. For images, we use generic placeholder images. It is only after the site is built and visual design applied that actual formatting will be added to the mix.

This is fine for comping purposes, but by making things a bit more specific, some general issues can be readily noticed and addressed. For images, I try if possible to make thumbnails look like thumbnails, with the correct alignment and rough size. This ensures that lists will render correctly with no blatant braking/alignment issues. If an image is going to be a banner graphic at the top of the page, make it work that way. Holding text can be made contextual by simply adding the description of the text before the generic copy. This will ensure, for instance, that abstract fields are showing up in the correct place, or that the “location” value for upcoming events is actually showing up.

Build everything as if it is the final product

This is similar to my last point, but I think is worth mentioning. It is very easy, particularly at the very beginning of a project, to simply put pieces of functionality in place and “fine-tune” later. I’ve had much more success when I’ve made it a point to always keep the site in a usable, organized state. There is less confusion when the client is reviewing functionality. Content entry can happen sooner and requires less explanation. Most importantly, other members of the team reviewing the site in progress will have an easier time catching bugs before they become major issues.

Simply spending a little extra time thinking about every decision you make means quality assurance really does start immediatly. Ask yourself: when the client looks at this data relationship in the CMS, will it make sense? Do the field names you’ve assigned really represent the field’s contents? Even if the final design has not yet been applied, is everything clearly and logically represented on the front-end view of the site?

By making these decisions early, a groundwork is set for a solid end product. The biggest gain, however, may be more subtle. By being mindful of how everything fits together even at this early stage, a sense of quality is naturally imposed on the project, encouraging everyone involved to follow suit.