Agile. We all have our ideas what it might mean. When listening about Agile Testing explanations, it's evident that testing is still testing but Agile is a context that changes many of the factors on how the testing ends up being done.
With Agile, the testers have learned to work together with developers. I guess it works both ways. We hang out in the same meetings. We share work on the same value items to deliver. We pitch in from a bit different perspectives, with a common goal of getting it done, learning to find problems before implementing still leaving the question to be answered on how well this works when it has been implemented. And "this" is something small, with a continuous flow.
In this setting, when a tester finds a problem, she tells about it to a close colleague. Having worked together for years on consistent pace, there's no drama to this. It's information exchange. I know something you didn't, now you know it. And knowing it means more work for both of us. It's only natural to ask if we could learn something from the information and avoid late discoveries next time. Optimistically we agree to try to work on it, yet always failing with some details. It's a "I wish I knew when I made that decision" -case.
Now that I've seen a bit of Mob Programming (whole team, one computer), I'm suspecting that the best of our current tester-developer collaboration is just co-creation, not true collaboration.
In Co-Creation, work well together but not really together. You know something, I know something, and we take turns to contribute our things into the end result. Some of this we pair up on, but mostly when we pair, we pair with the likes of us, with similar type of information at hand. We're not witholding any information, we're actively sharing, making anything available. We sit together in the same space, asking is easy - if only we know to ask.
In Collaboration, we don't need to ask as we build on top of each other. Like when we mobbed in my team, someone mentioned in passing looking at the code we were changing the words "one or many", with an instant conclusion that the answer was known: "one". I immediately jumped in correcting it's "many", adding a bit of history of why's to the shared knowledge. And a third person cracks a joke: "That would have been an expensive one to find later". Mostly me in the room makes others say things like "ooh, we need to test that", with a glimpse to my direction looking for acceptance, acknowledgement and approval on the developers being on their perfect behavior of discipline. But there's also these moments when I suggest variation to explore the limits of the box we've set ourselves into: change of browser, different data, different order of doing things, new viewpoints to see the same differently. And I do my share typing for my team, on my turn.
How could we move from sharing, helping and co-creating in our projects and professional communities into true collaboration, where we remove more of the time and task separation, without removing the specializing that enables each of us to contribute things the others could not by themselves? That's something for me to think about.
With Agile, the testers have learned to work together with developers. I guess it works both ways. We hang out in the same meetings. We share work on the same value items to deliver. We pitch in from a bit different perspectives, with a common goal of getting it done, learning to find problems before implementing still leaving the question to be answered on how well this works when it has been implemented. And "this" is something small, with a continuous flow.
In this setting, when a tester finds a problem, she tells about it to a close colleague. Having worked together for years on consistent pace, there's no drama to this. It's information exchange. I know something you didn't, now you know it. And knowing it means more work for both of us. It's only natural to ask if we could learn something from the information and avoid late discoveries next time. Optimistically we agree to try to work on it, yet always failing with some details. It's a "I wish I knew when I made that decision" -case.
Now that I've seen a bit of Mob Programming (whole team, one computer), I'm suspecting that the best of our current tester-developer collaboration is just co-creation, not true collaboration.
In Co-Creation, work well together but not really together. You know something, I know something, and we take turns to contribute our things into the end result. Some of this we pair up on, but mostly when we pair, we pair with the likes of us, with similar type of information at hand. We're not witholding any information, we're actively sharing, making anything available. We sit together in the same space, asking is easy - if only we know to ask.
In Collaboration, we don't need to ask as we build on top of each other. Like when we mobbed in my team, someone mentioned in passing looking at the code we were changing the words "one or many", with an instant conclusion that the answer was known: "one". I immediately jumped in correcting it's "many", adding a bit of history of why's to the shared knowledge. And a third person cracks a joke: "That would have been an expensive one to find later". Mostly me in the room makes others say things like "ooh, we need to test that", with a glimpse to my direction looking for acceptance, acknowledgement and approval on the developers being on their perfect behavior of discipline. But there's also these moments when I suggest variation to explore the limits of the box we've set ourselves into: change of browser, different data, different order of doing things, new viewpoints to see the same differently. And I do my share typing for my team, on my turn.
How could we move from sharing, helping and co-creating in our projects and professional communities into true collaboration, where we remove more of the time and task separation, without removing the specializing that enables each of us to contribute things the others could not by themselves? That's something for me to think about.
