Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria
Previous Previous
 
Next Next
New Post 5/1/2019 2:31 AM
User is offline MadiMo
19 posts
9th Level Poster


Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 

Hello,

I am having a confusion between the practical definition of a Requirement, Requirement Acceptance Criteria and the Testing Acceptance Criteria.

I understand what each definition means, however, an acceptance criteria to me re-states the workflow that must be followed to consider a user story done, for example:

This is a user story that says

As a content editor, I would like to update the content of my product, so that I keep the customers aware of the latest special offers.

The Requirement Acceptance Criteria could be:

Ensure the content owner is able to :

  1. Log in to the Content Management System
  2. Edit the current price
  3. Set up the offer timeframe

However, such acceptance criteria does re-instate the Functionality Workflow, does not it? In that case what is the difference between this and a Requirement?

Other people would say that an acceptance criteria for this feature is simply as this:

Ensure that 8 out of 10 users are capable to edit the product details in less 4 click interaction.

So which one is the best written acceptance criteria? Do you write it based on the Testing View or the Requirement View?

 

Many Thanks for your kind advice

 
New Post 5/24/2019 11:13 PM
User is offline Krishna 02
2 posts
No Ranking


Re: Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 

Hello

Thanks for raising this question. Keeps coming up multiple times in my mind and maybe others too - when we actually apply tools like user stories / acceptance criteria in real life assignments.

I feel as a BA, its our constant attempt to present requirements / solutions in ways that can be understood by both the user and developer. Tools / templates facilitate this sync up.

Maybe there is no single way of using these tools. Guess its fine to use them in our own way, to suit our situation - so long as overall objective of clear communication is met.

In given example, i like the way user story and acceptance criteria is written. If i read it wearing both User & Developer hats - the User story is giving me the context (what this requirement is about) and Acceptance criteria is giving me next level of details (what does "update the content" relate to).

Maybe User also expects the 8 out of 10 and < 4 click requirements. I would believe these are non-functional in nature, but a BA should tie these up and can add it to the above Acceptance criteria.

Just sharing my thought process, would like to hear views from you and others too !

Thanks and Best regards

Krishna

 
New Post 7/17/2019 1:44 AM
User is offline Stewart F
98 posts
7th Level Poster


Re: Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 

 

Hi MadiMo, it slightly depends on what methodology you use, but to be as simplistic as I can:

Requirement Acceptance Criteria

This tells your developers (if it is a system requirement) what the least that is expected is. So the 3 parts that you stated could indeed be the minimum that is required in order to meet the requirement. 

Why do you need a minimum level to meet a requirement? Well, typically Developers or for that matter anyone else who is responsible for making the requirement happen, will probably interpret your requirement slightly differently to how you intended. Developers are especially good at doing this. So your Requirement Acceptance Criteria is just that - "What must a User be able to do in order that this requirement can be signed off?" Normally, you wouldn't write this separately to the overall requirement in a User Story or Business Requirements Document, however, I tend to get my team to separate them out so that you end up with sub-titles:

(The following is if I am writing a User Story in Agile, but it applies to the more traditional Waterfall)

The basic thread "As a User, I want....."

*Business Requirements

*Technical Requirements

*Further Information

*Requirement Acceptance Criteria 

Testing Acceptance Criteria 

This follows the same as the above, with the exception that at this stage the requirement should have been built. The TAC basically just states what the bare minimum the Testers should test for, should be. So in your example a Tester should test that:

  1. That a User  can log in to the Content Management System
  2. That a User can edit the current price
  3. That the system/User can set up the offer timeframe
The Testers will also test other things as well, but they should derive that list from the Developers as well as their own experience of what to test. 

Again, the TAC is described as a part of the User Story or Business Requirements Document (Both usually have a separate section for writing the TAC. 

Why would you want to have either? Well, in short it helps you to make sure that you get the requirement signed off by the Stakeholder when development is complete.

 
New Post 8/9/2019 7:03 AM
User is offline fouadbokholef
2 posts
No Ranking


Re: Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 
Yes this is realy true i agree totlaty with you on this point
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria

Community Blog - Latest Posts

Rajesh-N
Rajesh-N
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
0 Responses
Ashish Adike
Ashish Adike
As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very ...
0 Responses
m_anst
m_anst
What Does Success Look Like? I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescripti...
0 Responses






Latest Articles

The Art of Letting Stakeholders Have Your Way
Nov 23, 2020
0 Comments
Study after study in behavioral science show that certain approaches are more effective than others when we’re trying to convince others to see ...
Copyright 2006-2020 by Modern Analyst Media LLC