Issues with the Software Testing Outsourcing

Improper and ambiguous documentation is one major problem that can make the outsourced testing a difficult task. The testing team will develop their test cases by understanding the requirements (Baresi & Pezze, 2006). So the Software requirement specification (SRS) document must be precise and unambiguous. Some of the questions that should get answered by reading the SRS would be (Ramesh, 2004):

1. What are the modules (sub systems) that make up the system?
2. What are the inputs and outputs of each module?
3. What is the business logic in each module that transforms the inputs into outputs?
4. Are there any external industry standards that the software should adhere to?
5. What are the interfaces between the modules?
6. What are the external interfaces that the software should present?

These questions will help the external testers to understand the software in a better way and can plan out the strategy to test the product. The effectiveness of the SRS can be judged if the testing team is able to prepare a Traceability matrix, which is a mapping between the requirements and the test cases (Horch, 2003). Understanding the SRS is also important when the Black box testing (testing a specific functionality as an end user) and Integration testing (testing the functionality of the module as a whole) is performed. In order to perform the white box testing which is primarily to test the code, its logic, conditional paths the design document plays a crucial role. Class diagrams, Data flow diagrams, and Sequence diagrams, help the testing teams to develop automated test cases to perform the tests. In short the documentation plays a crucial role in ensuring that the outsourcing team will be able to perform a good testing.

Lack of face-to-face communication is always a serious issue outsourced jobs where the two teams (developers and testers) are sitting in different physical locations. The client company might not be able to put their point properly when communicating via emails or phones. To make the things worse, the two teams might be speaking some other languages.

One of the main reasons why American companies generally outsource their software-testing task to India is because Indian engineers are well versed in English communicating with them is easy. Documentation, especially design documents if written using UML standards can be useful in scenarios where the two teams speak different languages to explain the software design efficiently. Since documentation seams to play a crucial role to make the two teams to understand each other properly, companies have started enforcing strict policies for documentation. The companies have defined standards about the level of documentation that will be done before the software can be considered as complete (Horch, 2003).

 In case the two companies are geographically separately like in case of American client companies and Indian outsourcing companies different time zones is another problem. The twelve-hour time difference makes it difficult for the testers and developers to find a common time to interact. Also any issue if reported by Indian team in the morning can only get addressed during night when the developers in the American company are up. So the resolution of issues can get really slow and time consuming. Sometimes the network infrastructure becomes a limitation when huge data has to be transferred between the two locations. Imagine a scenario where the client company wants to transfer their sample database running into gigabytes to the testing team over a low speed network. It will take days to get the transfer done.  

References:

Baresi, L. , & Pezze, M. (2006). An introduction to software testing. Electronic Notes in Theoretical Computer Science, 148(1), 89-111.

Ramesh G. (2004). Managing global software projects. New Delhi: Tata McGraw-Hill.

Horch, J.W. (2003), Practical guide to software quality management. Norwood, MA: Artech House Computer Library.