TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Offshore Testing: The PITS?



A StickyMinds.com Original
Article Picture
Offshore Testing: The PITS?

By Linda Hayes

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Offshore resources have proved useful, and companies continue to try and cash in on the cost savings. But those savings might not be what you or your company expected. In this week's column, Linda Hayes warns that outsourcing has some pitfalls we should always look out for.


Infosys
The use of offshore resources for development, while not a panacea, has been accomplished with varying degrees of success by corporations in many industries. The promise of the same value proposition--a reduction in resource costs--has encouraged some to pursue the transfer of testing offshore as well. Interestingly, the value proposition is not as clear for testing as it is for development. In fact, some companies have reversed course and returned functional testing back onshore. The past five years or so of experience has illuminated four key factors affecting the success or failure of these efforts: process maturity, independent verification, time to value, and security.

P: Process Maturity
Just as companies found that their own development processes and project oversight had to be significantly improved before offshore development could be effective, they also discovered that their test processes lacked the maturity, necessary detail, and structure needed to be successful offshore.

High-level test scenarios, rife with phrases such as "enter valid data" and "verify correct results," presuppose the tester has domain and application expertise. When working with offshore resources that have neither expertise, the test documentation must be reworked to provide explicit step detail and data values in order to be usable. And while this investment might be worthwhile if the tests are reused often, a high rate of change in the application under test may negate the value.

I: Independent Verification
For mission-critical software with a high component of specialized domain knowledge, it is essential to independently verify the functionality. And offshore development already poses a risk of misinterpretation of requirements due to the lack of domain knowledge and experience.

Some have sought to mitigate a portion of this risk by engaging separate organizations for development and testing, but this approach drives up time and costs due to extra overhead for contract and project management. Internal experts--the very resources whose time is supposed to be saved--may end up with even more responsibility. Thus, acceptance testing often ends up being performed internally as a check against external development.

T: Time to Value
Offshore resources are never a quick fix, especially for testing. A 2005 report from AMR Research found that it took between fourteen months and three years before the offshore testers had sufficient familiarity to be effective in finding the root cause of problems. Others have found that the lack of domain knowledge resulted in spurious defects being reported that actually increased development overhead due to review and response times. In fact, one organization identified that as many as 33 percent of reported issues were traceable to tester error.

So companies that choose offshore resources as a way to remedy a resource deficiency, or to handle an influx of projects while keeping costs flat, might find themselves with higher costs and resource demands for one or more years. Without careful planning and realistic expectations, this confluence may end up eroding quality and extending schedules.

S: Security
In many cases comprehensive testing requires access to a complete test environment, which may include a copy of production data. Although data scrambling utilities exist, they are not always used. Even when they are employed, they are time-consuming to implement and may not completely mask sensitive information. The potential for disclosing private or protected data is substantial and may violate laws and regulations, particularly in the financial services and health industries.

This risk exists for both internal and external resources but may be harder to manage in an offshore facility. Internal protections are usually already in place and must be extended to cover outside organizations.

Of course these factors have been successfully managed or overcome to yield a return on an offshore testing investment. For purely ad hoc testing, less-trained resources might actually have an advantage as they might be more likely to make the same mistakes as users. For the classic "brute force" approach, the sheer numbers of resources might prove beneficial.

Others have found that while less costly resources are useful for manually intensive execution, they are still more expensive than automated execution. And while using offshore resources to develop automated tests might appear to be less costly than doing it onshore, internal resources are nevertheless required to provide highly detailed test documentation as well as internal results analysis and verification.

As always, there are no easy answers or surefire formulas. Has your company moved testing offshore? What worked? What didn't? If you could do it over, what would you do differently ... or would you? Leave your comments below.


About the Author
Linda G. Hayes is the CTO of Worksoft, Inc., developer of next-generation test automation solutions. She is the founder of three software companies including AutoTester, the first PC-based test automation tool. Linda holds degrees in accounting, tax and law and is a frequent industry speaker and award-winning author on software quality. She has been named as one of Fortune Magazine's People to Watch and one of the Top 40 Under 40 by Dallas Business Journal. She is a regular columnist and contributor to StickyMinds.com and Better Software magazine, as well as a columnist for Computerworld and Datamation, author of the Automated Testing Handbook and co-editor Dare To Be Excellent with Alka Jarvis on best practices in the software industry. Her article "Quality is Everyone's Business" won a Most Significant Contribution award from the Quality Assurance Institute and was published as part of the Auerbach Systems Development Handbook. You can contact Linda at Linda@worksoft.com.

Back to Top
 

StickyMinds.com Weekly Column From 10/16/2006 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Sanat Sharma 4/16/2007

Offshoring testing will become successfull only when it is organized in a proper way. The management should understand this thing that testing is a never ending process. Testing only gets transferred from the testing team to the customer. So the managament should plan and manage test outsourcing in a appropriate way. If management is not able to do so, testing will become like biting a bullet. In that case, better to perform the in-house testing.
-- Sanat Sharma

 
 
Comment:    
by suresh cr 11/7/2006

One of the major aspects that is coming out, is the instability of test environments.. in almost all testing projects i have seen this is a concern, more so, if environment/development teams are a in different location other than test environment. We have to manage this by placing environment support in the time zone of the offshore test teams and ensure quick turn around time.



Another key success factor for success of offshore testing, is the availablity of domain experts within the testing...Read On

Author's Response:
11/7/2006    
Hi Suresh - lending SMEs to the test team sounds like a great idea but does that mean they move offshore? I have seen this problem but have not had that option available since few are willing or able to relocate.

 
 
Comment:    
by Sivakumar Ganesamurthy 11/3/2006

