Policies
Once infrastructure has been set in place, teams can move forward with creating policies that will dictate how this infrastructure will be used. The team must set internal standards, follow best practices and have strict corporate rules to prevent some of the typical mistakes that introduce security risks into a distributed QA environment.
The first set of policies should cover access restrictions and policies for using shared documents and data.
A lot of the fundamental aspects of these policies are covered when establishing infrastructure, for instance, by using Google Drive for document sharing and establishing a team hierarchy for determining who gets access to which documents. On a policy level, this is extended to ensuring only corporate accounts can access the data. This will also prevent the use of multiple accounts by the same contributor, which often leads to chaos.
The same access rights and restrictions policies can be used for documentation. Having an internal hierarchy can help teams decide that important documentation can only be available for the client and the project manager, for example.
Finally, in an ideal case, an offshore or offsite team is provided with dedicated work devices by a customer or by an outsourcing company. However, most often remote QAs have to use their personal ones. Depending on the project specifics and its network configuration, some approaches still can be used to keep control in this situation. Particularly, the QAs might be required to avoid connecting these devices to unsafe networks, such as undefended public WiFis, and to take responsibility for their work credentials and sensitive project information so that it does not get exposed to any third party.
Processes
The final, and arguably the most important, part of establishing a secure QA environment is a focus on the QA processes. It’s not just what you do to be secure, but how you do it as well. The process aspect of security is where corporate culture comes into play.
No matter how perfect your policies are, you have to make sure teams are actually following them. The best way to ensure it is through motivation, avoiding micromanagement whenever possible. A well-engaged teammate should be interested in the project’s success. Add a clear and complete system of responsibilities, and you are likely to have most of your security risks avoided and any disasters quickly solved.
If the team is new or a clear culture hasn’t been established yet, you can choose to monitor and log some key processes. Even if you do have a good culture, some logging should be conducted in the project network in case of a security incident, such as unauthorized access, some clues could be used to understand the problem. And it is crucial to support versioning for all important documents — with Google Docs you have it by default — so you could always roll back if something important was deleted for some reason.
The balance between trust and micromanagement is going to determine your team’s flexibility. A remote team should maintain a proper balance between security policing and efficient collaboration. The key to success is understanding real risks and taking adequate prevention measures — that is, being flexible!
Challenges and Risks
The biggest risk in any security measure is how closely it’s followed. It is often tempting to ignore formalities to save some time, especially if the deadline is close. Nearly every team has been in such a situation at least once. Of course, it may have worked for you previously. But the price of failure can be too high when there is even a small risk of important data loss or leaks of sensitive information.
On the flip side, building an overcomplicated infrastructure because of inefficient security policies can really slow down a team and hinder individual performance. Time losses or miscommunication caused by poor understanding of roles and responsibilities inside the team can lead to failure to deliver results in time. That is why flexibility and team engagement matter.
Without flexibility, the QA team might be too rigid to fit the client’s policies. The client’s wishes and policies should be followed, even if that means relying heavily on micromanagement.
However, a client’s security policy is the bare minimum of what a distributed QA team should go for. If the team members find that the client’s policies are lax, going a bit further than what’s been requested can help out in the long run.
Our remote QA teams intend to keep important data in test environments safe so they always bring up any problematic situation or loophole they find, and make sure that the customer is informed about the risk. It is our team’s responsibility to avoid breaching any important security rule while maintaining high output and efficient QA processes.
