How Do You Measure Quality?

By Jennifer Sander, C4T Product Owner

In our day-to-day shopping experiences, we instinctively perform quality checks before we make a purchase. Whether shopping for clothes, fresh food, furniture, toys—we have a sense of what quality looks like, feels like, and even smells like. We can read labels to gather more information about elements that contribute to quality, like ingredients and manufacturing materials. But how do we measure quality when investing in something intangible, for example a software solution?

At C4T, quality is one of our core values, and we have incorporated processes that include multiple checks and balances into our software development life cycle in order to ensure that the quality of our products is—and remains—top-notch.

1. Clean Code Although the term “clean code” is somewhat subjective, it essentially means that the code is simple and orderly, that it can be read and understood by developers across the board—not just the developer who wrote it—and can be easily tested and changed. At C4T, we follow the “Boy Scout Rule”: leave your code better than you found it. We have a multi-layer process to ensure clean code. 
   
   
2. Automated and Manual Testing First, the newly written bit of code goes through a peer review. Can other developers easily read it, and does it work? Second, the development team tests the code locally on their machines, then does one simple test run in the QA test environment. Alongside that, developers write so called integration tests to verify a given case runs smoothly end-to-end. Third, our quality assurance engineers (QA team) take a deep dive, testing the new code against requirements, using use cases based on actual user stories. Fourth, our QA team do regression testing before putting the newest version into production, to make sure the new code works in harmony with existing code. Our QA team even reaches out to our Customer Success team to assist in regression test runs, as they have the most interaction with our customers and a keen eye for detail. Lastly, we encourage our customers to run the new functionality through User Acceptance Testing (UAT) before going into production. 
   
3. Documentation, Documentation, Documentation We subscribe to the “bus factor”—in case the developer gets hit by a bus, will team members and end users be able to understand the critical components of the system? Naturally, we avoid stepping in front of buses, however we aim to document every stage of development so new team members can quickly and easily get up to speed. We require use cases and technical descriptions to be documented in Confluence, our documentation hub, before QA begins testing. If the user stories aren’t clear, QA will come back to the development team to add details to the documentation. 
   
   
4. Exceptional User Experience If our users aren’t happy, then we have not been successful in our endeavor to provide solutions that simplify the complicated world of customs, excise, and international trade. That’s why we have brought in UX specialists to work side-by-side with our development team to ensure new features and functionality are intuitive. Then, everyone who works in a non-development role at C4T test drives the system, reporting oddities and entering feedback into Jira, our issue and project tracking software. Again, our Service Desk team plays an important role in UX testing, as they are the people who will be training our customers on the system. This all-hands-on-deck policy helps ensure that we are not unknowingly making concessions in usability and that the quality of our software is not compromised just because the code works.

These are the primary steps we take at C4T to produce quality software—however the true test is how our customers react to our solutions. Visit our testimonials page and see if you agree that our process is working to keep our customers happy!