Tag Info

New answers tagged

0

Selenium IDE allows you to walk through a scenario and add assertions to check it works as expected. which you can then save as a file you can play back later. It does have a few limitations. the extension only works in firefox. checking for visual changes may be difficult. ( it looks like you can check css properties )


5

The key thing to consider here is whether your stories are manageable chunks of work. To be manageable they need to be: Unambiguously defined Fairly easy to estimate Completable within a sprint So, if you find that merging two stories somehow compromises any of the above points, then don't do it. Personally, I prefer working with many small stories as ...


0

I think it really depends on the stories themselves, are you going to differentiate the process or administration of the two tasks? I could envision a scenario where there really is no difference beyond whether or not you are creating a new record. This could be done as a single story. I could also envision a scenario when only certain admins can create ...


2

TL;DR They ought to be two separate, but related requirements. The risk in running them as separate requirements is that you'll have duplicated code for the associated UI and underlying services. But the risk in combining them as a single requirement is that the edit path has a slightly different setup to it. A create path would look something like ...


2

I think that Option A, with separate user stories, would be preferred. User stories are requirements. There are a set of characteristics of a good requirement that tend to be well accepted. Option A ensures that your user stories are cohesive (addresses one and only one thing), atomic (does not contain conjunctions), and more easily verifiable than Option ...


-1

This is a big mistake because the time that I will spend in the refactor of the special and complicated login system will not be paid. There is a big red flag showing you what has gone wrong. The problem was embedded in this project before any changes were requested by the client, they were there before the code was even written... Authentication and ...


4

Contract matters This is a big mistake because the time that I will spend [...] will not be paid Actually, the big mistake is that your contract makes it possible that you spend your time working for free. It doesn't matter if you are solving a bug or learning a technology required for a new project: the customer has to pay for the time you spend. You ...


1

Sure, rapid prototyping can lead to frequent changes on your APIs for a duration of time, but I will expect changes to eventually mature and stabilize after requirements fall into place and you can essentially do an 'API freeze'. If you are making changes to undo past changes, then you may be getting ahead of yourself and straying away from the You Aren't ...


-1

If my requirement is a new report and my assumption is that - the data required already exist in the application, is that not important? I need to make them aware for when they quote me, just in case they didn't know. I think assumptions are important. and are not necessarily requirements



Top 50 recent answers are included