Electricity, as we know it today, is something many of us often take for granted with little consideration of the process that went into understanding, and harnessing this essential and powerful commodity. The history of electricity is fascinating in its own right, and if you are interested, I highly recommended researching the topic.

But the point is, we didn’t really start consuming electricity as we know it today (as in using it at home). Until about a hundred years ago (sockets were only introduced in the late 1800s). Which, in historical terms, is not only recent but the fact that we have wireless chargers available today. Is something that would make your great-grandparents astonished.

On a similar notion, the world-wide-web only really started gaining traction in the late 90s. With every website looking like a carbon copy of the previous, including the flashing word art and solid colour text. Gradients were too fancy back then, apparently.

If you weren’t around back then and want to get a idea of how websites looked. A fun little tool to check out is this website. The MIDI music reminds me of the website I made for my A level ICT class.

Today websites and applications are popping up every day. Each serving their own purpose, targeted towards specific audiences and each with their own unique features that differentiate them from their nearest competitor. Many of these would be unrecognizable to an early web adopter, with AI chatbots and fancy JavaScript features now commonplace. It just goes to show how far the web has progressed in a few short years.

Read More

I sometimes wish I was more useful with using my hands to create and develop things that didn’t involve clicking on a mouse. Being able to create sculptures out of raw materials or upgrade my car’s engine would be a useful and interesting skill to possess. But at the current moment in time, I can’t even change a tyre without consulting someone else.

My Dad however is a natural with those sorts of things and being a trained carpenter, something that I feel should know a little about. And while it’s true that I do at least know the difference between a router and a router. I’m in the dark when asked questions like: ‘What is the most suitable sandpaper to get this finish?’ Or ‘What type of wood is best for this situation?’.

Much the same as he probably has little idea about what a node package is. So maybe I’ll explain that to him someday.

But even though we might have distinct skill sets regarding how we get things done. We share one key trait, and that is having a set of tools we rely on to be productive and get tasks completed. That is the definition of a tool, isn’t it? Something that allows you to be productive as quickly as possible. If you don’t know the advantages of the tool or what it is doing for you, then the benefits of using it won’t be clear to you. I couldn’t give some who isn’t a software tester my tools and say that they’re a software tester now. Much the same as I couldn’t be given a hi-vis jacket and a hard-hat and call myself I’m a builder.

Read More

Very early in my test automation career, I came across the legendary software engineer and author Robert C. Martin (aka Uncle Bob) who taught me that unnecessarily repeating code was a terrible idea. Not only because it leads to software systems that are hard to maintain and more prone to bugs and errors. But if large parts of the code base is compromised of code that is copy + pasted with a few variable names changed. Then if volatility is introduced via a change in the requirements or modification to implemented logic, then large parts of the solution will be made redundant with the click of someone else’s mouse.

So for combating this, instead of writing code to perform multiples of the same function with only a few slight changes to the data we are using. We should instead focus on only coding one test (in our case) and rely instead on the test automation framework to run our required test cases with the various scenarios that we ask of it. The benefits of this go beyond a solution that is easier to maintain and more flexible to outside changes. It also enables us to ramp up our testing efforts and run more test cases if needed.

For instance, you might only need to run 5 tests at the moment. But what if you need to run 15, or even 50 one day? With a code once and test multiple times approach. The ability for us to scale is much easier than if we took the approach of repeating every test case and making a few alterations.

This approach is not applicable in every scenario, and there may be situations in which we implement logic in one of our test cases and needs to be used in another. But this alone should not be a reason to take the simple approach and reuse code. It instead should only be done if there is no other solution available.

Read More

I have always had a preference for starting things in the beginning and then continuing linearly. It doesn’t feel right to be learning about the consequences of an event before knowing what the causation was in the first place. I don’t, for instance, see how you can fully appreciate the advantages of people having alarm clocks in the home if you didn’t know that a private employee with a stick was once relied on to get you out of bed.

That fact alone makes me utterly grateful to own an alarm clock. But I digress.

As software testers, we know that the best time to start testing is as early as possible in the lifecycle of a project. And I think the same is true of knowledge building (just not the being involved part – unless you have a time machine). If you have knowledge on the building blocks that a larger project is built on top of. Then you are in a better position to become more knowledgable, efficient and productive with the particular skill and knowledge area that you are working in.

The test automation framework Cypress is easy enough to pick up on its own. I think if someone took some time to read their documentation and tinkered around with some of the provided examples. They could probably come away with some code that would meet their needs. That’s all a tool of any kind has to achieve afterall.

