Bloggers Club: Oracles and Heuristics

In past projects, written requirements have often been used as oracles to determine whether or not the behaviour they are seeing in the SUT (Software Under Test) is correct or not.

According to Cem Kaner, an oracle or test oracle is a mechanism for determining whether a test passed or failed.

The thing is, not every project has clear written requirements – some projects lack written requirements altogether, while others are not clearly written and are very open to interpretation.

This is where heuristics can be very useful. I have previously written about my most used test heuristics (along with some examples), but in this blog post I want to elaborate on why heuristics can be very useful for testers, with or without written requirements.

Continue reading “Bloggers Club: Oracles and Heuristics”

How do you actually prevent bugs?

It’s not hard to find articles or pieces of research claiming that the sooner you find a bug, the cheaper it is to fix. But I’ve found there isn’t actually a whole lot of information out there on exactly how to prevent bugs in the early stages of a software development project. i.e. before code is written, while requirements/user stories are being written or just after the requirements/user stories have been written

Here I would like to share exactly how I help prevent bugs on projects and how I help others come up with ideas on how to prevent bugs as well.

Continue reading “How do you actually prevent bugs?”

How to start your career in software testing

So, you want to become a software tester but you are not currently working in the IT industry? There are a few things you can do to get your foot in the door, but it can take a bit of time to actually land your first role as a tester.

There are a few options regarding the very first step you can take.

1. Join a company that has testers by using the skills you currently/already have

I’ve met a few people who became testers using this approach. This approach involves you using the skills/experience/background you already have to get the job – then later on try and go for a transfer into a software testing role.

Continue reading “How to start your career in software testing”

Getting started on a testing project (revisited)

A few years ago I wrote a post on getting started on a testing project. I’ve learned a few things since then and wanted to share an updated checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project

Checklist for what new testers on a project need (Note, your project may not include all of the below)

Continue reading “Getting started on a testing project (revisited)”

Step by step guide to becoming a technical tester

It seems to me that there’s an increasing demand to hire people who can write test automation, or at least are “technical testers”. For more on what this term means, check out this article on the Ministry of Testing.

For the purposes of this blog post, I’m going to say that “technical testing” means someone who can go and test beyond the UI (User Interface). This means they can probably do the following:

  • They can test against APIs
  • Look under the hood and see network requests
  • Understand code and what it does – maybe even write test automation

Continue reading “Step by step guide to becoming a technical tester”

Dealing with Intermittent Bugs

Intermittent bugs can be a frustration for not only testers but the rest of a team. You may be lucky enough to uncover it before it reaches any beta testers or you may find yourselves having to figure out what the hell happened because a customer (or several) has reported it but you are struggling to replicate it.

Here are some ideas on how to deal with intermittent bugs.

Continue reading “Dealing with Intermittent Bugs”

Bloggers Club: The Essential Skills for Testing

I’ve been pondering about this blog post since I saw the Ministry of Testing discussion post  and to be honest, I really struggled to interpret it. I mean, how do I define essential skills exactly?

To help me structure my thoughts for this post, I’ll be interpreting “The Essential Skills for Testing” to be “What skills are useful for a great tester?”

Strong communication skills

Let’s be honest, we’ve all met people who claim they have communication skills or even strong communication skills and you can’t help but roll your eyes.

Like wth does that even mean?

In my opinion, strong communication skills (for a tester) means that a tester is:

  • Able to communicate exactly what, where, why, how, etc they have tested in such a way that the team understands what they did
  • Able to communicate exactly what, where, why, how, etc they will test a feature (etc) in such a way that the team understands what they plan to do, and can help expand on those ideas/or question them – to me, the second part is a test of how well you communicated what you plan to test.

Can give effective, actionable feedback

Test reporting and bug reporting is essentially feedback.

A tester is giving the team (often the developers) feedback on the feature (etc) that they have tested.

Often we expect/hope for people to gain some sort of value from our feedback, maybe we want them to know what a great job they did, or maybe we want them to know there are some areas of the feature that had quite a few problems. If it’s the latter then a tester should deliver the feedback in an effective, actionable way.

I don’t think a tester should just write a bug and say “it doesn’t work”. What is a developer supposed to do with that sort of information? There’s no clear point for the developer to start investigating. Even if you don’t know exactly what the problem is, you can note down what you did to investigate the issue; what you tried to do etc.

Appreciation for the bigger picture

