WavebreakmediaMicro - Fotolia

Manage Learn to apply best practices and optimize your operations.

Facing the future of software testing one change at a time

What does the software tester of the future look like? Not like today's tester. Get ready for a new role in tomorrow's software development team.

Software testers on Agile teams just can't win. Either testing's so important it needs a programmer to do it or testing can be done by anyone and everyone.

This, unfortunately, is the Catch 22 of many software testing jobs today. Under tremendous pressure to develop and release applications more quickly, companies are putting the squeeze on testers to make sweeping changes in their skillsets, from coding to reading a spreadsheet and even dealing directly with customers. Testers -- many of whom already feel chronically under-appreciated -- must now rise to the challenge or risk their jobs vanishing.

"The roles are blurring," acknowledged Agile testing coach, expert and author Lisa Crispin during a talk at Agile2015 in early August. "In the Agile world now the focus is on competency, not roles." And that raises serious questions, not only about the future of software testing, but how next-generation software development teams will be structured.

Should development and testing become one?

To figure out what the future of software testing holds, start with the thorniest problem of all: Where does development end and test begin, and should the two become one?

It's a high stakes question. "Many testers are really nervous about their jobs because they don't know how to code or script," said Gartner principal research analyst Nathan Wilson. And they have a reason to be nervous, he said, because automated software testing -- a key part of Agile software development -- could easily put these non-programming testers out of a job. "We've seen some companies that have eliminated software testing altogether because they've moved to Agile."

So is the answer to turn testers into junior developers? A lot of testing experts said absolutely not.

"We believe in technical awareness for testers," said Agile coach, trainer and consultant Janet Gregory, who was a co-presenter with Crispin at Agile2015. "But no, we don't think your testers also need to be able to code because you already have programmers on your team."

Software testers need to become more techie

Testers bring a unique mindset to the software development table, asserted Matthew Heusser, principal consultant of Excelon Development. "Creating software is a different technique than the critique that testers bring," he said. "Do testers need to get more techie? Yes, they do. But they don't have to become full on programmers."

They do, however, have to become something they're not today, said Henrik Andersson, co-founder of House of Test, a testing consulting firm based in Sweden. He is passionate in his defense of testers staying testers, but he was very quick to assert that many do a terrible job and give the profession a bad name. In his mind, testers becoming programmers isn't the answer.

"Many organizations value development skills and programming much higher than other skills," he said. "But I don't think the way to go forward is to focus on dev skills. That's a big mistake. I do believe most testers need to up their skills and be more aware of how development works, how code functions, and know how the business functions to make money. Yes, they need better technical competence, but that's only one out of several areas where they need to improve."

Expose testers to all facets of the process

It's a tricky balance to find, Crispin said, because the team needs to foster a "testing mindset" but at the same time she regularly has testers involved in customer service, for example, to make sure everyone has a broad horizon.

Exposure to other facets of the process is key, and so is collaboration. "You need to watch how everyone does their job," Gregory explained. "The goal is a shared understanding and a common language. Your team selects a testing framework together and the domain specific language and then you're going to have test automation knowing what tests to specify. This is a big investment and it takes time to experiment with it all, but it's an investment worth making."

Automation becoming the norm for software security testing

Pair up, but be smart about it, Andersson said. "Testers need to leave coding automation to developers. It's the fastest way for developers to get feedback, and if we have testers doing autotests all day long it's a waste of time. Instead let's have testers pair up with developers and help them (the developers) learn how to test. What can a good tester bring to the table? A lot."

There's pairing up, and then there's really pairing up, as mob programming teams do. In mob programming, teams of six to eight developers gather in one room and code together like crazy. But the philosophy can be used for testing (some call it mob testing) or as a way to put testers and developers in the same room to figure out how to make things work.

Pairing development and testing is powerful

"It's really the most powerful thing to have dev and test pairing and both work collaboratively on the user story from the beginning," Heusser said. "There's no hand off, no waiting. They can 'mob' on the entire story development and test all the way through."

That is exactly what Maaret Pyhäjärvi, software specialist and testing consultant with Altom Consulting in Finland, tried recently with her team. She's been involved with mob programming for the past four years, but only recently brought testers in to the process.

