What If I do This?

what-if-700-X-4501_zpsab730815When 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?

Wrong.

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.

 

Reference: What If I do This? from our JCG partner Gil Zilberfeld at the Geek Out of Water blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

One Response to "What If I do This?"

  1. Martin Vanek says:

    If you code happy paths only, you are most probably rubbish developer.
    From my expirience TDD quite contrary leads to
    1. Bad code design or broken architecture, because all coding is driven by ad-hoc test cases, which are in turn usualy driven by BDD – high level gibberish ignorant about anything but happy path of specific user story.
    2. Tests designed before coding usually omit most of else branches, edge cases, not even mentioning exception handling.

    Anyway TDD is just silly favouring one side of chicken and egg problem

Leave a Reply


× four = 16



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books