Nicky Tests Software

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

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

 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

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

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

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.