Building interfaces is a touchy area. Behind the scenes, you have ever-changing JavaScript libraries and naming schemes that can ripple throughout your application’s architecture. Then you must take into account the multitude of operating environments and the way they render your interface. A user on Windows looking at your application on Internet Explorer 10 must have the same experience as the user on a Mac with Google Chrome.

With all of these variables to manage, implementing a sane quality assurance process can quickly become a nightmare.

To maintain the sanity and to keep our QA folks from skipping town, my company has adopted a number of processes that streamlines software testing.

Set expectations up front

The biggest problem I’ve seen QA face is not knowing what the end result should look like for front-end development. Without any guidance, who’s to say if that button should be green or if the header needs that bottom border?

Transparency is key. Just like designers appreciate seeing their beautiful visuals coded correctly, front-end developers desire to have QA find the bugs that will ensure their code renders elegantly across platforms. But we must help our QA friends by being explicit with interface definitions.

Oftentimes, I help QA by providing interface screenshots, color scheme guidance, and other working examples. These samples give QA a reference guide to ensure stylistic nuances render appropriately based on the user’s device.

Develop a test matrix to track testing

Testing software is an iterative process that involves multiple rounds of fixing and reviewing. To track these activities, a document should be created that identifies the test areas and tracks progress.

On my team, we call this a test matrix, which is nothing more than a simple spreadsheet. For front-end tests, the matrix is broken down into different scenarios, expected behaviors, and tested environments. As a developer, I can open this document and quickly see where the application is passing or failing.

The main benefit of the text matrix is that it manages the test and tracks what’s being fixed. Without this document, the developer would be blindly fixing things and the QA tester making multiple unnecessary trips through the software on bug hunts.

Un-silo the QA department

One of the keys to a strong QA testing team is encouraging a cohesive team dynamic within the entire engineering department. This means letting QA testers interact directly with developers. I’m always open to fielding questions from QA because clarity in their job means faster, user-focused fixes on my end.

If your team is stuck in silos, it’s time to break down the barriers and let team members communicate with each other. Direct, one-on-one communication has been instrumental for my team.

Enact a project management process

Integrating the QA team into your project management methodology is critical. To organize our team, we ensure QA engineers are assigned tickets through sprint planning and that their status is known through daily standups.

Managing tickets has been somewhat of a challenge for my company. At one point, we were creating separate QA tickets to go along with development tickets. Once the developer finished their ticket, they notified the QA team. This quickly led to a messy process, where tickets would get lost in translation and the QA team basically trying to manage their own sprint. Instead, we’ve now chosen to integrate QA more tightly by reassigning the development ticket directly to a QA engineer. This has reduced the redundancy of multiple tickets and has allowed the developer to maintain a connection to the work the QA team is performing.

Set QA up for success

Software development doesn’t end when the last piece of code is written. More often than not, developers don’t spend enough time thinking too hard about quality. If the code is written and does what the specification says it should do, then the work is done—right?

Wrong. Developers must shift their mindset to the quality side of the development process. Just because code is written and working does not mean it’s done. Code must be developed to meet the engineering department’s quality requirements and it must be developed to a point that the user’s safety and experience is not in question.

Developing this culture requires maintaining a codebase that is compatible with QA tests. For example, QA engineers often rely on CSS class names and IDs for automated testing. That means the front-end engineer cannot constantly switch up naming conventions. The front-end engineer’s responsibility is to create a strong, consistent naming scheme that scales with the software and does not regularly interfere with the testing process.

And finally, the engineering department as a whole needs a QA process plan made available to all developers. This plan could be as simple as a Github document with a bullet point list of the steps and procedures engineers must take a move a ticket through testing.

Quality assurance can easily be neglected in the software development process. With unending tickets and deadlines, who has time for testing? But this can be a dangerous game, where ultimately, the user is the loser. Setting aside time to ensure the QA team can thrive is a wise investment and extends to all reaches of the engineering department, including back- and front-end.