We’re more connected to one another than ever before and this affords opportunities to collaborate with people from across the world just as though they were right next to us. That said, there are some underlying difficulties that make collaboration troublesome from a testing and QA perspective. Some of our past blogs outline the details around why it’s important to have testers who represent your user base from a cultural and societal perspective, but in many fewer words, the concern is around needing to ensure our applications are tested in the same way they are going to be used. By using people who most closely resemble our user base we’re naturally able to produce a better product without unnecessary training or experience.
Similarly, we also find that it’s important to have testers who can write test cases that are similar to how our future users will actually use the application, and this is easiest done with testers who share cultural ties to our users. So while your team might be remote, we highly recommend that your QA testers at least have local or regional ties to your user base.
With that in mind your QA testers are going to need the help of some frameworks and processes while they’re remote to ensure your software remains audit-ready and your traceability is still intact. Let’s go over our top tips for ensuring software traceability when using a remote team.
Use a standard naming convention
Standard naming conventions are essential for overall organization within your SDLC. Whether you have a formal QA program or you’re just getting started it’s going to be critical for your scrum Masters, Developers, or testers to be able to reference user stories or requirements from the past. The best way to do this is by having a standard naming convention across all of the applications you use within your software development life cycle. This way, from the human perspective, it’s commonly understood what each item is. Here’s an example:
Try naming user stories, test cases, or requirements with this convention:
[component]_[epic ]_[feature]_[story description]
This description above is a way to describe the work item so that there is a common understanding of where that work item fits into the larger picture, and it helps us keep everything organized for later audits and review. This obviously isn’t the only way you can name a story or work item, however having some common understanding of what each item is and where it fits into the larger picture is going to do an amazing amount of good for you and your team when it comes time to understand what was requested to be built, what was actually built, and then what needs to be tested from it all.
That’s really the whole point behind having a standard naming convention. So that you can take the one-off items that never really fit into feature or release, but get added in at the last minute and ensure they’re documented and tested fully.
Here where we see a lot of teams get into trouble from audit and traceability perspective. It’s not so much the work items and features that are planned for that later become audit issues. It’s the one-off requests and bug fixes that generally get people into trouble with auditors. Perhaps there’s a lack of documentation from an architecture, help text, and testing perspective for each of these bugs or special requests, but if you lack a way to organize literally everything that goes into a release in a standard way, you’ll eventually run into serious trouble.
Use highly Integrated Systems
It almost goes without saying that using disparate systems means humans are going to be needed to fill in the process gaps, and when that happens, we see an increase in defects. So, as we go through our software development life cycle if we can ensure our tools are speaking to one another automatically and updating each other as humans enter and update data throughout the SDLC we’re going to have a far easier time maintaining traceability.
In reality, this manifests itself such that use-stories, test cases, and requirements are all linked together (at a minimum) or that they update one another automatically (best case scenario) so that all the members of the team (and auditors) have a single source of truth.
A Final Note on Traceability
If 2020 has taught us anything it’s that we’re ALL deeply connected to each other and the butterfly effect is a very real phenomenon. Taking that back to our micro-cosmos of software development and we should conclude that the actions of a tester, BA, dev, etc. are not just linked in the present but we rely on each other to have always done the correct thing because so often we have to retrace our steps and dig back into someone else’s code from 2-years ago, or our own code from 6 months ago. When we do this it’s extremely hard (often impossible) to know all the code dependencies or architecture without the proper documentation or many hours of research (and a lot of prayers).
So, whether you need to maintain traceability for regulatory purposes or not, having a fully traceable system means you have a well-documented system, and that’ll save you and your team a ton of time, effort, and pain for years to follow.
Remember: quality costs money, but cheap is always expensive.
Are you struggling to maintain the quality on your remote team? Use the contact form on our website to schedule a call with us and we’ll help you begin turning around your quality issues.
