Are there any limitations to test automation?

Isn’t it great when one solution works for any problem that you might have?

When I was a kid. I was always curious why older people were always trying to boss me around, telling me where to go and what to do. Then I discovered the response ‘Why?’. And while it helped to satisfy my curiosity for a while. I soon discovered that it had the side effect of being quite (understandably) annoying and therefore, it’s usefulness waned over time.

Or how ten years ago if a company wanted to make the tech product better. The go-to solution would be ‘Add Bluetooth to it!”.

Kinda reminds me of that scene from Big Bang Theory.

Read More

How to make your GUI test automation less flaky and brittle

Change is inevitable for the GUI of a web application, or any part of it.

For a visual example of this, look at the Google homepage from the mid-2000s. And you will see a site that has the same features of today (minus references to several Google products), but if a test automation solution was written then that depended on the layout and overall design of the page. It probably wouldn’t work with the design of today.

I know this is probably a bit of an extreme view of things. The design of a web application from over a decade ago won’t be the same today. But thinking in extremes when faced with a problem is a useful tactic to adopt to unlock the solution.

Offtopic, but if you are interested. I’d recommend watching this TedX Talk on the subject.

Using this thinking, we can then work backwards and make informed decisions about the design choices we make, the selectors we target. And the features that we will create automated solutions for.

If you want to learn more about the kinds of tests that should be automated. Check out this blog post. But we don’t want to automate something if it’s a feature that is not going to be used going forwards, or it makes little sense to automate because of time constraints.

Read More

How to run your Cypress tests in multiple environments

Cypress as a testing tool is flexible in the sense that we can use it for mocking HTTP response, re-create complex user interactions as well as monitoring, and responding to network requests.

Plus, it’s written in JavaScript!

This may or may not be a plus for some. But considering it’s the de facto language of the web at the moment. It means that one language can be used for the web application stack. And powering your testing solution and enabling seamless collaboration with developers, testers, and even technology savvy stakeholders.

YAY, JavaScript

Just as a side note, these are not reasons alone to choose Cypress over another test automation tool. I have written before on the topic and advocate using the right tool to get your job done. But seeing as this is a blog post on Cypress, I’m going to assume you have already made that decision and want to find out more on how to use a single code base for testing across your multiple environments. So let’s keep going.

Read More

Why you need to have a dashboard

Software testers are many things to many people. We are analytical, technical and above all, curious about the software that we are testing. And while those descriptions are true, the traits we hold alone can not summarise the value that we provide to software development teams..

There is a distinction between what something is and what something does.

For example, my car’s engine is noisy and needs maintenance to function. But I can’t say that my car is defined by those characteristics.

If I told someone with no knowledge of cars that information. They would have little idea of what I am talking about except discovering that car engines are noisy and need to be maintained. Whereas if I told them my car’s job is to enable me to drive anywhere I need to go and to allow me to get places much quicker than walking. They would have a better understanding of what a car is.

This idea stems from Richard Feynman who once said, “Names don’t constitute knowledge”.

I would take that one step further and say that descriptions alone don’t equal the purpose of something.

Read More

Overcoming imposter syndrome as a software tester

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

The tools that I rely on to test software

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

Write once and run multiple test cases with Cypress

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

JavaScript for Cypress testing

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

TestProject is now better than ever

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

Why your tests are failing and how to combat unreliable automation

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