What should tester do when user stories/documentation is outdated or simply wrong?

Question

We are doing 'scrum', but we are also developing side feature (project) that has extremely hard time with defining correct business requirements.

This feature is not properly included in scrum, meaning work starts on empty, not well defined/planned tasks, often they are made in middle of sprint and so, mostly extremely quickly. (5 minute small talk - something new is coded)

Typical task/story (for each part of feature) will be poorly defined, similar to 'do x and y', assigned to developer, and when developer is working on it, he talks with business/product owner, face to face or emails, and implements 'something like x'. Usually actual implementation is very different to description/specification. Usually implementation changes after it is inspected by business users, and things are recreated differently

But tasks go through testing.

What should tester do in this situation? I see options:

1) Go though every issue assigned, test, make bugs, which will be rejected as 'we implemented it differently' - test actual implementation - then see it changed later on - it seems like a waste of everyone's time

2) Don't really test individual issues, but do exploratory testing on the complete/more finished product (ughh) just to catch some bugs.

Direct manager does not see any problem and is fine with doing testing only on paper, because 'just gotta deliver'.

What is generally accepted course of action for testers in above scenario?

Answer 1

Well, each individual employee (for example a tester) takes the decisions in the are of their competence. You as a tester is responsible for the product quality. Hence what you should do is to report the problem to your Scrum Master since Scrum Master should work with a product owner to make the stories clear and testable (define acceptance criteria and definition of done). So you as a tester are responsible.. yes..

However on the other hand your boss can overwrite your decision and thus overtake your responsibility since your bosses order has higher priority than yours. That is what the bosses indented for. To take the responsibility when the situation requires the decision which lays outside the normal and standardised processes.

So in your situation I would do the following.

1. I would do what my boss says
2. On scrum retrospective I would inform the team that I can see a risk area here and explained why (like technical debt increasing, possible reputation loss, etc) and suggested the scrum master to work out the process for such the cases
3. If my suggestion would not accepted by the team I would consider changing the company to the one where they adhere to the same principles as I do.

P.S. - The key to successful project is segregation of duties. If someone who is responsible for user story maintenance does not do their job good, it is hard to expect the testers will produce good testing for such the stories.

Answer 2

In your scenario, the tester should say NO to the implementation done without proper definition

The acceptance criteria for a functionality while testing will be derived from the user stories accepted during the sprint planning.The scrum master should maintain the user stories during the sprint by getting proper inputs from the product owner.

My suggestion is to say No to your direct manager.

1.In the stand-up meeting, you can inform the team about the possible failures which affects the quality. 2.Every company reputation exists on the application delivered with quality. So don't compromise with quality in any situations.

Answer 3

If the side feature project is part of your Scrum process:

Tell your Scrum Master that you are blocked in regard to your test-tasks due to inaccurate/incomplete documentation and a lack of properly defined acceptance criteria.

If your Scrum Master happens to be your direct manager who "doesn't see any problem", get him to sign off (in email or writing) that A) you stated your significant concerns regarding the test tasks and B) that he told you said concerns are not an issue in his eyes and that you should do X.

In the end he is your boss and disobeying his instructions would be bound to bring trouble to you; this way you can document that if issues arise you are not at fault.