It’s no secret that QA is considered second-class citizen in the Indian IT industry.
As the OP of this LinkedIn Post says:
I interact with a very large array of decision-makers on a daily basis. I am surprised to see many stakeholders not aware of the importance of the role of QA and the need for one. This is a very common occurrence. Secondly, I have been part of multiple conversations and seen instances, in my career, where QAs were clearly discriminated against. From multiple perspectives, promotions, appraisals, opportunities, exposures, roles, etc. Many conversations have had a condescending tone.
Ditto BPO. The output of BPO is arguably more mission-critical to the customer organization than the work done by DEV and QA workers. But BPO has even less cachet than QA (not to mention DEV).
Whenever a DEV demeans QA to me, I throw the gauntlet back at them with the following go-to response:
If you develop zero defect code, I’ll fire all QAs and redistribute their salaries to you.
Not a single DEV has taken me up on that challenge yet!
I also doubt if anyone will for I’ve heard veteran engineering leaders say, “Putting bugs is our birthright!”
Some people wonder if this is still happening in 2021.
Yes, it is, going by the aforementioned post and my personal experience in Indian IT Services companies – though not in startups and Indian subsidiaries of MNCs, which have different culture and business models.
If it’s any consolation, it’s not only QA: UX / Design is another function that gets the wrong end of the stick in Indian IT Services companies.
In the standard SDLC (Software Development Life Cycle) followed by IT Services companies, DEV happens before QA and QA is closer to GO LIVE.
As a result, DEV gets favorable exposure whereas QA gets unfavorable exposure.
Was a time when testing was an afterthought and project plan had no QA phase.
Slowly, QA entered the project plan. But it still played second fiddle to DEV because of the way software services sales works.
To win a deal, a vendor needs to tout CMM Level 5, ISO 9000 development processes, great quality of programmers, blah blah blah. After doing all that, it’s extremely difficult for sales to justify a high headcount for fixing bugs, which is the primary function of QA. As a result, while sales emphasizes quality, it tends to soft-pedal the QA team.
As a result, the QA team falls off the radar of the project sponsor. This resonates strongly with the aforementioned LinkedIn post: “… many stakeholders (are) not aware of … the role of QA.”
As anybody who has worked for any length of time in an IT services company would know, when your customer’s honcho doesn’t know of your existence, your big boss is unlikely to think too highly of your function.
The OP of the aforementioned LinkedIn post advises QA to pivot its role from catching bugs to Quality Assurance. While this is a noble goal, the big risk with this approach is that the customer will refuse to pay for QA headcount, which will put a huge strain on the project profitability. (IT Services companies do have a Quality Assurance function but it’s structured as an internal shared service across all customer projects and not billed explicitly to any one customer.)
Agreed.
And a lot of DEVs I know consider Critical Thinking as "Reflexive Pessimism / Cynicism". No wonder there's a lot of Dev QA conflicts.
To be fair, many DEV realities like business apathy, unrealistic release deadlines, etc. can't accept too much Critical Thinking.— Ketharaman Swaminathan (@s_ketharaman) January 7, 2022
An automobile manufacturer can spend 25% on DEV and 75% on QA for all he cares, and the customer won’t complain – because she doesn’t know the breakup.
Ditto a software product company.
In contrast, by its very nature, an IT Services company needs to provide visibility into headcount deployed on DEV versus QA. This gives Sponsors a lot of ammo to pushback on the QA component.
Many other PSO industries like architects and law firms historically faced this problem. They overcame it by cleverly converting many explicit costs into implicit costs, so that their customers don’t get a chance to question DEV v. QA headcount.
The same can be done in an IT Services company. It requires packaging skills.
That makes it a marketing problem. And one more area where the Indian IT industry needs sellers and marketers more than engineers, as I’d argued here.