loading...
Cover image for Testing IS for Beginners

Testing IS for Beginners

dowenb profile image Benjamin Dowen Updated on ・4 min read

Jon Calhoun recently posted a very detailed explanation of why "Testing is Not for Beginners"

I can relate and agree to much of the content, but reject the main premise.

Health warning

I am writing this to express myself and understand for myself why I think test analysis skills are important to developers. If you find I am waffling on, feel free to move on! honestly, I won't judge or be offended.

Also I probably have lot's more to say on the topic I haven't managed to get down yet - so I may even make further posts. Deal with it.

Bias of a professional tester

First of all, please know that I am biased. I have been working professionally as a Tester, and not a Dev since 2012. For longer then that I have been an "Armature" developer, but I have never done it professionally.

I reject your reality, and replace it with my own

I honestly believe learning some of the skills of a Test Analyst can make even a new Dev a "better" Dev. But how?

OK so I hope you will agree with me that:

  • Finding bugs early saves time and sanity
  • Bugs in "Design" or "Requirements" can be very expensive
  • Learning from failure is good and important, besides when does it ever work first time?

Where I totally agree whit Jon, if you try and learn how assertions and unit tests work on day 1, before you learn concepts and syntax, your going to fail. In that context, "Testing is NOT for beginners", sure.

But how can Test Analysis help with any of this?

Fundamentally Test Analysis is not about writing tests. It's about learning, exploring and asking questions.

What kind of questions? I won't cover that again in detail, as I already made a post about that.

My premise here is:

  • The more you understand about the problem your intending to solve (Requirement) the easier it is to break it down into smaller problems and solve them
  • "Thinking" Time invested early is time well spent and should save you time later

But what about spikes and prototyping and LEARNING how to develop?

Of course, this doesn't mean you shouldn't being experimenting and learning! To be clear when I talk about a "New" Dev, I really don't mean some day 0 of your journey. Anyway this is still part of "Exploring", exploring is important!

When you get to the point when your starting a Job, or an open source project your not doing on your own, this is where it starts to become more relevant.

How do you know you are done / it's working?

While there is no need to use TDD or BDD while your learning - spending time to understand what functionality is important to get working, even for a demo or learning project, is useful. It's useful because it helps you be "Done", it's useful because it helps you break things down into smaller problems.

Also - it will be even more useful when your working in a team, because you may only be responsable for a part of the functionality. And you will need to understand where "your bit" ends and some one else begins.

It can be useful to express some of this in some form of Test Case, or "Expected behaviour" so you can exercise your code and see if it does what you expect, or if you need to keep going!

Why "working" code isn't enough

Guess what - once you get as far as a job as a "Developer", or as a Tester in part of an Agile team. Working code isn't good enough.

You have to remember the context for why code is being written in the first place. And usually this will be to solve a "Business need" of some kind, assuming your intending to make money (or make some one else money). Or at very least your solving a "problem", often one that could be solved without technology at all.

This is where applying some of the fundamental analysis skills from testing come in:

  • Remember to ask "Why?" - a lot. If you understand the problem you can identify better solutions
  • If your lucky enough to have direct access to your customer/client, maintain a dialogue. Try and "Speak the same language", and this won't be code. But it might be models, mind maps, UML, Flow Diagrams, white boards, conversations. If your really unlucky it will be written statements
  • Remember or working on a solution to a problem, and not making software for the sake of it

Enough already! let me get coding

OK, I'm done. I genuinely hope this was useful for you, but honest I mostly wrote it to be able to express my opinion.

Do make your own opinions and experience known, comment, write your own post, share. I am interested to learn from you so feel free to let me know!

Posted on by:

dowenb profile

Benjamin Dowen

@dowenb

I'm a quality hero, customer champion. Experienced software tester and newbie developer. Okay, so I've actually been dabbling in code for a long time. I've just not gone very deep in any language .

Discussion

markdown guide
 

I think this post is great that one does not need to be a TDD expert before they can put on their software testing hat. However, I think it depends on the type of functionality one is trying to impose. I have found great value in the concept of event storming, domain driven design, and domain modeling. It truly is worth it to spend time designing and thinking about the problem before coding.

 

Those techniques sound interesting. I'll have to look into then as I'm unfamiliar. Can you recommend any reading material?

 

This article provides a pretty high level detail into what it is composed of.
This guide using FSharp is helpful when converting reality to code models.

 

Thank you so much for this post! I understood what the other post was suggesting, and also that the purpose of the headline was to be clickbaity, but it made me really sad. I love testing and QA, and the idea I got from that article that I wasn't "advanced" enough when I moved into this position gave me a couple rounds with impostor syndrome. #Testing4Life!

 

I'm so glad it was helpful for anyone but myself :)

 

Sorry, my OCD will keep me up all night if I don't correct you.

your => you are