Any IT people on? I need opinions/help!

E

evnshawn

TCS Member
Thread starter
Super Cat
Joined
May 2, 2005
Messages
978
Purraise
2
Location
Kansas City
I asked for help from IT people (and tried to change the title but can't), but I think this situation might be more of a human problem than a technical problem, so any advice is appreciated.

I am a QA engineer (tester, in other words), and for the first time, I am working--temporarily--with some offshore people. They are supposed to be helping us create test conditions. (Test conditions are basically step-by-step instructions to test development. They are time-consuming to write but vastly improve the whole testing process when done correctly.)

My problem is that the resources don't seem to be "getting it." Their conditions are nothing more then the requirements, broken down into sentences, basically. There's not enough information there for when we start to test.

I have sent my manager an email asking if maybe WE could write the test conditions (a fairly new development even for us; the new manager brought it in with her) and have the offshore people test.

So, 1) does that sound like a better idea, and 2) if she doesn't go for it, how can I better communicate with the offshore team so as to get them to understand what we need? I have tried sending them examples and explaining the level of detail we require; I am wondering if the difficulty comes because basically someone who knows the app needs to create the conditions. Maybe it has nothing to do with cultural/language barriers.

I'm sorry if this doesn't make any sense; I'm so wrapped up in it right now that I might not be explaining it as well as I could.
 
D

daddycat

TCS Member
Adult Cat
Joined
Jun 14, 2005
Messages
251
Purraise
1
Certainly sounds like a cultural/language barrier. They're giving you a high-level outline of the aspects of the system that need testing, and they should be giving you the actual procedures for the testing. They're giving you systems analysis and you're looking for program code. How about this: take a couple of their specifications, write an actual test scenario for that requirement and send that to them as an example of what you really need from them. As long as it's understood at the project management level that your offshore team should be providing the test scenarios and not you, that should clear up any misunderstandings.
 
  • Thread Starter Thread Starter
  • #5
E

evnshawn

TCS Member
Thread starter
Super Cat
Joined
May 2, 2005
Messages
978
Purraise
2
Location
Kansas City
Originally Posted by DaddyCat

Certainly sounds like a cultural/language barrier. They're giving you a high-level outline of the aspects of the system that need testing, and they should be giving you the actual procedures for the testing. They're giving you systems analysis and you're looking for program code. How about this: take a couple of their specifications, write an actual test scenario for that requirement and send that to them as an example of what you really need from them. As long as it's understood at the project management level that your offshore team should be providing the test scenarios and not you, that should clear up any misunderstandings.
Click to expand...
Thanks! You know, upon rereading my post, it seems like I am saying that we are getting the requirements from them. Actually, we have sent them the requirements; they're supposed to use those to write test conditions. The main problem is that they're not being granular enough. For instance, if a sentence in the requirement says, "Users of type X, Y, and Z should be able to access this link," they'll put that all in one test condition rather than three. Plus they skim over some details. We actually have pretty good requirements for this (laaaaarge) project, so as long as they stick to the requirements and make sure they get every detail of them, one "test" to a condition, we should be fine.

I think I will take some conditions they've already submitted and edit them, showing them what they should look like. This is so time consuming. Honestly I don't see how offshore development/QC is saving us any money.

To CoolCat and WellingtonCat: thanks for the good wishes. Hopefully we can make this work.
 
D

daddycat

TCS Member
Adult Cat
Joined
Jun 14, 2005
Messages
251
Purraise
1
OK, I see what you mean. From your example, they should be coming up with a test suite Access Control by Group. "Sign in as member of Group X and you should have View and Edit access on link 1, View only access on link 2 and be Denied access to link 3. Sign in as a Group Y user and confirm that you have View, Edit and Delete on link 2..."

It's been my experience that offshore developers/analysts are technically very competent but also very literal-minded. Maybe it's partly a cultural thing and partly a consequence of prudence when working in a non-native language. Ultimately, you and your group might be better off doing a complete "first draft" of the kind of test specifications needed, and submitting them "for comment and revisions" to the other group.
 
momofmany

momofmany

