Empowerment of SQA

This has probably become a hot topic recently. The 'scope of the empowerment' really needs to be defined. What 'powers' does empowerment include and what not? Whatever we say it 'includes', does it apply to all projects? even of different types?

SQA team, if empowered, needs definition of what they can do and what not. There can be some serious do's. For example, can they stop a software release which has many bugs? If so, can your team, your company or the client effort it? What is the real intention of this action, better quality even if it hampers project timeline and the business of the client?

There can be some less serious do's of SQA empowerment, for example: SQA team suggests to improve usability (a simple example of this: a numeric textbox takes all characters and validates and shows error later on if the input is not a number. SQA team suggests that the textbox should allow only number keystrokes in the first place). Now this sort of details may not be mentioned in the spec and so, in general, the developers argue with the SQA (may be because they feel lazy). According to empowerment do's, should the SQA be able to insist the developers to follow the suggestion?

If you want to empower SQA and try to draw some lines on their do's and don'ts then you're most likely to rediscover a simple fact.
In most of the companies, SQA teams are so much dominated by the development team that they (SQA) cannot raise their voices even if they see something is terribly wrong. It's the problem with a developer's perspective of the SQA team. In general, a developer feels much superior to a similar ranking SQA and feels he (developer) know much more and his work is the most important thing in the project's success.

So, now the empowerment is needed to make the developers feel that SQAs have some power too (!!) and a developer cannot just overlook their suggestions(?). Is this the main reason behind empowerment of SQA? if so, then let's look at the origin of the issue again. Is it again a developer's mindset and his careless or superior attitude towards a SQA? Can this be fixed? And is the officially declared 'SQA empowerment' the only way?

In Bangladesh, most of the SQA engineers cannot do programming or understand mature coding and the 'white box' is just too much for them. Some seriously lack knowledge of latest technologies, techniques and advance skills (for example, only few SQAs have ever built and installed a software on Linux command prompt, unless it's a project-specific task). So, SQAs, in general, fall behind technical capabilities of developers. This should be addressed and SQAs need much improvement in the technical areas to make a good impression with rest of the team.

Developers should learn the importance of others' comments. One developer sometimes doesn't value the suggestions of other good developers, let alone the SQAs. Horribly some seniors do that as well! This issue needs to be handled by the Project Manager or above. Developers should receive a 'clear message' saying: not to overlook other's suggestions and comments and to strongly collaborate with the SQA team.

If you can handle the root of the problem, 'empowerment' or other 'forceful' ideas might not be needed. Peaceful solutions are good for the project health and the forceful ones might not be so, rather they can introduce chaos.