4

starting position

At the moment I have different test teams at my disposal who work on different continents or who accompany my project like now in India.

I have noticed a wide variety of cultural characteristics:

  • There is no contradiction (no matter how meaningless an instruction would be)
  • Even if you ask for feedback or criticism, there are hardly any realistic answers.
  • So the customer (me) is always right, but exactly, that is a wrong view as I think. I expect comprehensive criticism and feedback from testers. Especially in my project I need negative feedback at an early stage to solve problems directly.
  • I have a team leader in India who does not allow direct questions to the testers. So I discuss 3 corners in an awkward way. Very cumbersome. Is this also a cultural habit? I do not know in such a way!

Problems

I currently see the problem that assessments of my projects, just from the QA field, are too positive. Am I wrong?

Solutions?

How can I prevent cultural differences in the test, across continents, across time zones, and local cultural differences?

Or is it really because I'm too bureaucratic as a German ;) Maybe I shouldn't see some things so doggedly?

Maybe someone from India who might be able to explain the cultural differences to me and how I can best build the team.

  • 3
    I updated the title because the issue is not specifically about culture clash - that can happen in the same office and a worthy topic. But the details show this may be more about off-shore workers. So I updated title. feel free to change or revert. – Michael Durrant Nov 21 '19 at 20:04
  • 2
    Maybe we could say 'off-shore people with different methodologies and motivations rather than 'cultural'. Just a thought I will leave here for now – Michael Durrant Nov 22 '19 at 14:44
  • I think it's good – Mornon Nov 22 '19 at 15:17
2

I expect that your remote testers see their job the way it is defined for nearly all the organizations that use them: does the software work? and can they sign off on that and get paid?

If you create an arrangement where their pay and employment is dependent on giving much greater feedback it will happen, though you'll need to invest time and training because they are not used to this

Ultimately 'off-shore' testers may add limited value because of such issues. you may ultimately find it more value to employ two local workers at $100,000 each rather than 20 off-shores at $10,000 each. Also when you have a lot of people, human notions of shared responsibility leads to 'it's not my job' sorta issues. Whereas when there are just 2 people and they are in-house you can focus better on the real value they add. There can be a greater sense of responsibility and pride in work this way.

To start operating this way you will also need to educate 'not in the moment of any given issue or test. You need to set up separate meeting(s) where you go over the requirements for constructive criticism in details. As with most messages about changes that are not usual to an arrangement, you'll probably need to repeat it several times.

Also this does happen to on-shore core developers too. I have worked in shops where code reviews are largely a 'thumbs-up' exercise and not the vigorous debates they are supposed to be.
So the culture problem here is not about place, ethnicity, etc, it's more about the culture of development, agile, seeking feedback, etc.

| improve this answer | |
  • This hackerone 2018 report . US and India makes more than 50% of the bug bounties. Location of the team doesn't limit the value , actually it increases the efficiency of the team if the process is well established. Most of the jobs In Europe is outsourced from US – PDHide Nov 21 '19 at 20:30
  • I think in-house testers gets more influenced by dev team and management pressure. An outsourced test team has more degree of Independence and can be more effective – PDHide Nov 21 '19 at 20:38
  • 1
    @PDHide Yes I agree, outsourcing should provide more independence. In my experience at a number of companies however the opposite has proven to be true. Off-shore testing frequently does not take into account agile development. They are traditionally used to having weeks/months to test and use many people. The need for more focused and much quicker testing has (in my experience) lead to a just cutting what is tested to meet shorter deadlines. INstead of, for example completely redoing the testing process. – Michael Durrant Nov 21 '19 at 20:49
  • 1
    It has advantages and disadvantages to use an offshore team. I just had some problems with it at the beginning, but I could use some tips here. – Mornon Nov 22 '19 at 9:44
1

This doesn't have anything to do with cultural differences. It's the issue with the organization's work culture. To fix this , you have to ask yourself some hard questions.

  1. How independent is the test team
  2. What are the KPI used to validate QA efficiency
  3. Is bug count and defect detection ratio could be considered as KPIs
  4. Does testers get appreciated and recognized on finding design flaws or other bugs
  5. Does there is an organizational culture that give more respect to developers than testers
  6. Does proper skill upgrade opportunities are given to testers
  7. Is there huge salary gaps between developers and testers
  8. Does the organization addresses job security concerns
  9. Is there a strong QA manager who stands with the team on all issues.
  10. Does testers get onsite opportunities , and get involved in early test stages like design, product backlog creation etc.
  11. Does the developer explain the bug and bug fixes in a technical manner to the test team? ( This helps in getting QA team more interested in the product )
  12. Is there a proper process in place? For instance, what is definition of done, when is a user story ready for testing, how bugs are traced, is there a maximum defect backlog deadline.
  13. What factors, who and when does defects will be marked as no fix, deferred, or fix required
  14. How are promotion decisions are made
  15. How often do team building activities happen

