It sneaked up on me. I can't really pinpoint to the exact moment of revelation, but now, looking back, I can see I've done yet another 180 turn on my beliefs.
I used to believe I, as a tester, was around for the benefit of the stakeholders, shining light on all sorts of perspectives so that we understand what we're releasing. Advocacy was a big part of what I did, making sure people would understand the risks and implications, but on untested features (and I had quite an imagination for things that could go wrong) and bugs we had found.
At some point, I started understanding that risks to business people mean opportunities to win. There's a chance I don't have to pay for this and things will still be alright! So I participated in all sorts of efforts to find actual bugs and problems, evidence of the risks being true and real, so that we can't just close our eyes and wish things did not go wrong.
Whatever the developers would change, I would test with my tester colleagues. Whatever features those chances were introducing, I would dwell in the implications of chances of bad things happening and then seeking for the evidence. I would often find myself estimating how much time we need on testing and getting my estimates dismissed, being given a shorter time.
Thinking back to those times with the way I perceive things now, I think I've found a less stressful world of testing.
Now I start with the realization that when things are failing in production, it's not my fault. I did not change the environment or the code, and I will not be the one staying late and sacrificing my weekends to fix it. The developers (programmers, if you will) will do that. They are the ones ultimately held accountable for quality. I'm here to help them. I'm here to help them figure out ways to prevent escalations because of bad bug fixes, because they did not quite understand the implications of a change or did not quite get all the "requirements" right. I offer my help, and they can choose to accept it. I no longer need to push it down their throats and sit there guarding a release making sure nothing untested gets released. I no longer work with estimates, I work with time boxes. I commit to doing the best possible testing I can with whatever time I'm allocated.
So today, I stopped to think about where the change of minds comes from. Here's some of my observations:
I used to believe I, as a tester, was around for the benefit of the stakeholders, shining light on all sorts of perspectives so that we understand what we're releasing. Advocacy was a big part of what I did, making sure people would understand the risks and implications, but on untested features (and I had quite an imagination for things that could go wrong) and bugs we had found.
At some point, I started understanding that risks to business people mean opportunities to win. There's a chance I don't have to pay for this and things will still be alright! So I participated in all sorts of efforts to find actual bugs and problems, evidence of the risks being true and real, so that we can't just close our eyes and wish things did not go wrong.
Whatever the developers would change, I would test with my tester colleagues. Whatever features those chances were introducing, I would dwell in the implications of chances of bad things happening and then seeking for the evidence. I would often find myself estimating how much time we need on testing and getting my estimates dismissed, being given a shorter time.
Thinking back to those times with the way I perceive things now, I think I've found a less stressful world of testing.
Now I start with the realization that when things are failing in production, it's not my fault. I did not change the environment or the code, and I will not be the one staying late and sacrificing my weekends to fix it. The developers (programmers, if you will) will do that. They are the ones ultimately held accountable for quality. I'm here to help them. I'm here to help them figure out ways to prevent escalations because of bad bug fixes, because they did not quite understand the implications of a change or did not quite get all the "requirements" right. I offer my help, and they can choose to accept it. I no longer need to push it down their throats and sit there guarding a release making sure nothing untested gets released. I no longer work with estimates, I work with time boxes. I commit to doing the best possible testing I can with whatever time I'm allocated.
So today, I stopped to think about where the change of minds comes from. Here's some of my observations:
- I worked as a solo tester with many developers who tested. I know they can do things without me, even if they can do things better with me.
- I saw the developer pain of late nights and lost time away from new features, and realized I could help relieve that pain channeling stakeholders directly to developers.
- I experimented letting features go out without testing them and the world did not explode.
- I helped change our release cycle to daily, allowing bug fixes and new feature development both go into the same cycles. It gave me full time to exploratory testing as some would happen pre-release and a lot more post-release.
- I got more done not going into the endless fights for testing time and advocating for risks for people that would only understand empirical evidence.
- I heard other testers, like Elisabeth Hendrickson speak of this: we are not gatekeepers.
