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?