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”

The Economics of Software Testing: Opportunity Cost

When I was in high school I learned about a very interesting concept called Opportunity Cost in my Economics class. To be honest, it’s probably one of the only things in high school that I still remember. I still remember this very interesting concept because it’s everywhere.

What is opportunity cost?

It’s the value of the next best alternative of a resource. (Source: https://www.econlib.org/library/Enc/OpportunityCost.html)

Continue reading “The Economics of Software Testing: Opportunity Cost”

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:

My Most Used Test Heuristics (with examples)

First, what is a heuristic?

A heuristic is a guideline,  it is fallible.

Therefore, it will give you a good idea of what behaviour you should see BUT it isn’t definitely what should happen – it\’s up to you to confirm that the behaviour you are seeing is correct.

In a previous blog post I shared a step by step guide on how to test without requirements/little requirements.   But I figured it’s good to share my most used test heuristics that I use for testing without requirements.

They are:

  1. Consistency with History
  2. Consistency with User Expectations
  3. Consistency within Product
Let’s take a look at each of them along with some examples to illustrate the concept.

1. Consistency with History

The feature’s or function’s current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense)
Example: Whitcoulls, a NZ book store.
Here you will notice that their products are broken up into main categories: Top Picks, Books, Stationery etc.
Then under Books you have Fiction, Children\’s Books, Young Adult, Cookbook etc.
To test against this heuristic, then let\’s say you were to redo/revamp/remake this website, then you would expect the products to be broken up into the same main categories (Top Picks, Books, Stationery..) and the Books to have the same categories (e.g. Fiction, Children\’s Books etc.)

2. Consistency with User Expectations

A feature or function should behave in a way that is consistent with our understanding of what users want as well as their reasonable expectations. (Source: developsense)

Example: Signal, messaging app.

In the first photo:

I expect that the “Search/Sök” functionality searches for both contacts I have as well as messages containing the search string. For example: “And..” would find a contact called Andreas as well as a sentence “I have coffee and tea”

I expect that the pen icon in the top right corner means I can create a message

I expect that the camera icon means I can take photos once I tap it. If I haven’t yet given permission to the app to access my camera or photos, then a pop-up should appear

In the second photo:

I expect tapping on the X on the top left means I exit the camera view

I expect that tapping on the two arrows means it switches to selfie mode

etc

If I were to be part of a project that was building a messaging app and was focussing on the camera functionality, I would ask myself – what do I expect to happen?

I sometimes find Consistency with User expectations can start to blend into  Consistency with Comparable Products when I test. (Consistency with Comparable Products: Using other products as a rough, de facto standard against which our own can be compared. Source: Developsense)

If i was testing against the Consistency with Comparable Products heuristic, I would ask myself: “What do other messaging apps have? How does the camera functionality work on other messaging apps?”

3. Consistency within Product

The behaviour of a given function should be consistent with the behaviour of comparable functions or functional patterns within the same product unless there is a specific reason for it not to be consistent (Source: developsense)

Example: Allrecipes, a recipe browser

To some extent this behaves as I expected as I see the breadcrumb which helps me find where I am on the website, but on the /desserts page it is lower down the page, on the actual recipe page, the breadcrumb is at the very top. See screenshots below

Step by step guide: Testing without requirements/ little requirements

If you haven’t already, you may one day find yourself in a project where there are no (explicit) requirements or very little requirements to go off.

Software can be created from conversations and assumptions. People may also assume that the little requirements they do write is enough to easily code against or test off, but then you later realise that the few lines that have been written actually pose more questions than provide answers.

You first time testing on a project without requirements can be a bit scary but I’m hoping this step by step guide will help you. Continue reading “Step by step guide: Testing without requirements/ little requirements”

4 Books Which I’ve Found Useful for my Testing

 1. Thinking Fast and Slow by Daniel Kahneman

I heard from quite a few people how beneficial this book was for them. About six or seven years ago, I tried to read it, but couldn’t get into it – then I tried again about two years ago and really enjoyed it.

It’s an intense read and focuses a lot on cognitive biases – a lot of which I come across in day-to-day testing. Continue reading “4 Books Which I’ve Found Useful for my Testing”

Lessons Learnt: Testing in a changing context

As a tester, I do my best to follow the principles of Context Driven Testing. 

But embarrassingly enough, only up until recently, did I realise that context can change, while you are working in a team – so anything you put in place at the start of your time in a team, might not be the best thing for everyone 6 months later, or 12 months later.

I’d like to share some things I’ve learned about testing in a changing context – but first let me describe my initial context and how it changed over the course of roughly 14-15 months. Continue reading “Lessons Learnt: Testing in a changing context”

How to set up a proxy on Charles (so you can test other devices on your local dev machine)

Have you ever wondered, how do I test my fixes/changes on my local machine on IE 11?
Or in general, how do I test my fixes/changes on my local machine, when I don’t actually have that browser on my laptop?

Continue reading “How to set up a proxy on Charles (so you can test other devices on your local dev machine)”

An analogy to explain the limitations of test cases

I love analogies. They help me explain things in a way that (hopefully) others can understand and relate to.

When I was thinking how can I try and explain the limitations of test cases (because knowing test cases aren’t all they are cracked up to be, and explaining that to someone – are two different things) the first thing that came to mind is job interviews. We’ve all been on job interviews – it’s an understandable concept and we can all relate.

Continue reading “An analogy to explain the limitations of test cases”