Discovering Logic In Testing. We all test in different ways and sometimes it can be hard to explain the thought processes behind how we test. What leads us into trying certain things and how do we draw conclusions, surely there is more going on here than intuition and luck? After working in games testing for almost a decade, I will draw from my personal experience to explain how games testers develop advanced logical reasoning skills.

Mistakes Matter - Maximizing the Benefits of Mistakes Made in Testing This talk can be viewed on the Ministry of Testing Dojo Everyone makes mistakes. How we cope with mistakes at work, can have a massive impact on our careers. Generally Testers are the kind of people that pursue self-growth. Learning is important to us and we want to learn from our mistakes. Yet this trait makes us focus on the mistakes that we have made.

Discovering Logic In Testing. This talk can be viewed on the Ministry of Testing Dojo We all test in different ways and sometimes it can be hard to explain the thought processes behind how we test. What leads us into trying certain things and how do we draw conclusions, surely there is more going on here than intuition and luck? After working in games testing for almost a decade, I will draw from my personal experience to explain how games testers develop advanced logical reasoning skills.

I started working for Ably recently, at the beginning of 2022. One of the first tasks I was given was to build a demo project that used one of the Ably SDKs. Working as a backend Go developer for the past 4 years made my choice of SDK easy. I definitely wanted to work with ably-go. I found myself wondering how to explore, debug and test an SDK in a visual way, rather like how the Postman API Client interacts with an API.

I recently wrote an article called Hello Little Lambda which explained what Serverless Lambdas are and how to create them using the Amazon Web Services console. While it’s great that humans can create that a new Lambdas can be made using the AWS console, there are some significant advantages that can be gained from using code to create your Serverless Lambdas for you. When your Lambdas are created by code, they will always be created in the same predictable way, making their configuration less error prone.

What is Serverless? A Serverless Lambda is essentially code, written by you, which a cloud provider like Amazon or Google will run for you. Your code gets run on a cloud providers servers on demand, as and when it is needed. The benefit of having someone else run your code for you is that there is no need to worry about paying for idle servers, managing servers, keeping servers secure, upgrading servers, ensuring servers have capacity and a whole plethora of other issues.

I used to write regularly. I haven’t written for over two years. I need to fix that. I purchased this domain, gathered up all my old stuff and moved it here. New site built (with Hugo & Netlify) and after much tweeking and adjusting I am happy with my creation. I feel ready to start writing again… Hey Rosie! What Happened? So much has happened since I last blogged, it is beyond crazy.

Learning Go I started learning Go in March 2016. I felt like I had reached a point with software testing where I would not be able to improve unless I started really putting more effort into my coding skills. I had previously written a bit of test automation in Python but I was seeing and reading lots of cool things about Go. I had heard that Go was 25 times faster than Python and I also really liked the Go song.

Back in May I taught myself a programming language called R so that I could solve the problem of analysing large amounts of data collected as part of a survey of software testers. After writing some R code to analyse the data from my survey and blogging about the findings I realised something. I was sharing my findings with other people mainly through static images, graphs and charts. I felt like there were a large number of combinations and queries that could be applied to the data and I wasn’t able to document all of them.

I've recently been lucky enough to be involved with a new software development project from the very start. One of the advantages of being the first Test Engineer on the project was that I was able to help implement and set up test automation on the project from the very beginning. Frequently software development projects see test automation as an after-thought and try implement it later, when the software is already quite advanced.

Blah blah automation. Blah blah Selenium. Apparently automated testing is what all the cool kids are doing these days. I’m not naive enough to believe that automated testing is some kind of magic spell that when cast the software will test itself and suddenly reveal the location of all the bugs. But, having experienced first hand the pain of long drawn out manual regression testing, if ANYTHING helps ease even a small amount of that pain - I want to know about it!

Solving Testing Problems With Go The code examples for this talk are available here on github

Gracefully Jumping on to a Moving Train This talk is available to view on YouTube

Discovering Logic in Testing We all test in different ways and sometimes it can be hard to explain the thought processes behind how we test. What leads us into trying certain things and how do we draw conclusions, surely there is more going on here than intuition and luck? After working in games testing for almost a decade, I will draw from my personal experience to explain how games testers develop advanced logical reasoning skills.

