Offshoring: Using Process Flow Diagrams to Improve Communication with Outsourced Projects

The Scenario

A large financial institution outsourced all their Functional Acceptance Testing to the IT company I was working for. Our test line for this customer consisted of 20 people, half of it in India. We implemented a series of very effective solutions for improving the quality of testing in India.

The Process

New software is delivered in releases. Releases for the whole system including the new changes, or releases per application. And of course there are changes that have to be implemented quickly because of production problems or last minute changes. These so called “must” changes are tested in the Netherlands. The rest is brought to India: first the regression tests and gradually the changes too. Step by step we increased the complexity and workload.

The customer provides release documents with all the changes in the new release and functional designs, often with ERD’s and DFD’s in them, but not always. Neither does the customer provide process flow diagrams, which are a rarity in the software development world. But for testers these process flow diagrams are a great help. Indispensable really.

Process Flow Diagrams

This is what we did: we let the Indian testers create process flow diagrams of the applications, since knowing the application is the most important part of testing. A proper flow diagram says more than a thousand words. Plus you avoid of a lot of language interpretation problems.

The goals for the process flow modeling were:

1. To use the models as a tool for communication between the Dutch and Indian team in the test line.
2. To qualify the expertise level of the testers
3. To use the models as a tool for communication between the test line and the customer.
4. To set up the models in a modular way, so parts of the flow diagrams can be detailed e.g. for certain changes
5. To improve the understanding of the functionality
6. To make the testers more pro-active
7. To pay more attention to integration tests
8. To be able to identify missing parts in the available regression test scripts
9. To be able to identify which parts of the application are affected by the changes
10. To make it easier to create test scripts

We used a basic modeling technique that both teams are familiar with, similar to decision diagrams or activity diagrams of UML. We also defined a basic set of rules for modeling:

• The diagram has only one start and one end node
• We use a basic set of symbols: start/end, process, automated process, decision, data, database, document
• A decision can only have one Yes and one No output
• Only put in the diagram what is part of the main process (no screens or fields)
• Always base the process flow on the functional design and knowledge documents and never on the regression test set or the GUI
• Only model what can be controlled (input) or measured/observed (output)

The process modeling was a great success. We improved the testing processes and communication in a short period of time. The testers saw the benefits of process modeling immediately and enjoyed making these models. After the reviews of these diagrams the people involved (onshore and offshore) understood the functionality the same way. Testers became more assertive and asked more questions that good testers should ask. Also the customer took part in these reviews. The creation of test scripts became easier.

Detail a Process Flow

Additional Measures Taken

We changed the organization of the Indian team a little bit. We divided the test team into two parts that correspond with the two main parts in the system: “customer processes” and “financial processes”. The testers could focus on a limited set of applications. This improved acquiring knowledge and experience in the test line.

We appointed two test leads in Mumbai, experienced test professionals with good communication skills, whom we made “Single Points of Contact” in communication with the team in the Netherlands. All deliverables and questions of the Indian testers first had to be reviewed and filtered by the test lead. After reviewing the deliverables, the test lead could communicate these with the onshore test coordinator. These test coordinators were also Single Points of Contact for the applications they coordinated. Questions they couldn’t answer they put to the customer.

Also we used clear work packages to manage the testing process and the deliverables. For example, we made work packages for “create test script for x” or “execute regression tests for y” with a clear description of what had to be done. That helped divide the testing process in clear manageable parts.

Furthermore we created a web based knowledge base. For each subject, for each application, the knowledge was stored and updated on a regular basis. Updating the knowledge base was standard part of the Completion phase of the testing process. All relevant information that was necessary to repeat the tests was documented.

Conclusion

We realized a significant increase in Quality for which we needed less Time. The changes in the processes and organization already paid off in the first releases they were implemented. The benefits of the process flow diagrams will pay off even more in future releases, since these diagrams can easily be maintained because of their modular structure. Of course these process flow diagrams are added to the knowledge base.

Transition of the Funtional Acceptance Testing for additional application parts is in progress!