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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

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


− 7 = two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
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.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close