ThoughtWorks
  • Contact
  • Español
  • Português
  • Deutsch
  • 中文
Go to overview
  • Engineering Culture, Delivery Mindset

    Embrace a modern approach to software development and deliver value faster

    Intelligence-Driven Decision Making

    Leverage your data assets to unlock new sources of value

  • Frictionless Operating Model

    Improve your organization's ability to respond to change

    Platform Strategy

    Create adaptable technology platforms that move with your business strategy

  • Experience Design and Product Capability

    Rapidly design, deliver and evolve exceptional products and experiences

    Partnerships

    Leveraging our network of trusted partners to amplify the outcomes we deliver for our clients

Go to overview
  • Automotive
  • Cleantech, Energy and Utilities
  • Financial Services and Insurance
  • Healthcare
  • Media and Publishing
  • Not-for-profit
  • Public Sector
  • Retail and E-commerce
  • Travel and Transport
Go to overview

Featured

  • Technology

    An in-depth exploration of enterprise technology and engineering excellence

  • Business

    Keep up to date with the latest business and industry insights for digital leaders

  • Culture

    The place for career-building content and tips, and our view on social justice and inclusivity

Digital Publications and Tools

  • Technology Radar

    An opinionated guide to technology frontiers

  • Perspectives

    A publication for digital leaders

  • Digital Fluency Model

    A model for prioritizing the digital capabilities needed to navigate uncertainty

  • Decoder

    The business execs' A-Z guide to technology

All Insights

  • Articles

    Expert insights to help your business grow

  • Blogs

    Personal perspectives from ThoughtWorkers around the globe

  • Books

    Explore our extensive library

  • Podcasts

    Captivating conversations on the latest in business and tech

Go to overview
  • Application process

    What to expect as you interview with us

  • Grads and career changers

    Start your tech career on the right foot

  • Search jobs

    Find open positions in your region

  • Stay connected

    Sign up for our monthly newsletter

Go to overview
  • Conferences and Events
  • Diversity and Inclusion
  • News
  • Open Source
  • Our Leaders
  • Social Change
  • Español
  • Português
  • Deutsch
  • 中文
ThoughtWorksMenu
  • Close   ✕
  • What we do
  • Who we work with
  • Insights
  • Careers
  • About
  • Contact
  • Back
  • Close   ✕
  • Go to overview
  • Engineering Culture, Delivery Mindset

    Embrace a modern approach to software development and deliver value faster

  • Experience Design and Product Capability

    Rapidly design, deliver and evolve exceptional products and experiences

  • Frictionless Operating Model

    Improve your organization's ability to respond to change

  • Intelligence-Driven Decision Making

    Leverage your data assets to unlock new sources of value

  • Partnerships

    Leveraging our network of trusted partners to amplify the outcomes we deliver for our clients

  • Platform Strategy

    Create adaptable technology platforms that move with your business strategy

  • Back
  • Close   ✕
  • Go to overview
  • Automotive
  • Cleantech, Energy and Utilities
  • Financial Services and Insurance
  • Healthcare
  • Media and Publishing
  • Not-for-profit
  • Public Sector
  • Retail and E-commerce
  • Travel and Transport
  • Back
  • Close   ✕
  • Go to overview
  • Featured

  • Technology

    An in-depth exploration of enterprise technology and engineering excellence

  • Business

    Keep up to date with the latest business and industry insights for digital leaders

  • Culture

    The place for career-building content and tips, and our view on social justice and inclusivity

  • Digital Publications and Tools

  • Technology Radar

    An opinionated guide to technology frontiers

  • Perspectives

    A publication for digital leaders

  • Digital Fluency Model

    A model for prioritizing the digital capabilities needed to navigate uncertainty

  • Decoder

    The business execs' A-Z guide to technology

  • All Insights

  • Articles

    Expert insights to help your business grow

  • Blogs

    Personal perspectives from ThoughtWorkers around the globe

  • Books

    Explore our extensive library

  • Podcasts

    Captivating conversations on the latest in business and tech

  • Back
  • Close   ✕
  • Go to overview
  • Application process

    What to expect as you interview with us

  • Grads and career changers

    Start your tech career on the right foot

  • Search jobs

    Find open positions in your region

  • Stay connected

    Sign up for our monthly newsletter

  • Back
  • Close   ✕
  • Go to overview
  • Conferences and Events
  • Diversity and Inclusion
  • News
  • Open Source
  • Our Leaders
  • Social Change
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
Software TestingBeijingTechnology

Virtual Panel: Should Testers be Technical?

Yang Du Yang Du

Published: Apr 19, 2015

“Should testers be technical?” This is a frequent question especially in the last decade, as the Agile approach has been adopted by more and more organizations, and people agree that tester have to do more than before.

But should they be technical?

Recently, the discussion happened  within ThoughtWorks testing group about a blog post on "Should testers be technical?" written by Sreedevi Vedula. Here are some great viewpoints shared by ThoughtWorkers.

Coding is nice-to-have skill but requires more efforts to learn

Yes, coding is definitely a kind of technical skill. In the beginning of this century, the industry needs many testers for blackbox and exploratory testing to verify functionalities since system behaviors are much more complicated than ever. Some of them never learnt coding or only know a little about coding. 

“I agree with you that testers need to understand the system. But there is a big jump to being able to code and talking technical on how a system works. I reckon it's more about changing your mentality: build vs test quality. For that you don't have to be able to code. You have a dev that can sit next to you to help with that.”, Torsten Leibrich says. 

