There are some discussions that make me both happy and sad at the same time. I had one exemplary version of these chats at Agile Alliance Technical Conference right after my session I wanted to share with you.
My session was about exploratory testing an API. I wanted (and succeeded) in creating an experience in mob format where people would apply exploratory testing as a group on something without a user interface. So we were testing ApprovalTests. I like ApprovalTests for many reasons. First of all, testing a testing framework is so wonderfully meta in many ways that I feel a lot of testers would have intuitively ideas about what could be valuable in that domain. Second, it has extensive unit tests and a large number of users (or downloads, rather). It could work. I would love to test something that mostly works, to not get bogged down with the simple bugs but to actually show where value of exploration lies even with "well-tested software" like ApprovalTests.
I felt pretty successful delivering my message, and especially enjoyed the insightful and deep end-of-session questions. There were a few testers in the room, but my perception was that the majority of my audience was developers.
One of the developers approached me after my session, with the experience of what they might be missing focusing on testing as artifacts (automation) over testing as performance (exploration). He shared that his company had let go all of their "QA folks" and been told that they are doing all of the testing among developers. And now he could identify they had a skills gap.
The genuine interest he showed to learning these skills and becoming a better developer was what made me happy. There's nothing about exploratory testing that developers couldn't learn if they realized that it was a set of skills in its own right. While the little mob had just shown that people with a tester background were more function & value focused in exploring and dared to ask for better usability of the API, the difference is a learned behavior on both roles. What I do as an exploratory tester in my team coins down to two things: perseverance and serendipity. I stay with the software longer giving it more chances for positive surprises of it failing in ways I can't even expect. And it helps me to stay around longer that I too "test until bored" but don't get bored very easily as there's so many dimensions, so much viewpoints and so much variation that I never need to approach a problem the exact same way.
What made me sad though was the idea that there are organizations, who will throw away skilled people in my craft for missing some part of the skill (often explaining what they do). Instead, they retrain other people to do that work, often complaining that 1) there's lack of people with the right mix of skills available and 2) there's so few women in the industry.
I believe I can train developers to explore. But I could also train the testers to work better with the developers, and grow into their full potential. The 1st is a positive opportunity, and I love how many developers are actively volunteering to learn that - fast tracking them to seniority. But the 2nd is a lost opportunity that shows how little people mean and how little we're willing to help them.
The world is full of "commodity testers" that are that because that is what they think they're asked. Those of us who have fought our way of the that cast keep fighting regularly as there are managers who would love to put us back into the stupid old ways. But I have so far met very few people who, given the chance wouldn't grow fast.
The environment often makes us what we are. Change the environment. It's not an overnight thing to change, but changing all of the software work into high-value assumption is so worth it. For both organizations and individuals.
My session was about exploratory testing an API. I wanted (and succeeded) in creating an experience in mob format where people would apply exploratory testing as a group on something without a user interface. So we were testing ApprovalTests. I like ApprovalTests for many reasons. First of all, testing a testing framework is so wonderfully meta in many ways that I feel a lot of testers would have intuitively ideas about what could be valuable in that domain. Second, it has extensive unit tests and a large number of users (or downloads, rather). It could work. I would love to test something that mostly works, to not get bogged down with the simple bugs but to actually show where value of exploration lies even with "well-tested software" like ApprovalTests.
I felt pretty successful delivering my message, and especially enjoyed the insightful and deep end-of-session questions. There were a few testers in the room, but my perception was that the majority of my audience was developers.
One of the developers approached me after my session, with the experience of what they might be missing focusing on testing as artifacts (automation) over testing as performance (exploration). He shared that his company had let go all of their "QA folks" and been told that they are doing all of the testing among developers. And now he could identify they had a skills gap.
The genuine interest he showed to learning these skills and becoming a better developer was what made me happy. There's nothing about exploratory testing that developers couldn't learn if they realized that it was a set of skills in its own right. While the little mob had just shown that people with a tester background were more function & value focused in exploring and dared to ask for better usability of the API, the difference is a learned behavior on both roles. What I do as an exploratory tester in my team coins down to two things: perseverance and serendipity. I stay with the software longer giving it more chances for positive surprises of it failing in ways I can't even expect. And it helps me to stay around longer that I too "test until bored" but don't get bored very easily as there's so many dimensions, so much viewpoints and so much variation that I never need to approach a problem the exact same way.
What made me sad though was the idea that there are organizations, who will throw away skilled people in my craft for missing some part of the skill (often explaining what they do). Instead, they retrain other people to do that work, often complaining that 1) there's lack of people with the right mix of skills available and 2) there's so few women in the industry.
I believe I can train developers to explore. But I could also train the testers to work better with the developers, and grow into their full potential. The 1st is a positive opportunity, and I love how many developers are actively volunteering to learn that - fast tracking them to seniority. But the 2nd is a lost opportunity that shows how little people mean and how little we're willing to help them.
The world is full of "commodity testers" that are that because that is what they think they're asked. Those of us who have fought our way of the that cast keep fighting regularly as there are managers who would love to put us back into the stupid old ways. But I have so far met very few people who, given the chance wouldn't grow fast.
The environment often makes us what we are. Change the environment. It's not an overnight thing to change, but changing all of the software work into high-value assumption is so worth it. For both organizations and individuals.
