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, you're 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 is 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 you're 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 and exploring is important!
When you get to the point when you're starting a job, or contributing to open source projects you're no longer doing so on your own. This is where it starts to become more relevant to think beyond the code.
How do you know you are done / it's working?
There is no need to use formal TDD or BDD while you are doing early learning. Instead spending time to undetand 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 you're 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 the problem being solved is part of a bussiness process that could be solved without technology at all, or historically relied on analogue equipment. Think shop till and paper ledgers, mail order to modern e-commerce.
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!
Top comments (8)
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.
Thanks!
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
Corrected,I hope.