When I started my career, I sometimes struggled to appreciate the bigger picture. Testing and software quality was in the forefront of my mind and I struggled to comprehend why/how you could knowingly release software with bugs in it, or why people didn’t want to dedicate more time to testing, or more budget to testers. (I’ve talked a bit about this in an earlier blog post)
I only saw the testers/testing perspective but failed to appreciate how testers/testing fit into the bigger picture.
Often, decisions need to be made where if you have limited time and resources, then something has to give (often testing time unfortunately), now you don’t have to always agree on the decisions made but if you accept that sometimes you don’t get what you asked for – then you know (hopefully early) to prioritise your testing so the most important/riskiest areas are covered first.

What I wish I knew when I started testing: Get involved with the testing community

In November 2018, I gave a talk at Belgrade Test Conference on ‘What I wish I knew in my first year of testing’.

Here’s the second post on the series with some key areas from that talk. (Here’s the link to the first post on Expectations vs Reality)

This post will focus on more “accessible” ways of being involved in the testing community (i.e. not speaking at conferences or starting testing meetups/events) Continue reading “What I wish I knew when I started testing: Get involved with the testing community”

How to write a bug report /defect report

Here’s a step by step guide on how to write a bug report /defect report.

First, we need to ask ourselves a few questions:
  • Why are we writing a bug report?
  • So there is a record of the behaviour
  • So that the bug gets fixed – for the bug to get fixed we need to provide clear enough information so the developer can act upon it and the product owner/manager etc can decide how to prioritise this bug and if it should get fixed.

Continue reading “How to write a bug report /defect report”

What I wish I knew when I started testing: Expectations vs Reality

In November 2018, I gave a talk at Belgrade Test Conference on ‘What I wish I knew in my first year of testing’.

Here’s the first post on the series with some key areas from that talk. (For the second part of this series: What I wish I knew when I started testing: Get involved with the testing community))

This post will focus on Expectations vs Reality (Since it was over two years ago since I gave that talk, there’ll be some mismatch between my talk and this post to reflect new things I’ve learned etc).

These expectations reflect the expectations I had when I started my software testing career back in 2012

Expectations vs Reality

Perception of quality

My understanding of what quality was, was similar to perfection – I thought all (known) bugs had to be addressed before you went live. Bugs were something that hurt the quality of the software.
As time passed, my understanding of quality and “good enough” has changed. Now I don’t only focus on bugs, but mainly on the value that can be provided to the stakeholders.
 
 

Agile

When I started my testing career at the Assurity Graduate Program, I heard some amazing things about Agile. I thought ‘This sounds amazing – I’m sure I’ll only end up on Agile projects’ (or maybe a few non-Agile projects).
The funny thing is, I’ve been on a lot of ‘Agile’ projects. I’ve found that some companies believe they have Agile projects just because they are doing a daily stand-up (while there is definitely some value in running daily stand-ups to make sure that everyone is on the same page, I’ve found it can be hard to focus when the daily stand-up can run up to 30-45 minutes long, that in one past project it became a daily lean-on-the-wall/desk then eventually a daily  sit-down).
I can’t help but think that ‘Agile’ is quite the buzzword to throw around to seem cool.
While I have worked on some projects that implement a lot of the fundamentals from the Agile Manifesto, they are, however, outnumbered by the projects I have worked on that only claim to be Agile.


The purpose of testing

Even something as simple as why we test software is something that I haven\’t always agreed on, with people I work with. It never occurred to me that my understanding of the purpose of testing would not be the same as other testers (let alone other people on a project).
To me, it was a given that we would at least have a shared understanding of what testing is supposed to achieve.
But I was wrong.
There are multiple interpretations of the purpose of testing.
My interpretation: We test software to get a clear picture of the state of the software.  I quite like Anne-Marie Charrett’s analogy where testing is the headlight and the road is the software project.
Here are a few purposes of testing I have come across, which I disagree with, along with reasons why:
  • To find all the bugs – you can’t ever KNOW that you have found all the bugs as it’s near impossible (if not impossible) to prove that something does not exist.
  • To ensure high quality software – testing in itself sheds light about the quality/state of the software; it tells you how things are looking, but it’s up to the team to ensure high quality software
  • To improve the quality of the software – similar to the previous point; testing in itself doesn’t improve the quality of the software, but if testing is done well it can give your team a good idea on what needs to be improved.  i.e. Testing –> information/input on what needs to be address –> make changes –> improved quality of the software
For the second part of this series: