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”

The Economics of Software Testing: The Sunk Cost Fallacy

What is a sunk cost?

A cost that already has occurred and cannot be uncovered. (Source: https://en.wikipedia.org/wiki/Sunk_cost

 

What is the sunk cost fallacy?

Individuals commit the sunk cost fallacy when they continue a behaviour or endeavour as a result of previously invested resources (time, money or effort) (Source: https://www.behavioraleconomics.com/resources/mini-encyclopedia-of-be/sunk-cost-fallacy/)

Put simply, if you are continuing to do something because of the resources you have ALREADY committed to it, then you have fallen for the sunk cost fallacy.

Continue reading “The Economics of Software Testing: The Sunk Cost Fallacy”

Minimalism and test documentation

Outside of work I consider myself a minimalist.

The definition of minimalism I most closely align with is

Minimalism is a tool to rid yourself of life’s excess in favor of focusing on what’s important—so you can find happiness, fulfillment, and freedom

https://www.theminimalists.com/minimalism/

For the past few years I’ve done my best to not over-consume and to donate or sell things when they are no longer providing value to me.

Continue reading “Minimalism and test documentation”

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.

Bloggers Club: The Importance of Exploratory Testing

Before we dive into the importance of Exploratory Testing, I would like to clear three things up.

Firstly, I align with this definition of Exploratory Testing, by Cem Kamer, it is an approach to software testing that consists of simultaneous learning, test design and test execution.

Secondly, I don’t think Exploratory Testing has to be a substitute for test cases, it can complement test cases. (It’s up to you, how or if you choose to combine both Exploratory Testing and Test cases when you test a feature)

Lastly, exploratory testing is not adhoc testing – adhoc testing is random, unstructured testing, exploratory testing forced you to think critically about the application under test. (For more about the difference go here.)

  Continue reading “Bloggers Club: The Importance of Exploratory Testing”

The Economics of Software Testing: The Law of Diminishing Returns

What the law of diminishing returns?

if one input in the production of a commodity is increased while all other inputs are held fixed, a point will eventually be reached at which additions of the input yield progressively smaller, or diminishing, increases in output (Source: https://www.britannica.com/topic/diminishing-returns)

How does the law of diminishing returns apply to testing?

This picture below shows how testing does NOT work.

Continue reading “The Economics of Software Testing: The Law of Diminishing Returns”

Explore/Exploit: An approach to software testing

I recently read a chapter on Explore/Exploit in Algorithms to Live By, and saw how much this concept can apply to software testing.

First, let’s define what we mean by “Explore” and “Exploit” in the context of software testing.

Explore: continue to explore the software under test and look into new areas of the SUT Continue reading “Explore/Exploit: An approach to software testing”

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”