One of the things that draws me to context-driven testing is the idea of scientific methods, and seeking for viewpoints that might even be opposing in search of better understanding. For me it's become clearer that whatever I believe in are beliefs, and while I'm prepared to strongly argue in favor of them, there's other people who would look at my beliefs and conclude that I must be wrong. The more of these disagreements I run into, the more I appreciate the idea of mutual respect: there are arguments where winner cannot be announced. But we can still get along, it's not personal.
Agile, testers and testing must be one of these disagreements. All in all, I personally think agile is the best thing that has happened to testing, with the emphasis on feedback (testing) and the cycles that make acting on that feedback possible to extent that wasn't there before.
There's also the downside to agile, which seems to be the constant need to defend the idea of being a tester.
It appears James Bach feels something in the same direction with a recent yet completely disconnected tweet:
But it also reminded me on the idea that other than wanting to call testers developers (or get everyone to code), there's a lot of things I've learned working with agile. Including the idea that having a tester in the team can be harmful and that some teams actually are very successful - really - without a tester. And that the stories of the latter will continue to inspire the recruiting managers to the extent that they are not hiring non-programmers to some organisations.
Tester role can be harmful
I work with an agile-aspiring team as a tester. The idea of shared responsibility for testing in the team wasn't a hard one, as there's so much to test that we need to share the work. I took upon me the ideas of not being a tester (only), but a testing coach for the team - and a coach of all sorts of things that could help us be better together. The developers I work with don't seem to excel in testing, judging from the numbers of problems we need to catch - on average 4 issues / day every day of the year for one tester. But looking at things openly I have a few observations that conflict my own conclusions of tester importance.
It would seem to me that a big part of why testers are needed is that we allow current developers to rely on externalizing this responsibility. Externalizing the responsibility is a way to make sure testers are needed. And since I sincerely want the best for my organization, I need to think if having a tester around is really that, regardless of this being a core thing for my personal happiness.
Agile teams rely on feedback. The feedback could come from end users, by improving the relationship we have with the real users so that more of them tell about their negative perceptions, regularly. The feedback could come from logs that allow us to see the troubles of the end users, even when they choose not to share their experiences. And we make choices to change the dynamics by investing into systems that allow us to release software to subgroups of end users risking different users to the impact of software that does not work. Small incremental changes are a game-changer. And it has impact on what testing our organizations are willing to invest on. Developers can test too. They can learn to test if they can't test now. And with the continuous feedback, they might actually get really good at testing.
Of course there's a but...
There are teams - plenty of them - that are quite like my team's developers. They're lacking feedback since aspiring to be agile is not enough, you really need to work hard on building the ways of getting the feedback. If your product managers comes and tells that "I did not know it was possible it could work when I start using it", the expectation of quality that team could deliver is very low. If they don't know to expect more, the feedback on the lack of quality is almost too kind to be changing anything with respect to how the team works. If your end users call after a week of your system not working for them at all on a relevant area saying "I thought it might just start working in a few days without me doing anything on it", you're not really talking with your end users to get feedback, but you've trained them to accept almost anything.
There will be junior developers, who have not learned yet to program, let alone test their own programs. Focusing on all these skills at once is overwhelming. There will be junior testers, who will never become the great testing coaches we would need, since they will not have enough time to think of testing - they're required to grow to be developers. And developers will need testing coaches, exemplary testers to catch ideas from.
Being a junior developer isn't just about years in development. Some people can write code with the copy-paste method after 20 years of practice and that type of code tends to break in real use and be very hard to fix as there's no copy-paste solution. And some organisations will have to settle for now with these developers, as finding better ones isn't possible. So they find one of these, and compensate for the lack of skills by having a tester around.
As much as being a tester is relevant for my happiness, I've met developers who find that not thinking about the end user too much is essential to their happiness. Details of code are beautiful, and the people stuff (people using the software) are just not so interesting. Luckily, there's others who feel the other way around, and together we can be happy and do great stuff.
It seems to me we are discouraging testers from being testers. We encourage them to be test coaches. Use a little less time on testing and more time making sure everyone learns. Share. Use the special superpowers to enable others. And we just really don't need as many test coaches as we needed testers. Which also means we have to realistically say that the tester / test coach jobs will be harder to get. Employees won't be in the lookout for testers in masses. Too many good experiences of not doing so. Including cases where testers were completely left out and new generations of developer-testers emerged.
Agile, testers and testing must be one of these disagreements. All in all, I personally think agile is the best thing that has happened to testing, with the emphasis on feedback (testing) and the cycles that make acting on that feedback possible to extent that wasn't there before.
There's also the downside to agile, which seems to be the constant need to defend the idea of being a tester.
Whatever you are doing in a software team and you help adding value to the product it means that you are a software developer. Period.
— Adrian Bolboaca (@adibolb) October 10, 2014
I'm a tester, I'm not a developer. I try hard being a developer and I feel miserable most of the time. I am a tester and loving every moment of it. Personally for me, it's a matter of staying in software industry. And I believe software is better off having people like me. It's how I feel, and regardless of how much you explain, you can't change that. The employers might change that, not giving me jobs unless I'm a developer. Perhaps that's the core of the argument - which belief system the employers will choose. All I can ask is to respect how I feel and not impose titles that my head refuses to accept without forcing as "no other options" - a very negative way.It appears James Bach feels something in the same direction with a recent yet completely disconnected tweet:
@mheusser @augeva Sounds to me like another Agilist who is discouraging testers from being testers.
— James Marcus Bach (@jamesmarcusbach) October 11, 2014
This tweet was a reply to sharing a post with an insight that it appears that most people would really not seem to yet get what agile + testing is about (http://mysoftwarequality.wordpress.com/2014/10/10/testing-the-big-agile-misunderstanding/)But it also reminded me on the idea that other than wanting to call testers developers (or get everyone to code), there's a lot of things I've learned working with agile. Including the idea that having a tester in the team can be harmful and that some teams actually are very successful - really - without a tester. And that the stories of the latter will continue to inspire the recruiting managers to the extent that they are not hiring non-programmers to some organisations.
Tester role can be harmful
I work with an agile-aspiring team as a tester. The idea of shared responsibility for testing in the team wasn't a hard one, as there's so much to test that we need to share the work. I took upon me the ideas of not being a tester (only), but a testing coach for the team - and a coach of all sorts of things that could help us be better together. The developers I work with don't seem to excel in testing, judging from the numbers of problems we need to catch - on average 4 issues / day every day of the year for one tester. But looking at things openly I have a few observations that conflict my own conclusions of tester importance.
- Developers turn into pretty good testers just by sitting next to them
- Removing me after I have been there improves quality
- Testerless teams have delivered really good software
It would seem to me that a big part of why testers are needed is that we allow current developers to rely on externalizing this responsibility. Externalizing the responsibility is a way to make sure testers are needed. And since I sincerely want the best for my organization, I need to think if having a tester around is really that, regardless of this being a core thing for my personal happiness.
Agile teams rely on feedback. The feedback could come from end users, by improving the relationship we have with the real users so that more of them tell about their negative perceptions, regularly. The feedback could come from logs that allow us to see the troubles of the end users, even when they choose not to share their experiences. And we make choices to change the dynamics by investing into systems that allow us to release software to subgroups of end users risking different users to the impact of software that does not work. Small incremental changes are a game-changer. And it has impact on what testing our organizations are willing to invest on. Developers can test too. They can learn to test if they can't test now. And with the continuous feedback, they might actually get really good at testing.
Of course there's a but...
There are teams - plenty of them - that are quite like my team's developers. They're lacking feedback since aspiring to be agile is not enough, you really need to work hard on building the ways of getting the feedback. If your product managers comes and tells that "I did not know it was possible it could work when I start using it", the expectation of quality that team could deliver is very low. If they don't know to expect more, the feedback on the lack of quality is almost too kind to be changing anything with respect to how the team works. If your end users call after a week of your system not working for them at all on a relevant area saying "I thought it might just start working in a few days without me doing anything on it", you're not really talking with your end users to get feedback, but you've trained them to accept almost anything.
There will be junior developers, who have not learned yet to program, let alone test their own programs. Focusing on all these skills at once is overwhelming. There will be junior testers, who will never become the great testing coaches we would need, since they will not have enough time to think of testing - they're required to grow to be developers. And developers will need testing coaches, exemplary testers to catch ideas from.
Being a junior developer isn't just about years in development. Some people can write code with the copy-paste method after 20 years of practice and that type of code tends to break in real use and be very hard to fix as there's no copy-paste solution. And some organisations will have to settle for now with these developers, as finding better ones isn't possible. So they find one of these, and compensate for the lack of skills by having a tester around.
As much as being a tester is relevant for my happiness, I've met developers who find that not thinking about the end user too much is essential to their happiness. Details of code are beautiful, and the people stuff (people using the software) are just not so interesting. Luckily, there's others who feel the other way around, and together we can be happy and do great stuff.
It seems to me we are discouraging testers from being testers. We encourage them to be test coaches. Use a little less time on testing and more time making sure everyone learns. Share. Use the special superpowers to enable others. And we just really don't need as many test coaches as we needed testers. Which also means we have to realistically say that the tester / test coach jobs will be harder to get. Employees won't be in the lookout for testers in masses. Too many good experiences of not doing so. Including cases where testers were completely left out and new generations of developer-testers emerged.
