This is likely to be a controversial topic, and it’s honestly a bit tongue in cheek, but the thought has occurred to me more than once recently. I figured that it would make for an interesting blog post and some interesting discussion.  I think that, in the modern Software Development world, Testing is harder than Development.

If you had said this to me 10 years ago, I would have thought that you were crazy. Perhaps it wasn’t true 10 years ago (it likely wasn’t). Perhaps you think I am crazy to think this today, but in this post I am going to outline 8 reasons why I’m not.

Let me make a confession. When I left University, I took a job in Testing because I thought that it would be easier than Development. I had struggled with writing much worthy programming code during the 4 year course. Even for the generic and mostly straightforward lecture assignments. I didn’t feel that I had produced anything of decent quality. The thought of having to write ACTUAL code, to solve real problems in the real world terrified me.

But I knew that I was going to work in IT. At the time it was the only thing that I was passionate about. So I decided to take the easy path of a career in Testing. Let some other boffin come up with the complex solution I thought. I’ll just run a few manual tests and tell him (or her) if it works or not. What could be simpler!

Well, 15 or so years later, it hasn’t exactly worked out like that for me. Thank heavens for that as well. The job I described in the last paragraph doesn’t sound like the most fulfilling. It’s not something I could persist with day after day.

So why on earth do I think testing is harder than development? How can that even be possible? Let me clarify that for this post I am talking about the role of the modern tester. The tester who is embedded deep in the Agile team, flanked by developers. The SDET – Software Development Engineer in Test (or whatever variation your company has chosen to adopt). Not the old fashioned manual tester that I described above.

Let me make an important distinction here. Crappy testing is easier than crappy development. There isn’t much doubt about that. In this post, I am saying that excellent testing is far harder than excellent development. This was highlighted by Neel Kumar in this great post on Quora . I obviously know that excellent development work is hard too. But I feel that sometimes there is a perception within the industry that testing is significantly easier that development. I don’t think that is true, hence the reason for this post.

Without further ado, here are the 8 reasons why testing is harder than development:


Reason 1: You need a broader set of skills


So of course you have the core set of traditional tester skills. Strong attention to detail. The ability to think outside the box. To be able to spot a potential bug or defect from a mile away. To write a great defect report with detailed recreation steps. All that good stuff. But there is so much more as well.

You must be able to read and understand the development code. I mean REALLY understand it. To a point where you can explain why something is wrong or inefficient (and how to improve it).

You also might need get involved and write your own development code. I am noticing more SDETs getting asked to write development code. This doesn’t have to be a bad thing, far from it. Although it is  yet another skill required to succeed.

On top of that, you will need to write and maintain the automation testing framework. Write the code for the tests. Implement them into the CI system. Determine where the mocks are required. Write them and put them in place. Write the UI tests. Write the Integration tests. Write the End to End tests. Write the Unit tests (if you are really unlucky…).

Does your application need performance testing? Of course it does! So find a tool that you can use for performance testing (and forget about budget, open source only…). Write the tests. Create and organise the test data. Procure the test environment. Of course, it needs to be dedicated. It also needs to be a replica of production…. Good luck with that in most organisations… Arrange the monitoring and instrumentation. Execute the tests. Analyse the results. And when (not if) it all falls over, tell the team exactly where the problem is.

Of course there is also the need for test strategy and planning documentation. OK, with the rise of Agile there is less documentation required these days (thankfully). But these core documents are still required, and guess who will be writing them? If you don’t write them, people will definitely ask why not. If you do write them, no one will read them anyway. At least not until something goes wrong.

I’m going off on a bit of a ranty tangent here. But hopefully you get my point, this is a lot of skills required to succeed.

Reason 2: You need to have a multiple personality disorder


OK, perhaps I am exaggerating here a touch…. But you can’t just think like a tester. You need to be able to think (and act) like a developer. To understand why they have done things in a certain way, and why that makes sense (or not).

You also need to be able to think like an end-user. There isn’t just one type of end-user either. Some are smart and know what they are doing. Some less so. You need to be able to think like them both, and everyone else between.

