I started off by explaining how we, developers used to see these QA people. QA people are the first level customers, who try out the product and tell the possible improvements before we ship the product to the end customers. Moreover they are the people, who thinks from the end user's perspective and drive the product development in a such a way to deliver a usable & less buggy product to the end customers. To be precise, they are the worst enemies for the developers, who are lives in the near qubicles. Anyway these harder part of the relationship between the developer and QA need to be handled through one the Bug reporting tool (eg: Bugzilla). But verbal communication should be so friendly, so that bug could be explained in a friendly manner to come to a common agreement to fix the bug. I believe QA is more professional when they act as a mixture of worst enemy & a good friend with the developers. They need to believe themselves as a customers to get the thinking right.
Even each of the QA guy should seriously think about their career and need to find the ways to improve their ways of testing. They are in a situation to prove themselves to the developers. Then only, your justifications for your reported bugs will be given respect from the developer's side. As a Developer I know how I rate a bug based on that person's abilities. Some guys can be good with the scripting so they can choose one of the scripting language to write some of the scary performance testcases to find some of the performance bottlenecks. Some people are good at lateral thinking ability, they are the kind of guys, who prepares the testcase scenario document to come with the testcases for the both the Success/Failure scenarios in few hours. These sort of special abilities will simply helps you to build a self confidence among yourself as a QA person and the developers will show a lot of respect, based on your way of testing. Each QA Engineer should find their strength and improve on it to create a respect for yourselves among the team. This will make the developers to believe that, these QA guys know something special.
Requirements are the base for the QA Engineers to refer and test. So they need to make sure these requirements/changes are captured properly. When you follow a agile process these requirements will have a change every other day. These changes are going to be badly affecting the development + QA testing process. These change of requirements will be communicated with ease depending on the relationship, you have with your Requirements engineer. There are instances these requirement communications will happen without the knowledge of the QA engineers. So they will be surprised to see the note within the release email and enough preparation will not be there to tackle those new requirements. So QA Engineer need to have a proper communication with the Requirement engineers to get the proper update. I strongly feel they need to be much closer with Requirement engineers than developers to get the advantage of knowing the what is happening around in the requirements side. They can use the following tactics to move closer to the Requirement engineers
- Help the Requirement engineers by reviewing the SRS and give your feedback which considers the corner cases, which were not addressed
- Actively participate in the Internal requirement knowledge sharing sessions. Show your presence by asking the sensible questions
- Try to share a spreadsheet kind of document to raise your side of concerns regarding the requirements. Try to come up with something important to make a point.
- Always give pressure to the Requirements Engineer on the parts, those are not addressed clearly. Ask more questions and give more suggestions to have a good SRS. At the end of the day, QA Engineers can contribute to the quality of the SRS as well.
When Requirement engineers are benefited by your efforts, they will try to consult you next time before going for a possible change in the requirement. So rarely these new requirements can sneak in without your knowledge.
Anyway this is from my point of view. I feel one person can be a good QA Engineer when he/she enters in to the Developers' dream to threaten them with a tough bug :). The more you scare the developer the more you contribute to the project.
