In recent years, rather more than a decade now, QE has emerged as a strong entity in overall SDLC cycle. Not saying it was not previously, but companies realizing the cost of fixing bugs in production, moved emphasis on having a disconnected test team, giving them more power.
But one side effect of this is - Misuse of power.
Many times I observed QE team stepping out of their boundary and doing things like suggesting functional changes at the time of delivery (not at the time of backlog grooming, which actually is a good thing).
I remember once multiple QE's huddled around me and were trying to arm twist me in changing a UI flow which 'they thought' was right. I didn't negate, but requested them to check with Product Owner. To my surprise they wanted the change to happen then and their !!!!
Thankfully I held my position.
But many developers are not like that. Recently something similar happened, where QA reported a UI error message appearing in unexpected flow. On analysis found that it was not required at the first place.
Dug further and was surprised by the reason -
A recent guideline was given to QAs to ensure unit test code coverage for the functional areas marked as critical. (Not sure how QAs can track unit test coverage)
Blindly following that policy they asked for the code coverage for a negative scenario in a method, which was not present as per the functional flow. And hence an error message was specifically added, to ensure what QA called a proper coverage !!!!
ahem... !!!
Obviously the developer should have stood his/her ground, but to make things worse even the team architect approved the approach.
Not sure if a single person can be blamed here, but overall teams should always take a firm stance when someone is trying to encroach out of their permissible limits. Not because of pride issues, but because of the scenarios like the one mentioned above.
As usual, happy coding...
But one side effect of this is - Misuse of power.
Many times I observed QE team stepping out of their boundary and doing things like suggesting functional changes at the time of delivery (not at the time of backlog grooming, which actually is a good thing).
I remember once multiple QE's huddled around me and were trying to arm twist me in changing a UI flow which 'they thought' was right. I didn't negate, but requested them to check with Product Owner. To my surprise they wanted the change to happen then and their !!!!
Thankfully I held my position.
But many developers are not like that. Recently something similar happened, where QA reported a UI error message appearing in unexpected flow. On analysis found that it was not required at the first place.
Dug further and was surprised by the reason -
A recent guideline was given to QAs to ensure unit test code coverage for the functional areas marked as critical. (Not sure how QAs can track unit test coverage)
Blindly following that policy they asked for the code coverage for a negative scenario in a method, which was not present as per the functional flow. And hence an error message was specifically added, to ensure what QA called a proper coverage !!!!
ahem... !!!
Obviously the developer should have stood his/her ground, but to make things worse even the team architect approved the approach.
Not sure if a single person can be blamed here, but overall teams should always take a firm stance when someone is trying to encroach out of their permissible limits. Not because of pride issues, but because of the scenarios like the one mentioned above.
As usual, happy coding...
