0

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!

Improve this question

2 Answers 2

Reset to default
2

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.

Improve this answer
5
  • Hi, thank you for your response! Yea, for sure these changes are affecting a lot the process.. But everytime I try to tell the team that these ACs are broad,, they will answer with something like "we cannot think about everything now, otherwise we are waterfall, we will maybe give more details in the user stories, but not every detail". Is this something correct? To have a feature with broad acceptance criterias and user stories that are linked to these acceptance criterias with little more detail? Moreover, should the user stories be completely defined when the feature is written?
    – Dev
    Jan 13, 2022 at 8:00
  • 1
    Make sure you get to discuss this with the whole team in your Retrospective - ask your Scrum Master to ensure it's covered. Explain why the vague ACs are hampering the team's ability to deliver. Once the developers understand that it's a whole-team problem, solicit ideas to improve the situation. In our team, clear ACs are part of the definition of ready: a story mustn't be planned into a sprint without them, and we check that when the developer picks up the ticket to work on it. Maybe that could work for you.
    – Toby Speight
    Jan 13, 2022 at 8:40
  • 1
    @Dev No, writing all the user stories to completion beforehand would indeed be waterfall under a different word template. But a story must be complete (including acceptance criteria) before it get's into a sprint to be worked on. If it's incomplete and vague when someone has to imeplement it, it's broken. I agree with Toby here... have a definition of ready and check that before you work on an item. Vague, untestable ACs are something that should bring the story back to the drawing board.
    – nvoigt
    Jan 13, 2022 at 9:08
  • Thank you guys! I'm really glad to have this conversation. I agree, I'll make sure to have an agreement with the team about the definition of ready. @nvoigt regarding the process, say that for this PI we plan to do some features and they have good ACs, when we break them down into user stories, each of them should be related to an AC of the feature? I'm asking this because looking at the example here, it doesn't look like that scaledagileframework.com/story . Thank you again for your time.
    – Dev
    Jan 13, 2022 at 19:42
  • AC on a story should relate to the story and be testable with just the story complete, not the whole feature. The link you posted, under "Confirmation" the examples for acceptance criteria look very nice and testable. Maybe you should use those as examples when talking to your team.
    – nvoigt
    Jan 14, 2022 at 7:50
2
  1. Here is a link that outlines how to write good acceptance criteria. Some highlights:
  • Each acceptance criterion is independently testable.
  • Acceptance criteria must have a clear Pass / Fail result.
  • It focuses on the end result – What. Not the solution approach – How.
  • Include functional as well as non-functional criteria – as needed.
  • Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story.

  1. Agile gives priority to "Working software over comprehensive documentation". So, you have to get used to the idea that there will not be any requirements register, well written architecture...etc.

  2. You should participate in the Backlog Refinement and Sprint Planning as a full-fledged dev team member. Take the initiative and contribute to developing good and testable acceptance criteria. Put yourself in the shoes of the user and visualize what typical users will be looking for and what they tend to do in the UI.

Improve this answer
4
  • Hi, thank you for your response
    – Dev
    Jan 13, 2022 at 8:00
  • Yea, I know that we should be more involved in these events, but I still struggle with the lack of documentation. Is it possible in agile to have document that sums up the needs from the customer? I'm asking this because many times I was added to a project in the middle of the development and unless I went through all the features and user stories (hundreds of them) I had no way to check what the customer asked. And that is a problem for me as a QA team member. Thank you again
    – Dev
    Jan 13, 2022 at 8:05
  • @Dev, the only documentation that is discouraged in agile is the documentation that is never read by anyone (with the possible exception of the poor soul who has to maintain it).
    – Bart van Ingen Schenau
    Jan 13, 2022 at 9:22
  • Thank you, Bart
    – Dev
    Jan 13, 2022 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.