I’ve been thinking a lot lately about what’s next in software testing. What are the new ideas in testing? What is our role in the future of quality software? How do we advance the state of the art in testing?
But I worry.
I think forward thinking will come from highly experienced testers with a breadth of knowledge and the ability to lead to help us define what’s next.But testing still seems to be (for most) a job you do for a while until you do something else rather than a career.
When I go to industry test conferences, someone often will ask the keynote audience how long they’ve been testing. For as long as I’ve been attending conferences, over 75% of the audience has been testing less than a year. Most of the people who have been testing longer are presenting at the conference or attending in some other “official” capacity (vendor tools, consulting opportunities, etc.).
I think the obstacles to advancing testing are worse than the revolving door pattern of the career choice. The role of the experienced (or “expert”) tester appears to be a role of helping the new testers get a handle on the basics. Now – don’t get me wrong, I have said a million times that the role of an expert tester is to make their team and peers better, but it’s a vicious circle when the career path of a tester ends at coaching and mentoring for the noobs. Then again, it’s big money if you want to go into test consulting 
. Given the perceived turnover rate in testing and the growth of the industry, if you are good at bringing new testers up to speed, you should have gainful employment for years to come.
And it’s good to coach, mentor, and guide new testers – but it’s not enough. There are a world of challenges out there in testing, but little exploration into advancements, let along game changing activities. I’m approaching 20 years in software testing, and I still love it. But I think there’s much more out there than most of us think.
So let’s go find it.
Hi Alan,
Thanks for sharing your thoughts, this is thought provoking to say the least.
I wonder what you’d consider the big ideas in testing from the last five years?
I don’t think the next big things will have to come from experienced people, nor do I think they have to come from our field directly. They might but it will be interesting to see
I think certainly lean approaches & doing away with unneeded waste will be essential as systems get more and more complicated as time goes on. I’d also like to think everyone will begin to think of more proactive approaches to testing systems, in that they prevent bugs more than finding them.
Thanks for sharing this with us.
Darren.
Since you brought it up, I hope it’s OK to leave a link to the CFP for the Second Writing About Testing peer conference here. The purpose of the conference is to advance the public discourse on testing exactly along the lines you describe. WAT is not for n00bs.
http://chrismcmahonsblog.blogspot.com/2010/10/call-for-participation-second-writing.html
No problem at all Chris – definitely OK.
My opinion is that testing in an organization should more decentralized. Not so many “leads” and structures.
Instead of hiring many and trying to make the team work, hire better and let them decide what to do.
Let testers be creative.
Do not mix too much with coding needs to force them show “their coding skills” to be pleased by developers.
Hire less and pay them more (at least like dev with same experience).
More geeky testers should be hired not testers with too much attitude. Geeky does not mean always diplomas. Where I come from diplomas are bought and cheating is high.
Those are my ideas. Of course its only from
my perspective. I haven’t implemented a large scale organization testing structure. So I cannot imagine all the problems and interactions and needs and psychology involved.
“More geeky testers should be hired not testers with too much attitude”
I agree. Partly because I’m very Geeky, but also that I find that people who can throw big words around in interviews will usually get the job in my experience.
Software Testing’s a hard job to interview for though. Someone may talk the talk until they’re blue in the face, but when it comes to walking the Geeky walk, they stumble over and burst into flames!
Adam
http://testing.gobanana.co.uk
@brownie490
My point was: motivate testers and solutions will come. Like in every other domain.
The way we manage test teams (entire engineering teams, really) has to change. I read a lot of books on management theory, and have been recommending “The Leaders Guide to Radical Management” a lot lately. If you don’t get a chance to read it, I will likely blog about it soon.
Agree with your other points too. MS pays testers the same as devs, but that’s not enough – you need to given the challenging and motivating work too.
As far as code goes, testers should be able to use programming skills to solve problems they couldn’t have otherwise, or to allow them to perform testing not otherwise possible. If coding skills are used to demonstrate credibility, the organization is sick.
As usual, thanks for the comments.
“For as long as I’ve been attending conferences, over 75% of the audience has been testing less than a year. ”
Does that mean that mostly newbies and people who like presenting go to conferences? If I look around at how many years experience people have that are employed here there’s a good mix, however not many are conference go-ers.
Is the problem rather that people are enthusiastic in the first year and then, apart from a few get disillusioned or just no longer interested and stop going to conferences?
The conclusion that testing is just a stepping stone to something else might have been true 20 years ago, I’m not convinced that this is still the case now (but happy to discuss).
A problem I see with conferences is that there really isn’t much for the intermediate or advanced tester. The research conferences have interesting material, but it’s rarely practical.
I agree that testing-as-a-stepping-stone is much less prevalent these days. In fact, I would bet that we have more testers with 5-10 or more years of experience now than in any other time in history. BUT – we don’t have a place for these experienced testers to share their NEW ideas and advance the craft. The only time I ever hear from someone who SHOULD be a forward thinker in test, they’re preaching the basics to the new testers.
Make sense?
Hi Alan,
Great thought provoking post. I’ve seen the same thing here in the UK with testing audiences being mainly new people to testing.
The frightful thing I see though is that many of these “experts” just shout loud, but don’t say anything new. “Talking Loud, but Saying Nothing”
With a new generation entering the workforce it’s crucial we make our message relevant for them. I see lots of these “experts” talking about things that aren’t relevant to this next generation. It’s no surprise most of these new testers don’t last long when they are faced with “experts” talking about technology and highly formal structures that don’t work in most workplaces.
I think the (good) future of Testing lies in our abilities to improve our softskills (i.e. communication), integrate ourselves more closely with the rest of the team (increase our awareness) and look at how we can build a challenging, yet safe and trusted environment to develop our skills, with strong and encouraging leadership. Not difficult then? 🙂
I’ll probably be proven incredibly wrong though and the next 5 years may be filled with yet more needless standardisation, jobs devoid of critical thinking and more and more consultants pushing specific ideas that just don’t float any more 🙂
Great post Alan – thanks for sharing this.
Rob..
Alan, this:
“The way we manage test teams (entire engineering teams, really) has to change.”
struck me. You’re completely correct. In particular, managing testers differently from how we manage other engineers has got to change. We don’t manage roles, we manage people.
I got a little carried away, so I blogged about it here:
http://blog.abakas.com/2010/11/manage-people-not-roles.html
I (potentially) have an upcoming blog on this as well. Thanks for commenting and elaborating.
Hi Alan,
I’m not pretending on forward thinking ideas, but I had one thought many times over a few past years: why no one cares to test further after a product is released? Why wait for customer complaints to start investigating?
And it’s not always the money or staff availability question.
Actually, I even observed as existence of the bug in production worked out as an excuse of not fixing it in the upcoming release.
Thanks,
Albert
Interesting – I’m doing this exact thing right now. We just wrapped up a product that isn’t even in customers hands, but we still test it. I would bet that this is common in applications where future versions are planned, but much less so in one-off applications (there’s just no cost benefit in continuing to test). For example, if I release a new PC game, I’m may not plan to make any updates to the game – in which case, I wouldn’t fix any bugs test found anyway, so I wouldn’t test.
However, if I just released FooBaz 2.0, and I know that I’ll be working on FooBaz 3.0 soon, I’ll probably keep testing, since testing investments I do now will pay off on 3.0 quality.
I guess it just depends on context.
That sounds to me like a different story.
However, if I just released FooBaz 2.0, and I know that I’ll be working on FooBaz 3.0 soon, I’ll probably keep testing, since testing investments I do now will pay off on 3.0 quality.
You test for the benefit of FooBaz 3.0; no intent to improve quality of FooBaz 2.0. Once you get customer complaints on FooBaz 2.0 you’ll probably start investigating those issues and working on the patch for 2.0. Did I get you right?
Thanks,
Albert
one reason I can think behind it is: the issues/goals that software testing want to resolve/achieve cannot be resolved/achieve by software testing itself. Once people realize this issue, they may start thinking to move to other dicipline…
Great article, and yes I find myself in the same position after 15 years in Test (mentoring, coaching, motivating, supporting). However I’m not sure if the problem (in my own words) is in not having long term career options, but rather in the type of mindset one needs to have to remain in Test. IMO I think people lose interest in Test because they lose the love affair with breaking code and disproving functionality….and If those same people also have a misconception that finding bugs is all we do then a non-disciplined person will walk away. Combine that with pressures to deliver on time on quality and the movement into more technical environments where some of us don’t cut code, it’s hard!! Developers use us as their safety shield, Business Analysts rely on our requirements testing to make them codeable, and Project Managers get us to do all the leg work with estimates, schedules, and the like…..I could on and on…:)