I couldn’t agree more with it because automation is a good thing to do repetitive work for us so that we can spend more time on deep or complicated tests. Moreover we can think and talk deeply with developers and ask them to help us to check software internal quality. That’s the reason why I like quote from Sir Tony Hoare (I changed the word “testing” to tester):

"The real value of tester is not that they detect bugs in the code but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code." I think that's where Tester standing on in this domain. 

“Perhaps there is a happy medium between "full on manual tester" to "uber technical tester who can code". There is still white box testing that is still a great skill to learn (or upskill). Instead of learning how to code, they can start to learn how to read and understand how the code works (or just the flow). Not only that is a nice introduction to programming, it will also help them debug and find the root cause of the bug instead of offloading it to the developer. Furthermore, they can also understand what a stack trace is and look at the line in the code that throws the exception and it might indicate why it failed. “ - Thien-An Mac mentioned

Business Oriented Testers are always important

Technical skills are good but there is still more about testing. . 

“Isn't there a home for the more business analytical testers? IMHO most enterprise systems are complex enough that it's a challenge to keep all the elements 'in your head', but many of the strong analytical testers *are* the ones who can tell me most about a system.  They're the ones who say "If you do that, then X system downstream will do Y" -- they understand how a change will ripple through the system.” - Tim Brown

If we're doing a good job of separating our test concerns -- test definition, implementation, and driver  (h/t to Twist) -- then the more analytical types I'm referring to might very well define the user journeys & system flows, while the more technical testers might do the automation implementation, and the most technical handle the driver layer. 

Darrell Grainger, who has worked with many testers who do not program or have any idea how test automation works. “However I would hire them in a heartbeat over many technical testers. Just on my current project the QA department is actually separated out into manual testers and automated testers. They were completely manual testers. The manual testers really understood the business. During inception we found the application we were asked to write (1/6 of all the software this department uses) was incredibly complex. The SMEs are constantly re-explaining things to me because it is so hard to keep all the details straight.”

“One of the automation testers was explaining the automation to a manual tester because she felt she really needed to learn automation or she would be obsolete. As he explained a test case he was automating she immediately pointed out the flaw in test and how it completely under-estimated the complexity of the software it was testing. Essentially the test wasn't sufficient. When she explained why the test was insufficient I explained back what I thought the actual test should be to see if I got it. She then pointed out that my test was too complex and there were equivalences which could make the test, literally, 10 times less complex than my test but still be 5 times more complex than the original test. Knowing how to manually test the correct things is FAR more valuable than knowing how to automate the wrong test. They have a dozen highly skilled automation testers. They are having a hard time finding people who understand the business well enough to know how to test it. She is one of three manual testers. She is what Tim is talking about.”

“That is one why a manual tester adds value. I'm not going to say she is better than the automation tester. She knows WHAT to test (manually). The other guy knows HOW to test it over and over again without burning out (automation). Neither is better. They are just different.” said by Darrel Grainger

Rethink about the role and responsibility

As the software development methodology evolves, we need to evolve. With Agile, with incremental releases, the team is under tremendous pressure to live to the “definition of done”. Does that mean manual testing / manual testers are out of the picture now?
 
“As pointed out by various people in this topic, I don’t see any disagreement in the need for manual testing. However, manual testing itself maybe a misnomer - now more than before!” Anand Bagmar says.
 
“To me, manual testing means - someone, at some point in time has identified test cases, and written them down in an excel / QC / or any other tool. Then the same person, or another set of people over a period of time, go and manually execute the same test case (with or without following all the steps listed) and report success / failure. That is the kind of testing / testers that I definitely do not see adding much value on teams (in most cases).”
 
HOWEVER, the manual testers that most are referring to in this post and thread are more evolved beings. They are the SMEs of the product. They understand what and why things need to be done from the domain as well as the product perspective to ensure it works fine for the end-users of the system. I strongly believe that every team needs people with this mindset. They may not be separate people / roles, but someone who thinks constantly from this perspective. I think it is high time we stop diluting their worth and value by simply calling them “manual testers” who do “manual testing”. Maybe we call these folks “exploratory testers”, or “system testers”, or “domain testers / validators” … or something more fancy - but we need to break out from this mental model what “manual testers” represent and imply - that too different things in different parts of the world. Another advantage that this will potentially bring out is in setting the correct expectation from these roles.

So what’s Software Testing

Maybe it’s good opportunity to look back something: What’s Software Testing and What skills Software Testers (hereafter as Testers) need to have in last decade and now. 

From the definition about Software Testing from Wikipedia, you can see that Software Testing requires many things, like:

  • Communication skills
  • Domain knowledge and Business requirement
  • Testing strategy and methodologies (Tests Design, prioritizing, Test Data preparation) 
  • Technical Knowledges (OSs, Network, Protocols and Coding ... etc)
  • Bug/Defect reporting and tracking
  • Quality Assurance/Software Engineering Knowledge 

So my opinion is that testers should be technical and technical parts are not just about coding. And there are still more technologies involved in testing activities.

Finally, I would repost those comments from Anand Bagmar:

I have been seeing people tend to go from one extreme stance of - QAs should do Test Automation, to the other side, QAs should NOT do Test Automation. In my opinion, there are good reasons why we need this variety of QA profiles - mainly because we have different types of projects, different duration, different distribution, different domains, etc. 

My friends, what would you say and what are you going to do? 

  • What we do
  • Who we work with
  • Insights
  • Careers
  • About
  • Contact

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

Media and analyst relations | Privacy policy | Modern Slavery statement ThoughtWorks| Accessibility | © 2021 ThoughtWorks, Inc.