How does a tester's perspective towards software differ from a developer's?

Just as there are developers who are orders of magnitude more productive and creative than other developers, so are there testers who are similarly outstanding. We all have our opinions about what constitutes an outstanding tester. I believe one contributing factor is a matter of perspective, that a great tester approaches software in a different way than a developer.

This is not to say that an individual can't have both perspectives, or that one is superior to the other.

I ask because there are times when a tester will find a bug using a use case that I would never consider, and I wonder where the idea came from. Or a tester devises a way of testing something so that is unorthodox, clever, and perfect for the job at hand, and again I wonder what led them to there.

How is a developer's perspective different from a tester's? I believe the question is relevant to interviewing and perhaps to continuing education and an organization's culture.

• Next time you find yourself wondering how a tester came up with something, ask. Personally I love my job and if a developer (or anyone else) expressed interest I would be happy to talk to them about it. – CKlein May 13 '11 at 13:20

I think the fundamental difference between the tester and the developer is the difference between synthesis and analysis. The developer synthesizes code. He builds up things, putting pieces together and figuring out fun and unique ways of combining those distinct little bits to do wonderful and amazing things.

Testers are all about analysis. Once it has all been put together, the tester likes to take it apart again, piece by piece, this time looking for those little corners, edges, and incongruities that hide in those weird and strange interactions that come from those new and amazing ways of putting pieces together.

Both testers and developers like figuring out how things work, but the difference is where the developer is focused on putting things together to make them work a certain way, the tester is focused on taking things apart to find out all those unintended consequences.

• Let me add that I think an EXCELLENT developer has some of that tester in them because it is in finding out those strange and weird interactions that come from analysis is how they find out new wonderful and amazing things to build. Likewise EXCELLENT testers need a good sense of synthesis to be able to know how to put the things together to create those new wonderful things so that they can better understand how they come apart again. – TristaanOgre May 13 '11 at 2:05
• I think so too. The best testers I've worked understand a product for what it really is: a bunch of algorithms that, when used in a certain way, could potentially be used for a certain purpose. They're able to let its intended purpose fall away so that its other potential uses are exposed. Each algorithm is just a bunch of inputs and outputs. We assign meanings to those inputs and outputs, but those meanings only make sense in the context of their intended purpose. Allowing other meanings leads to creativity and, of course, to finding bugs. – user246 May 13 '11 at 13:15

"I believe one contributing factor is a matter of perspective, that a great tester approaches software in a different way than a developer."

I agree! And I think that's one of the primary factors which allows testers to add significant value.

Here's something I wrote a while back:

In my experience, developers tend to be optimistic folks, while testers tend to be more pessimistic.

• Developers are creators, with a natural optimism about making new things and solving difficult problems.
• Testers are fault finders, with a necessary skepticism and doubt.
• If developers are the yin, testers are the yang.

I believe this is a good thing, a sort of checks-and-balances tension that makes for better software.

But it does lead to some interesting contrasts...

Optimistic Developer: The glass is half full

Pessimistic Tester: The glass is twice as big as required

Optimistic Developer: This code hasn't yet been tested. It's not known if it has any bugs

Pessimistic Tester: This code hasn't yet been tested. It's not known if it actually works

Optimistic Developer: We are 90% done

Pessimistic Tester: We don't know when we'll be done, if ever

Optimistic Developer: We will refactor the code to make it better

Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity

Optimistic Developer: I only changed one line of code

Pessimistic Tester: The entire system must be retested

Optimistic Developer: The code is the design

Pessimistic Tester: There is no design

Optimistic Developer: We'll fix those bugs later, when we have time

Pessimistic Tester: We never have enough time to fix the bugs

Optimistic Developer: This build is feature complete

Pessimistic Tester: The features exist; some are completely broken

Optimistic Developer: Anything is possible, given enough time

Pessimistic Tester: Everything has flaws, and given enough time I can prove it

Optimistic Developer: Of course it will work

Pessimistic Tester: It might work, but probably won't

Optimistic Developer: One last bug fix, and we can ship tomorrow

Pessimistic Tester: Fixing this one bug will likely lead to two more

Optimistic Developer: Stop finding bugs, or we'll never be done

Pessimistic Tester: Stop creating bugs, so I can find them all

Optimistic Developer: There's no need for more tests

Pessimistic Tester: Let's just run a few more tests to be sure

Optimistic Developer: There is no I in TEAM

Pessimistic Tester: We can't spell BUGS without U

Optimistic Developer: That's an "undocumented feature"

Pessimistic Tester: That's a bug

Optimistic Developer: I like to build things

Pessimistic Tester: I like to break things

Optimistic Developer: Sure, we can use the Beta version of this component in Production

Pessimistic Tester: We should wait until version 2.1

Optimistic Developer: Willing to bet that there are no more bugs

Pessimistic Tester: Willing to take that bet

Optimistic Developer: Let's slip these changes in now, because I'm starting my vacation tomorrow

Pessimistic Tester: Let's not

Optimistic Developer: That will never happen in Production

Pessimistic Tester: Never is a long time

Optimistic Developer: It works on my machine

Pessimistic Tester: Perhaps your machine is the only one where it works?

Optimistic Developer: The sun'll come out, tomorrow...

Pessimistic Tester: Raindrops keep fallin' on my head...

Optimistic Developer: I'm a Realist

Pessimistic Tester: I'm a Realist

And here's a slideshow version, in case you need it: http://strazzere.blogspot.com/2010/05/slideshow-optimistic-developers.html

• Fantastic, Joe! Consider this slideshow bookmarked. – TristaanOgre May 13 '11 at 12:17
• Love It!! I've actually had discussions with my supervisor about my percieved "negative" attitude. I'm finding ways to phrase questions to sound less pessimistic, but I keep asking. It is part of our job to look for holes, gaps and worst case scenarios. We can't afford to assume something is okay or right, because that is where the defect will slip through. So while the majority of the team is designing a wonderful tool to solve problems for our customers Testers sit to the side & keep saying "yeah, but...." – CKlein May 13 '11 at 13:00
• Great post! Published in my team room :) – Luca Giuffrida Nov 14 '15 at 10:38

Although I completely agree with TristaanOgre's answer, I do have another piece to add. Developer's are often (even if they don't realize it), emotional attached to their code. They've spent hours/days/weeks, sometimes years putting it together. They have taken what someone wanted and (normally) crafted those requirements into a working, and often elegant creation. As TristaanOgre pointed out, they have the mindset of a creator.

Testers on the other hand, we don't have a mind set, we have many. I don't know of any tester's worth their weight in salt who wear only one hat. Instead, we wear multiple. We analyze the requirements looking for holes. We (sometimes) look at it as another developer, wondering if there may be a more effecient way to develop it.

Here's the main mind sets that I use while testing:

How does the customer who ordered the software want it to work? How did the developer build it to be used (think tire swing)? How will the end user use it? How will a power user use it? How will a disgruntled employee use it? How will a disgruntled end user use it? How will someone who's not familiar with the product use it? How will someone who wants to break it use it? How will other applications use it?

One of the other ways that we differ is the fact that, again, developer's are concerned with building the software and teaching others how to use it. Although we like to learn from the developer, we also like to learn from the software. There's been more than a few times that I've shown a developer something that their software can do that they never expected it to be able to, completely different from anything desired, but still useful. We take what we learned, and we think of more things to test. I like to talk about how during my testing, I see shiny things (something that seems out of the ordinary). As soon as I'm finished with my session, I go and look at the shiny thing hoping that it's a silver thread left to lead me through a maze to a treasure (a bug).

I don't want to write a novel here, but I think that this gives a basic understanding of how a developer's mindset and a tester's mindsets differ.

• Good statements, Lyndon. I think it's those multiple hats that really distinguish good analytically thinking testers from folks who just use a standard set of tools. – TristaanOgre May 13 '11 at 2:33
• +1 Agreed. I'd add that we tend to take a higher level view as well where we understand the system in more detail than the Developer who tends to know only the pieces they interact with. – MichaelF May 13 '11 at 12:11

Testers are different from not only developers, but also everyone else in a software organization, because they are the only people whose primary mission is to figure out how the product could fail, and not how to make the product suceed.

Developers spend their spare moments trying to figure out how the code can be refactored to be cleaner or an elegant way to organize the object hierarchy in order to make the product work well, but testers will ponder new ways to hit threatening race conditions or a new unexpected output that might not be handled right that could make the product fail (at least a little). No one else is so dedicated to avoiding failure, or such an expert in all the ways that software tends to break.

Development and testing are two diametrically opposed disciplines.

Development is all about construction, and testing is all about demolition. Effective testing requires a specific mindset and approach where you are trying to uncover developer mistakes, find holes in their assumptions, and flaws in their logic. Most people, myself included, are simply unable to place themselves and their own code under such scrutiny and still remain objective.

Let’s say that a developer has to write some code that calculates a sales commission, where the commission is normally 5%, but rises to 7% for sales over ten thousand dollars, and they implement the following code.

if  (SalesAmount < 10000.00)
{
Commission = SalesAmount  * 0.05;
}
else
{
Commission = SalesAmount  * 0.07;
}


The developer has made the assumption that a sale of exactly $10,000 should earn 7% commission. If they are testing this code as well they might write tests similar to the following: [Test] public void VerifyLowerCommission() { Assert.AreEqual(499.9995,CalculateCommission(9999.99)); } [Test] public void VerifyHigherCommission() { Assert.AreEqual(700.0007,CalculateCommission(10000.01)); }  The problem with these tests, is that even though they achieve 100% code coverage, the developer has based them on the same assumptions and thought processes they used when writing the code itself. In this contrived example, let’s assume the actual calculation should have been based on commissions greater than or equal to$10,000. So, even though these test cases would pass, the calculation is actually wrong. This type of bug would probably manifest itself infrequently, as it would require a sale of exactly \$10,000 to cause a problem and would otherwise remain dormant.

Having someone impartial write the tests for the code increases the chance of finding that type of issue significantly. This helps because they will have make their own ideas about how things should work, and challenge the developers assumptions.

The heart of development is creation. -- The heart of testing is science.

All Software testing is testing the hypothesis "Is this software suitable to ship to the customer." There are a lot of nuances, testing has a lot of art to it and it's all about testing assumptions.

Your development mindset should be "How can I best solve the costomer problem with the resources I have?" Your testing mindset should be "Did my development effort solve the problem sufficiently?"

It's could be hard to change gears so having people with different viewpoints test the software other than the people who made it helps to keep from overlooking tests that would invalidate the hypothesis. It's a good ideas for the actual developer to test as much of what they write as possible. This shortens the feedback loop, decreased costs and increases developer skill quickly.

Developers must put thier ego on the line In order to be a good developer you need a bit of hubris. You have to believe you can to the impossible. You have to own the problem and the code becomes your baby. If you don't have a level of passion where you feel personal investment in all the code you write, you need a new job.

Testers should never make it about the developers ego One occupational hazard for testers is to start testing and complaining about everything. Be on guard for that. Never attack developer personally for flaws in the software. Figure out how to give them meaningful, actionable feedback that doesn't crush thier ego. If you think that being harsh motivates developers, you need a new job.

As testers we have to understand that development is a creative effort and our jobs are to point out flaws in something the developer put a lot of effort into. It's productive to point out defects in the execution but not the person. For example, you might say "20% of the BVT's we agreed to are not passing yet." That's objective usefull feedback. "You suck, you have been working at it for weeks and it is still not ready to ship." Not objective. Still technically accurate and perhaps even deserved on some level, but not called for.

Nothing is sadder than a technically skilled tester who is the enemy of every developer on the team. Except the one who took testing home and is now estranged from family.

Developers need to be subject matter experts and tune out distrations Developers need to spend a lot of focus on solving hard problems at a micro level. They need to be experts in every line of code they write. Specialization means ignoring distractions and cutting out meetings that are too general.

Developers must focus on solving the technical problems at hand.

Testers shouldn't lose site of the big picture Testers shouldn't strive to be as much as an expert at the micro level. They need to have a foot in the micro and macro world and provide course correction data to developers who are "down in the tank." Having a good PM can relieve the tester of some of this burden, but a tester who doesn't get the big picture is a liability to the developer they work with.

Testers must focus on making sure the technical problems being solved advance the user experience as a whole.

Testers need to know when to measure the widgets and when to fix the assembly line Testing activities roughly divide into quality control and quality assurance. Quality control is making sure the delivered items are to spec. Quality assurance is making sure the process leads to high quality output in the first place.

The one thing I would add is something I learned from Whittaker's 10 Commandments;

1. Thou shalt hold thy developers' sins against them

I use this thought every day. If I get code & I know that developer leaves error messages until the end, I'm going straight there to make sure they were not forgotten. If I know someone has had trouble with handling date fields in the past, there is where I start. Did I hear two coders discussing an fix that could impact this old defect, guess what the first regression test will be. Is the designer responsible for the module notorious for leaving sections TBD or vague, I start there to see what we ended up with.

This isn't supposed to be vindictive or nasty, but the fact is we all have certain habits and traits. If my understanding that helps me focus in part of my testing I would be remiss to not use that information.

10 Commandments by Whittaker

TL;DR Developer = Let's make something! Tester = Let's blow it up!

When I took my first job in QA, I would describe what I did to people this way: I have a hammer and screwdriver and someone has just pointed me at a grandfather clock with instructions to tear it apart to find out how it works and, and...(this is the best part) I don't have to put it back together.

To me, developers build the ivory towers, the gears and the guts of a system. A tester's job is the systematic deconstruction of those towers, gears and guts to find weakspots and outright failures.

I noticed that novice developers tend to focus on their module and have very limited insight on the product or users, whereas a tester must have (at least) good knowledge of the whole system and its use cases.

• Good point. A developer focuses on their section of the application where as we get to put the pieces together from many developers. A lot can happen at those interaction points that the developers didn't see because it was outside their module or section of code & they assumed the input/output/interaction would be okay. – CKlein May 13 '11 at 12:58
• I voted this down because I don't think it answers the question. A great developer will have a broad knowledge of the whole system, and a poor tester will tend to focus only on the module they're testing right now. – user246 May 13 '11 at 13:55

In a few simple words: A developer makes a product so that it runs successfully. A tester's job however is to test the software in a way that makes it to fail.

• Can someone who put -1 justify that so other can learn more what's wrong with this answer? – dzieciou Dec 1 '12 at 13:27
• I did not vote on this answer but I think it is obvious that this answer is too short and doesn't live up to the expected detail that the question is begging. – djangofan Aug 2 '13 at 15:46
• I'm inclined to disagree djangofan - the length of an answer isn't always an indicator of a bad answer. This particular answer would be better if it was expanded on, but as it stands it's not a bad answer. Having been on both sides of the coin I understand where it's coming from. – corsiKa Oct 7 '15 at 15:30