Building Your QA Strategy When Working With Off-Site Vendors
Working with your off-site developers and creating QA deliverables when access is limited.
Sometimes you are unable to perform your own software development and will need to work with either a third-party development group, or maybe even the software owners. When working with off-site vendors, you can run into challenges merging your quality assurance (QA) processes with theirs. This can surface in a handful of ways: access to each other’s requirements repository, visibility to progress, and access to testing documentation to name a few. So how can you implement a sufficient QA process when collaborating with another company?
COMMON ASKS THAT CAN PRESENT DIFFICULTIES AND WORKABLE SOLUTIONS
HOW TO MITIGATE RISKS
When starting projects, holding honest conversations where both sides can set their expectations is key. Without this open discussion, gaps in needs cannot be found and there is bound to be frustration later in the project. Understanding both sides’ expectations of each other seems like a straightforward process, but most times one side will surprise you. Setting these expectations early can alleviate problems later in the timeline. Sometimes expectations can change or needs that once thought were met, are not. This open line of communication is not a one-time thing, but working with each team as needs evolve is a continuous process. If your QA team is already in at this point in the project, great, you’re steps ahead of most. But what if they are not?
NOT DISRUPTING THE PROCESS
Ok, now that we have set needs and expectations, what if another group joins the process? For example, what if your company’s QA team comes in after these discussions have already happened? The off-site developers may have their own QA team, or they may not. How can you now add on without disrupting the other groups?
Everyone wants a quality product, but occasionally QA is brought in later after a project has started. The QA might not have had a say in what needs to be delivered for their success. But as a QA member there are many tools available when coming into a situation where they may not have what is needed and still thrive. Developing processes internal to the QA team can alleviate some of these pain points of missing deliverables and reporting to keep their Test Strategy alive.
Going one step deeper, one common way this can surface is when one side has limited access to the requirements repository. How does the QA team report their progress if their tests are not linked to stories or requirements, and we are not seeing stories move or tasks closed? One option the QA team has is developing a QA scorecard for the team that can communicate where the deliverable is and the team’s progress. Documenting the requirements, mapping them to test cases and aggregating all that into a scorecard lets anyone quickly see the progress their team is making.
Another positive biproduct of making a scorecard in this situation where you do not have access to the repository is visibility into your test case coverage. Being able to see that all User Stories have been reviewed for needs, and tested thoroughly gives confidence in the test plan. Taking this document to business users also delivers confidence going into User Acceptance Testing (UAT). By seeing what was tested and how thoroughly, you will save the business time and cut down on the scenarios they may have wanted to cover.
DELIVERING WITH CONFIDENCE
Working with an off-site vendor where access is limited can be a challenge. But this example of a QA team’s progress reporting is just one way, we at Trexin, have implemented check points to help communicate the testing status, and working towards clear communication of a project’s delivery. By implementing a testing matrix and scorecard, this team has now provided the confidence needed that the project has been designed for their business’ needs and is working as intended. This is just one example of something that could come up when working with an off-site vendor. Open communications and expectations of needs and requirements between your two organizations remains the key to a great delivery.
Contact a Trexin Advisor to learn how we can help you “get to done”.
