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:

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”

Reflecting on leading a Testing Community of Practice Part II

For Part I go here

Devoting time and effort – when I have it

While I’m on my project my priority is as a tester in my scrum team. Therefore, I only devote time and effort when I have it. Some weeks I’m very busy in my team and barely give the CoP a second thought; other weeks I have more time to prepare a presentation or approach people to give presentations (or look up topics to see what people may find interesting to hear about from others).

I really appreciate the flexibility. While there is an expectation that something happens regularly, it seems that definition of “regularly” has become roughly once a month. Continue reading “Reflecting on leading a Testing Community of Practice Part II”

Reflecting on leading a Testing Community of Practice Part I

For about 4-6 months, I have been leading the Testing Community of Practice at my current project. Before then there were 4 of us being co-leads (for 6 months ish) before I was approached to see if I wanted to drive it and be the lead. I said yes – and said I wanted to see if I was a good fit as a lead, if I had the energy/desire for it and if there was a need/desire for a Testing CoP in the first place. Continue reading “Reflecting on leading a Testing Community of Practice Part I”

Protecting your time

Last night I attended a software testing meet-up  where Örjan spoke about his experiences in Managing Quality in an Agile team. He raised a few interesting points from a management perspective – but it was one in particular that caught my attention: protecting time.

Continue reading “Protecting your time”