Sergey Nivens - Fotolia
ORLANDO, Fla. -- Siloed quality-assurance roles often stand opposed to Agile and DevOps methodologies, where speed is king. Most organizations don't turn a blind eye to QA, but many see it as their principal IT bottleneck.
So, what does that mean for software tester roles, as continuous delivery, test automation and artificial intelligence capably handle more test cases over time? That question was on the minds of many attendees here at the STAREAST conference.
For many QA managers, it's not as simple as embracing one side or the other. A testing team requires balance, said Janna Loeffler, a senior manager of experience quality standards at Carnival Corp., based in Doral, Fla.
Loeffler has worked across a variety of industries over the past 15 years, in engineering and testing roles that implemented test-driven development and Agile, as well as other roles that followed a more traditional Waterfall model. Her 12-member QA team at Carnival reflects her diverse experience: She classifies them as test automators, manual testers and software development engineers in test (SDETs). Test automators write scripts to automate test cases, while SDETs maintain the tooling that both developers and testers will use.
However, she makes a point to retain manual testers. These workers often have nontechnical experience -- Loeffler said she has hired testers with drama and theater backgrounds -- but they often best understand software from different user perspectives.
"It's truly [through] that diverse perspective that you get all these different personas of users and testers giving you different feedback and results," she said. "That just really vastly increases your product coverage."
Hey, testers: Let's get technical
The allure of continuous testing, however, will push many organizations to automate many of their test cases and hand off some testing responsibilities to developers, a methodology called shift left.
A Gartner report, "DevOps and Cloud Speed Are Driving the End of QA as We Know It," makes the case for a team-centric approach to quality, one in which teams remove separation between dev and test via behavior- or test-driven development and pairing. By involving developers in the QA process, they can become more responsible for code quality.
These cross-functional teams will alter the way traditional QA is done. As a result, many executives and managers believe testers must achieve code literacy, the ability to read and comprehend code, said Jeffery Payne, CEO at Coveros, a software consultancy that acquired TechWell, which hosts STAREAST. This applies to dev collaboration, as well as both bug catching and test scripting.
"For me, a QA person needs to learn how to read code, and they have to understand what the terminology means, what the syntax means, because it's going to help you be a better tester," he said.
Payne said he talked to many testers throughout the conference who plan to improve their code knowledge to better their career prospects, but he's unsure if enough will follow suit. Code literacy and knowledge of tools help testers apply more rigorous QA to applications, whether tests execute manually or automatically, he said. "I worry that we have a lot of testers who aren't up to the task of learning and growing into what they need to be," he said.
The problem, Payne said, originates at the university level, where software testing is rarely a separate education track, so some testers lack knowledge of QA fundamentals, let alone complex applications.
"Our industry hasn't really emphasized the educational aspects of understanding techniques and approaches to testing," he said. "Sometimes, I think we have erred too far on [the idea that] a tester is just a business analyst who plays with the software."
Manual skills translate to creativity, leadership
However, many others laud the expertise of manual testers. A Forrester Research report, "Shift Performance Testing Left to Streamline App Delivery," recommends testers set up test environments and data, analyze raw performance testing data, perform manual smoke tests and set key performance indicators -- tasks that they cannot presently abstract away.
Dorothy GrahamSoftware testing consultant, speaker and author
"People are encouraging testers to learn how to write code and things like that, and I see a big danger here," said Dorothy Graham, a software tester, consultant and author based in the U.K. Graham has more than 40 years of experience and delivered nearly 400 conference presentations in software testing. She worries that a narrowly technical focus denigrates testers' natural abilities to perform exploratory or UI tests, and could even hurt the workforce.
"If we are pushing all testers to becoming coders, not only is that not good for everybody, but we're possibly going to lose people who are dyed-in-the-wool testers, who don't want to become coders," she said. "My objection is forcing everybody to be in one pigeonhole where they don't fit, and they don't want to be there."
Graham related a story from one attendee whose organization planned to convert all of its testers to coders. Within a few months, half of those testers jumped ship. Graham said she supports automation, but believes test automation should serve testers, not replace them.
"I feel that things are unbalanced; the pendulum has swung too far," she said. "The most important thing that a tester has is their mindset -- and that's not technical. It's being curious, likely to break things, thinking outside the box, thinking what could go wrong, questioning everything, challenging everything."
Soft skills and adaptability are crucial for testers, Carnival's Loeffler said. She holds monthly one-on-one meetings to encourage her workers' professional development, whether that means coding expertise or not. She found that manual testers are often more well-suited for leadership roles than people who prefer to work with code, as long as they can develop the skills to communicate and manage the needs of stakeholders, which includes developers, managers and users.
"People get so focused on specialties that they forget to really be a good tester. You have to be able to wear multiple hats," she said. "Technologies change, languages change, and you have to be able to know how to change with it."
The communication gap between developers and testers, in particular, can create a chasm within IT departments, Coveros' Payne said. He said he believes code literacy can help alleviate some of those challenges, especially as developers influence so much of organizations' IT purchasing decisions. But developers and testers still must work more resolutely toward a collaborative middle ground.
"We need a lot more [collaboration] with where we're moving with Agile and DevOps, because that piece is often the Achilles heel," he said. "It's not the technology, not the tools, not the knowledge -- we [must] get people to engage and work together."