Do I prefer manual testing or test automation?

We had our weekly European tech team meeting today and the format was to be randomly assigned someone and then ask them questions about work or their project. We posed these questions to our partner in front of everyone else, and everyone else heard the answer.

I was randomly paired up with Joāo -who asked me if I prefer manual testing or test automation?

Continue reading “Do I prefer manual testing or test automation?”

Why it’s important that it’s safe to fail

When my daughter started to learn how to walk, we immediately started buying corner protectors and had multiple scans of our apartment to see if there were any dangers lurking that we had to remove or cover up. We wanted to make it safe for her (to fail).

When it comes to software development, I think it’s also important to make it safe for people to fail.

People make mistakes.

It happens to everyone – and in my opinion, it’s not a bad thing.

Continue reading “Why it’s important that it’s safe to fail”

Bloggers Club: First day in a team

I’ve had many first days in a team since I started my testing career almost nine years ago. But it’s always been daunting and there’s a lot to take in.

New faces.

New names.

New context.

New project.

I’m often trying to gain my bearings and not necessarily looking to start testing on my very first day. (For getting started on a testing project, read this)

Continue reading “Bloggers Club: First day in a team”

Feedback: Solicited vs Unsolicited

I tend to be wary of giving unsolicited feedback in general, even with the best intentions, it doesn’t always go down well.

Let me give you an example: I used to work with a tester who wrote the bare minimum when it came to bugs. There was hardly ever any information on steps to reproduce, no information on OS version, screenshots sometimes were provided and actual result vs expected result were never there.

Continue reading “Feedback: Solicited vs Unsolicited”

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”

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”

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:

How to add an image for multiple locales using XCTest

An annoying thing I’ve had to deal with recently is adding an image (both where you take a photo with the camera and also from the gallery).

You might think that sounds pretty straight forward, but when you want to run your test in multiple locales then “Choose from library” and “Upload photo” etc just doesn’t quite cut it.

Attempts to record the steps I took within the gallery view also proved futile, as I could not actually record what I did there.

Here is how I went about adding images to my tests:

    func testAddPhoto() {

        let addPhotoButton = app.tabBars.buttons[LocalizedString(\”add.photo.button\”)].firstMatch

        let photoLibraryButton = app.staticTexts[LocalizedString(\”photo.library.button\”)].firstMatch

        let takePhotoButton = app.staticTexts[LocalizedString(\”take.photo.button\”)].firstMatch

        addPhotoButton.tap()

        XCTAssertEqual(waiterResultWithExpectation(photoLibraryButton), .completed)

        XCTAssertTrue(photoLibraryButton.isEnabled)

        XCTAssertTrue(takePhotoButton.isEnabled)

        photoLibraryButton.tap()

        //here I am selecting the first image album

        app.cells.element(boundBy:0).tap()

        //opted for a sleep to give it time for the images to appear

        sleep(1)

        //selecting the most recent image

        app.cells.element(boundBy:0).tap()