Then there is the product owner and stakeholders. What would they think of this system? What are they likely to ask for next? Would they be happy with how this has been implemented?

This is a lot of different caps. You better get used to wearing them all.


Reason 3: You need to be good at delivering “Bad News”


Everyone loves delivering (and receiving) bad news, right? What could be better than going over to the downtrodden, emotionally unstable developer’s desk. For the 50th time today. And telling them that the code they have poured their soul into still doesn’t work. What could be better than that… ?

Any tester will have felt varying degrees of being seen as an inconvenience. Or as someone who “likes to cause problems”. Ironically, the better you are at testing the more you will feel like this. Bugs are often seen as a fault rather than help, even though that notion is ridiculous. You don’t want to fix these bugs in production, do you?

How about presenting the latest performance test results to the leadership team? The results are shockingly bad, and going to cost a lot of time and money to fix. There is no way you can launch next month as planned. It’s not your fault (at least not entirely, you are one of a team, remember?). But it’s you standing there delivering the news, sweating like Josef Fritzl on MTV Cribs.

Reason 4: There is no training


Alright, that isn’t strictly true. Of course there are training courses available such as the ISTQB certifications. But I think they have questionable real world value due to their subjective nature. It can be difficult to apply the theory you learn into practice in reality. Experience is key to software testing. There is no substitute for it. I found that this post on the value of ISTQB certification from Simon Prior shared my views. He summarises by saying that the knowledge needs to be applied extensively in the real world.

Let’s compare this to development for a moment. Experience is without doubt important here as well. But say you know that you are going to be working on a certain technology stack in your next project. You can take specialised and relevant training courses on that technology. You can study other materials and example code on those technologies. Then you put what you have learnt into practice. If you run into difficultly, you can post the specific problem to a forum. It often isn’t that straightforward for testing.

Reason 5: Recruitment is a nightmare


Have you or your organisation had to recruit anyone in testing recently? How was the process for you? I have been involved with or conducted the interviews of over 100 testers in the past few years. It has been a difficult and frustrating process to say the least.

The tester market is unfortunately flooded with candidates that are quite simply bad. I think a lot of potential candidates are still under the impression that testing is an ‘easy’ profession. They tend to list a huge array of skills and technologies on their CV. When they are pressed on any of them, they struggle to answer even basic questions.

The problem is that it can be hard to assess and judge the skills of a tester in a couple of short interviews. You can query them on testing technologies and various theories. But answers to these questions can be quite easily learned and recited.

A common problem I find, that is true of both candidates and recruiters, is too much focus on Testing Tools, rather than core Testing Skills. James Pulley touched on that in an interview with Northway Solutions, and it is often discussed on the fantastic PerfBytes pod cast (if you have any interest in performance testing, it’s well worth checkout out).

Perhaps a better way is to get them to talk through how they might test an application with components A B and C. What testing would they instigate, and what issues would like look out for? This still doesn’t ascertain whether they could implement what is discussed, but it would be a start.

Development isn’t immune to these issues either. Goodness knows there are enough poor quality candidates in the field as well. But a developer can be set a specific coding challenge relative to the job requirements. Suppose they can pass that, and answer some suitable technical questions on WHY they did what they did. The interviewer has something far more concrete to go on here.


Reason 6: Less Involvement, More Expectation


This was mentioned by Bhumika Meta in the excellent post “Why Software Testing is a Tough Job”. There is a huge expectation placed on testers. All test scenarios need to be covered and documented. Every test case should have been executed, even if the testing window was only 1 day because development overran (again…). The expectation is that testers are certain there are no bugs in the system. Everything should work perfectly when moved to production.

All this expectation often comes with less involvement. Testers often aren’t queried on what THEIR requirements are for the testing. Whether what has been developed is even testable. Or how they will complete the testing. Or how much time they need (which can be difficult to quantify anyway)

When things do go wrong in production, the tester is often blamed. You are seen as the “Gate Keeper of Quality“, so why wasn’t this picked up in testing? Why wasn’t there a test case for this (complex and almost impossible to replicate) scenario?

