SLA - The who, what, where, when, how and how much
The SLA or Service Level Agreement defines precisely or “legally” who does what, where, when, how and how much. For example, the SLA is a working agreement that defines the work that will be done, who does it, and what the schedule and delivery requirements are to meet the legal contractual obligations. You’ll want to ensure that the SLA is understood and agreed to by both sides before work begins. Granted, once the work starts you may find changes that need to be made. SLA’s are part of the continuous improvement process and should be updated as required to meet the business needs and enhance the strength of the relationship.
Choosing the resources best suited to your needs - QA Skill LevelsQA tester skill levels vary as do development skills. It’s important to understand which level you require and if you want a mixture of experience where each fits within the SLA. For example, if you need detailed security testing then you’re going to need a team of security testing experts. Or, it may be possible to get a mix of QA skill levels 50% expert and 50% at the intermediate level. If you plan to do a usability test cycle, then it would benefit you to vary the mix of experience levels for a more thorough test coverage. You could hire 25% expert, 25% intermediate and 50% beginner level. With this combination, you may find more visibly apparent defects that affect customer usability immediately after a release. Why? Many testers with less than expert skills are adept at spotting workflow, spelling and other display issues, as well as parts of the application that are confusing to end users because they are the most similar to end user audiences. End users are not always expert users of an application and skill levels vary widely. You may increase test coverage effectiveness by hiring QA’s at various skill levels.
Continuous process improvement between releasesIn order to keep the working relationship working as seamlessly as possible, remember to check in after each release. Hold a retrospective or discuss what parts of the SLA or work process can be improved? Similar to an Agile retrospective, select 1 to 3 of the ideas that improve the team’s productivity or the application quality. Assign team members to champion each idea and track the progress. Repeat after each release. Changes can apply to communication methods, testing methods, or debugging/troubleshooting improvements.
Change management & CommunicationCommunication is king in software development teams. When a team communicates well, they are more efficient and productive. When deciding to outsource testing, make sure to develop a communication channel. For example, if schedule changes occur there needs to be a list of names whom to contact. When functionality changes, those changes need to be communicated to the testing team. Designate a resource to handle both or split them up depending on the expected volume of changes or questions. Getting issues or questions answered by a single resource point is imperative to a smoothly functioning team. Keep communication consistent and moving through defined channels for the best testing results.
Intellectual Property ProtectionConsider using a confidentiality agreement for outsourced resources. You’re hiring bright tech users, which you want to make sure your application’s design is protected by a non-disclosure agreement. Your application company may have an existing document that can be updated, or forwarded as is. Check with your software testing services provider to determine what they can provide and what you need to provide. Make sure that your business assets are covered.
SecurityIntellectual property protections secure your business’s non-physical assets but also plan to secure your hardware assets. Servers, firewalls, databases all need a security a new plan or an adjustment to an existing plan. Ensure authentication functions as expected for both internal and external users. Many times, outsourced teams encounter processing delays that excessively slow performance which hinders their productivity. Part of your security plan is also to ensure your outsourced resources can work productively on your secured network. Make sure outsourced team members can work.
FlexibilityIf you expect requirements to change frequently, make sure the SLA and the testing team is flexible. You may need to consider a sudden change in the type or volume of testing. Do you need more? Or do you need another type of testing - like performance or load? Testing service QA teams can typically deal with variable and frequent changes.
Physical Location (access to environment)Where are your testers located? Are they global or condensed in a specified area? It’s important to know where your testing resources are located so you’re aware of any impacts to their use of the test environment that may influence testing results. If your application is only relevant to Canada and the U.S. for example, it makes sense to choose a team of testers in those countries. The same applies if your application is global, pick a team with representatives in the parts of the world that interest you. Remember to consider all types of customers and their location to ensure the testing provides as much business value as possible.
Device access and definitionMake sure you determine what devices you need to be tested, as well as the settings or configuration required. In other words, what options do you want to be tested? Are your application web and mobile or mobile only? If so, what are all the device types and configurations? Ensure the testing team can access the devices they need. One advantage of outsourced testing teams is that frequently you gain automatic access to a larger variety of devices and configurations. Testing services providers may also provide access to testers to a large number of emulators as well as physical devices for testing.
Requirements understanding - make sure you communicate the test objective(s)One mistake that occurs time and again is expecting a testing team to test without knowledge or access to acceptance criteria or application requirements. If you don’t deliver acceptance criteria or application documentation internally, then consider providing training or concise, accurate documentation to the testing team. If you don’t supply the expected results, it’s difficult for any tester to find a large number of valid defects. Understanding test objectives are critical to delivering a higher quality test execution.