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):
- What
are the modules (sub systems) that make up the system?
- What
are the inputs and outputs of each module?
- What
is the business logic in each module that transforms the inputs into
outputs?
- Are
there any external industry standards that the software should adhere to?
- What
are the interfaces between the modules?
- 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.