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.

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.

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.

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.

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.

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?

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 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.

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.

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.

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 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.

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!

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.

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.

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!

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.

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.

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?

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.

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.

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.

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.

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.

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!

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!