Software testing usually has two types of tests. These are firstly functional and also non-functional.

But why the two? And why are they both important?

Let’s give the example that we are testing a new website. The websites main purpose is to provide an easy way for people to order items online. And although it does allow the processing of orders. Concerns are raised about the quality of the product.

Testers have found that the website is slow to respond. What’s more, it has a confusing UI, doesn’t work in certain browsers. And if released to the public. Wouldn’t attract many sales.

If the goal of software testing is to provide feedback to contribute to a quality product. Then we can say that functional and non-functional testing are two sides of the same coin.

But what is the purpose of each one? What are the advantages, and disadvantages? And in what situations are they used?

Let’s take a closer look at these in detail.

Read More

Want to kick start a career in software testing? A wise decision.

Getting your first software testing job can seem like a daunting task to take on. Which it can be, but that ultimately depends on you and your willingness to learn.

New terminology, new techniques, and possibly, even new ways of thinking.

But don’t let that put you off. In fact, it’s extremely rewarding. You get to work with the latest advancements in software technology. Are encouraged to think creatively about your challenges. And best of all, have the opportunity of working with some really amazing people.

But with no testing experience. What is the best way to get started?

Read More

Manual software testers are clearly a thing. You just have to look at the job boards of companies to work that out.

But Manual software testing is not a thing.

There, I said it.

It’s long bothered me that there is this distinction between the two sides in the discipline of software testing. Almost as if one side is doing more than the other.

And while that may be true to some extent (designing and developing automated checks does take some new skills). Is there really enough to separate the two?

Take for example a couple of cars that are parked on the road.

If you were walking by and had no prior information about the cars. Would you know which one was a manual, and which one was an automatic? Would it even matter?

Probably not. They’re just a couple of cars to most people.

The “manual” prefix in peoples job titles. Seems to throw a lot of people off. Making it appear that they’re doing a separate job, compared to their “automated” counterparts.

But are they really? And what do these “automated” testers do that you don’t?

In reality, not a whole lot.

Read More

If there is one word that sums up software testing the best, it’s learning.

Learning how software works, its capabilities, strengths, and weaknesses. Teaches us more about our own perceptions and tests our understanding of product.

I’ve blogged before about learning from mistakes we have made. But the opportunity to learn from the mistakes of others is as, if not more important for our growth. Gives us the ability to think better and is fascinating as well.

If you receive my weekly newsletter (you can sign-up here if you’d like). You would know that I’m reading Black Box Thinking by Matthew Syed.

In it, Matthew describes how failure can be redefined to cultivate new ideas. Thus, enable creative thinking, and how if we can change our perceptions of failure. We can use the experiences of others to be lead to success.

“Learn from the mistakes of others. You can’t live long enough to make them all yourself.”

From surgeons and pilots to the head of Dyson. Matthew uses the examples of others to describe how failure is the catalyst for us to learn.

Read More

Welcome to 2020 software testing enthusiasts!

And while It’s not the same 2020 that was portrayed in the 2000 film Mission To Mars. A new year brings its own sense of discovery. Challenges and exciting opportunities for software testers.

2020 will be my ninth year involved in software testing. But the subject remains as fresh as the day I started. With so much to learn and ideas to try out. The subject of software testing is one of the most exciting and rich career paths available.

And with so much to learn. Committing to life-long learning and having a growth mindset. Will enable you to achieve more, do more, and generate greater levels of success.

The best time to get started is now, and an even better time is yesterday. But with there being so much to upgrade your skills with. Where do you start?

Here are my top 5 learning subjects that you should commit to in 2020. Not only will they make you a more rounded tester. But if you’re new to testing. They’re a great place to start and get your feet wet with the subject.

Read More

When starting a new position at a company. I’m sure most of us would relish if someone was able to show us the ropes. Directing us around the obstacles of the job. And putting us on the right path for success.

Did you have someone like that in your last position?

Most likely you had some sort of induction process where you were shown the location of the fire doors and the kitchen area. But when it came to getting the best out of you and explaining where you are going wrong. That most likely fell at your doorstep.

While it can be argued that it is the responsibility of the employee to ensure they are offering the best of their ability at the office. But it also in the interests of a company to better their workers through training, skills advancement, and mentorship.

Read More

We all have our own personal preferences and routines that we like to believe allows us to work at our optimal ability.

You may have a prefered set of activities that you like to do in the morning to set yourself up for a productive day in the office. Have a need to have your desk arranged in a certain way to achieve optimal productivity. Or maybe you are only able to perform deep work with headphones on and locking out the noise of your surroundings.

Alternatively, you might not care about any of those things and can pump out the same quality and quantity of work no matter how your day goes.

I always recommend finding out what works for you, remain consistent with it, and then build it into your daily routine. What works for me, won’t work for you.

