Hey, would like some advice on the above. For context I am a software dev.
For story work, we usually get attached functional tests with a bunch of scenarios I am then supposed to satisfy. These are created by the QA which then is reviewed by the PO and the team lead before the story is handed over to us.
When it comes to writing the code to satisfy these, it becomes apparent that some scenarios make no business sense at all. If I implemented them as is, the code wouldn't work and the business wouldn't get what it wants. I then have to confirm this with the Dev lead, talk with the PO about what I think he meant, rewrite the scenario, then wrote the code for it.
The problem is, I don't want to be doing this step to fix the incorrect scenarios . IMO the scenarios should be pretty bulletproof before they get to me, it's making me lose confidence that the work I'm being asked to do is well understood by those that have given it. It's kinda defeating the point of the functional tests if the story fivers don't know it should function.
Is this a fair assesment by me? Or am I being too harsh? Any suggestions on how to improve this? It's been happening for a long time now and I'm at a loss on how to approach it.
submitted by /u/rfrenchy911
[link] [comments]
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/2ZSNJDi