TCS Member
Veteran
Joined
Jul 15, 2003
Messages
16,249
Purraise
70
Location
There's no place like home
My company started using offshore people last year and we both a language barrier and a time zone barrier to contend with. I have been in systems development for about 26 years and have never seen such an issue with the interpretation of requirements - we get bad code because they write neither good code or good test conditions. Right now I'm a general manager that has the people reporting to me that write those requirements, then take the code from the offshore staff that codes/tests what they give back. We brainstorm all the time on how to make this better - the bad code costs us a LOT of money in rework and retest.

The language barrier is not nearly as bad as the culture barrier. The joke we use is this: Make us a sweater. Oh, you don't know what a sweater is? It's a garment that covers the torso with 2 openings for the arms. With that we get a jacket. So we add that it has an opening up front with buttons on one side and button holes on the other, is made from 100% cotton that is in a loose knit, the sleeves go to the wrists and taper down to be tight fitting at the wrist, the part that covers the torso starts at the neck and goes to 3 inches below the waist and it needs to be pink, specifically dye lot 32495. That gets us closer but still no sweater.

We started doing a couple of things. First, we do what Daddycat suggested - go to a level of minutia detail on the requirement. Secondly, we take the code they deliver and retest it on our end before we allow it to be delivered to end users. We're not IT folks, so don't have the level of detail needed to do a unit test, but we do know how to write an acceptance test. We allow a minimum of 2 months to test everything that comes back to us, and sometimes that turns into 6 months. Our cost has tripled since we went offshore.

If you are in IT, I suggest that you have a walk thru on their test plans. It will at least confirm in your mind whether or not they "got it". You will never know how they coded it unless you walk thru their code also, so you have to depend on them to a great degree to write their own test plans.

I hope this helps. PM if you want to talk more about it.
 
  • Thread Starter Thread Starter
  • #8
E

evnshawn

TCS Member
Thread starter
Super Cat
Joined
May 2, 2005
Messages
978
Purraise
2
Location
Kansas City
Originally Posted by Momofmany

My company started using offshore people last year and we both a language barrier and a time zone barrier to contend with. I have been in systems development for about 26 years and have never seen such an issue with the interpretation of requirements - we get bad code because they write neither good code or good test conditions. Right now I'm a general manager that has the people reporting to me that write those requirements, then take the code from the offshore staff that codes/tests what they give back. We brainstorm all the time on how to make this better - the bad code costs us a LOT of money in rework and retest.

The language barrier is not nearly as bad as the culture barrier. The joke we use is this: Make us a sweater. Oh, you don't know what a sweater is? It's a garment that covers the torso with 2 openings for the arms. With that we get a jacket. So we add that it has an opening up front with buttons on one side and button holes on the other, is made from 100% cotton that is in a loose knit, the sleeves go to the wrists and taper down to be tight fitting at the wrist, the part that covers the torso starts at the neck and goes to 3 inches below the waist and it needs to be pink, specifically dye lot 32495. That gets us closer but still no sweater.

We started doing a couple of things. First, we do what Daddycat suggested - go to a level of minutia detail on the requirement. Secondly, we take the code they deliver and retest it on our end before we allow it to be delivered to end users. We're not IT folks, so don't have the level of detail needed to do a unit test, but we do know how to write an acceptance test. We allow a minimum of 2 months to test everything that comes back to us, and sometimes that turns into 6 months. Our cost has tripled since we went offshore.
If you are in IT, I suggest that you have a walk thru on their test plans. It will at least confirm in your mind whether or not they "got it". You will never know how they coded it unless you walk thru their code also, so you have to depend on them to a great degree to write their own test plans.

I hope this helps. PM if you want to talk more about it.
Click to expand...
These guys won't be coding at all; they will only be doing the test conditions. For now, their deliverables consist solely of spreadsheets which we will import into a database. And these tests are all functional and integration; our developers have to write their own unit tests. Ironically, the reason we have some of these resources is that they were being used for coding, actually, until the powers that be decided to go with something else (state-side contractors, I think). So we (the QC department) have them for the remainder of the year, until their contracts expire.


This particular project is huge, a complete rewrite of an app we use to administer most of our other products. And we will have two weeks to test it, not two months. (Another problem at my workplace, but that's another story.) So it's imperative that these test conditions be complete, thorough, detailed, and accurate. So far the test conditions I've seen have been accurate, but not much else. My next crack at will be to actually rewrite a few test conditions they've submitted; maybe that will give them a better idea of what we want.

I'm so tired.
 
You must log in or register to reply here.
Top