But for performing our best work, does the time of day that we do it make much of a difference?

Read More

Have you ever bought something in a shop and only realized that when you go to use it, that you learn you’ve made another one of your mistakes and bought the wrong item?

Being on a vegan diet, I can not begin to count the number of times that I’ve done this with food items.

Blindly picking something off the shelf because it has ‘dairy-free’ on the label. But if I had taken the time to read the ingredients list in the shop. Rather than when I’m half-way through cooking a delightful pasta dish that evening. I would have discovered that the sauce contains eggs.

Not a good feeling.

But even though I dislike it when something like that happens. It’s a good opportunity to reevaluate my strategy for the situation and try to mitigate similar issues from occurring in the future.

So in this case, it would be “Don’t go by what is on the front of the label and read the ingredients before buying food.”

We can make mistakes in a wide variety of situations as well as occupations. They are inevitable if we ever want to get better at our craft.

For mistakes made in software testing, they can originate from a variety of different sources. Not limited to, communication issues, documentation problems, resourcing conflicts or just plain mistakes.

But whatever the source of the issue is. It is imperative that as software testers do we not only own the problems that are made to build trust in our teams. But to also learn from them and realize the lessons that they provide.

Ownership

Depending on the issue that has made it into the production environment and the hands of their users. Mistakes can have serious effects on the image of your company.

When an issue is first reported, some people may have the initial reaction to point fingers and try to find someone to blame the problem on. Even though this might seem like the right course of action at the time. Blaming people won’t get issues solved and creates a negative atmosphere within teams. It can often be toxic and gives life to a culture in which people don’t enjoy working in.

What everyone will appreciate is when a tester steps forward and owns the problem. Admits their part that contributed to the issue getting its way into the client’s code.
Now it may not be 100% your fault and there could be other reasons that contributed to the issue being present. But as testers, the least we can do is own our contribution to the process.

Mistakes can be compared to a tiny spark which has the potential to grow into a great burning fire that engulfs everything you know. Ignoring the problem, or not recognising your part that contributed to the spark existing in the first place, only feeds the fire further.

I know from my personal experience that admitting when i’ve made my own mistakes, either by missing something, or another error of my own. Can be I’velike admitting not only a personal failure. But also my inadequacy as a tester.

But we only need to remind ourselves that everyone has made mistakes. Every single person that we can think of.

So don’t beat yourself up about it and be honest with yourself and others.

Lessons to be learned

After owning the mistake that has already been made. Attention should now be turned towards ensuring that it doesn’t occur in the future.

First of all, you need to understand the problem and investigate all the contributing factors.

I find it useful at this point in the investigation to compile a timeline of the events from start, to finish. This enables me to look up a step which is responsible and either make amendments to my test steps if needed. Or make suggestions to other teams.

Again, this shouldn’t be a finger-pointing blame game. We are all part of the same team and responsible for delivering quality software to our end users. That should always be at the forefront of our intentions.

Once you present the evidence of a potential weak point in a process to another team. How they act on the information is beyond your control and you should instead focus on the things you can change. Like your documentation, training processes or test scripts.

Followup

It’s always a good idea to hold a follow-up session to not only talk to stakeholders about any changes to your test scripts. Or any steps taken to mitigate the mistake from occurring in the future. This also allows you to inform your team about the changes so that they are aware of anything they need to do.

It’s possible of course that no-changes need to be made to any of your test cases or test scripts.

Given the example of a step getting missed in a test-case. You may need to highlight that fact and be honest with everyone about it.

Conclusion

I read a quote a while ago that read “You’re only as good as your last haircut.“

I think that can be interpreted differently.

The way we react to mistakes that we have made or contributed to speaks volumes to others.

So when you make a mistake, choose to be honest about it and responsible for the follow-up actions.

I’m glad to say that this year, I’ve read a lot of books.

Unfortunately, I’ve not read a lot of books dedicated to software testing, choosing to read blogs, watch videos, and attend conferences to get my software testing inspiration.

But still, 41 so far, a personal best for me for books read in a single year.

I’ve achieved that number by always carrying my Kindle with me, reading instead of wasting time and most of all, loving the books I’m reading.

Reading has become one of my favourite ways to learn new ideas, discover concepts I find interesting, and upgrade my knowledge in new areas.

However, with the year (and decade), coming to a close, a new intention that I intend to adopt is to increase my software testing book library and read as many of the amazing books on the industry that I can.

Read More

Have you heard this before?

‘The software was working perfectly fine until the testers got their hands on it’.

What about this?

‘Don’t give it to the software testing team. They’ll break it!’.

Are any of these claims actually true?

Can testers really break a perfectly good piece of software by running a few test scenarios and pressing a few buttons?

Well… no.

Read More