Read More

When I meet someone who I haven’t met before, and we get talking about what each of us does for a living. After getting past the explanation of what software testers do (hint: It’s not breaking software). I like to drop in some details about my work with automation and how I work with tools to enable applications to perform predefined actions.

Usually, this gets reaction that you are probably thinking, and they say something like: ‘Wow, I wish I could do that!’

But the thing is, they can if they really wanted to. As much as automation engineers like to think we have unique abilities and can make the DOM submit to our every need. Test automation isn’t complex in the slightest.

Back when I first started, I had no other option than to start learning a programming language (which first started off as being Perl, then Python and finally C# and Java). As well being familiar with a framework like Selenium or Robot Framework. Nowadays however with advancements in technology and the availability of newer and better tools. The barrier to entry has come way down and now anyone with a passion to apply test automation to a new or existing project. Only needs to do a bit of learning and they can jump right in and start reaping the rewards almost immediately.

Read More

If you have previously created automated test scripts, or are in the early stages of creating a new solution. You have likely come across situations where things, for lack of a better word. Brake, and seemingly for no easily explainable reason.

Either they have previously passed and are now failing. Failing inconsistently. Or possibly never passing, but getting closer to the end with every attempted run that you make.

And despite the temptation to immediately rerun any test that may have failed and chalk up anything that doesn’t meet your expected results to ‘one of those things’. You really need to take the time to understand what caused the failure to occur. Put in the steps in place to prevent it from happening in the future, and you” come away with a more reliable and effective test automation suite.

Read More

I’m a man of simple pleasures. Good books to keep the mind active and exposed to fresh ideas. Music that I can enjoy and relax to when needed. And also doing things with as little extra effort then required. Or sometimes referred to as taking the path of the least resistance. Why push a boulder up a hill if you don’t have to?

One of my favourite quotes by Bill Gates touches on this very topic and I think it illustrates perfectly the mindset that I try to apply to my daily life.“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”

Bill Gates

Lazy seems to have a negative association in today’s society and coupled often with the image of someone laying in a hammock and snoozing the day away while avoiding more important work.

The word originates from the 1540s word lasey whose original definition was someone that was “verse to labor, action, or effort“. And despite the modern-day connection with the word idle and the associated images that it brings to mind. I’m happy to associate myself with at least part of the original definition.

Because like I say. Why do something the hard way if you don’t need to?

Read More

The array of original web applications released today is outstanding. From blogging platforms, marketing tools and even websites dedicated to sharing photographs of your beloved pet cat. The diversity in the web’s utilisation for users to work, play and get tasks done is huge.

But there’s some functionality that nearly every application out there today has in common with one another. Whether its to keep track of how often you use particular services. Enable the ability to provide a rich and tailored experience. Or just restrict access to allow certain users. The process of registration and logging in is one of the most common tasks that users have to do when they want to interact with a new web application.

And for testers trying to construct an automation framework or toolset. These can be some of the most challenging parts of any automation approach. Not because it’s notoriosly difficult. But more because there are several unique approaches to achieving the desired goal:

• You could use a static account. Already pre-configured and authenticated.
• You could create a new account on the fly. Simulating the process of a real user.
• You could also seed the database with an API POST request. Allowing you to mock login responses and other core functionality.

Each one of these options has their own pros/cons and I would highly suggest taking the time to think about which one not only works for your situation. But which one will provide the most value to the project that you are working on.

Read More

Our ability to predict human behaviour in various contexts is remarkably accurate. From measuring the likelihood of us buying a certain number of items based on our past shopping history. To whether we might want to go on holiday by analyzing our past Google search results (I’m sure you’ve seen the targeted ads).

And even though we can do amazing things with software and hardware to help us in predicting behaviour. We still run into issues in certain situations.

Think of a scenario in which an automatic car is driving down the road, and we throw an obstacle into its path. Will the car detect what is going on and take corrective action? Or will the car carry-on and cause a potential accident?

The answer is a favourite response of mine: ‘It depends’.

Read More

Following on from my recent post detailing why you should be focusing on API testing (if you aren’t already). I wanted to show an example of a testing tool that I’m sure many people are interested in using for their automated UI testing needs and detail how to use it to perform automated API testing.

Why use Cypress?

If your tech stack is dependent on JavaScript in the front-end with a framework like React or Vue. And you’re making use of it in the back-end layer with a service like Firebase. Then using a JavaScript end-to-end testing tool might be something that you may want to consider.

Read More