Skip to main content

Posts

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. 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 Gradua
Recent posts

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: Consistency with History Consistency with User Expectations 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

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

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. 1. Understand the difference between implicit requirements and explicit requirements There are ALWAYS implicit requirements. But there aren't always explicit requirements. An implicit requirement is a requirement on the SUT (Software Under Test) that is not explicitly stated somewhere (e.g. in documentation) An explicit requirement is a requirement on the SUT that is explicitly stated. Some potential examples: I

3 Things I've learned: Adjusting to my changed identity as a (paid) working mother

As I write this my daughter is having a nap, and I'm trying to enjoy my first day of vacation. Keeping a baby/toddler entertained without just turning on the TV is a struggle (we've made an exception for cutting her nails, she can watch a cartoon then). I'll openly say that before we had our daughter I never realised how much of a struggle it is to achieve a balance that feels like a balance. And now I understand what the parents were going on about when they said they went to work to rest. I'm also rather grateful that my husband is now on paternity leave, we're walking a mile in each other's shoes. I can see how difficult it can be to focus on work sometimes with a baby/toddler in the background and he can see how difficult it is to entertain a baby/toddler all day every day. I never realised how much less free-time I would have, and that's just with one child! We don't have any family support; no parents to take our daughter for a few hours. It's

Bloggers Club: What's the best career advice you've had?

When I was in university, I signed up to a mentoring program. Back then, I actually had no interest in pursuing a career in IT, I was actually a lot more interested in a career in management consulting - so this piece of advice can apply to all disciplines, in my opinion. I spoke to the careers advisor at my university   about what I was thinking of doing in the future and she suggested a guy called Dan to be my mentor. There's one piece of advice that he gave me, that still sticks with me. What makes you so f***en special? Now, as someone who lives in Sweden - this seems to be in direct contrast to the first rule of Jantelagen (Law of Jante) , "You're not to think you are anything special" so let me try to explain how I have interpreted this piece of advice. It's more a matter of forcing some self-reflection and realising what you have to offer , than it is about being special. When I was starting out my career, I was well-aware of the fact that it can be very ha

Bloggers Club: I wish I knew more about...

I wish I knew more about... Git and Source Control. While I've used Git in the past and been able to do what I need to do - I've never felt particularly comfortable in this area. I've read up a bit on what exactly source control is, and why we have it - so I feel that I understand the concepts at least. BUT when it comes to actually using Git - I tend to feel that I'm only keeping my head above water; technically staying afloat. I find that I have a fairly good idea of what to do, and what my options are if I need to park some changes I've made in my local etc. but when I read more up on it online, then I realise there's actually so much more to learn - and that I've barely touched the tip of the iceberg. My first step to tackling this is to take Simon Berner 's course on Git Source Control. I recently discovered the Bloggers Club on the Ministry of Testing Club. For more posts on this month's theme, check this out.