Delivering effective software that meets the needs of business is never an easy job. It's even more difficult when...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
delivery is spread over a globally distributed model, in an atmosphere of outsourcing, and with ever-present challenges of scope, timelines, costs and effort. The test team needs all the help it can get to effectively test the software and make sure that it meets quality expectations and does so without causing time and budget overruns.
Offshore teams today have a variety of tools, processes and methodologies to help them test efficiently. However, quite often, there is one potentially critical ally that's not leveraged as effectively as possible -- the User Acceptance Testing (UAT) team on the client's side.
Leverage the UAT team from the start
It's best to start at the beginning. A test manager and the offshore team should consciously engage UAT in dialogue from the start. The testability of a lot of features is best known by the people closest to it, which in this case is the UAT team.
Also, quite often, there are nuances in the application that could prove to be significant inputs to estimation and test-planning activities. One of the most enlightening experiences I have had is an input from the UAT team (luckily quite early on) about the amount of time it would take to set up test data.
That input had a significant effect on my estimation and effectively made me rework a portion of the entire test schedule. Such insights are invaluable in the long run, and they emphasize the importance of the UAT team.
Keep the UAT team involved
While it is good to have the UAT team's input at the beginning, it is also crucial to keep the team involved -- and INFORMED -- throughout the cycle.
Relationship building is both an art and a science, and like Rome -- or any other city -- a relationship can't be built in a day. The importance of regular communication cannot be over-emphasized, but it is sadly often underestimated. Both sides have a lot to offer each other, and it is imperative that regular dialogue is maintained.
One of the things I like about Agile-oriented approaches is the focus on the ability to deliver "working," testable pieces of functionality in short cycles -- thereby enabling the client (and the UAT team) to have a look at the application as it gets built and not wait until there's a "Big Bang."
Even if you don't follow an agile process, it is good practice to let the client/UAT teams "peek" into the evolving software. Not only does it help catch potential bugs early on, but it does a world of good in boosting confidence in the clients' minds.
And don't forget, quite often some of the bugs caught early via such sneak peeks, could potentially have been Severity 1's or 2's in a formal UAT cycle. And that would then have knock-on effects on other aspects of delivery (not to mention financials).
It is also a useful practice to formally exchange test scripts with the UAT team. If done properly, that can help both teams understand each other's perspective while testing and often widens/deepens test coverage to ensure that business needs are met. The UAT perspective on desired functionality may be wholly different from that of the outsourced project team.
Another practice I have found quite useful is to formally set up regular checkpoints with the onsite UAT team via conference calls. These serve as a forum to exchange status reports and thoughts, as well as address any potential issues early on.
Ensure a thorough handover
Too often we see project teams target the "delivery date" -- when it's handed over to UAT -- as something similar to climbing the summit. I recall an incident I observed when a project team indulged in celebrations at having "achieved" the date and somehow forgot to send over the list of "known/open bugs." The emails the next morning were hardly flattering.
I'm sure this isn't really the norm. (I hope!!!) Nevertheless, a test manager's job doesn't end with successful completion of testing offshore. The UAT team needs to be ramped up on any relevant aspects (usage, features, CRs, etc.) as may be required. They need to be informed of the correct and current state of the application, including the known/open bugs. The UAT and offshore test managers need to be on the same page with respect to deployment schedules, defect lifecycles, defect reporting mechanisms and triaging, test environment issues, patches to be applied, exit criteria/quality thresholds and the like.
While the UAT team is very much a part of the client's business, and is a completely distinct entity, it nevertheless can often add a wealth of information and provide valuable inputs, not to mention be a part of the all-important relationship-building effort.
This isn't, as they say, "rocket-science." It is more a common-sense approach to engaging a partner in a meaningful dialogue and giving true meaning to the word "partnership," which is often the cornerstone of successful software delivery, as well as most other things in this world.
About the author: Debashish Chakrabarti works as a senior associate at Sapient Corp. He has worked in IT and testing for approximately eight years and has dealt with functional testing, non-functional testing and test management.