Requirement Traceability matrix maps the user requirements with the test cases. In simple words, the matrix helps in determining if all the requirements have been covered(i.e there are test cases which can be traced back to the requirements).
There are 3 types of RTM:
Backward: Test Cases->Requirements
The definition of ‘functional requirement’ is that it essentially specifies something the system should do.
The definition for a non-functional requirement is that it essentially specifies how the system should behave and that it is a constraint upon the systems behavior. One could also think of non-functional requirements as quality attributes for of a ...
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 ...
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.
This is an example of building a software system for the marketplace. In this case, you have many customers or users, each of which has its expectations for the system. However, someone must have identified that there is a need for the product in the marketplace. If someone did not justify the possible need or desire for the product, how did anyone fund the ...
Make testing the focus
For a given feature that you are discussing, as a group, go through what you plan for unit tests, integration tests and end-to-end tests. Talk about how you will do performance, security and usability testing for the feature.
Discuss what makes sense to test manually and what makes sense to automate
Discuss which tests you should ...
To my understanding:
As the developer, even you will not perform this action; you will still need to test running it as part of your unit tests.
In the case of this action can not be performed due to other parts of software unavailable, you will still need to code a stub to execute it.
Back to your question:
IMO, The widget shall be able to perform ...
Review business and functional specifications on early phases. This should not take much time. Don't be afraid of asking questions and to look silly. After all this is your job to find bugs and bugs might appear not only in the code but in specifications as well.
Force your analysts to keep the specifications structured.
Use mind mapping tools when you ...
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 ...
The short-short answer - it depends.
The longer version
Despite the names and theoretical definitions, the differences in practice in my experience come down to how a particular organization chooses to use them. What one company calls a Business Requirements Document, another will call a Functional Specification. I've seen (and worked with) Use Case ...
It is not answerable. Answer is: "QA should devote as much time as needed to find out all inconsistencies in requirements, but don't waste anything beyond that". So you are back on square one.
To avoid mistakes, good judgement is necessary
Good judgement is based on experience
Experience is based on learning from past mistakes
Welcome to the evil realm of nonfunctional requirements.
The core information your teacher gave you is, in other words, "No idea, go figure something out, and I will decide if I agree with it."
And this is what happens most of the time in real world projects.
Focusing on your information: one user, local environment, we already have some valuable ...
One of the ways is Example Mapping.
All you need is a pack of coloured cards and pens and preferably a table.
Write the story on a yellow card and place it at the top of the table
Write the acceptance criteria and the already known rules on a blue card beneath the yellow card
Under each rule/AC add green cards with an example that illustrates it
I think this question is as a result of not following two of the most important testing principle:
Early testing states that testing activity should begin as early as possible. This helps in reducing the cost involved in fixing the defects. The earlier the issue found lesser is the cost. Here the cost is calculated by the paid working hours ...
I think UX is often miss-interpreted as design. Design is often an acquainted taste and therefor it is pretty much untestable, but usability testing is something different. It is important that user can use the product with only minimal training, but more important it should feel logical and non repetitive within the users mental model.
During evaluation ...
It’s better to catch the requirement ambiguities and fix them in the early development life cycle itself.
Project functionality (What should be done and what should not be done).
Software, Hardware interfaces, and the user interface.
System Correctness, Security and performance criteria.
Implementation issues (risks) if any.
You see that as a problem, I see that as normal development process in an Agile team.
There is a reason why The Agile Manifesto says
Welcome changing requirements, even late in development
Like you demonstrated very well in your question, it's very hard to know everything in advance. If you and your team really adopt Agile you will drop writing detailed ...
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 ...
The short answer: you can't prevent regression in third party software.
Third party software, as one of the comments mentioned, is outside your control. Since it's essential to your software, you have a few options in how you handle this.
Regular smoke tests - Have a set of smoke tests that cover the essential functionality of the third party ...
I'd also add that seeing the story beforehand is a good way of making the Three Amigos session more likely to provide benefit.
Thinking up questions and issues on the spot when you've only just seen the story is a lot harder versus having a day or so (or even an hour or so to be honest).
Assuming that you are asking if there is some kind of typical measure of how many requirements for a given system are in fact incorrect in some way, the simple answer is it depends.
Is a requirement that turns out to be unusable once implemented a defective requirement?
What about one that the customer insists they want then never use?
Do you include the ...
As a QA Tester, you can take some time out before starting testing and using that for writing extensive use cases which will cover most of the scenarios. This will help you in later stages. However, no matter how much you strive to think all use cases, some are missed. We tester are humans too.
Let the business analyst know about the specification they ...
Ensure the requirements address the objective or its purpose.
Ensure negative scenarios or conflicting workflows of the requirements.
Define scope of the requirements. What is covered and what is out of reach and why.
Define performance parameters, unit test requirements, pre and post conditions of the environment.
Define additional or supported libraries ...
When I read the word requirement my spline shivers. It is just an idea, probably a flawed one, it is definitely not required. What that blog describes is traditional waterfall, where the costs go up if defects are found in later stages. Nor does it give any proof that lack of requirements analysis leads to the most defects, I just don't believe it.
It always boils down to the question of how much documentation do we actually need and when does it start to become waste. Waste is documentation no one ever reads or uses. I think a lot of this documentation waste is created in the world. Its our task to minimize it :)
So to answers your last question
Which document out of all serves best to assure ...
Write Test Cases based on the requirements
Clarify any assumed requirements
Begin Testing at the requirement phase
Requirements should be:
clear and specific with no uncertainty
measurable in terms of specific values
testable having some evaluation criteria for each requirement
complete, without any contradictions”
The requirements ...
First, I'd suggest you read widely: the blog list at the Ministry of Testing is an excellent starting point and will guide you to more resources (disclaimer: I have published a few articles on their related site, the Testing Dojo). I check their blog list daily, and usually find at least one article that gives me a better perspective.
Second, if you don't ...
I think you've got caught up in english language differences. "Shall be able" is getting into an odd tense where we are talking about the future. With testing we are talking about the present - running the tests now and seeing the results now.
For testing purposes
The widget performs the action
Also you may wish to consider approaches such as: