It’s been six years since James Whittaker proclaimed that test was dead (and many people still haven’t figured out what he really meant), and since then testing has continued to change dramatically.
For some of us.
But not for others.
Earlier this week, I linked to an article titled “Stop Hiring Testers”. The title, as you can imagine, scared the pants off of a bunch of afraid-for-their-job testers, but the content embraced the change in testing that many of us have been riding for a while now. Every time I see a person, an organization, or a company realize that they’ve left their old world of testing behind, I see an article like this, along with the accompanying cries of those who don’t want to admit that change is happening.
One thing that strikes me is that every time someone makes a statement like “test is dead”, or “stop hiring testers”, a lot of testers scream; but some inevitably say, “of course – this isn’t anything new to me”.
But that’s expected, I recognize that there are different worlds of testing out there. For lack of a better word, I see two different schools (which sucks given the existing connotations with this word, but is applicable considering that I could see testers self-selecting for these schools) of test prominent in discussions about testing on the internet.
The first, and likely the larger is the “traditional” test-as-information-provider (and often, test-last) school. This is how most (I have no metrics to back this up) testing is probably done. Most testing books, as well as the wikipedia page on software testing describes many aspects of this approach. Testing in this school is typically done by an independent test team, and involves a wide variety of analysis into the state of the software in order to provide information about the product for stakeholders. Admittedly, I’m quite familiar with this school, as I documented Microsoft’s version of this approach in How We Test Software at Microsoft. Attention to requirements, and risk-assessment are often key parts of this approach. I’d guess that a test phase of software development is prominient within practitioners of this school regardless of whether the team considers themselves “Agile” or not.
This school isn’t wrong by any means, but I believe it’s fading away. For what it’s worth (using replies to the Stop Hiring Testers post mentioned above as data), people in this school generally don’t like the idea that it’s going away.
Plus ca change…
What I’m seeing more and more of, is the test-always, or test-as-quality-accelerant – or maybe, with a nod to Atlassian, the quality-assistance school. In more and more teams, testers are taking on the role of quality assistant, quality coach, or quality experts. Rather than existing in a separate team, they are members of feature teams and take on the responsibility for ensuring that the entire team embraces a quality culture. Yes, they absolutely bring testing expertise to their product or feature area, and they test the product more than anyone else on the team; but they also help other developers write and improve their own testing and think a lot about the customer experience. Good developers are extremely capable of writing tests (including service monitoring and diagnostic tools) for their own code, but testing experts ensure that the end-to-end experience and other big picture items (e.g. load or perf) are covered as part of the daily work.
Teams with testers like these typically do not have a release phase since they are (typically) releasing often or always.
It’s worth mentioning that some testers would say that when you do many of these activities mentioned in the previous paragraph, you are no longer testing. I agree with this sentiment – and believe it’s part of the evolution of the role. As test teams evolve towards the quality-accelerant school, test “experts” will take on several roles beyond testing. You could say that testers in this school are getting themselves into the quality assurance business.
Definitely some food for thought here, and something I expect to ponder (and write) about more.
Good to see and hear you outside of the Microsoft bubble (BTW can you freely use ‘”Teams” in your writings ?).
I am not sure the distinction between those two schools is black and white (or True/False depending on the language you use) as you describe it, it’s more of a spectrum. You can work in a separated test team and still be a quality-assistant, or work in a small Scrum team and still do isolated test work.
Many times it’s not even company policy but depends on individuals.
With your second school example, following the shift left where a testers analysis is input into the developers tests I am just curious. Where are the negative test cases executed, where are the non-functional’s tested and who keeps the metrics to report to upper management on what the testers or dev-test are actually responsible and accountable for?
Battles are regularly had where a developer has read a statement similar to this and wants to enact on it immediately but nobody (product/ dev) is ever willing to give time to the above mentioned cases.
I have in my current job been through the transition you describe. Prior to this we were exploratory agile testers, that were involved through the whole development process with a test-phase at the end, where we gave ‘thumbs-up’ for the functionality. Then, in a transition phase, we introduced a ‘Testers are not allowed to test’ rule, where testers were supposed to support developers in the beginning of the development phase (and help write some acceptence criteria / test-plan), but were not allowed to be involved in the actual testing. This taught the developers to do their own testing (together with code-review). Testers were laid off, but we are still 2 out of 4 left: a QA/Release Manager who is the guy who pushes the release button (and will make a quick survey of the stories released with his x-ray QA eyes) and me, doing automated functional regression tests.
I think this works fine, but there is a problem. I, as a tester, lose the contact with the new functionality and the development process, and it is impossible to jump into the old role of dedicated tester, as this involves a lot of work of knowing the product in and out and having all the test tools ready and following the stories from start to finish. We recently had a story that had gone bad and I was put on as QA to help: that was very frustrating and inefficient.
Isn’t this similar to what that “agile school of testing” preaches? I am surprised that people would assume that testing is going away just because more teams are embedding testing earlier in the process. Isn’t that what testers have been asking for all along? I know it’s been one of my biggest requests whenever I onboard to a new company.
Really interesting perspective Alan! I think I fit in both “schools” (and yuk… I hate that word too). I definitely am an advocate for testing everywhere and everyone being responsible for quality. I promote that a lot.
But equally, I’ve seen so many failed attempts at developers learning to explore. Most are uninterested and still see testers and “testing” as a lower class. And many of the “other” skills needed to do good exploratory testing are really hard too (lateral and critical thinking skills, communication skills, influence skills, sociology skills, Psychology skills, etc).
Many developers are uninterested in these skills and struggle to focus on these when they need to focus on learning all the skills and languages relating to their coding, ops and development activities (we’re calling for multi skilled people, that means stretching developers to be multi skilled in different developer directions too – front end, back end, web, mobile, etc). So this is a challenge too.
That’s why I think there needs to be a blend. We need to continue to have testing experts, but I don’t believe the title of “coach” cuts it enough…
Not sure what the right title might be… Perhaps call everyone a developer while still recognising the separation of skilled experts somehow.
Anyway, great post! Thanks for kicking my brain!