Which QA Best Practices Fit Your Team’s Product Needs?
November 11, 2020
Originally posted on Built In Colorado, for the full post please click here.
Quality assurance best practices differ by company and product — how do you know your team is implementing the right testing processes?
For professional services and software company Trineo, QA testing means taking a purposely simple approach. “As we approach the end of our sprints, we keep a close eye on how tickets are moving, what the likelihood is of any tickets missing the cut, and ensuring that whatever code needs to be tested and confirmed as working is able to receive the attention it needs,” Lead Engineer Michael Ovies said.
At IntelePeer, a cloud-based software company, regression testing is essential for QA. “We execute regression testing for each software prior to production release so we can ensure existing customers not only receive the latest and greatest product updates but also that the system still performs to 100 percent specifications,” Director of Quality Assurance Ricky Otero said.
Although QA testing is determined on a ticket-by-ticket basis at software company Documoto, it does require a standardized set of processes. “Our product team does a great job of making sure tickets have clear and concise acceptance criteria, and then engineering makes note of the areas of code that were touched,” Senior QA Engineer Melissa Bruckner said.
Built In Colorado caught up with Ovies, Otero and Bruckner to take a closer look into their QA practices and how it helps them deliver the best possible product to their customers.
Trineo, a professional services and software company, focuses on freeing legacy data, delivering future-proof API platforms and developing innovative customer and employee experiences. In addition to standard QA procedures, Lead Engineer Michael Ovies cites the team’s culture as vital in ensuring changes are communicated.
What’s the most important best practice your QA team follows, and why?
As a consultancy, our direct control over QA processes can vary from client to client. In my current engagement, we have a number of QA counterparts who test absolutely everything produced by the developers. As great as automated testing tools are, or having high test coverage for a codebase is, in my opinion there’s just no substitute for a human trying to break your work!
While our testers are knowledgeable of the system as a whole, we also work to keep them in the loop alongside new development. This approach has worked out well for us, as their overall knowledge of the system can allow them to pull levers and push buttons that we, as developers, may not have anticipated.
How do you determine your release criteria?
Considering the number of strategies possible for production releases, we’ve worked to keep ours purposefully simple. We do production releases at the end of each two-week sprint. As we approach the end of our sprints, we keep a close eye on how tickets are moving, what the likelihood is of any tickets missing the cut, and ensuring that whatever code needs to be tested and confirmed as working is able to receive the attention it needs. It’s at this point that Trineo can really shine, in that we aren’t going to rush out half-baked, unacceptable code that doesn’t meet our own standards. At the end of the day we need stable, healthy code and systems.
How do you ensure the QA team stays up to date on shifting requirements, and how do you plan ahead to ensure changes are handled smoothly?
With a healthy team culture! Obviously, changes happen, and some initial uncertainty finally reveals itself or an overlooked detail rises to the surface. In my opinion, the attitude of the team in general can be tremendously impactful on how these changes are both received and acted upon.
Whether it’s shifting requirements or planning ahead, the name of the game is communication. Recently my team had to pivot a bit due to some unknowns that came into sharper focus as we started development. Handling something like this well really comes down to coordination with the project manager, stakeholders and QA team. Don’t assume anything, and work to make sure everyone is informed of the changes and any impact those changes may have. Sometimes changes are more drastic than others, but regardless of size, calmly evaluating the changes and determining the near- and short-term steps is a recipe for success.
For the full blog post, please continue reading at Built In Colorado.