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 1:31 AM
User is offline MadiMo
31 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 10: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 12:44 AM
User is offline Stewart F
119 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 6: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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC