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

Question

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.

Answer 1

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.

Answer 2

"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	Pessimistic Tester
The glass is half full	The glass is twice as big as required
This code hasn't yet been tested. It's not known if it has any bugs	This code hasn't yet been tested. It's not known if it actually works
We are 90% done	We don't know when we'll be done, if ever
We will refactor the code to make it better	They are throwing out the working code and replacing it with an unknown quantity
I only changed one line of code	The entire system must be retested
The code is the design	There is no design
We'll fix those bugs later, when we have time	We never have enough time to fix the bugs
This build is feature complete	The features exist; some are completely broken
Anything is possible, given enough time	Everything has flaws, and given enough time I can prove it
Of course it will work	It might work, but probably won't
One last bug fix, and we can ship tomorrow	Fixing this one bug will likely lead to two more
Stop finding bugs, or we'll never be done	Stop creating bugs, so I can find them all
There's no need for more tests	Let's just run a few more tests to be sure
There is no I in TEAM	We can't spell BUGS without U
That's an "undocumented feature"	That's a bug
I like to build things	I like to break things
Sure, we can use the Beta version of this component in Production	We should wait until version 2.1
Willing to bet that there are no more bugs	Willing to take that bet
Let's slip these changes in now, because I'm starting my vacation tomorrow	Let's not
That will never happen in Production	Never is a long time
It works on my machine	Perhaps your machine is the only one where it works?
The sun'll come out, tomorrow...	Raindrops keep fallin' on my head...
I'm a Realist	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

Answer 3

Although I completely agree with TristaanOgre's answer, I do have another piece to add.

Developers 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, don't have a mind set, they have many. I don't know of any tester's worth their weight in salt who wear only one hat. Instead, they wear multiple hats. They analyze the requirements looking for holes. They (sometimes) look at it as another developer, wondering if there may be a more efficient way to develop it.

I'm a tester, 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 testers differ is the fact that, again, developer's are concerned with building the software and teaching others how to use it. Although testers like to learn from the developer, they 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. Testers take what they've learned and 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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

From my point of view, Developers work more in a one direction where they have to achieve a particular output by building a code, Where as A tester will think like a user, assume scenarios in which users will use the software and try to operate the software. So the ability to think in more ways, Tester are the ones who can contribute to Software in more way.