New answers tagged

0

For testing purposes take small steps. I think the best way is to prepare the scenario with the fake and small database instead of the real production database. You can copy some of the rows and as soon as you succeed then try for the real data.


0

I set up the appropriate data as part of the givens. That way the scenario is completely self-contained. Having a test database requires tacit knowledge (which customers are considered "active"?) or end up with data for obscure corner cases (I need a customer with two previous purchases and three items in their current basket.) And I agree with the other ...


2

You shouldn't have to have a production working database in order to run your tests. Also, querying and altering a production database when doing tests is generally a pretty bad idea. You want your tests to work in isolation. So, make a fake customer before your test. Use it. Delete it. If the creation is too complex, you could prepare a whole database for ...


2

The best practice is a third option. You create a separate test database with known contents and you write your tests against that. In between test cases, or in the set-up a test case, you make sure that this test database contains the known, well-defined data set, so that changes made in one test case don't affect the next test cases. I would never write ...


4

What has happened here is that you've discovered value. The input value was not thought of when the story (and acceptance criteria) was written or when the code was written. If it's not part of the acceptance criteria, you don't really have a basis to reject the story. What we would do on my team is: Create a Bug detailing expected and actual behavior. ...


3

Some observations: ...when I reject his stories I don't know your work culture or process, but to me rejecting a story is a severe step. If I were the dev, I would also generate push back on that as it is a recorded action that reflects badly on me and on the team. He says its unfair since I don't specify the edge cases. It's unfair of him to ...


11

The team needs to work together as opposed to having a "Not my job, not my responsibility" type of attitude/mantra. Acceptance criteria comes in the form of: Business Acceptance Quality Assurance Acceptance Typically the business acceptance is usually answering the question: Does the feature that has been implemented do what I want it to do? The ...


5

Writing software that behaves in a robust manner in the face of incorrect or ambiguous input is an essential part of a software developer's job. If your developers don't see it that way, include additional non-functional requirements in the requirements specification that state this requirement explicitly, and provide your developers with an example of ...


14

I think the answer is you both should be thinking about your own set of edge cases. He as the dev should handle edge cases that are data specific such as does the app crash from any given user input, 5 / 0 certainly falls into this part of the spectrum. The dev should ask about you what you think would be an appropriate error message when the input given as ...


-3

The requirements should be clear and concise. If they are not, then happens exactly what happened to you. It is your fault, and the worst thing you can do when specifying requirements is to assume things. You specific example, about division by zero. If you didn't specify that you want to log the error, then don't complain if the developer prints 100 as ...



Top 50 recent answers are included