During a recent campus hiring visit to a reputed engineering college, a student whom we had shortlisted after multiple rounds of interviewing for an entry level QA engineer position seemed to have some doubt lingering in his mind regarding the role on offer.
In the final HR round, the student decided to speak up and popped the question - whether QA engineers were "below" Developers in the organization? The HR representative promptly called me to clarify. As is my wont, the expectation was for me to (over) sell the QA role. However, on calmly listening to the student's question and his source of (mis) information, I decided to play it even. I did accept that there were/are organizations where QA engineers are perceived as lesser cousins to their development counterparts. However, the QA engineers and their management need to share a part of the blame for this state of affairs.
If your QA team is seen as a non-technical entity, who cannot converse and actively engage with Development and other functional groups in their language then you deserve to be at a level below the rest. While black box manual testing is good and important, testers must constantly acquire and renew their technical skills to stay relevant. Else, the tester stands out like a sore thumb who needs a fair or more amount of spoon feeding and hand holding. Wouldn't it be wonderful if Developers and Testers worked side by side, treating each other as equals and challenging one another in the pursuit of better quality software deliverables? To do so, the QA team needs to raise the bar of technical competencies expected from testers to a level wherein they can clearly understand the architecture, design, requirements and the code to a large extent. Rather than divide testers into the specialist black box (and thereby perceived as technically challenged) and specialist white box groups, testers must evolve to take the best of both worlds while ramping up on technical competencies.
Testers need to earn credibility and I have seen quite a few such testers who are experts in their product/area/technology/domain to the extent that other functional groups ping-ed these testers when they had queries that need answering! Were these testers seen as second level citizens? Of course, not ! they were considered as respected peers and key members who had to be involved in decisions impacting the product/project.
Every organization needs to see the value of testing and testers. Yes, all (ok most) organizations tend to think that testing is a necessary function and testers are necessary parts of the production process. However, the degree of importance accorded to testers is directly proportional to the perceived value of testing. What can testers do to impact this value perception? Think about it !
Getting back to the student, I did explain that in the context of the organization he was being interviewed for (namely the organization I represented), we do not discriminate or think QA engineers as being less important than Developers. Of course, the student needed to do his part once he's on board in terms of earning his credentials and respect. He had to demonstrate his ability to quickly grasp the area he would be asked to work upon, ask intelligent questions, make efforts to expand his knowledge of the area and domain both breadth and depth-wise, have an insatiable thirst and commitment to excellence. Both Development and Testing are key to producing quality software with well defined and challenging career options in both areas.
Note: In the above post, I have used the term QA liberally to refer to testing. I am very well aware of the QA function and how QA literally isn't testing. However, I have come across various organizations and groups where Test engineers are referred to as QA engineers and the usage was in this context. As the bard would say, a rose by any name would smell just as sweet!