5 QA Tips for Developers
As a developer, building and maintaining quality software is part of the job description. Unfortunately, it’s not unheard of for developers to push quality control onto the QA or testing department. But anyone who has coded for a while knows that it’s much easier to build in quality as you go than to raise quality on an existing project. Below are five ways to build and maintain quality on your projects.
1. Check Your Work
Have you ever written some code, maybe even written some automated tests, merged it, deployed it, and walked away with a song in your heart and your mind already elsewhere? Did you forget to actually look at what the code does in the final (or as close to final as possible) environment? Oops.
Before you submit a pull request (PR) (or merge a PR, or deploy), check that your code does what you think it does. Use a staging environment, look at your work in supported browsers, load test it if necessary, just make sure that at minimum it does what you think it’s supposed to do before you ship it to the next step in the process. Test it and ask yourself:
Does it meet the requirements?
Does it match the architectural and/or visual design?
Does it follow the baseline code best practices for the team or project?
Are the automated tests passing?
Does it work on the primary supported browsers and breakpoints?
Do errors appear on form validation and if so, do they make sense?
2. Advocate for the End User
We’ve all been there: the end user is using your app the wrong way! Well, maybe they are. Or maybe they’re using it that way because that’s the intuitive way to use it for someone who isn’t a web developer. Are they using it “wrong” because the messaging is unclear, the interface is clunky, or the colors are drawing them to the wrong location? How the end user navigates your site or uses your app may make no sense to you, but it’s your job to try to get in their head and continue to advocate for them. After all, the end user is really the only user that matters.
You may be thinking, “But wait, isn’t this the UX department’s job?” And yes, it is! But it’s also your job. User experience is crucial to an app or site’s success in the wild, so UX is the entire team’s job. You may have devoted specialists and that’s awesome, but it doesn’t get you off the hook.
So, how do you advocate for the end user? It can be hard to put yourself in the shoes of someone from a completely different walk of life, especially if they are much less technically minded. If you’re finding it too hard to step outside your comfort zone and think like the end user, refer to your personal contacts. Who among your family/friends/coworkers more closely resembles your end user profile? How do you think they would use your site or app? Throughout development, keep the following in mind:
How does the app/site/feature function on mobile? Is it usable? Is it frustrating? Is it easy to find what you’re looking for?
Remember that websites are scanned, not read. Users jump to the first readable element on the page. If you’re scanning the page, is the first thing you notice the most important?
Content hierarchy needs to visually make sense. Is it clear what the title is? The subtitle? Is it clear which content relates to which element (header, image, etc)?
Is your site accessible? Does it support keyboard navigation or screen readers? Is the content readable for colorblind users?
3. Practice Peer Review
On top of the cognitive biases inherent in being human, you will have developed certain ways of doing and thinking about things that are unique to your personal experience. This is the dark side of all that brilliant coding and creation you do: you make mistakes, just like every other human on the planet. But if we are all fallible, how do we prevent those mistakes from getting in front of the end user?
In the words of Atul Gawande: “Man is fallible, but maybe men are less so.” There will always be defects in a software project. However, with some humility and the help of your super-smart peers, you can drastically reduce the number of defects that end up in front of the end user. Peer review (also referred to as ‘second pair of eyes’) is the process of having someone else check your work. There are many ways to practice peer review, including:
Formal and informal code reviews
Pair programming
Rubber duck programming
Manual and automated testing
Exploratory testing sessions
Informal chats
4. Refer to the Style Guide
You should not need to guess at font size or whether an element should have X or Y padding. The style guide probably has that information in it. If your project doesn’t have a style guide, designate or make one. A style guide can be as simple as a collection of guidelines that everyone on the project knows about and agrees to follow. It should specify:
Colors
Font sizes, types, and weights
Vertical and horizontal spacing and padding
Line height
Icon and image sizes
H tags
Breakpoints
Referencing the style guide throughout the project will result in a cleaner, more consistent site. It will also make the site easier to maintain. A site that has multiple developers guessing at styling elements usually results in a lot of unnecessary rework down the line to make the look and feel consistent.
5. Keep SEO in Mind
SEO is crucial, especially for websites or apps that serve as a marketing tool for your client. You may not be an SEO expert but that’s okay, you don’t need to be. A good quality app or site should be able to be improved, but not require rework of the features you just built. With the goal of quality in mind, use the following guidelines:
On every page, there should be:
One (and only one) H1 tag, no longer than 70 characters
One meta title
One meta description
Structured data, when appropriate
All images should have alt-text
Internal links to related pages - don't rely only on the main navigation or footer menus
If you build quality into the product, you’ll have less to fix moving forward. And the end user will be happier, which is really what web development is all about!