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?
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. |
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