So, you land into a project unknown. You collect a bit of info, organize the claims by sources you've heard them for, pay attention to differences between sources and decide who you're going to primarily believe, for now. And then you dig into testing.
A lot of what you're experiencing does not match any of the claims. And there's a bunch of claims you're making now that no one else did.
You realize there might be a usual problem going on, with "no-one's land". With enough small teams around, there's things where you just see things end to end that none who focus on their bits have. So what do you do?
I remember clearly a time, when I wrote clear and well-investigated bug reports about these, and then the ping-pong game starts. It often continues until there is either a developer with a system perspective or until I play personal relations on getting someone who wouldn't want to look at it to look at it to help pinpoint it further. I feel exhausted just thinking about this.
Today I run into something of this sort. And instead of writing a bug report, I made a list of reasonable expectations I was planning to talk about. Reasonable expectations are my claims on what I find would be reasonable to expect and I let the developers tell me I'm wrong - or find out that I'm right and then discuss the bugs I did not want to log against the end-user perspective claims that are not true after all, based on evidence. For now, until we've changed our software or our perceptions.
I realized this isn't something new for me. I've had great success with this before, with a difficult project manager of the past. The mechanism is just something I've never before labeled. I play a lot with the dynamics of communication while I deliver the messages as a tester. The dynamic of making me the one who is proven wrong on the reasonable claims turns around the feeling of how we'd talk about the exact same thing through a bug report.
A lot of what you're experiencing does not match any of the claims. And there's a bunch of claims you're making now that no one else did.
You realize there might be a usual problem going on, with "no-one's land". With enough small teams around, there's things where you just see things end to end that none who focus on their bits have. So what do you do?
I remember clearly a time, when I wrote clear and well-investigated bug reports about these, and then the ping-pong game starts. It often continues until there is either a developer with a system perspective or until I play personal relations on getting someone who wouldn't want to look at it to look at it to help pinpoint it further. I feel exhausted just thinking about this.
Today I run into something of this sort. And instead of writing a bug report, I made a list of reasonable expectations I was planning to talk about. Reasonable expectations are my claims on what I find would be reasonable to expect and I let the developers tell me I'm wrong - or find out that I'm right and then discuss the bugs I did not want to log against the end-user perspective claims that are not true after all, based on evidence. For now, until we've changed our software or our perceptions.
I realized this isn't something new for me. I've had great success with this before, with a difficult project manager of the past. The mechanism is just something I've never before labeled. I play a lot with the dynamics of communication while I deliver the messages as a tester. The dynamic of making me the one who is proven wrong on the reasonable claims turns around the feeling of how we'd talk about the exact same thing through a bug report.
