Developers Recognize the Need for Testing, But Still Devalue Testers


I had the pleasure of attending Mobile+Web DevCon last week in San Francisco. Being a fairly new and relatively small conference, I was a bit skeptical about how much I would get out of it. Fortunately, the conference ended up having a good number of attendees, and the sessions were – for the most part – thoughtful and engaging. What really caught me by surprise was all the chatter about testing mobile applications.

That’s right testers: this was a small community of developers, creating mobile apps, talking about mobile quality and the importance of testing. If I were to tag a theme onto this conference, it would absolutely be mobile quality.

If you’re a commendable software tester, you understand that testing is not an easy task nor is it for the weak minded. To be an effective software tester, you need to approach the software philisophically, overcoming biases and understanding the context of each and every testing situation. Of course there is much more to it, but I am not going to go into it here. The point is that software testing is a skill that is not as easily attainable as some might initially believe.

So what am I getting at? I was a bit put off by some of the discussions about software testing. Of course, there were a few people who understood the importance of testers, but the general vibe was that testing is something anyone can do.

For instance, one speaker said you can just hire testers off of Craigslist, essentially devaluing the software testing occupation to that of a one-time handy man. I’m not sure what the intentions of that comment were, but I was definitely taken aback by this inference.

Since this was a mobile conference, I can only speak of the mobile developers at Mobile+Web DevCon, but there seems to be a serious divide around the importance of testers. I fully recognize this divide is hardly a new phenomenon, but the issue lies in that developers themselves are not putting their mobile apps under the same scrutiny as apps for other platforms, i.e. Web and desktop.

Roughly 8 out of 10 developers that I talked to at this conference said that they do both the development and testing themselves. That’s like writing this blog post without an editor—the quality of my writing would be significantly degraded. I could try to edit my own work, but I know that I would likely overlook a typo or fumble over a phrase due to my own biases and partiality.

I understand that the lack of testing may be a resource issue, especially for smaller development houses, but is that an excuse when the credibility of your organization is on the line? You just need a few 1-star reviews on the app store to keep others from ever giving your app a shot.

The irony comes to life when the very same developers who tell me they don’t need testers to do their testing turn around and insist that mobile app quality is the most important factor to the application’s success – an assertion that is backed up by SmartBear’s own original survey data.

Am I the only one who sees how crazy this is?

If the mobile industry is going to continue to evolve, testing needs to be at the top of every organization’s task list. The mentality of “code now, test later… if there’s time” is no longer acceptable. If time is a pressing factor go ahead automate some of the testing, but keep it in the hands of someone who truly knows what they’re doing.

We’ve all seen the embarrassing results of nonchalant testing. Are you really willing to risk the future of your mobile app?

