Saying No to QA Leads

Business Analysts are important people in the QA process as they deliver the value of requirements to testers. However they are also responsible for the entire Requirements package and are, at times, forced to say a solid “No” to people like QA Leads, which is difficult hence it’s his team you are currently caught in working with and his experience and proficiency as well as deep knowledge of all QA related matters have lead him to his position. This may be intimidating at times.

However requirements do change, various processes take longer than expected and choices, difficult choices have to be made. Choices you, as a decent Business Analyst will be held responsible for. And if something fails you will be, without hesitations, able to take the blame proudly and if things work out the achievement will be 100% yours. However you are not a one-man army and opinions of others, especially QA Leads who are experienced also do have to matter and affect your own point of view. Where does one find balance? When and how should you say your ‘NO”?

  • Imagine the situation when final requirements are demanded by testers but are not quite done yet. You are going to be forced to communicate with the Lead and to explain him why should testers move forward without any final requirements. If the QA Lead insists on the delay you must make sure he fully understands why the path you have chosen is the best possible option. However you should never haste. Move only with the parts of testing that may be done without defined requirements. Don’t go fast forward with it all.
  • What if testers are running late? It depends. Are the deadlines negotiable? If yes, combine your effort with QA Lead’s and try advocating why extra time is essential. But, if not, things do become a little bit trickier. You will, eventually, have to determine which processes have higher priority and you will face a necessity to settle all that with the QA Lead and he may not agree with you. Remember, you are the one responsible and decisions have to be made by you.
  • Testers want to do more by doing less. Skipping parts does not save time (in larger perspective) and certainly does not increase test coverage. Most commonly integration and regression are neglected. But this is risky and you should definitely talk to the QA Lead if something of this sort is happening.

Surely these are just few examples of a vast amount of various possible scenarios, however they should definitely set you up on the right track. Do you have anything you are willing to add? Please share on the comments.


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Images are for demo purposes only and are properties of their respective owners.
Old Paper by ThunderThemes.net © 2017

×