Cfxtrjtrk

As a manual software tester, i ask a lot of questions/queries to my team's business analysts in email. For ex, there are some UI or functionality changes implemented, then i have queries both before development phase has begun and when in testing phase, i see contradiction in the specs and QA environment.

Now, i try my best to ask better queries to BA, like issue 1, issue 2..etc. I paste relevant screenshots/images of the issue and ask them to confirm/clarify my doubts. The problem is that BA rarely understands my points and says that she cant understand the real question im asking.

How can i structure my analysis/research on a particular issue, draft it in a well written email so that my BA gives good answers? Refer to some good material on analysis and requirements engineering , which might help?

As others have said, communicate the way the BA is most comfortable with.

Some other suggestions:

• 
  Start by confirming your understanding of the functional spec/feature behavior - I can't stress this enough. If you and the BA have a different idea about what the new feature is supposed to do, you will never be able to communicate effectively. This will also help you to find any places where the implementation has evolved from the specification and the document wasn't updated (and get it up to date).


• Once you and the BA have the same view of what the feature should be doing, ask about interactions between the feature and the rest of the application. Testers tend to have a good overview of an application and how its features work together, where BAs often focus only on their projects and developers often focus only on the code they work with. It's possible the BA isn't aware of the potential impact to another part of the system.


• 
  Phrase questions in terms of the specifications/behavior - If coding hasn't started, your questions should be along the lines of "Spec says the application will do X if Y is enabled. Y also enables A, B, and C, but C isn't compatible with X - what should happen in this case?". If coding has started, you can reference what the spec says with what the application is doing in test, as well as what you know it should be doing elsewhere.


• 
  Never blame - Just state what the specs you have say, what you're seeing, and ask if this is correct, and what should be happening if it isn't. I've lost track of how many times requirements have changed and nobody thought to tell me.


• 
  Meet with the BA/Devs - It doesn't hurt to get together with the BA and the developers to go over what the new feature is supposed to do, as well as the way customers are expected to use it. This helps to make sure you don't misinterpret the requirements, and gives you some idea of how much tolerance your customers will have for error. It's possible that they will tolerate some bugginess in areas they won't need much interaction with, as long as the areas they'll use constantly are solid.

It's not an easy question and I am not sure it belongs in SQA, but have you tried to set up meetings and ask the questions face to face ?

Many times a small demo or a few minutes of screen time can resolve misunderstandings.

See if you can get some time with the BA to walk through questions. Maybe they comprehend better by seeing than by written description. If you aren't in the same office a quick skype (or what ever tool you are using) might be enough. Or if you have numerous questions save them & book 30 - 45 minutes to cover them all at once (more respectful of the BAs time that way than peppering them with skype requests all day).

If the BA says they are good with e-mails, then ask how to better document things. Try going in with a specific example that you've worked through & ask - 'Now that we are on the same page with issue #1, how could I have structured the first e-mail in a way that would have been better for you?"

Over the years, working with many BAs, product owners & developers I've learned everyone has their own distinct style & the best way to get the product right is to adapt on the fly. I might be on a team where The BA prefers slack conversations, a developer wants screen shots & another developer prefers a phone call.
This is the "soft skills" part of our job... learning those different styles & making it all work. Challenging, yes! But also a very important part of what we do.

Also google how to write up a good defect.

Here are a couple I found just googling "defect writing".... I'm sure you'll find many out there that will be helpful.

https://techbeacon.com/write-software-defect-reports-get-results-boost-credibility

http://www.softwaretestingmentor.com/guidelines-for-writing-a-good-and-effective-defect-entry/

So here I can see two possible issues:

1. BA does actually understand your questions but they do not want to take responsibility since there might be some tricky points or areas.


2. BA does not understand your questions because you're looking at the issue from the different perspective.

In both the cases I would chase my BA with the iteratively asking something like:

What exactly in my question do you find unclear?

This will let you correct some of the points and step-by-step bring your question to the state that seems clear for all the parties.

First when you go through the Change request document, you read it carefully, inline it with current implementations and the raise queries to your BA with previous implementation and current change request, how this changes can affect, what impact it makes at that time only no?

Your sentence is self contradictory, you said development has begun and then in testing phase you had questions,
You should clear all the doubts before it goes to development and put all your points to your team so everyone knows its impact.
Asking questions at the time of testing can only lead to increasing cost of test efforts and development efforts, asking question at this phase only means that you are not clear with CR document at initial phase.

Refer

https://www.softwaretestinghelp.com/how-to-write-effective-emails-to-qa-team/

on how to write emails specifically for QA Teams.

just to be clear, the function of testing is to verify the behavior of the entity under test. the role of QA probably should not be to design or engineer the product (that is unless the company only consists of one or two people where the same person conceives, designs, develops, implements, tests, markets, delivers and supports the product.)

there is a simple answer here: use the bug reporting system to log all matters that you consider issues. if the feature or function under test does not behave as specified in the functional spec - write it up. if you have an enhancement request - write it up as an enhancement request. the purpose of the bug reporting system is to communicate information to the 'stake-holders' of the project. communicate formally via a written bug report and you will recieve a formal reply via that bug report - in this manner transparency and accountability will be assured.

A picture is worth a thousand words.Try Mindmap!

Try to present your questions/queries with pictures/screenshots/diagrams whereever possible.