Master
ThoughtWorks
Menu
Close
  • What we do
    • Go to overview
    • Customer Experience, Product and Design
    • Data Strategy, Engineering and Analytics
    • Digital Transformation and Operations
    • Enterprise Modernization, Platforms and Cloud
  • Who we work with
    • Go to overview
    • Automotive
    • Healthcare
    • Public Sector
    • Cleantech, Energy and Utilities
    • Media and Publishing
    • Retail and E-commerce
    • Financial Services and Insurance
    • Not-for-profit
    • Travel and Transport
  • Insights
    • 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

  • Careers
    • 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

  • About
    • Go to overview
    • Our Purpose
    • Awards and Recognition
    • Diversity and Inclusion
    • Our Leaders
    • Partnerships
    • News
    • Conferences and Events
  • Contact
Global | English
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
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
Continuous Delivery Technology

I automate, but I don't typically test!

Pavan Sudarshan Pavan Sudarshan

Published: Nov 2, 2012

I am a fan of teams where roles and people are disconnected. A model where all roles are hats and people can wear any hat that they are capable of wearing. Basically, try getting an m:n relation between roles and people. However, one of the key to this model is, like I said, capability.

I recently attended a few QA conferences in Bangalore. I spoke with other participants about my experiences with “Selenium and Sahi” and I have a blog on test automation. In one of these conversations, someone who came to know my background asked if I am the QA lead on my team. I told the person that I was a developer and don’t do QA primarily. The person was confused as to why I would not call myself a QA, especially since I spent a good chunk of my time writing automated functional tests using Twist and Sahi on the Go team. Surely, I am some sort of a developer tester.

Here’s my take on why I continue to call myself primarily a developer:

Primary Responsibility...

Mark Chang, when he was my delivery manager, used to use this term. It was in the spirit of roles as hats. I have worn L3 Support , UI Dev and QA among other hats on the Go team but I have mainly been responsible for the delivery of software through writing code. My primary responsibility has been that of a developer.

I have spent time learning the practices involved in engineering software. The code I write usually involves dealing with the likes of Spring, Rails, Apache Webserver configuration, Chef Recipes or, say, shell scripts. Just like working with all of these, test automation using some framework is just another kind of code that I write.

QA on Go...

Whenever I wrote a Sahi test on the Go team, it did not mean I came up with the actual test case to ensure the correctness of the system. It just meant that I wrote code using a

framework to test some functionality. Just like how my product manager and business analysts told me what needed to be built for the release, my QAs told me what needed to be built for functional regression.

On Go, we have awesomes QAs on the team. Apart from other kinds of tests, they also do a lot of story testing. They come up with what needs to be automated for functional regression. I do pitch in and give them context on the implementation, but they do the heavy lifting and come up with the test cases.

I have paired with them before and have worn the hat of QA. In that sense, I have done some testing. However, I do not think just by writing test automation, I am testing.

QAs I have loved working with...

Have a crazy skill to figure out where the edge cases lie. Their exploratory testing skills are very good. Automation is a technique that frees them up from doing mundane manual regression and instead concentrate on exploring a system to find where the bugs lie.

Good QAs I have seen work closely with BAs and make sure they come up with a list of things that are not acceptance criteria because of business requirements but are AC because of reality (what happens when the disk space runs out, what happens if the server are upgrading when the payment gateway responds with a success etc.)

I am by default a “happy path” person - unless I am trying explicitly not to be one. I am quick to dive into figuring out how I would build something. In my head, I start thinking architecture, the design, logging etc. I do not naturally start thinking about - what the requirement should not be, what are the edge cases, what happens when things do not go as they are supposed to etc.

So, yes, while I can automate tests I am not a professional QA. Most awesome QAs have a very specialized skill set and it’s a humbling experience to work with them. So, if you are a looking to get generalists in your team, make sure they have the right skill sets before they wear the QA hat.

Master
Privacy policy | Modern Slavery statement | Accessibility
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.