Considering Agile software development process. Is it a good practice to ask developers directly for requirements rather than the product owner? The development team had already gathered some requirements from the product owner, as they are ahead with development. Ideally, from whom QA should gather the requirements?
3
-
4How does your agile environment look like? It sounds like the testers are not part of the team....?– Ray OeiCommented Mar 12, 2019 at 10:56
-
Teams works independently.– Shubham TakodeCommented Mar 12, 2019 at 11:18
-
1This is what ticketing systems are for: the requirements, or description of behaviour, should be written in the ticket.– pjc50Commented Mar 14, 2019 at 13:02
Add a comment
|
10 Answers
No. Requirements should be originated from a single point. Your developers might misunderstand something so that you'll be testing not what your stakeholders require but what your developers implemented (effect of a broken phone).
Asking your product owner will let you catch the gaps between what the business expects vs what your team actually implemented.
answered Mar 12, 2019 at 11:25
-
3I agree that there should be a single source of truth, i.e. a product owner, but it may make sense to ask developers about requirements in addition to asking the product owner. If they do not match that might be helpful to identify misunderstanding earlier (if the requirements have not been implemented yet) or focus tests in this particular area (otherwise).– dzieciouCommented Mar 12, 2019 at 11:56
-
What if the product owner is not aligned with the current state of the application, and the team made a conflicting decision, because good reasons? Probably you should consult both the developers and the product owner. Commented Mar 12, 2019 at 13:08
-
Yes, but consulting does not mean asking for requirements. Asking both devs and PO means just a doublework. There could be other roles in the team, so in this logic adding new role would add one more step to negotiate the requirements. If the product owner is not aligned with the current state then there are serious issues with company processes. I'm not saying that QA may ask devs about the source of their vision of the final product. But this is rather the exceptional case. Obviously not the "ideal case" the OP's mentioning in their question. Commented Mar 12, 2019 at 13:23
-
2Probably you're right. Probably they failed together with scrum Master. But. Developers implement the functionality. They might introduce defects and there could be several reasons for that, for example improper understanding the requirements. We're not discussing here how well a hypothetical PO works in a hypothetical team. We're discussing the effective and reliable way to communicate requirements to the team Commented Mar 13, 2019 at 6:31
-
2This is absolutely right. Part of QA's job is to make sure that the developers understood the requirements properly. If they didn't, then QA got the same wrong message, so most of the purpose of QA is lost. (The other purpose is to find QoI things, like outright bugs or crashes or horrible UI windows, which will still be possible.) Commented Mar 13, 2019 at 16:15
I wouldn't say it's "good practice" to ask the developers for requirements, as they'll have their own interpretation of them.
If possible, always try and get your requirements from the business analyst or product owner (if they're the requesting the change or providing the requirements).
You can ask the developers as a last resort... but take what they say with a pinch of salt and challenge them (always ask 'why') if the changes don't make sense to you.
-
I disagree, Agile development teams should have the freedom to change requirements if it helps them to reach their goals easier, better or quicker. Now the code is the only truthful implementation of the requirements. So I would try to get the info from the full team, e.g. Developers, PO's and any other person in the team. Commented Mar 12, 2019 at 11:20
-
3Developers should be the enablers for change, not the definers. That would also remove the need for BA's or PO's. If the requirement is for a background to be blue but they decide it's better in green... then what's the point in having requirements (or a BA or PO) in the first place?– dvniel ♦Commented Mar 12, 2019 at 11:27
-
The PO is to maximize ROI and steer the what, not detailed requirements. I would rather have a development team that decides green is better then blindly following requirements. Read about the 41 shades of blue at Google. Therefore I dont see a need for BA's or other disciplines in Agile teams, although having expertise might make the full team stronger, silos wont. Read: theguardian.com/technology/2014/feb/05/… Commented Mar 12, 2019 at 13:04
-
1Focusing on the challenge to be solved and not how to solve it. Teams should have room for creativity. “If I had asked people what they wanted, they would have said faster horses.” - Henry Ford Commented Mar 12, 2019 at 16:20
-
1@NielsvanReijmersdal "Agile development teams should have the freedom to change requirements if it helps them to reach their goals easier, better or quicker." Nothing could be further from the truth. Your team should feel free to go and talk to the product manager and suggest changes, and Agile should enable them to incorporate changes into their workflow if the product manager decides that the changes are warranted. But developers absolutely must not be altering the requirements on their own recognisance. That's crazy! Commented Mar 13, 2019 at 16:16
Ask your team, maybe during the Daily Standup? Saying your impeded by lack of requirements details. The team can now decide whom is the handiest to assist you. Hopefully the Product Owner is at the Daily Standup and can help you, but at least the Team coach (e.g. Scrum Master like person) can try to support you to resolve the issue.
I would expect the whole team to be aware and aligned of what they are currently focused on, including the acceptance criteria. Sounds like you are not part of the team, or not working together closely enough.
Also the Agile Testing Manifesto suggests:
We value testing throughout over testing at the end.
They suggest testing is an activity, instead of a phase or handover. You could be working on the same details as the developers have in parallel.
answered Mar 12, 2019 at 11:18
-
1Thanks this is exactly what I think. Also our product owner never participates in daily stand-up :( Commented Mar 12, 2019 at 11:21
-
1@ShubhamTakode That's an important detail to add to the question. But it probably means there is no answer in Agile methodology because you're not really doing Agile. Commented Mar 12, 2019 at 15:27
-
2@TKK Agile does not mean the PO has to be at the standup, but a lot of teams showed it has value. We could argue requirements are also not very Agile. The it is not really Agile comments do not really help, better suggest inspect and adapt :) Commented Mar 12, 2019 at 15:48
-
@TKK I'm not the type to religiously do things by the book. I'd agree that the "not really Agile" comments wouldn't be constructive, except that the OP specifically asked for an answer within the Agile paradigm. There isn't one. Commented Mar 12, 2019 at 17:01
Whatever you do, don't create a situation where developers are inhibited from making small improvements because the process for establishing requirements is too heavyweight, or because input from developers is undervalued. That's especially the case if developers have a good level of contact with users. Product owners sometimes are too immersed in high level business strategy issues to recognise that what users really need are little tactical improvements; if developers talk a lot to users they may have their ears closer to the ground.
I don't think it's a good idea to ask requirements directly to developers rather than the product owner. A product owner should always be centre or common point during the development process.
Lets consider, if we ask requirement directly from developers than they(Developer) will share only those points whatever they understood from product owner...that requirement will become basis for you at that point & if there will be some communication gap between (Product owner >> Developer), then this gap may increase when this requirement pass to another link of the chain (Developer >> QA) & QA will test product based on requirement shared by developer. In this case, it's will be very difficult to decide what is right or what is wrong. So the requirements must be a single source.
answered Mar 13, 2019 at 6:45
Some interpretations of the agile process have only the three roles: product owner, developer, and scrum master. That leaves the QA as developers with a particular skill set. So they can ask their fellow developers at any time, and they can also ask for clarification from the POs at any time (but ideally during refinements).
If in any way possible, clarifications should be requested before the sprint planning since clarifications should go into the acceptance criteria.
Even if QA are separate from the developers, as in your case, they are IT professionals with a distinctive view on the requirements and acceptance criteria, and they should always check acceptance criteria for testability before the sprint starts -- a criteria that cannot be tested may be a bad criteria.
Summarized, QA should be present while developers talk to POs, they are entitled to have an opinion on requirements from their own specific part of the team workload, and also in a general way as part of the team effort. Doing that would change the nature of QA, however. They would no longer check on the developers' work for the stakeholders, instead they would with the developers in fulfilling the acceptance criteria of the POs.
If you're doing agile then no, the development team should definitely not be your source of requirements - this comes from the Product Owner or, potentially if they are not available, a business analyst.
As noted elsewhere devs quite possibly will have their own interpretation of requirements which may not match the testers' understanding. This is why you should have some kind of implementation of the 3 Amigos early in the development process to clarify everyone's understanding of the requirements.
QA should not rely on Developers for requirement. But they need to work with Dev and BA collaborate way. Specially after requirement analysis done and when they come up with test scenarios, those need to review with BA ,DEV
Product Owner (PO) or the person who is authorised by the Product owner. Sometimes, a Business Analyst (BA) or a Requirement Engineer (RE) who would be authorized by the PO to clarify and define requirements. Even in that case, the PO will have the final authority.
Please note nothing stops you as the QA to discuss with DEV on requirements. I find the below two benefits from such discussions.
- As a QA, you could provide some nice insights about the requirements which you think DEV might have missed out.
- As a QA, you would get some insights from the DEV, which could make you rethink about your understanding on the requirements.
It's not a good approach to ask the developers for requirements. Especially in the world of agile methodology, there will be little or no documentation at all. Two recommendations:
check if there is any possibility to get something like a use case
from your experience, hands-on with app knowledge and insight, create test case and discuss it to ensure the functionality checks you added are enough to cover the scenario.
