A lot of people view testers as second-class citizens; probably because QA guys rarely ‘create’ stuff like devs do (although they sometimes do original work creating test frameworks and platforms). They are more similar to editors who verify the work of authors. However, testers are just as important as developers; without QA the end product is bound to be buggy and might even miss out on the requirements!
Developers usually believe they write bullet-proof code, (after a couple of ‘subjective’ tests which assume some ‘condition’ will never happen and so on…); however as we all know it; this is not true. I believe every software project requires testing – yes QA is that critical. You can’t be really sure that some complex piece of code works properly, you can only be sure that you didn’t find bugs. Even well-known APIs, languages and frameworks have issues, for example, a bug was found in the Java implementation of binary search some time ago.
Testing requires a different skill set from development and all programmers will benefit vastly from spending some time as testers. In fact a Microsoft Test lead said the best developers he knows all started out as testers. This is not far-fetched; such test-devs do more automation of mundane tasks, know more about potential failure scenarios and try to guard against it early in the writing process; moreover they test their own more thoroughly leading to more reliable software.
Testers have to make sure the product is robust, matches the customer’s requirements and find out flaws the developer probably overlooked while writing his code (e.g. passing in wrong parameters, graceful degradations, bad failures etc). They always have to devise ingenious testing scenarios that expose flaws and defects in system design and/or implementation. Contrary to opinion, testing might involve writing code to test code (automation) and building testing frameworks/platforms; some testers probably get to write more challenging code than developers.
Why do devs/PMs etc dislike QA?
Imagine having to tell proud parents that their beloved child is ugly? Sounds tough right? QA guys have the unpleasant duty of pointing out the flaws in the work of devs and PMs. Well, no one likes to be criticized or told they made mistakes after working so hard on a feature. It’s not difficult disliking guys who routinely point out the flaws in the design, system implementation or find out bugs in your code.
Pros of QA work:
- Testers understand the project requirements and have a wider knowledge of the product life-cycle.
- They ideally work well and interact with a lot of team members – PMs, devs and other QA guys.
- They learn to be patient carrying out repetitive work and come to appreciate automating lots of things.
- They have great analytical skills – well that’s all what testing is about right?
- They learn how to communicate, how to be impersonal and tactful and how to diffuse tense situations when they happen.
- Testing skills come in handy if you ever switch to development.
- Replacing good testers can be a very difficult task… talk about job security ;)
Cons:
- As I said earlier no one likes being told their brainchild is ugly even though it’s true. You might have to handle friction.
- Yes, it might get extremely boring repeating the same things but you can always up your game.
- Testing experience might not count as development experience.
Well, if you still believe developers are better than testers; that’s fine. Just learn how to test your code properly and save us all the pain of bad software and evil failures. Moreover, don’t feel bad if a tester shows you 7 bugs in your one-of-a-kind-awesomeness-embedded-wonderful-piece-of-code.
Still think testers are inferior to devs? Have your say in the comments.
CodeKraft 
@popoola … this means I am not second-class citizen….:)
LikeLike
lol, :) not at all!
LikeLike
The one time I had to deal with a QA guy, it was hell. They basically exist to frustrate you, constructively though, pointing out the flaws of your design, code etcetera. This is good because it saves everyone the embarrassment of shipping buggy code. It brings a SE course I’m taking to mind, where we talked about famous software failures. The baggage handling system of Heathrow and Denver that delivered baggages to a different destination than the one intended, the Mariner 1 spacecraft shot down because someone didn’t code a pseudo code properly and the FP problem on Intel chips. If only they took QA seriously. I doubt firms in Nigeria do. IMHO, the QA as part of an SE team should be treated as a an equal. Think of them as extended pair programmers if you will. Please write more often as I learn something good everything you do. Barakallah feeh!
LikeLike
Ameen; jazaakumullaahu khayran – you’re the top commenter too :)
lol @ ur time with a QA guy and no, he’s not out to annoy you – YOU are RESPONSIBLE for ya own code :).
Nigeria’s software process still has to mature; however Alhamdulilah it’s growing.
LikeLike
There is only one problem with software testing – you always get hired temporarily and you cannot make a living. I started as a developer, after moving to the USA started working as a tester in hope that after proving my abilities I will get a chance to develop hi-tech products. I was wrong! I wasted 8 years of my life and 3 times almost ended up homeless.
Nobody took me seriously as a tester. When applying for positions as a developer or tester I was showing demo of 3D GPS map which could be controlled by finger gestures, but nobody seemed to be interested. That was before first iPhone was released. I guess nobody believed that tester could come up with new technology. I had to start working as developer on my own projects. Now employers take me seriously as a developer and innovator. Now I don’t have to look for jon and beg to get hired, employers contact me, because I’m 10 years ahead with my ideas, but mostly because I am a developer, not a tester.
Recommendation to young people out of school: don’t even start as a tester. You will have hard time to get out of it. Don’t waste your life.
LikeLike
Thanks Developer; great to hear about your success story. But surely, your testing experience gave you some edge while developing your application?
Sadly a lot of firms see QA engineers as being inferior to developers and this is not supposed to be the case. It’s not difficult getting out of test; you can build a career out of it or switch after honing your skills.
LikeLike
Are developers better than testers? Good testers (analytical) are no worse and are as important as good developers. The trouble (and that is where the general assumption that testers are “second-class”) is that many testers are NOT analytical, many end up “polluting” the development/testing process. I (as a developer) will expect good/analytical tester to understand that there is no point in testing (and failing) multiple tests after an error in “lower level/base” code was found.
Example: When developing BigDecimal implementation once a bug is found in add()/subtract() functionality there is no point in testing any further because all other functions will be using there base ones.
LikeLike
Great view point! Thanks.
LikeLike
I’m a test engineer not a tester. One of the most misunderstood in the industry is to distinguish between tessters and test engineers. Most people doing testing are testers and do not design or create. But test engineers absolutely do create and design not only test cases but test suites, test approaches, test strategies and test plans for an entire project. This can be as small as a simple software change all the way up to a brand new test release to a system.
The title “Are developers better than testers” threw me. As a tester, I need a qualifier…Better than what? There is no definition in the post as to what the requirements are and yet there are people who respond with their assumptions of what “better than testers” means. Do you mean developers offer a more direct impact on the business? As developers are viewed as “innovators”, “designers” and “creators”, developers develop software, a real tangible product. Testers do not develop a sellable, tangible product, the testing group is viewed as a service in the checks and balances of a financial spreadsheet. Testers are a drain on the budget because as a singular group, separate from development, the creative group.
But the question I have to the author and everyone who responded, why make the comparison of “who is better?” Seems rather silly to me.
LikeLike
Well, it is easy to point out mistakes in something that can be tested, but is it easy to create software that needs to be tested in the first place?
LikeLike
Hello Madhan;
You make a statement of “it is easy to point out mistakes in something that can be tested”, my question to you is have you ever been a tester on a project? How about when you’re given a software application where there is no documentation…the tester would be given no expectations of how the application should work or even from the creator on how they expect the application to work. Now do you think this is still easy? Try it sometime, you might be surprised with a different perspective.
And the idea that testers exist to point out mistakes is a self defensive idea. When I test, I take on the attitude of wanting to make the developer look brilliant. I want the product to be truly fantastic and I don’t point out mistakes, I try to HELP clean up some things that were either typos (mistakes) in the code, but also to work with the developer to help make the product even better! I’ve worked with some fantastic developers where we worked together to make the product stronger and in the end, we were both thrilled at what we accomplished.
My question to you Madhan, how is “easy” or not easy the measurement for who is “better”? I would never claim creating a software application is an easy task. I would never diminish what any developer does, as the creative process, designing how something should work is quite amazing and difficult. But guess what, testers also have to design and create tests out of nothing. Sure we might have requirements. But here’s a simple example of a poorly written requirement I had early in my career. “Phone number field is required” and from a programmer or developer point of view – you write code:
>>>> If phone_number = nulll
>>>>>>>>then print “Error: phone number field is required”
>>>> Else (allow the user to continue with the page change)
Context: this is a sales order form and containing important customer information
As a tester, I have to read the requirement as a developer would code it BUT I also have to read it as the customer service manager who stated what she wanted but didn’t state what she really meant…not in developer speak. Testers must be able to translate language on both sides. My first response was going to the developer and tell him/her “hey, the manager meant they don’t want the field left blank and to make sure him/her workers to enter a numeric value” but I wasn’t even asking for a check on if the phone number itself was valid. Just to distinguish from blank vs null and to enter numerics only rather than alpha an special characters. Now there was a whole thing involved where the project was late a week due to a poor process in place where this could not have occurred so late but it happened. This was a fairly easy thing for a tester to catch and the “customer” or manager would never have known the mistake if the tester and developer could have fixed it ahead of time. The customer or manager would have thought “how brilliant, I got what I wanted” and the developer is considered brilliant. The tester, me, would have been thrilled if the project would not have been late. I test to PREVENT problems and most definitely not just to point out mistakes. Many testers I’ve worked with, know through conferences, on LinkedIn and through testing associations feel as I do.
I still need a qualifier where the original poster has not addressed. What do you mean by “better”?
LikeLike
The distinction of anyone being better than another only serves to muddy the water. Consider that the function of the team as a whole is to deliver the application/system..
To do this requires a whole spectrum of abilities, that are impossible to find in a single person or group of people all sharing the same skill-set. There is a need for the purpose of each person within a team to be clearly recognised, and accepted by all within that team.
There is no place for a false hierarchy of egos to be built. The level of experience and capability of the people determine who can take responsibility for the decisions that need to be made, with the ultimate arbiter of the customer/user waiting at the end.
Building out a team is a skill in itself and should be taken seriously. The sharing of a core principle is the basis of that exercise, the fit of skill and capability comes thereafter.
Encouraging a debate on who is better than who is not something I find constructive. If you take a stand in this way, you have already lost a measure of cohesiveness within your team. Instead talk about how the people working together complement each other. Talk about the strengths they bring to the table and how they can be focused to deliver the best they can.
LikeLike
Thanks Ivor; I agree with your view that they have different roles.
LikeLike
Thanks Ivor feels good to know the views put forward by you. But this doesn’t work in majority of the situations and that is why we have this whole conversation going on above. While working on some project people have the mindset of who is better and not that we can build up a better software to make things easy. I agree that both the fields of development and testing have pros and cons and we should accept it rather than arguing on who is better and who does a better job. We all work as a team and should strive to make the team better by understanding the differences between the two fields. Frankly speaking the job for anyone is never easy if there are innovations done as a part of your work. So we can focus on doing that. Thanks :) . This is my personal opinion.
LikeLike
Thank you Prajakta; that was exactly the motivation for writing the post: I wanted to help dispel the baseless notion that devs are better than testers.
LikeLike
as a tester I totally agree with the author…if I turn to be a developer in the future then I will try to respect testers…as I do respect developers for their great and endless job!
we should never forget to act as a teamwork. Life is a wheel…
LikeLike
Thanks a lot Elisa
LikeLike
I really enjoy the article, pls i want you to also discuss developers and designers. Thanks you.
LikeLike
Thank you Abd’Hakeem for the feedback and suggestion!
LikeLike
Devs cannot be replaced – be it good or not that much…if we dont code you dont have anything to test. But we can take your job anytime. The other way round is not true most of the times.
LikeLike
Thanks IWantToBeAnonymous for the comment!
However I disagree with you. Here are my points:
1. Testers are not necessarily tied to ‘testing’ code; ideally they work hand-in-hand with the PMs in designing and verifying features. What’s the use of testing a feature that no one wants to use?
2. Most testers are software engineers and can write code! I have met excellent developers who say the best devs they know were former testers.
3. I disagree that developers can test effectively, you’ll have to convince me about this. A very good tester is worth his weight in code and very difficult to find. Here are some puzzlers – how would you test a car engine? A pen? An ATM?
4. Like I said, the general perception of testers being inferior to devs is wrong. Sadly it exists but if you have such views, you might be in for some huge surprises.
5. Yes, I was a tester before and I knew all this and I got to learn a lot about writing robust code too!
Do let me know your views.
LikeLike