See also:



  1. I wish I were surprised. This seems to be a never ending cycle:

    – Devs & management want testing to be easy
    – Teams hire testers to do easy stuff
    – The testers hired to do easy stuff don’t add very much value
    – People around those testers decide testers are kinda useless
    – So they assign more and more trivial tasks to the testers, who deliver less and less value by doing what they’ve been assigned to do
    – GoTo Start

    The reality is that *good* testing isn’t easy. Good testers are good at it. Good testers can (when given the latitude & tools they need to be successful) are amazingly valuable. Devs (as well as BA’s, SME’s, Product Owners, etc.) can do good testing too, but again, only when provided the opportunity, resources (and often training) to do so.

    So here’s the real question. How do we break the cycle? Until teams start hiring testers who have the skills & experience to do good testing & enable them, they will always see testers as, shall we say, not so valuable. And until they experience good testing, they aren’t going to hire good testers to do good testing — which in turn leads to *tons* of mediocre to disinterested testers getting jobs (because they are the low cost service provider).

    My vote? If you’re one of those folks who think testing is easy, spend some time learning about “good testing” — testing that provides business value, testing that helps the team deliver better products, faster & cheaper, testing that saves a company more $ than it costs. Then start expecting the testers on your team to deliver to that standard (get them training of needed) & if those testers can’t (or won’t) meet the standard, upgrade your testers.

    I bet that any team that follows that pattern for a year will change their song about how valuable a tester can be.

    At least, that’s what *I* believe.

    • Unassigned says:

      Well stated.

    • Software Tester for 25 Years says:

      Testing is a Science and an Art, and pride myself on getting within no greater than 10 lines of code to make it easier for the Developer to find the issue in their code. You get what you pay for, and seems this subject matter is more over egotistical issues then truly understanding the subject at hand. Nothing makes a Software Quality Engineer happier than knocking down a developers ego…

  2. marketomlinson says:

    Crappy testers have always been devalued. Same goes for crappy developers, crappy PM’s, crappy ops guys, crappy CEO’s and crappy customers.

    But, if the corner office and your customers actually care about quality then you must VALUE talent. If you value TALENT, then you should be willing to pay reasonably for it.

    Crappy == cheap == no value.

    Talented == not cheap == value.

  3. How many of those devs were one man band shops selling apps for .99c?

  4. Lanette Creamer says:

    This is no shock to me, nor is it a suprise that very few testers were even AT this conference.

    Just as developers are quick to devalue testers. Testers are too quick to dismiss developers as the MOST IMPORTANT testing customers. If we are showing developers how we can help them develop higher quality software cheaper and better than they can do it themselves, testers are also failing. We are failing at the ONLY advocates who could possibly understand the important details involved in what a talented tester does.

    So, who is important to our future, as testers. Certainly not the idiots looking to hire automators at the large companies. I don’t want to work for those clowns. It better be talented developers. They are the least likely people to waste my work. There’s an opportunity for a great partnership to happen between developers and testers, but only if they get a chance to test out the difference.

    If someone is doing a valid study of using random people willing to test (such as a crowdsourcing company) vs a small group of skilled testers, I’d volunteer my time so that some data can exist. How do we know what works well if we never test it?

    I believe cheap is more popular because most developers dont want to hire or manage another person, and I don’t blame them. It’s a big risk in an area they aren’t always talented in.

    • Sure, some of the problem is on us (and by us, I mean the global community of people who are either assigned to do testing, or who self-identify as testers as a whole). If we aren’t going the extra mile to demonstrate the ways we can add value (or even going the extra mile to *learn* how to add value), we are not only doing a disservice to our stakeholders & employers, we are doing a disservice to our industry peers.

      That being said, *so* many people assigned to do testing aren’t even aware of communities, training, conferences, blogs, or books about testing that I find it hard to blame them for not knowing about a field they were assigned to and offered nothing more than OJT from the last person who was assigned without training, ya’know?

      • Gregory Mooney says:

        It goes both ways. Sure, we can stand here and say we should do more while these development “pow-wows” go on, or we can interact more in the development community, rather than nesting in our own and not coming out to play.

      • Sanjay Daiya says:

        Well with so many cheap testers avialable to do click and wait testing people have started believing that testing is all about click and wait nothing more…Another common thing we have here is automation testers are better than manual testers. So if you know how to write a scripts on what is already stable then you are good automation testers. Some automation guys have even started calling them automation engineers to avoid the so called low profile tag “Tester”.Unfortunately our community (All those new testers coming in from different backgrounds, some even from dev thinking its an easy job.) is doing its best to make sure we loose respect. for eg. I worked in a project where dev guys gave me a war file and I just deployed it on tomcat and started testing…My manager (A developer throughout his life) added that to my learning saying see you learned deployment in this project (a new learning)…that mindset almost killed me…I said c’mon we testers are not bad. Time for testers to stand up and show there worth.I always say testing is not a skill set its a mindset.Overcome click and wait thing…learn the techincal aspects of the project.

        • This is a two sided coin — or a “chicken and egg” problem — or a recursion problem — however you like to think about it.

          Somewhere in the past, a cycle began where (on average) less was being expected of testers. Testers accepted the lower bar and did what humans do — the minimum they could get away with. Believing this was the best they could get, the expectation setters, lowered the bar yet further… lather, rinse, repeat.

          Here’s the thing. The cycle isn’t going to break itself (inertia and all). Someone needs to exert force against it. So who is that? I *believe* the expectation setters would be more than happy to raise the bar *if* testers are ready to meet the higher bar — unfortunately, (on average) today’s testers are some combination of uninspired, under-trained, stuck in a rut, comfortable, or even unaware of what a higher bar looks like.

          Thus the dilemma. (on average)Expectation setters don’t know how to instruct testers on what “more” they want *and* (on average) testers don’t know what “more” they could be providing.

          10 Print “Welcome to the Recursive Recursion Department”
          20 GoTo 10

    • Michael Larsen says:

      I think this is a good point, and it points to a critical part of the discussion… what are we, as testers, doing to help show the programmers we work with that our input is providing value to them? If we just sit around and do whatever we are “asked” to do, then we should not be surprised when later we are seen as not offering much in the way of value to them. we should provoke discussion, and we should be able to make clear what we are finding and sell what we are finding persuasively. Some times that comes in the form of making a personal connection with a programmer (or several programmers) and working directly with them and giving them valuable information, not just what they are asking us to provide.

      • Sure – but many mobile apps are developed by lone gun devs or small dev shops that have zero testers. How do we connect with these people ?

        • Gregory Mooney says:

          I agree that many are, and that is usually a resource issue as I suggested in this post. However, there were just as many larger companies developing mobile apps and doing the testing later. It’s definitely a mixed bag, and I’d be interested to see that in a survey with a large sample size. I’ll look into it.

  5. Did you speak to the devs? Were they all doing “code then test”? any of them doing TDD? What about the guy that got testers off craigslist – did you ask him how well that worked out for him? Maybe he got a great tester for $10?

    • Gregory Mooney says:

      Of course I spoke to the devs, or else I wouldn’t make these claims. Yes, with the exception of a few they were all coding and then testing. Apparently, it worked out good enough for them to actually suggest it in a presentation, so I say yes, maybe you’re right, they may well have gotten a good tester for $10, but is that a good tester if they don’t even understand their own value?

  6. Richard Taylor says:

    20 yrs ago read article by Geoff Quentin entitled “Testers & Developers Think Differently”. Not much has changed there, for reasons of basic psychology. No dev deliberately writes buggy code (I know, I was one b4 I started to test for a living). So most dev’s, who have put blood sweat & tears into the best code they can write and have total confidence in it, view testing as a way to prove that their code does what they have written it to do – and, surprise, it usually does. They are not aware of the subconscious assumptions they have made about what the spec meant, nor even that they might have made some, and don’t think to check that the code doesn’t do stuff that they didn’t intend. Best way to overcome this, in my experience, is to pair up with them on testing and win their respect by example. When that works, they become more test-aware and start to be better at testing themselves.

    • Gregory Mooney says:

      Thanks, Richard.

      Pairing is a great way, but it shouldn’t just be about a tester trying to gain the respect of the developer. Respect should be mutually acquired.

Speak Your Mind