There are tons more , find the human factor and the technical factor. Then the issue will be resolved in no time.

If nothing works then you have to take the hard decision of replacing current workforce with more passionate testers , who does testing because they love it and not because they hate development.

NOTE: I as a QA would recommend to have bug count as a KPI. I believe that it keeps testers motivated about their efforts. But should never use it to measure efficiency of dev team.

And also make sure bug count should be related to feature complexity. Sometimes some QA gets complex features with less bug , but that doesn't make them less productive. In short , have a mix of KPIs and human factor in your decisions.

| improve this answer | |
  • 1000 trivial layout bugs can be less important than one 'everyone gets 404 or 500 page' bug. For this reason raw counts.. count for little to me. If I know that number of bugs is rewarded then I will find more including trivial ones, ones already found, etc. Reward the behavior you want but be careful that's really the behavior you want. If you want less bugs I will find less, dismiss some, treat others as not important. Whatever number we want we can game it over time – Michael Durrant Nov 22 '19 at 14:42
  • @MichaelDurrant it's obvious that duplicate bug, bug marked as not a bug , would not be considered in the bug count. And also other metrics like feature complexity , stability , effort required to find the bug , severity etc will also play a role. If there is a QA engineer who finds all critical bugs and others who find all non trivial ones , then the critical bug founder will be given more preference. If a person finds most critical and in addition finds all minute bugs then he will be the first one to be assigned to test a critical project . – PDHide Nov 22 '19 at 14:58
  • 1
    Great points, thank you. "I" might then (sometimes) try to find a difference so I can consider it truly different, instead of trying to find commonalities that let me use an existing bug. If those other factors you mention are used to generate a score, rather than a bug count, then that is great, yes that's the way to go. 'critical' is actually a super super hard definition. I've seen business folks call 50% of bugs critical whereas devs and qa might consider (for example) only the 5% of errors that are page 404's and 500's to be critical. – Michael Durrant Nov 22 '19 at 15:20
  • The CIA triad and buissness value are the factors that determines severity in most cases. The confidentiality , integrity and availability requirements will very between products . A backup server that will be used just weekly once won't require 100% availability , but requires 100% confidentiality and integrity. But a customer facing website requires 100% availability and so a 404 may be critical in this case . It all depends on the bug and test scope. – PDHide Nov 22 '19 at 16:24
  • I once had a UI where text was in the right and checkbox was in the left . This was hard to use for most of the users who where right handed . And it was decided to move it to the right side later – PDHide Nov 22 '19 at 16:26
1

TBH this doesn't come from the culture characteristics, if so: Indians are some of the most unaccepting of many cultures that i have worked with.

From my past experiences with Clients (Having managed many QA offshore teams)

The problem here is the way we work in Agile(Mostly)

It is highly results-oriented where all the teams(not just QA) are focused on delivering their job, thus much less focus is on the bigger picture viz. the ultimate value proposition of your application or what is the MVP or what is the job that your product is made to do.

And all this leads to what?

  • Lack of the motive for the end goal (it's all about delivering it right)
  • Disconnect from the actual idea. ( nobody really knows what they're working for)
  • Insecurity. (If you do not know what the product is supposed to do, you would rather not say anything that may sound foolish and un-related)

Thus what is more important here is educating the team about the utmost value of the product and give them time to respond instead of rushing.

Not to deny that a team of non-thinkers is going to solve any of the issues.

Of course, you can always change the team but i believe it's more about the process.

some of my great experience was with clients when we worked with them on their projects as an off-shore team(Astaqc.com) and they never treated us different, shared their goals and views, this would help us deliver them more values than shiny reports. ciao!

| improve this answer | |
0

I work as an offshore QA in India and to some extent I agree to the problems shared in this questions.

But this is not a cultural difference issue, instead it is organizational, leadership and engineers training challenge

Many companies have mindset that keeping client happy by agreeing to their all proposals would keep them in business, rather it would irritate the client when he is not getting feedback and suggestions for improvements in product and processes

You should hire a company that works as your partner rather than just QA vendors.

If the culture of the company is not to ask questions, then the engineers would be executors only.

So try to understand about the company processes and culture. You can also interview the candidates before hiring how expressive they are in sharing their thoughts.

There is definitely a advantage in onshore-offshore model, but the team has to be thinking team and not 'just follow the instructions' team.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.