Nicky Tests Software

 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 .) Job Interview Analogy To illustrate the importance of Exploratory Testing, I'd like to first use the analogy of a job interview. (I wrote about this in a previous blog post but will expand on this further) The Test Cases in this analogy In a job inte

  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. This is a more accurate portrayal. At the start of your testing period, if you increase your testing effort you will increase the value you receive from testing (say from Point A to Point B) but later in the project, an increase in your testing effort will result in a smaller increase in value (compared to earlier on in the project), this is shown in the picture above from Points C to D. Being aware of the law of diminishing returns will help you know when you can STOP testing. It's important to be aware of the fact tha

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 Exploit: Focus your attention on one specific area (or a few areas), based on your findings from the Explore part. One of the most important factors to consider when deciding whether or not to continue exploring is to consider how much time you have remaining. Christian and Griffiths advise, “ Explore when you will have time to use the resulting knowledge, exploit when you’re ready to cash in .” Let's say you are given one day to test a new feature. You may choose to plan your day by spending the first half of the day exploring the feature to "get a feel for it"; to see the "general state" of the feature, then you may spend the

 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) How I discovered the testing community At my first company, I worked with a few people who were involved with the testing community - it is through them I discovered it existed. There were also a few people at the company who organised a testing meetup in Wellington, New Zealand. Later my former mentor and two other women started a testing meetup in Auckland, based off the model that was done in Wellington. Note: The meet-ups would have a 20 minute experience report (where someone shares their experience on something) and then this is followed by a facilita

In this blog post, I will focus primarily on the struggles I've faced in managing and achieving my goals, as well as what I've learned from it. Less is better When it comes to managing and achieving goals, I've found that less is better. I used to have many goals (which I used to share on my blog in the Skills Development List page) but then found that I felt like I was being pulled into too many different directions. By having too many goals that I was simultaneously working towards, it meant that I often didn't get things done - things were often constantly ongoing. This was rather tiring. Once I decided to focus on fewer goals at a time, then I could actually start celebrating that I had achieved some goals. Frame it differently One of my personal goals used to be to lose weight. The thing is, I found that (as a horribly impatient person), there was too much of a delay between action and result. As someone who loved good (bad for you) food, hopping on the scale a wee

 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 ) In other words it's the "price" you pay for making a choice. Every time you decide to buy something, or spend time doing something etc. you are ultimately paying an opportunity cost by making that decision. Example I Here is a non-work example of how opportunity cost has affected me recently: I was in the final steps of going live with a personal project, had registered the business with the tax agency, done my research on logistics, website was ready, budget was done etc. But then I took a step back. My time is limited.  Aside from wor