Thankfully, and again with the rise of Agile and the SDET role, this situation has got better. It is  more widely accepted that the whole team owns product quality, not just the tester.  Joel Masset, my Director at Concur / SAP, recently wrote a great article on this .

Testers should no longer be treated like second class citizens in most forward thinking organisations. If you are still treated like one, get the perceptions changed. If you can’t change them (or they won’t change them), find another job. The demand for high quality test professionals is at an all time high.

Reason 7: Less credit and appreciation


Again, this reason is less true where developer and tester are seen as equal (or close to it, at least). But elsewhere, the common scenario when everything works well is – “The Devs did a great job!” When it doesn’t work so well, and there are bugs – “Why didn’t the testers find these problems?

This doesn’t bother me much on a personal level. I have learnt to award myself Gold Stars, rather than wait for someone else to do so (thanks in part to this great book – The Success Principles). But of course, it never hurts to get recognition for a job well done. This can be hard to come by for testers.

Reason 8: You are outnumbered


Maybe this is a bad thing, maybe not, you can decide. The general ratio of developers to testers in most Agile teams seems to be 2:1. Perhaps this is a reasonable ratio, but it depends on the expectations placed on the tester.

The expectation might be to pair with the developer to do ATDD or BDD . Also to write every type of test (unit, integration, e2e). And get all those tests automated. And conduct performance testing. And write up all the test results and reporting. And make the tea / coffee (i’m joking…. developers only drink coffee). That’s a lot of work for 1 tester to support 2 developers!

Being outnumbered naturally means that testing has less of a voice. That doesn’t need to be a problem though, we just need to shout twice as loud.

So there you have it, its official, testing is harder than development! Well, maybe it is, maybe it isn’t. But I think with the points I have outlined above, there is at least some justification to say that.

