I'm about to spend a weekend on writing a book with a crowd of about 20 people on Agile - in Finnish. Thus it seems appropriate that just today I've been watching long discussions about worries that some context-driven testing community members seem to be showing towards agile.
We're talking about our fears. Fear of dismissing testing narrowly as checking, fear of testing as something that will happen in the team without details or skills, and fear for losing our right to identify as testers - people who intentionally study testing and choose to invest so much time on that that it is not possible to invest as much on something else.
The fear for our identity may go as far as saying that programmers wouldn't study critical thinking or recognizing threats to value in the products they work on. Claiming that is the core of 'being a tester'. To me, they are just to examples of skills areas that help demystify testing in agile teams. I see development as process of transforming ideas to code. Ideas we build together with diversified skills are stronger. Code we evaluate together, seeking to check they are as we intended and to explore ways we never intended. And explain what we know and don't.
I realize agile can be scary. It can be scary that we're asked to stop owning things like critical thinking and recognizing threats to value, and allow everyone in the team do those. It can be scary that there just isn't as much of what we do now to do in the future. That we don't get to do all that by ourselves. And that we need to find rationales of what makes us special in depth of skills and concurrent actions instead of just labeling it all "testing".
To me, testing includes checking and exploring. Checking helps with being able to focus on other things than the ones we're capable of checking with automation. A lot of the stuff in rapid testing has had a twist of "emergency testing" to it. Agile may remove the emergency by making it continuous.
If an agile team does testing badly as a team effort and has their feedback loop of continuously delivering to real customers / end users in place, the team will learn to test the hard way. I've seen organizations retrain a new generation of testers this way as their existing testers wouldn't fit in the teams, through a series of failed deliveries they could have avoided leveraging the existing tester's skills. This unfit was as much due to testers not making compromises on their role as it was on the idea of "everyone must code".
Some years back, in an organization transforming to agile, we were asked "would you go back". In groups that would, two stuck out: testers and project managers. The testers felt we were losing something. But instead of going back, we looked at what we feel we lost - respect for our skills, the feeling of being needed and important. And we addressed the fear instead of allowing that to drive us to something that wasn't right for the product business.
We're talking about our fears. Fear of dismissing testing narrowly as checking, fear of testing as something that will happen in the team without details or skills, and fear for losing our right to identify as testers - people who intentionally study testing and choose to invest so much time on that that it is not possible to invest as much on something else.
The fear for our identity may go as far as saying that programmers wouldn't study critical thinking or recognizing threats to value in the products they work on. Claiming that is the core of 'being a tester'. To me, they are just to examples of skills areas that help demystify testing in agile teams. I see development as process of transforming ideas to code. Ideas we build together with diversified skills are stronger. Code we evaluate together, seeking to check they are as we intended and to explore ways we never intended. And explain what we know and don't.
I realize agile can be scary. It can be scary that we're asked to stop owning things like critical thinking and recognizing threats to value, and allow everyone in the team do those. It can be scary that there just isn't as much of what we do now to do in the future. That we don't get to do all that by ourselves. And that we need to find rationales of what makes us special in depth of skills and concurrent actions instead of just labeling it all "testing".
To me, testing includes checking and exploring. Checking helps with being able to focus on other things than the ones we're capable of checking with automation. A lot of the stuff in rapid testing has had a twist of "emergency testing" to it. Agile may remove the emergency by making it continuous.
If an agile team does testing badly as a team effort and has their feedback loop of continuously delivering to real customers / end users in place, the team will learn to test the hard way. I've seen organizations retrain a new generation of testers this way as their existing testers wouldn't fit in the teams, through a series of failed deliveries they could have avoided leveraging the existing tester's skills. This unfit was as much due to testers not making compromises on their role as it was on the idea of "everyone must code".
Some years back, in an organization transforming to agile, we were asked "would you go back". In groups that would, two stuck out: testers and project managers. The testers felt we were losing something. But instead of going back, we looked at what we feel we lost - respect for our skills, the feeling of being needed and important. And we addressed the fear instead of allowing that to drive us to something that wasn't right for the product business.
