Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 76 posts at DZone. You can read more from them at their website. View Full User Profile

What If I Do This?

  • submit to reddit

When I started my career as a developer, there were testers on my team. That was a new concept for me, since before that I didn’t need any testing, because I didn’t have any bugs.

I learned to work with them, although they were a kind of an annoyance, since, suddenly, They discovered I had bugs.

Jumping ahead a few years, I managed teams. I’ve built them from scratch. I got the developers first. When they had something to test, we got testers on board.

I finally got me a tester. She quickly became my trusted advisor. After some time on the team, I even paired her with the developers so they wouldn’t produce crappy builds.

What made her better than the regular bug finder?

What are good testers made of?

“You can’t add quality in the end” is very accurate. Build a crappy product, and the best you’ll get from testers is a list of bugs. That’s the classic view we have of testers – those annoying people that provided me with rework, many years ago.

Now, let’s pretend we’ve gone passed that. Our builds aren’t failing. We’ve got loads of unit tests running, even some automated end-to-end tests. We can get rid of the testers, right?


To explain, I’ll start with what developers usually do.

Generally, when we write code-first, test-after, our tests prove our design. What we build is how we translate specs and assumptions into code, and the tests (assuming we can write them, test-after is not that easy) are the proof that indeed we solved the problem.

Now, stop and think. What are the chances we didn’t think of everything? Of all use cases? Of the edge cases?

Unless the task is simple (and boring), we probably missed something.

This is where the tester comes in

Good testers have the wonderful skill of asking “What if I do this”? This thinking is different than “happy path” coding, where we “know” the answer.

People with experience in TDD develop this skill as well. Since the solution is still not finalized in one shot, introducing “What If” questions during development allow for more tests to answer them. When the testers get their hands on the system, and try their “What if I do this” magic, problems may already be solved.

“What if I do this” is a great question. Good testers ask more questions. Not whether if software is working as it’s specified. The more important questions are whether the software solves the business problem of the customer. If it’s easy to use. If it can scale.

The answers provide the feedback we really need to continue developing in the right direction. We can leverage this feedback to get more quality inside. Sometimes, this feedback can get us more money.

This is the best use of testers in the team. In fact, if I had to build a team from scratch today, I would probably start with a tester.

A note of caution: All this works if you’ve already baked the quality in. Otherwise, you’ll get “It breaks” answer too many times.

For that, we don’t need testers. In fact, we usually know this in advance.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Fabien Bergeret replied on Wed, 2014/05/21 - 2:38am

Developer have the tendency to write tests that prove their dwn evelopments are OK.

Testers write tests that try to find the weaknesses in the developments.

That's why, on my projects, in a team where there are no testers, developers test other developers work.

But I think that, anoyhow, functional testers are compulsory ...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.