Discovering Logic in Testing We all test in different ways and sometimes it can be hard to explain the thought processes behind how we test. What leads us into trying certain things and how do we draw conclusions, surely there is more going on here than intuition and luck? After working in games testing for almost a decade, I will draw from my personal experience to explain how games testers develop advanced logical reasoning skills.

How To Help Testers Succeed This talk is available to view on YouTube

Twitter Mining and Sentiment Analysis with R Slides for this talk are available here

This article was shared with me today. I especially loved the addition of the speech bubbles to stock clip-art. I found it very special and utterly hilarious. It really made me giggle! See if you can guess the answer to this one…. This post was originally published on my software testing blog Mega Ultra Happy Software Testing Fun time.

The scariest pumpkin I’ve seen this Halloween. This post was originally published on my software testing blog Mega Ultra Happy Software Testing Fun time.

This is a test (did you really think it would be anything else?). This post was originally published on my software testing blog Mega Ultra Happy Software Testing Fun time.

It’s been a month now since I attended Test Bash Manchester. I heard two very powerful talks at that conference which have been swishing around in my brain for a while now. Both talks came from speakers that shared a desire to advance the craft of testing. The first talk was by Martin Hynie (@vds4), currently Director of Test Engineering at Medidata. The second talk was by Michael Bolton (@michaelbolton) a tester, collaborator, coach, consultant, author and Twitter super star.

I was very fortunate that I was able to attend my second ever Test Bash in Manchester. This year was better than last year as two of my co-workers (Hannah & Jack) came along for the ride. I got so excited seeing them get excited! I spent most of the conference day scribbling notes again. However unlike last year where I mostly wrote text in a pad. This year I had plain paper and used coloured pens.

At the start of August I attended North East Agile Testing (NEAT) meet up at Campus North in Newcastle. While I feel I am active within the software testing community (through Slack, Twitter, blogging etc.) this was actually the first time I had ever attended a face to face testing event. While at NEAT I found it easy to express my views about testing (possibly helped by the free beer) and tried to share my experience by answering some of the questions which were being asked.

2017 has been a stressful year for me so far. I bought a really ugly flat in February, then found myself with two months to make it habitable and move into it. While frantically arranging appointments with trades people and deliveries of essential things (like carpet and furniture), a call for speakers came up for the Agile North East Lightning Talk competition. I was already so stressed out from trying to move house, the stress of giving a talk felt insignificant by comparison.

Happy New Year everyone! For the last 18 months I have been testing software designed to trade foreign currency, known as FX or Forex trading software. I consider myself lucky as I joined the project on day one which enabled me to learn a lot about testing trading systems. Challenges Financial software, including trading applications, can be some of the most incredibly difficult complex applications to test because they contain many challenges such as:

Recently I attended a software testing conference held in Manchester. While I was at the conference I had a conversation with Andrew Morton (@TestingChef) about Twitter. Andrew told me he had a theory that at conferences people tweeted more in the morning than in the afternoon. As an active Tweeter and passionate R user I thought it would be interesting to try collect some real data, take a look and see what was happening.

