Well that’s strange!
Wow! Another month has nearly passed without a post. Life and work have been incredibly busy and I am working hard on my next code project; my own Pagefactory implementation. While we wait for that to take form more fully here is a little something to think on.
Pat yourself on the back for identifying that doozy of a bug before it causes any trouble for people using your software for real. Recognising that odd behaviour and confirming that it wasn’t just you being dumb is harder than it sounds.
Alexander Oliveira Dunn 2019 š
The power of ‘What the ā¦ā¦?’
A few events and bugs recently have reminded me just how important the inquisitive mindset is to the successful tester. If you have spent anytime alongside someone testing software you will know that it is a life of multiple states.
1. OK so far.
The phoney war stage. It is early in the project, there is not much to test yet, but what’s there looks like it is working as it should.
Of course you have detailed specs to be writing API / UI system tests in parallel right?
2. Everything is looking good.
This is where you want to be. The code is behaving as it should, there are probably a few issues but they are well known, understood and in the backlog for tackling.
Hopefully you have some already got some good system tests checked in and its just about ensuring that nothing slips in at the last minute. Get those ‘would be nice’ extra tests checked in and keep testing those subtle edge cases for anything unusual.
3. Everything is on Fire!
To be honest you really don’t need an experienced tester to tell you when the code is in this state. Typically we are talking catastrophic failure here and there really is not much a test specialist can do other than make sure that the developers realise just how broken it is. Hopefully this was picked up by testing in CI/CD before this even got deployed to your development environment.
You really don’t want this in production:
Of course you should be looking at your integration test results here. If the server is completely non responsive, or returning ‘503 – Internal Server Error’ you should be very concerned if an integration / unit test managed to pass. Equally, if this wasn’t picked up until after the deployment you’d better be sure that you are writing a test to prevent it ever passing the release again.
4. WTF?!?
Of course it is not always the tester, but when you hear words like this you should be worried. It was probably something that didn’t look out of place to anyone else, but suddenly you realise that you just found something should not have happened.
These are often the edge cases: The unlikely scenario that hasn’t been caught before. In everyday life most of us go around ignoring those little out of place events, but I find turning off this reflex is one of the most important and difficult skills for the software tester. Also having the awareness to know when this could be critical and requires you to drop what you are doing and the confidence to go straight to the product owner to prioritise fixing when required.
Of course it then goes to back to the Dev team, often leading to:
The Six Stages of Debugging
Mike Cramer: The Newton TM Scapegoat: The Six Stages of Debugging
That can’t happen.
That doesn’t happen on my machine.
That shouldn’t happen.
Why is that happening?
Oh, I see.
How did that ever work?
In Summary
It is never nice finding issues with the software that your colleagues have worked hard to write; You will probably also feel bad and blame yourself (or fellow testers) for not finding it earlier.
Sometimes however it is important to pat yourself on the back for identifying that doozy of a bug before it causes any trouble for people using your software for real. Recognising that odd behaviour and confirming that it wasn’t just you being dumb is harder than it sounds.
The truth is:
- Software will contain bugs.
- Testing will never find all bugs.
- Every bug found is a victory.
A reminder:
If you want to ask me a question, Twitter is undoubtedly the fastest place to get a response: My Username is @AlexanderOnTest so I am easy to find. My DMs are always open for questions, and I publicise my new blog posts there too.