Where and how V&V applies in an agile context?
I joined a company that is leaving the waterfall approach to implement a SAFe (scaled agile framework) one for developing. I'm part of the Quality Assurance team. Before we had requirements register and fixed gates, so verification and validation were easy because verification was done by using the well written architecture, FRs and NFRs, and validation by testing with use cases and showing/"pre-releasing" to the customer.
Now I'm really confused since we have no more the requirements register and I don't know what should be tested because of the vague and just in time acceptance criteria that we have in features and user stories. And the architecture/ux is not available until the end of a feature...
Example of what we have:
Epic: Tool to create cooking recipes
Feature1: Ingredients selector tool
- Acceptance cr1: web application
- Acceptance cr2: using Ingredients from doc1
- Acceptance cr3: basic authN and authZ
User story1: As a user I want to be able to login to my application
- Acceptance cr1: possible to login using email and password
For me AC1 and AC3 of the feature1 are too vague and I don't know how to test them. They could mean everything. I really don't know how to apply old V&V here.. and it seems also impossible to perform system testing /E2E testing when I get these features/stories... until the dev is done I really don't know what test cases I should write.
I don't know also if the user should be able to sign up and what data should he give. Don't know also what if the user wants to add new ingredients..
Can you help me understanding how can I verify/validate the system like I used to in the previous approach? I know that this is a really huge topic, but I cannot find any information on the internet regarding this, only theory with no or incomplete practical examples
If you can make examples it would be great, thank you!
Can you help me understanding how can I verify/validate the system like I used to in the previous approach?
Agile does not mean vague. Quite frankly, you are right. Those acceptance criteria you have problems with are just bad. That has nothing to do with agile of any kind. Acceptance criteria should be testable. If you as a QA person do not know how to test it, how would anybody know? It's called Acceptance Criteria so they can be validated and accepted. Your examples cannot.
The only way out is to write better acceptance criteria. Maybe whoever wrote them for your new agile stories can ask the people who wrote them before how to do it. I would say acceptance criteria are probably the one thing that has not really changed except maybe in name. They cannot be vague, or they don't work.
It's not your fault. Somebody threw out the baby with the bathwater. I guess the people writing the stories in agile are new to this or just overworked with all the changes they are going through.