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.
Whether it’s shifting requirements or planning ahead, the name of the game is communication.”
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.
Software company Documoto helps equipment manufacturers, their network and their equipment owners to “keep the world’s machines working,” with its proprietary SaaS solution. Communication across teams has been the key to the small company’s success, Senior QA Engineer Melissa Bruckner said, resulting in engineering and product teams being highly integrated during the development process.
What’s the most important best practice your QA team follows, and why?
One of the best practices that we follow is using a manual and automated approach to testing. We are a small team, and it is not practical to run a full manual regression for every ticket completed. We take tickets as engineers, complete them and thoroughly manually test them to ensure all acceptance criteria are met. Once we are confident that the ticket has met all the requirements, we then add in limited automated tests to be for future automation.
How do you determine your release criteria?
My typical release criteria are met on a ticket-by-ticket basis. Our product team does a great job of making sure tickets have clear and concise acceptance criteria. Our engineering team does a great job of noting areas of the code that were touched. I focus heavily on the areas of code that were changed by manually testing. I use existing automation to ensure the rest of the app is still doing what it should be doing.
Communication has been the key to our success. If a requirement changes, we are generally in the know right away to change our test cases.”
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?
Because Documoto is a small team, the engineering and product teams are heavily integrated. This gives us the ability to approach testing early and at numerous stages of development. Communication has been the key to our success. If a requirement changes, we are generally in the know right away to change our test cases. We will also run automation right away on new or changing functionality, so we are aware if the change affects anything else in the application.
IntelePeer enables companies to communicate better by leveraging omnichannel automation and self-service AI and analytics through its cloud platform. To ensure shifting requirements run smoothly, the QA team meets every morning to discuss daily requirements and priorities to ensure each member stays up-to-date on any changes that have occurred, Ricky Otero, director of quality assurance, said.
What’s the most important best practice your QA team follows, and why?
Our QA team at IntelePeer has many practices that we follow, but one of the most important is our regression testing. 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.
Communication from our management and tagging Jira tickets with release and sprint info ensures the QA team stays up to date on shifting requirements.”
How do you determine your release criteria?
Our release criteria is determined by our product management team. The release depends upon the functionality they determine is needed in production at the release date. For example, by acceptance of successful use case completion, that signals to QA that a customer will not be impacted by new product updates from the collaboration of product management, development and QA before each release.
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?
Our team meets every morning to discuss daily requirements and priorities. Communication from our management and tagging Jira tickets with release and sprint info ensures the QA team stays up to date on shifting requirements. We also have a Jira board that contains items or tickets for each release with applicable user stories. The Jira board assists in helping with shifting requirements to see tickets that have been moved to the next release or updated with more information. This information helps us to plan ahead and begin creating test cases for new functionality and existing regression.