"We decided to try mobbing rather than explaining the common experience," she said. Teams can communicate well but still hang on to "silent information" -- everything from a keyboard shortcut to a problem-solving strategy -- that everyone would benefit from. Mobbing pushes that information in to the open. "Mob really brings out the best in everyone, instead of just in individuals. Good ideas come together."

Focus on being the best tester possible

It's also a good idea to focus on being the best tester possible, trite as that might sound, Crispin said. "It's important to remember what testers do well that no one else does. Bring your excellent testing skills with you. Get good at penetration testing -- that's very important -- and remember to make testing a team problem."

And it's also helpful to remember why you got in to testing in the first place, suggested Ernest Mueller, a developer and blogger for The Agile Admin. "If you got into QA because you really were interested in development, go do that. But if you're passionate about the testing process, that's where your focus should be. Situations like the one we're in today, with all the pressure on manual testers, are really going to skim the cream off the top."

Next Steps

Testers need scripting skills

Software testers: Diversify your skills

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How do you feel about the future of software testing? Will you be changing careers?
I think that Wilson misspoke (capitalization of agile aside) when he said that he’s “seen some companies that have eliminated software testing altogether because they've moved to Agile.” I would warrant that those companies haven’t eliminated software testing altogether. They’re still testing their software but, as Crispin points out, the lines have been blurred, and the focus has changed to competency, not role. So, while they may not have a role designated as software tester, they have people in their agile environment who have a high level of competency in, and apply that competency toward, testing software.
I do not have any plans of changing careers, but I do realize that the traditional role of the software tester as many are familiar with it is changing or has changed. To that end, my focus is to provide the most value to my organization as possible, and that means working with the development team directly to encourage quality at all parts of the development process. I agree with Henrik, there is much we can teach to programmers and others in the organization, but we also need to up our game as well. For some, that will mean programming or learning more about the way code works and how to leverage that knowledge to provide better testing.

There's this concept: Division of Labor. There's a long Wikipedia article on it:https://en.wikipedia.org/wiki/Division_of_labor

"Because of the large amount of labour saved by giving workers specialized tasks in Industrial Revolution-era factories, some classical economists as well as some mechanical engineers such as Charles Babbage were proponents of division of labour. Also, having workers perform single or limited tasks eliminated the long training period required to train craftsmen, who were replaced with lesser paid but more productive unskilled workers."

Now, those who view testing as a mechanical work must be worried about their job.

Those who view testing as a skilled craft and evolving practice don't need to worry about their career.

However, I'm personally worried about the industry because quality of software degrades and people more and more often pay for it; sometimes with their lives already.


No, I don't forsee changing anytime soon.  Testing is life time learning.  It won't always look the same, nor should it.
I think Albert has hit upon a key point here. It's not that the job or role is in danger, but the traditions of work we have done is certainly changing. Based on what I did in the 1990's, I can only say "Hallelujah" to that! The key to success for any organism is adaptation. When you become perfectly refined for your niche, therein lies extinction. Those willing to grow and branch out with new directions will ultimately do well. Additionally, so long as the scientific method is the model for learning and experimentation, there will always be a need for testing and testers. We may not be dedicated to that role, but that's OK; there's plenty of things to do in a software delivery context to keep the vast majority of us very busy if we choose to be ;).
I won't be changing careers. Our team develops and tests our own code. I have not worked for a company yet in over 30 years that has had a separate testing team. This may happen with much larger companies. 
Test is dead, long live test!
I'm not even the slightest bit concerned about my job going away. We earn our keep - our team is very mature and has some excellent developers, yet we very frequently find significant issues, and help to resolve those issues. We are also involved in many aspects of a BA type role.
"Software testers on Agile teams just can't win. Either testing's so important it needs a programmer to do it or testing can be done by anyone and everyone."

Or #3 the entire premise that testing is dead in agile teams is wrong.

Look the structured design paradigm is well past its prime.  There's never going to be a stand alone testing phase like there used to be for months or weeks for every product.  At some point, we have to test as fast as we can, ask questions when planning work, and try to reveal problems before they become a line of code.  That's not the death of testing, that's a breath of Test air!
The true tester of the past, present, and the future is first of all a critical thinker and learner. The rest can be picked up.