What do you think? Please leave you comments below, I would love to hear from you! Especially if you are a developer, and think I am ludicrous!



  • Max Crane says:

    You missed some. Examples are:
    Business rules don’t always cover the assumptions. Take the example of an analyst/programmer writing the logic for making a cup of coffee – Locate a cup, Locate the coffee, Locate the hot water, Locate the sugar, Locate the milk, fill cup with hot water, place one teaspoon of coffee into cup, stir etc. What happens if there is no cup? What is the logic if you have cold water? What type of coffee have you located – instant, ground or beans, etc How do you write a test for the things the business assumes will always be there or will always have instant coffee, but the customers want ground for a percolator?

    The business doesn’t always know its business. How can business explain what it wants if the subject expert is the most junior and inexperienced person you can imagine? What happens if we are automating because the SME has quit?

    Testing is tough. I like the example of testing three inputs – A,B,C (each a length of the side of a triangle) passed into a sub routine that validates the whether the inputs make a valid triangle and determines if it is equilateral, scalene or isosceles. Seems simple… How many tests are needed?

    Is A, B or C a number (three tests to pass)
    Is A, B or C a negative number (three tests to fail)
    Is A, B or C = 0 (three tests to fail)
    Is A, B or C a null value (three tests to fail)
    Is A, B or C a character (three tests to fail)
    Does A, B or C exceed max int on the server (three tests to fail)

    If A,B and C valid then test return values
    If A=B, B=C and A=C it is equilateral ( 1 test to set return value)
    If (A=B and A=C but not B=C) or (A=B and B=C but not A=C) or (B=C and A=C but not A=B) then isosceles (3 tests to set return value)
    If not(A=B or A=C or B=C) the scalene ( 3 tests to set return value)

    I got 25 here but my memory suggests there may be more, but I hope not. How many did you get?

    • Ohad FK says:

      You should use equivalence classes (EC) and boundary values (BV), like: are A, B and C numeric (non-characters), greater than 0 and less then MAX_NUM (why did you decide it’s supposed to be an INT?!) (and by definition, if they’re numeric, they’re not NULL) can be something like the following pseudo-code:

      if 0 < A <= MAX_NUM return True, else return False
      HANDLE_EXCEPTION # Will be raised if A is not a numeric quantity, which covers both NULL and a non-number character/string.
      (Rinse and repeat for B and C).

      But, sure, the point of the comment is loud and clear: a lot of testing is required for even the most trivial **LOOKING** apps.
      (I can easily come up with at least 10 more test cases, without even breaking sweat).

  • Thanks for the comment Max, and great scenario… To think, that is only with 3 inputs… most projects will have a LOT more 😉


  • John Ruberto says:

    Great post James. My comment is somewhat similar to Max’s: For any non-trivial project, there are literally an infinite number of tests that could be run. However, we have a very finite (and shrinking) amount of time to test. That is the intellectual challenge that drives me in this role.

  • Alaine Miller says:

    I have had the privilege of working with some outstanding developers recently. They champion testing and have skillsets covering multiple programming languages, networks, security, deployments, desktop support, devops and communicate phenomenally well. I don’t think testing is harder. I do think they are equal and I do think we have reached the point where the dev and test skillsets have widened to truly overlap.

    • Thanks for the comment Alaine – I have worked with some excellent developers too, and they have always had a great appreciation for the value and complexity of good quality testing. I have also worked with developers who treated testers very much as second class citizens and didn’t have much insight into how complex our role can be.

  • Vivek says:

    For the triangle example, you also need A +B>C or A+C>B or B+C>A to get a triangle in the first place.

    • Thanks Vivek … so its even more complex than it first seemed ? 😉

      • Ohad FK says:

        Just for the sake of arguing, here’s a wild, super out-of-the-box-thinking test case for the triangle question:
        It is assumed the coordinates are given to be displayed to the screen.
        Now, given the coordinates (and assuming they’re valid and OK)…. it is entirely possible that for certain coordinates and certain screen resolutions, the displayed triangle is out-of-bounds for the given screen.
        I.e. the triangle is “projected” to the I/O Stream that governs the display on screen, but nothing will be shown on screen due to technical issue.

        Now, the really hard part, is it a bug? Feature? If you got the empty screen result when using these coordinates but a nice looking display when using a different set of coords, would you have made the mental leap and figured it out or classified as a “Heisenbug” hoping it won’t show up on production (thus **MAKING** you analyse this seemingly strange issue).

        And that’s all in a day’s work for us QA professionals who, as the article so aptly summarized, are the ones held responsible when things f*!&-up but rarely get an “ataboy” for, you know, covering all the more common issues that **WERE** caught by us in time to be fixed before shipping.

        (And yes, I’m for one, extremely pissed-off by that. Especially since it never seems that “yeah, I missed it, but so did the dev who 1. wrote the actual code and, 2. wrote and ran the “units” did, so how am I the **SOLE** one to blame and assign responsibility to?!?!” is a legitimate answer. Apparently, this answer is responsibility-shifting and blame-dodging. But solely assigning blame to one member of the team isn’t. Logical enough, right?)

  • That’s a great post James and a nice read. As you told on twitter, it might be good to get opinion of developers.
    Sorry, bu I’m not one of them, but more a “manual tester using tools” after being for a short time a developer. I really don’t know which one is the harder, tester or developer. The one you describe is more about the Software Development Engineer in Test, but why do you call it the modern tester? I guess you oppose it to the old tester which is only writing test cases and execute them manually (or make them execute by someone else and just check the result). The modern is then the one who is writing code to execute these test cases. Another modern tester could be the one who continue to test mostly manually, and who is helped by tools, who is writing a few scripts, investigating by going deeply in logs and sometimes in the code to find where things could be wrong. A modern tester is also a context-driven tester (not following any ISO standard) using his brain and adjusting, an exploratory tester, sometimes a penetration tester, sometimes a security tester, an accessibility tester, a UX tester…Etc. There are so many different fields in testing, but I think it’s the same in development, you always have to improve your skills and find new things.
    To put it in a nutshell, working in software industry is hard because truly complex and continuously evolving. Development is resolving one problem, we, testers, must live with the infinity of possibilities that are the result of this problem “maybe” “almost” solved in some specific conditions 😉

    • Hi Stephane, thanks for the great and thought-provoking comment. I think it would be a really good blog post to look at each of the different testing types that you described in more detail 😉

      You are correct that the role I am describing here for the “modern tester” is indeed for the SDET – but that is where I see the demand in our industry moving now, and hence will become the “modern tester”. It seems to be a given that the top / best paying jobs in testing now have a core requirement for the candidate to have deep technical knowledge (as well as the many other core skills needed to excel at testing).

      The problem is, and John referred to this in his comment above, demand and time. As applications and interwoven technologies grow more complex seemingly by the day, the only way that testing can keep up is to be “smart” – to automate what can be automated, and decide which other testing to complete based on the risk & reward. There simply isn’t time in high demanding environments to spend hours doing exploratory testing of a system (which is a real pity, by the way…)… Anyway, this is my situation currently and from my point of view – but perhaps it is different for you?

  • Amit says:

    Great Post !!

    My experiences

    1. I have herd this many time “Why wasn’t there a test case for this ?” … Should i shot my self for that , its agile team now and still am only accused
    2. “Changing from Not a bug to Bug”, it takes lot of energy and time for this , specifically performance issues , where req are either one liner or not present at all .
    For example –
    a. Dude(Developer) , your code is using only half CPU’s on system , do you want to rent other free CPU’s (This is not how I log bug however that’s how it is in my mind 🙂 )
    b.Your code is using lot of kernel CPU , what are you doing there ?
    c. I was handle leak in your code , it has not break anything till now however this can in long run, are you effectively utilizing memory, DO you close all the result set objects, statements or whatsoever.

    3. From managers , I need 4 testers on board from next week …are you joking ???

  • Jim Hazen says:

    The one point I would say you missed is that Tester’s need to be Masochists. Because we endure a lot of pain for the “pleasure” of our jobs. That and we all need to be taking the proper anti-depressant drugs to keep us going through the day. Just remember “The beatings will continue until moral improves” as the motto of Testers. Sorry, been doing this for 30 years and somethings never change.

  • Rushi says:

    Great Post !! Real situation presented here.

  • Bruno says:

    I agree with outnumbered, so by my experience it’s most often 3:1 up to in our case 7:1 (and I heard of one case where one QA guy was giving test support to 14 devs)

    • Hi Bruno,

      Yes, I have heard the same sort of ratios since I made this post. To think I was complaining about 2:1 !!
      14 devs to one QA is insane!!


      • Thomas Sullivan says:

        I recently worked in a group that had 2 testers for 15 developers. The number of developers needed on a project was determined by the number of agile points (proportionate to number of days work) per sprint. For testers there was no such proportionality. The solution was always just to heap more work on the test pile.

        • James Willett says:

          That is some ratio Thomas, but doesn’t seem to be uncommon. The ‘solution’ is obviously going to lead to problems before long. I wondered if there is scope in this group to transition a few of the devs into testing?

          • Thomas Sullivan says:

            I left the company about a year ago so I’m not sure what has transpired since then. Things may have changed since then but I would wager that is probably not the case. What you propose is a reasonable solution, no doubt. However, there’s the rub. If management decides to hire more developers based on an increase in agile points per sprint and then does not apply the same principle to hiring testers, how could one expect that they would encourage developers to become testers? Another factor is salary. If testers are considered second class citizens, and paid accordingly, what would be the incentive for a developer to become a tester? No developer in his right mind would ascent to this, let alone desire it pro-actively.

          • James Willett says:

            Good points, and of course no developer would make the transition under these conditions, hence why the company should make testers and developers equal (or close to it), in terms of salary and everything else. There is a huge gap in the market right now for skilled & quality testers. That gap is making it harder for companies to acquire and retain those resources. It’s my belief that we could soon start to see the salaries of the best testers exceed that of the equvilent developers. But that’s just my opinion based on how things are moving right now

      • Yeah! I was to comment the same, I’m on a team where the ratio is 8:1, but 14:1, wow.. xD

  • Ram says:

    Great post James

  • Joel Masset says:

    Very good post James

  • Alex Zaicu says:

    Interesting read, James. May I point out that there is training beyond istqb. Notable examples with hands-on approach to software testing training are Cem Kaner’s BBST course and the RST trainings of James Bach and Michael Bolton.

    • James Willett says:

      Thanks for that Alex. Have you taken any of those courses? I would love to know your feedback if you have!

      • Thomas Sullivan says:

        I just took the BBST Foundations course (AST). I’ve been testing for over 15 years and yet found in it many points of clarification and new understanding. I proudly display it on my resume.

  • Prashant Hegde says:

    Good read!

  • Catla says:

    Great read. And in point 3 you can add becoming a true diplomat and psychologist. I have found over my many years working in the QA/Test field that developers are complex being all with a different approach required.
    My skills as a communicator (already fairly good coming from a linguist background) have increased at least tenfold since doing this job. And it means great impact on all aspects of life too.

    • James Willett says:

      Thanks Catla – you have made some wonderful points as well that I totally agree with. Its great that some of those skills you have been forced to learn in testing have had other positive impacts in your life!

  • ישראל פרוכטר says:

    What if you took the tester out of the equation ? and everyone on the team are developers ? who would do the testing ?

    Who will build the tools ? or CI system ?

    We are trying it for a long time, some development team can do it, some less. but the change attitude is refreshing, but really hard to get right, now the whole team get blamed for stuff that’s break , and they do quite often..

    • James Willett says:

      I have noticed the trend of teams trying to remove the tester role entirely from the team. I don’t agree with it and feel it is detrimental to quality in the long term, even if there are some short term gains.
      In our team, we encourage that quality is owned by everyone (tester / developer), so we all get “blamed” (if thats the right word to use!) when things go wrong

  • Andrea Melo says:

    Great article. In my long +10 years of experience in QA/Software Testing area, with six years experience in Technical Writing, I would like to point out the importance of certifications. At least, they are, for me. Another point is the fact that we, Testers, also have to convince the ‘super mighty’ Business Analists gods/godesses, that sometimes they are not that right about something (s). 😀
    But I love my job.

    • James Willett says:

      Thanks for the comment Andrea. I myself have a few relatively straightforward certifications (Certied Agile Tester, ISTQB Advanced Technical Test Analyst), but I must be honest and say that I haven’t found much use for them, nor have them offer me much value other than having them on my CV. I am curious to know what certifications you hold, and how they have served you well?

      Agree with you on the Business Analysts point, infact as testers yet another skill we need is being able to convince others of our (often unpopular) findings! That goes for all our colleagues 🙂

  • lashini says:

    Really good post James, learned lot.

  • Evgeni Kostadinov says:

    Best article I’ve read in the past few months. Admiration! Just one small thingy to add – QAs should implement unit tests of their own (core framework) logic. Further more, I consider myself lucky when I have to write such tests for the DEV code. I’m learning a lot for both tech and domain aspect of the project.

    • James Willett says:

      Thanks Evgeni . You raise a great point as well. In my experience it often falls on the devs to write the unit tests, but if QA can get involved in that as well then its even better. The more exposure you get to the code, the better you understand it, and the better you can test it 🙂

  • asdsada says:

    I think you have never developed in your life 😉

  • friend says:

    To be quite honest none of the points actually a valid argument, more over that past point 2 everything is basicly pure whining. If we go throught the points:
    1. Design of testing framework, unit tests, end-to-end tests, performance tests – If one implements an automated test framework everything I can’t think of the possible number of such frameworks out there, performance test – do you actually not just register flaws in the performance of a software, but propose an actual solution? I would be surprised if you actually do.
    2. I admit this is pretty much the essence of your job and is something I admire and have no argument against. Keep it up guys, we love you for it!
    3. Being unable to take criticism is a problem on personal level and has nothing to do with your occupation.
    4. Try learning algorithms, data structures, OOP, data bases and SQL, basic cryptography and communication protocols. I believe that in about 6-7 years you will be quite decent with that training. There is no shortcut to getting good or even mediocre, tutorials on how to print “Hello world” are helpful, but I’m afrait they don’t really meet the level for even the entry level as a juniour developer nowadays. Welcome to SQA(https://sqa.stackexchange.com/).
    5. Whine, whine, whine.
    6. More whine.
    7. Even more whine.
    8. This is actually insulting.
    In conclusion, please respect your teammates. We are on one side and I, as a developer, DO APPRICIATE your great effort and dedication.

    • Florian Heigl says:

      And as the first thing with your sharp mind you declare that nothing brought up is “valid”.
      You end up asking for respect, after saying it’s insulting to say that testers have less of a voice when they have a lot lower staff participation.

      Wait a minute. Did you really first tell him what he says doesn’t matter, and to top it off, added that pointing it out is insulting to *you*?

      LOL. You guys are so incapable of taking a step back from your arrogance that it hurts even over the internet.

      • friend says:

        Let’s break down your response:

        “And as the first thing with your sharp mind you declare that nothing brought up is “valid”.”

        I see that you really make no difference between making a reasonable point and plain whining. If you want to make a statement you need well founded reason, not a list of blind statements, I’ve noted my arguments why I don’t consider his arguments to be valid (where I do not agree with them).

        “You end up asking for respect, after saying it’s insulting to say that testers have less of a voice when they have a lot lower staff participation.”

        If you work at banana software corp where QA’s are treated like monkeys it’s your own fault and has nothing to do with the position itself.

        “Wait a minute. Did you really first tell him what he says doesn’t matter, and to top it off, added that pointing it out is insulting to *you*?”

        “Being outnumbered naturally means that testing has less of a voice.” – Testing always has the loudest voice and no developer will just blindly state the oposite. What’s insulting is depiction of a group of developers that are abusing their numbers..

        “LOL. You guys are so incapable of taking a step back from your arrogance that it hurts even over the internet.”

        This is pretty much in the spirit of the article, focused on the hating and whining.

  • An angry developer says:

    Whine, whine, whine indeed.
    So to summarize what you say. You (as a tester) do all the work, working 25 hours a day 8 days in a week, working for 10 people at the same time, while the developers do noting. Software companies should have only QAs and no developers at all.
    Saying QAs do nothing would be as true as what you’ve said. I don’t suggest that.

    A software tester that does everything you’ve said would be welcomed in any team, at any company. Such a person doesn’t exist.

    If a product needs more skills and knowledge to be tested than it needs in order to be developed – then it is a crappy product.

    “You also need to be able to think like an end-user.” That is true, but “You need to be able to think (and act) like a developer.” is not. Not only that, but combined with the other thing in you post seems that you say developers can’t think for themselves. That is not true in general.
    But I can say that many of the QAs don’t think. Our bug-tacker (we use JIRA) is full of duplicating issues and any of the well known problems with our product is logged at least 3 times, because bigger number of issues means the QAs are working ‘really’ hard. And a large percentage of this issues aren’t bugs actually – they are misuses of the product by our own QAs, because reading the documentation or even just the 2 pages of FAQs is boring. And who notices the warning messages saying “you are an idiot”…

    I am a developer and I’ve come to this post because a QA in the company I work for has shared it. So I will note how the software testers work in this company. There are some who work really hard and get as close as possible to what you describe here, but then there are the 50% to 60% of all the QAs (and from the user support too) who spend on average 3 hours of their works time in the cafeteria next to the office and 1 hour telling jokes in the hallway (which obstruct the work of other people, because they do it quite loud). Every day. And if you ask them what are they doing, the response always is “I’am waiting for the tests to finish.” We make professional software and running a typical work case of an average client takes a lot of computation time even on a powerful workstation and that can go without human intervention. Our clients usually tweak the setting while at work, let the task run during night time and get the results in the morning, but it is easy for someone who does not want to work to say he/she is waiting for the software to do its magic.

    In summary you’ve described a perfect (fictional) software tester. I can describe also perfect and also fictional developer, whose duties will be brazillion times harder.
    Every job can be hard and every person can try to do his job well or can find excuses.

Leave a Reply