This is a follow up on [my earlier post] (http://testingfuntime.blogspot.co.uk/2016/09/learning-to-talk-finding-your-voice-and.html) about learning how to give a technical talk. I did it! I gave my talk! The feeling of euphoria afterwards was overwhelming and I think I might still be buzzing from the experience. I wanted to write a mini blog post to say a massive THANKYOU to everyone that came along to the Newcastle Testing meet up on 1st November. It was good to see a mix of both familiar and new faces.

Usually Test Bash events in the UK are held in Brighton making them a bit inaccessible to people living in the North. However this changed on Friday 21st October when I was lucky enough to attend Test Bash Manchester, a software testing conference held at the Lowry in Salford Quays. Organised by Richard Bradshaw @friendlytester and Rosie Sherry @rosiesherry, this was the first time a Test Bash event had been held in the North West.

Back in May I carried out a survey of Software Testers and I have been continuing to analyse these survey results. My previous blog post about the survey was well received and focused on experience in the workplace. One of the objectives I set out to achieve with the survey was to examine the backgrounds and experiences which have led testers to be where they are today. I wrote another R script to help me interpret the survey results data.

Why is it really difficult to hire testers? A few months ago I found myself involved in a number of discussions not about testing, but about testers. All the conversations I had revolved around the following questions: Why is it difficult to hire testers? How do people actually become testers? Does anyone actually choose to be a tester or do they just fall into testing by accident? Is it possible to persuade computer science students to pick a testing career over development?

Modern software testing has become agile Anyone that cares about making good software has moved away from the old waterfall ways of “throw it at QA when it’s finished”. One recent trend is to embed a single skilled tester within a small development team to test early, test often and add as much value as they possibly can. In the old days, before test automation was as common as it is today, large numbers of human testers were required to carry out large quantities of laborious repetitive checking.

Some of the biggest challenges when testing software can be getting the software into some very specific states. You want to test that the new error message works, but this message is only shown when something on the back-end breaks and the back-end has never broken before because it always “just works”. Maybe the software you have to test is powered by other people’s data, data that you have no direct control over and you really need to manipulate this data in order to perform your tests.

As Software Testers, we have to frequently imagine the unimaginable. Through experience we learn, adapt and prepare for the next time we encounter similar circumstances. Recently, I found a particular annoyingly awkward bug and was able to draw from experience to not only identify but also explain very quickly without too much investigation why this bug was happening. I was able to do this as I had encountered an almost identical bug a couple of years previously.

Its now 2015 and we’re all living in the future! Our world has become a place where invisible intangible things (like APIs) have become rather important in our day-to-day lives. This morning while staring at my PC with sleepy eyes, details of a security vulnerability at www.moonpig.com popped up in one of my social media feeds linking to this article. The post itself was fairly negative towards Moonpig, along the lines of “I will never use their service again because they fail at security.

When it comes to testing anything in a browser, Internet Explorer tends to have the reputation of being the black sheep of the browser family. Anyone with any experience of testing know that there is a greater chance of something being broken in Internet Explorer than any other browser. Let’s face it, IE doesn’t have a great track record. As software testers, we all remember the pain of having to support IE8, IE7, IE6.

I've recently been lucky enough to be involved with a new software development project from the very start. One of the advantages of being the first Test Engineer on the project was that I was able to help implement and set up test automation on the project from the very beginning. Frequently software development projects see test automation as an after-thought and try implement it later, when the software is already quite advanced.

Writing good requirements for software development might seem like an easy task on the surface, but it’s actually much harder than many people imagine. The two main challenges that arise when writing requirements are firstly, requirements can change frequently. Secondly, even if you manage to capture a requirement before it changes, it’s really easy for someone to completely misunderstand or misinterpret it. Good requirements are absolutely crystal clear with no room for interpretation whatsoever.

It’s been a roller-coaster of a month since my last blog post. In the last four weeks I have successfully managed to change job and learn JavaScript! I started on JavaScript the same way as Python by completing the free codecademy course. If you test things and you want to learn basic programming you should definitely give it a try. Some initial observations made while learning JavaScript: The learning process was much faster than last time.

Eight months ago I started my selenium adventure by learning how to automate finding pictures of cute cats. I chose Python as my weapon of choice due to it being very easy to install, not requiring a server to run and not needing a heavy IDE for development. I have been writing automated UI tests both at home and at work. I found my automated tests not only saved me time carrying out tedious repetitive regression tasks, but also found a range of genuine bugs ranging from obscure to showstopper!

Just as different people can possess different political beliefs and not everyone believes the same thing, I think the same can be said with software testing. In the world of testing there isn’t a one size fits all ‘right answer’, it doesn’t exist. Lots of people have lots of different ideas and some of these ideas can conflict with each other. The whole manual vs. automation argument is a good example of this.

Assume any information given to you could be made of lies until you have proven it to be true (and seen it to be true with your own eyes). If information given comes from a non-technical or customer facing source be especially wary. If that source is members of the general public then loud warning klaxons should be immediately sounding in your head! What happens when someone else sets your baseline or expected behaviour and the thing you are testing does not meet that baseline?

So in the last couple of weeks a newly discovered computer security exploit was found - hooray! Something we thought that was safe, trusted, tried and tested over a very long period of time has turned out to be flawed. It’s in the media, the sky is falling and people that use the internet are scared about things they do not understand! Customers are frantically emailing companies to ask if they are safe, and how safe safe actually is.

When you work in software testing, every now and then, you get to hear other people’s stories about bugs. Most of these stories will be fairly mundane. Something along the lines of like “Yeah, I clicked the button and nothing happened”. But there will be other times, once you have been working in software testing for a while, when you may get to hear a story about a legendary bug. Legendary bug stories tend to something like “Yeah, and then if you paste that in to the text box and hold down the shift key, it sends an email to 193,248,2489 customers thanking them for ordering Nickleback’s latest album”.

Everything is urgent, everything is critical, rush rush, develop develop, test test, now now now! This is a common theme in both games development and software development. Management pressure always trying to get the product shipped or the next chunk of code released. Everything may appear shiny and happy on the surface but underneath, code becomes a twisted, tangled, distorted mess which starts testing the sanity of anyone that has to interact with it.

I recently had to give a presentation to my test team at work with about testing APIs. The team covers a wide range of experience levels and with varying technical knowledge so I wanted to try describe API’s in a way that everyone would understand. The presentation I gave was well received so I wanted to share an excerpt of it here. I’ve seen quite a few non-technical people look worried just at the mention of the word API.

Blah blah automation. Blah blah Selenium. Apparently automated testing is what all the cool kids are doing these days. I’m not naive enough to believe that automated testing is some kind of magic spell that when cast the software will test itself and suddenly reveal the location of all the bugs. But, having experienced first hand the pain of long drawn out manual regression testing, if ANYTHING helps ease even a small amount of that pain - I want to know about it!

I saw this article recently about how a website owned by a company called eDreams nearly charged a lady £23 billion for a return flight. Closer inspection revealed that it wasn’t the flight that caused the problem, it was actually the return baggage check-in cost. How could such a massive error make it unspotted onto the eDreams website? Maybe they didn’t have any automated tests that could verify the return baggage cost was far to large.

Don’t lie, ever. Not even a little lie, not even once. Software does not lie. Software will not cover up for you. Testers that lie, ALWAYS get bitten in the ass. When I worked with small teams of testers sometimes a tester would get through their work for the day far too easily, far too efficiently, ask no questions and all of their tests would mysteriously pass. As a team lead, situations like this scared me a lot.

I’ve been doing a fair bit of thinking recently about testing new features in software. New features are special. They are all shiny and new which means its very unlikely they will have been tested before. It can be insanely difficult to measure something new, especially if there is nothing similar to which it can be measured to against. Over the years I have seen many new ideas and designs translated into software and many test teams trying their best to test them.

Realise that testing the quality of something and making decisions about the quality of something are totally different things. Don’t get upset if someone goes through your precious bug database setting all your bugs to WNF (‘will not fix’). Novice testers can struggle with accepting this concept. They tend to moan a lot, develop a negative attitude and start mumbling nonsense like ‘what is the point of writing bugs if they won’t fix them’.

Given that games and software testing are two of my favourite things it was only a matter of time before I stumbled upon a game that claims to “test your testing skills”. I know what you’re thinking, who would even try make a game about testing a game? I’m really not making this up, it exists. Here is the link if you don’t believe me. Software that tells someone how good a job they are doing of testing the software - this was too good to miss.

For some reason, the world of software testing is a minefield when it comes to terminology. The International Software Testing Qualification Board (ISTEQ) currently has a 50 page pdf document explaining testing terminology which can be downloaded from their website. When I first learnt how to test computer games I was not taken to one side and told to memorise any of these terms before I could start testing. I’m fairly certain that someone with zero experience of testing software could learn all the these terms, but even once they knew the lingo this probably would not enable them to perform meaningful tests.