Organizations should not look at Offshoring activities from the Cost Perspective only. Rather, Organizations should look at Off shore activities where they could develop a 24 hours Model of Testing/development and other efforts. The change in the mindset would immensely help to decrease the time to release their products to market.

For Any Off-shoring operation, There should be consistent and meticulous planning by the people who are involved. Off shoring cannot fix all the problems. However, With the Right push from the Management and the Right Attitude from the...Read On

Author's Response:
11/3/2006    
Hi Sivakumar - it's good to hear that this can work and I hope I did not to imply that it can't, just to point out what the considerations and factors are that must be considered.

 
 
Comment:    
by Johnzie . 11/2/2006

My view is from the other side of the fence ,I have been a test lead for a consulting firm in India and have seen many customers reap great success with their outsourcing of testing. IMO some of the factors that contribute to the success are to set the expectations right and have a right channel in place for daily communication . If its a big engagement ,most of the Offshoring companies set up ODC's which are on the customer networks with high security which is as good as working onsite.



Often...Read On

Author's Response:
11/2/2006    
Thanks, Johnzie. There are always two sides and I'm glad you can share a positive experience.

 
 
Comment:    
by Vrinda Menon 11/1/2006

Hi there



As an Indian having worked in India and overseas & having worked with outsourced Dev & QA teams in India & in the same city that I live in, I just HAD to say something after reading the article and comments.






Read On

Author's Response:
11/2/2006    
So true, Vrinda. The quality of people is not geographically determined, you can get the best or worst anywhere. Also local processes are not inherently better than remote ones. However you can compensate more easily for poor process in the same room than you can across continents - not that this is an excuse in either case.

 
 
Comment:    
by Steve Collins 11/1/2006

Your article is correct in it's intent but the scope is a little off. Everything you said applies equally well to onshore outsourcing, sure some of the difficulties in going offshore are not present with onshore outsourcing such as time zone differences (although that can be somewhat of an issue between the East Coast of the US and the West) and Language Barriers but overall nearly all outsourcing is a bad idea.



In my own experience offshoring is never worth doing UNLESS you have the resources...Read On

Author's Response:
11/2/2006    
Thanks, Steve. You are absolutely correct - the only difference between on and offshore outsourcing is the degree of time zone dislocation and maybe some cultural anomalies. The rest applies to any outsourcing arrangement.

 
 
Comment:    
by Jonathan Zimmers 11/1/2006

I wanted to add a little bit to the discussion regarding working across timezones. I worked at an offshore company in Asia, and I have seen the delays that can occur due to the time difference. If a question or problem arises during execution, a full day may be lost before there is a resolution. If this happens several times over the span of a project, the impact can add up. It is an issue that can be mitigated with some planning, but it needs to be considered when planning an offshore testing model.

Author's Response:
11/2/2006    
Thanks, Jonathan. You're right that time is always a factor - the bigger the time difference the longer the delay, and when you add in the extra explanations that may be needed it becomes even longer.

 
 
Comment:    
by Amy Caligiuri 11/1/2006

I just recently canceled my 3 year offshore contract and brought the testing back onshore. The first year and a half I had a team that was working the India day hours. Much time was wasted when things went down. When I changed the team and moved it to another part of the country I insisted they work our hours. They weren't happy but I compromised and split the team so half worked US day hours and the other half worked hours that had them leaving at 11:00am our time. This worked much better than my first team. They changed there shifts every month.


Read On

Author's Response:
11/1/2006    
Hi Amy - as India expands its economy the turnover you experienced is becoming more common. Opportunities abound and of course workers will take advantage to advance their careers, just as people do onshore. The difference as you saw is the training and ramp up time.

 
 
Comment:    
by Allan DeKoninck 11/1/2006

We began utilizing off-shore testing with Y2K due to staff shortages and found the testing to be much more thorough than was being done with on-shore staff. I believe part of the reason for this thoroughness was because of the initial set up and planning that our company did. We had the team lead for the off-shore test group meet face-to-face with the development team for about 4 weeks prior to the start of testing. We reviewed our test processes, standards, and tools. The team lead had spent a number of years working directly with U.S. companies, had a good grasp of technology, terminology, and the English language. We walked through...Read On

Author's Response:
11/1/2006    
Thanks, Allen. A great example of what it takes to be successful with this model. Let me know how it works when you transfer acceptance testing offshore since that is usually the most challenging.

 
 
Comment:    
by Ted Bartlett 10/31/2006

I have worked as test engineer in the US and worked as Test Ops manager in both the US and Philippines. I believe that only a robust and bullet proof/mature product can be transferred without significant support from US engineering. I have seen both good and bad "mature" products dumped off in the Philippines, and the results were a party mix of good to really bad. If management is not completely aware of the soundness and repeatability of a production line before it is sent off-shore, then results can be bad for both companies.


Read On

Author's Response:
11/1/2006    
Ted you said the magic words - "If your company does not have an extremely sound release process in your own factory, then expecting something to run well off-shore is an unrealistic expectation". Too many companies think that sending testing offshore will solve problems when instead they must first be solved.

 
 
Comment:    
by Mayank Sharma 10/30/2006

Hi Linda,







It is a very useful write-up. You have considered very practical issues. I have encountered similar issues several times. However, I think these are pitfalls of having inadequate processes. An example referring to the “enter valid data” test scenario is a typical problem of an ambiguous test case. It does not matter if this test case is...Read On

Author's Response:
10/30/2006    
Thanks, Mayank. You are absolutely correct that you need explicit documentation regardless of where execution happens - unless the subject matter experts are performing the tests themselves. That is why transitioning to any other model, regardless of location, requires enhanced formality. The only difference is that local resources can at least consult with SMEs more easily than remote ones.





 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Seapine




STARWEST 

Agile Development Practices