We’re fortunate to have a dedicated QA team at Barrel, but in reality, quality is everyone’s responsibility. Under the old model, the developer would write code independently and the QA analyst would unleash a fury of tests. The underlying tone would often be antagonistic, as the developer assumed the QA tester was overly critical and the QA tester would get frustrated with buggy code. Both parties would forget that they were actually on the same team.
The traditional method assumes that QA is a reactionary process. In reality, QA is also a mindset that is preventative. If bugs aren’t implemented in the first place, teams can save hours in filing and managing bug reports.
In fact, when JIRA, Atlassian’s popular bug-tracking platform, kept development and QA separate, 100% of stories were sent back for rework. It didn’t mean everything was broken, but lingering issues needed to be fixed. When developers learned to test their own work, the rejection rate drastically decreased to 4%.
The QA team does have its place in testing for breadth, but developers can also bring testing to the table. Below are six easy ways for developers to impress QA testers.
1. Reference the QA Checklist
Developers, QA testers are not trying to trick you into making mistakes. We want you to write the best code possible. At Barrel, we maintain a QA checklist to cover design, content, mobile/tablet, performance, and SEO. For example, the list covers favicons, meta descriptions, and 404 page styling—details that are easy to forget.
We’ve also documented common browser and device-specific bugs. For example, some browsers default to double arrows on drop-down menus, and IE 8 and 9 don’t support transitions. Think of QA as an open-book test. Together, we can use these checklists to prevent bugs from being written.
2. Review the Functional Specs
While the QA checklist can be applied to any project, functional specifications are detailed instructions of how a particular site should behave. It lists possible user actions and desired responses. It also describes events that should not happen and fields that need to be editable in the content management system.
Scenarios can range from simple (navigation bar disappears on downward scroll) to complex (breadcrumb navigation changes based on the previously visited page, but the first breadcrumb shouldn’t be clickable). Again, functional specs are part of the open-book test, and you can guarantee that QA will hammer these scenarios.
3. Cross-Test on the Actual Browsers and Devices
Modern versions of Chrome, Firefox, and Internet Explorer have built-in tools for browser and device simulation. They’re convenient, since you don’t have to switch machines or e-mail yourself screen grabs. However, they offer a false sense of security. Simulations apply a general set of rules but don’t account for OS or hardware. I can’t name the number of times a site looked great in simulation but suffered on the actual platform. I’ve even made the mistake myself, when a site was fully functional in an emulation of Internet Explorer 8 but crashed on the real thing. Also, nothing can replicate the experience (scrolling, tap targets, or squinting) of a mobile device. That’s why it’s important to test on the actual environment.
4. Populate Fields as You Go Along
Until a site has actual data, you’re looking at a theoretical framework. Yvonne, our UX designer, touched on this blindspot. As developers build back-end functionality, they should populate the content management system with a couple examples of relevant data to see how the front-end reacts. If the CMS contains several options for formatting, do those combinations work? How does long text wrap? If the site is supposed to parse data, is it happening correctly?
5. Provide Error Validation Messages for Fields
If data needs to be entered in a specific format, it’s helpful for developers to note instructions or limitations (preferably in the CMS itself). Without this documentation, QA testers might assume that functionality is broken when in fact the site is working as intended.
6. Make Yourself a Ticket
I’m always impressed when a developer files a bug report so I don’t have to. Developers know their code intimately, so why not take the initiative in noting what still needs to be implemented? When developers have ownership of their tickets, they’re more likely to complete them to satisfaction. However, they should also remember that all project members need to understand the ticket, so no shorthand please.
Conclusion
The best QA starts early on in a project, and developers are a vital part of the process. By adopting a QA mindset, developers can improve their code and save time in the long run.
Illustration by Andres Maza.
