1. Radhika Jain Sandra Richardson
Knowledge Transfer Mechanisms In Software Testing: An Empirical Investigation
Radhika Jain
Sandra Richardson

2. Current status Review of existing literature
Completed first round of interviews
Interviewed 3 Client and 2 vendor employees
Informal discussions (50 Client employees)
Completed preliminary data analysis
Determination of appropriate knowledge management (KM) constructs that need further investigation

3. Goal To improve knowledge management in software testing process
By understanding how knowledge is partitioned and transferred currently
Use this insight to develop effective mechanisms to enable knowledge sharing

4. Interim Results: Client Side Knowledge Management
Major knowledge partitions:
Across multiple projects
Across departments/units within Client organization
Between Client and Vendor organizations
Knowledge documentation
Seen as non-productive
Knowledge capture flexibility vs. knowledge access and distribution ease
Peer-to-peer knowledge transfer
Mostly within testing teams  Knowledge islands
Knowledge sharing with development team
Issues in knowledge transfer outside a given outsourcing relationship
Lack of awareness  cross-team knowledge transfer difficulties
Our analysis pointed at three knowledge partitions. First partition exists across multiple projects within a given org for example within testing org. Major concern here in lack of information on application dependencies. This is becoming a major issue with distributed system environment.
Second partition exists across multiple organizations such as between development org and test org. Another example given was sales org which has great infrastructure for sharing and disseminating knowledge but again within the sales org and not used much outside.
Third partition arises with the existence of outsourcing relationships. Without any existing system documentation, vendors have no choice but to sort of reverse-engineer these systems and document knowledge about them, their dependencies. In any case, vendors become more acquainted with the systems over a period of time and thus more knowledgeable.
Now lets talk about how knowledge gets transferred in the presence of these partitions.
Two primary approaches: knowledge documentation and peer-to-peer
Knowledge documentation is not done to a large extent for several reasons: 1) issues of capturing 2) issues of making it available and accessible, 3) issue of utility of such documented knowledge. Because of these issues, knowledge documentation is perceived as non-productive. Also there is no consensus on what knowledge should get documented or what constitutes knowledge.
This leads to use of peer-to-peer knowledge transfer, which primarily takes place within a given testing team leading to isolated knowledge islands as I mentioned earlier. Management sees this P2P nonproductive as it can be time-consuming and ad-hoc. However this takes place very regularly.
On most occasions knowledge that gets shared with development teams is about defects say in BRS, or design documents, or code level defects. While the defects are addressed, it is unclear as to how this knowledge is used in future projects. We need to conduct further interviews with the development org to understand their needs in this regard.
When working with vendors, vendors develop sizeable knowledgebase of systems and their dependencies. Unfortunately,
since this knowledgebase is untapped it rarely becomes available to others outside this relationship. Big loss for FedEx and increased reliance on vendors.
Also this knowledge building effort may potentially be incomplete and inconsistent since vendors may not have holistic view of application dependencies. They are relying on knowledge capital of FedEx PMs who themselves have incomplete partial view of the systems.

5. Interim results: Vendor Side Knowledge Management
Peer-to-peer KT
Seen as productive
Can lead to brainstorming of unknown issues
Knowledge documentation
Documented primarily when an issue occurs repeatedly
Seen as productive  future time-saver
Knowledge capture flexibility vs. knowledge access and distribution ease
Driven heavily by high workforce turnover rate
It is interesting to contrast knowledge management process of FedEx with KM process of vendors.
Initial P2P:
Vendors not only have basic documentation of GDP process but they also have good product documentation that is used to bring the new team-members up to the speed. Team-members collaboratively spend significant amount of face-to-face time to ensure new team-member has good basic understanding to do the work. This process is overseen by management.
Ongoing P2P:
Besides this initial ramp-up P2P, vendor employees engage in P2P on a regular basis. The nature of issues being raised leads to two potential outcomes
When the issue is raised first time, it leads to some brainstorming that involves experienced and novice employees. This brainstorming is seen as productive, as the ensuing discussion might help solve potential other problems. Typically issue is resolved as a result of this brainstorming. When a similar issue arises, person knowledgeable of that issue is queried, and so on
If the same issue is seen occurring again and again, then typically this recipient of the query ends up documenting the issue and its solution. Next time, person is then referred to this documentation, thus saving time. Decision of when and how to document is left to an individual. This seems to address the problem of what to document and whether it is useful.
Nature of issues raised by people and how the process of issue resolution is managed by them, is indirectly used by project managers and test leads to “identify” employees who will be an asset, thus impacting their performance appraisals.
It should be noted that much of this driven to a large extent by the high workforce turnover rate. However as pointed out in our interviews, there is increasing awareness in pay by performance in FedEx environment. Thus some of these practices have implications for FedEx.

6. Implications
Greater understanding of current processes and frameworks and how they impede knowledge transfer
Identification of goals and perceptions across all levels of employees at various areas of the organization
Insight that can facilitate development of new frameworks and models specific to Client that facilitate knowledge exchange
Across the organization (testing centers, GDP, and levels of employees)
Within systems testing teams
With Vendors
These initial findings provide management with a better understanding how knowledge is partitioned currently and what approaches are used to bridge the gap in these partitions.
We have some initial understanding of how knowledge management is perceived by the senior management and by other employees. This exercise will help us understand goals of stakeholders at these different levels, thus help us in identifying goal-driven knowledge management strategy.
Better understanding of knowledge partitions can facilitate identification of frameworks and approaches to make knowledge exchange possible at different levels.

7. Implications Cont…
Insights that can lead to models for knowledge repository design (across organization and with vendors)
Reduce redundant information
Reduce isolated information
Increase efficient search processes
Increase synergy of information (organizational learning)
Models for goal-oriented KM strategy aligned with employee goals
Comparison to key indices of success in other organizations with a similar approach
Identifying best practices
A concerted effort at this knowledge exchange can perhaps guide the design of knowledge repository rather than simply a document repository that help us address the above issues.
Finally our goal is compare and contrast FedEx’s practices with similar organizations to determine best practices. We have taken one step towards this by comparing and contrasting FedEx with vendor.

8. Next Steps Conduct next round of interviews (April/May 2007)
Client test managers, development managers, and developers
Various vendor test leads and project managers
Conduct survey to triangulate findings from interviews (Sep/Oct 2007)
Develop models to address issues identified during data collection (Nov 2007)

9. Thanks!