Digging Deeper: who can be a Software Tester

First question. What is quality assurance and what do software testers do?

One of the official business definitions says that testers and quality assurance (QA) experts bring value to the product by making sure that all of the features are created according to the specification. I like to say that software testers ensure we’re all building a right product and that we’re all building a product the right way.

Explain building a right product and building a product the right way…

Well, when you start working on a digital product for a client, you usually get a set of functionalities and requirements you need to fulfil. Developers will implement them according to the specification and the final product will fulfil all the needed requirement and work flawlessly – that’s what happens in theory.

In practice – there are bugs, there are errors, there are misunderstandings. We as testers check if the final product is made according to the specification – that’s the part of building a product the right way. Another part of testing is to see if we’re building the right product – we need to ensure the product makes sense for users and the client. You see, sometimes the problem is not an error, but a lack of features, and that’s also something we document and report to relevant stakeholders. These two aspects are how we testers bring value to the product.

When we talked earlier, you mentioned putting yourself in someone else’s shoes as an important part of testing…

That’s the basis – that is one of the most important tasks of every software tester. Now, how do you do it? Everyone has their own way of achieving that, but some of the most common tactics are researching and asking questions, communicating with a wide variety of different people and just envisioning yourself as a completely different person – both physically and mentally. When we tested applications for the Sheikh Abdullah Al Salem Cultural Centre, we had to turn ourselves into children that are between 8 to 12 years old. You need to get into their mindset and see what they would find interesting, can they understand what’s going on, are the elements on the screens within their reach…

As I said, that’s the basis, that’s what you have to do as a software tester. Another thing are the tools we use – pen and a notebook are the holy grail, but from time to time we also use some more complex tools to automate repetitive tests and processes. But you have to know that software testing is really hard to automate – it’s a common misconception that everything can be automated. When I started, I thought the same thing – I wanted to automate everything. I remember saying to our CEO that I’ll write the apps that will automate everything. Turns out it doesn’t work that way. You see, you can automate simple, repetitive tasks like checking if I’m really logged in after I click on the login button, but you can’t automate the test that needs to see if that login button even needs to be in the place where it was placed or if the entire game makes sense from a user’s perspective.

That’s why a pen and a notebook are the most important tools. Everything else is just a support!

OK, so what goes into the notebook?

Every tester has a different system – some draw, some scribble, some point out precise highlights and bullets, some testers draw complex mind maps… The thing is to document key information. That’s the gist of it – you document key information, your train of thought that will help you organize all of the aspects of a certain project. And it’s much better than trying to keep it all in your head – especially if you’re working on a couple of projects.

Tell me more about those automation tools you mentioned…

The Swiss army knife of the software testing world is a tool called Selenium. It’s an extremely popular tool because it enables you to automate your browser. Notice that I haven’t said that Selenium is a testing tool – it is not, it just automates browsers, but it’s really powerful at that.

For example, you can write a script that will instruct the tool to go to bornfight.com, open the contacts page, fill out the form, submit entered information and then check if the new submission is visible in the database. You write a script and then use Selenium to initiate it. Selenium will read the script, open a designated browser and use it to perform tasks set within the script. This test I just described is one of more important tests we conduct because the form on the contacts page is the primary way potential clients can contact us, but it’s a simple, repetitive test. And that makes it perfect for automation. Imagine a person having to come to work every day at 9 AM and filling out a contact from just to test if it works – that’s not effective, and that’s why we automate things.

The other part – for example, is the contact form visible, does it maybe have too much steps, is something off… That’s the human part of testing, that’s the part you can’t automate.

When do testers start working on a project?

At Bornfight, we start working on a project right from the beginning. We’re there on the very first discovery workshop when we’re just getting to know the client, their idea and the overall strategy of the project, and we follow the development process as it goes through different phases. Another common misconception about software testing is that we need finished products to be able to test them out, but to test different aspects of the product in different development phases, we just need different inputs.

For example, if we’re testing the user flow of the application, we don’t need a working application. We just need to have mockups and screens, and that’s enough for us to start working. As we’re closely tied in with every part of the process, every new aspect and every new feature goes through us before it’s implemented into the final product – and that’s what keeps us all in the loop and the entire project on track.

The amount of testing we do, as well as the types of tests we do depend on the projects themselves, but the main backbone is always the same – we put ourselves into the users’ shoes, dive deep into the specific aspect of the project we’re working on, document all our findings and then inform the relevant stakeholders. When that’s done, we test the next aspect. And we build the product feature by feature, sprint by sprint.

And when does it end?

Software testing is something that can literally be done indefinitely. You do it before the production starts, during the production and also after the product is launched… Knowing when it’s time to stop testing a product is one of the hardest tasks in software testing because it’s all about optimizing available time to achieve maximum results.

To put it into perspective, you can, for example, invest 50% of your effort into testing and that would give you 300% results. But if you double the effort, you wouldn’t get 600% results – you’d get around 315%. Detecting that moment when you maxed out your cost/benefit, well that’s something you can ask on a job interview for senior software testers, and you still wouldn’t get a precise answer.

Software testing is often connected to development. Do software testers need to be developers, do they need to write code?

Well, that’s one of the misconceptions or anti-patterns about software testing. Software testers don’t need to write code and they don’t test code – testers test applications. Code is tested by developers because their output needs to be functional code.

How do you get functional code? If you’re a flawless developer, you’ll never write a single test – you’ll write your code and it will work flawlessly. If you’re not a flawless developer, you’ll also write a couple of tests that will help you in creating functional code – your primary output.

Software testers don’t test code because they don’t have to know it and because that’s not their primary output. Their output is information that will lead to a building a right product and building a product the right way. If testers know how to code, that can help them with tools like Selenium, but knowing code is not a prerequisite for being a software tester.

So, you are actually connected with all different teams…

Exactly. We give relevant information to relevant stakeholders. For example, if a code isn’t compiling, that’s an issue that could be relevant to developers, but it probably isn’t that relevant to a product owner. On the other hand, if we find out that the platform won’t work if there’s more than 100.000 users on it – well, that’s most certainly relevant to the product owner.

A part of software tester’s work is to know who we need to inform about certain issues so they get resolved. When you talk to the right people about the right things – that’s when they get done. It’s something called bug advocacy!

This is a fairly complex position. What skills are needed for someone to be a good tester?

There are no specifically defined skills, but I always say that curiosity and passion for technology are a must-have. You need to have these two things to be a software tester, and that’s something that can’t be taught. All of the other skills can be learned and mastered.

If you’re curious and passionate about tech, I’m certain that you also have at least one additional talent that we can uncover and which can be used for software testing – whether it’s coding, management, design, business, philosophy… Practically anything can be used as a part of software testing because different people with different skills and talents look at projects from different angles. That’s why you always want to have a diverse team of specialist within a Quality Assurance team.

Having two similar testers on a project won’t give you results that are two times better, you’ll just get two sets of same or similar results. On the other hand, having two completely different individuals is the way to go because they’ll use their specific talents to look at the project from different perspectives, and that’s how you get results that are two times better.

That is why I always say that curiosity and passion for technology are the only requirements for software testing. They are the main pillars – you need to want to dig deeper in order to create something better. Everything else you bring to the table is just a valuable skill that will quickly become a part of our collective – we’ll help you sharpen it, master it and use it create value for projects we work on.

Let me get this straight. In theory, anyone can be a software tester?

Yes – I’d say that anyone can become a software tester. There’s no specific prior knowledge, there’s no college for testers or anything like that. There is a level of efficiency and success you can achieve, but I believe that if you’re curious and have a passion for technology – you can be a good software tester.

Now, what’s a good software tester? Well, it’s all about finding that third, fourth, fifth quality inside you and using it to the max. At Bornfight, we created a really good setup that enables us to find out what people are good at, and guide them in that direction. We’ll see if your development skills are stronger, maybe your design skills have the upper hand, maybe you’re exceptional at philosophical analysis – we’ll detect that, we’ll give you the tasks that will help you bring value to the product and you’ll become a good software tester.

That doesn’t mean you start tomorrow and you’ll be good right from the start, but if you’re willing to put in the work, and if you find joy in experimenting, getting better and learning something new every day – well, that’s something we’re looking for.

You say it makes you happy. Why? Is it because you get to break things…

Well, getting to break and deconstruct things is just a bonus, an added benefit. You see, as a kid, I really liked playing with LEGO bricks, building complex things. And at that time, a game with LEGOs came out on PC and it had one interesting feature – a giant bomb which you clicked and it destroyed everything you built. To me as a kid, that was the single most terrifying thing out there – why would you want to spend hours building something amazing just to see it destroyed in less than a second. I never liked that destruction aspect.

What I do like about this job is that we can make sure the project we’re creating is done well. I want the people who use it to be happy, I don’t want to see them frustrated because something is not working as it should – that’s me stepping into the shoes of a user and looking at the product. On the other hand, me stepping into the shoes of a client is about making sure that everything we do achieves profit, and creates progress. Those are the things that make me happy about this job, and really drive me to give it all to ensure we’re adding additional value to every product we create at Bornfight.

Getting to deconstruct products is just a side benefit, something extra.

Last question. Why would someone want to be a tester at Bornfight, what can we offer them?

We can definitely offer them a platform where their creativity, curiosity and passion for tech can thrive. In a large number of development companies, you have software testers that are not satisfied with their positions. And they’re not satisfied because they’re kept out of the loop – they aren’t involved in the processes, but are instead seen as the last step before a product is launched. Their task is only to see if the product was built according to the specification. That other important aspect of software testing, that ‘building the right project’ part that I talked about earlier is unfortunately often put on the back-burner.

The task of the Quality Assurance team and us as software testers is not just to look at finished products and say ‘this needs to be fixed’, ‘this needs to be fixed’, ‘this needs to be fixed’. Our job is to be involved in every step of the process and to provide feedback to all relevant stakeholders on the project, whether that’s the client or our internal teams, about the aspects of the project that need to be done differently in order to satisfy those two crucial aspects of Quality Assurance and software testing – building the right product and building a product the right way.

As I said, in a lot of companies that’s not the case – testers don’t have the opportunity to give their input. And that’s why they aren’t satisfied. At Bornfight, we do things differently. Our QA team gets a lot of respect – our input and feedback are valued, appreciated and implemented into the projects we work on. And we see amazing results because of it because this input and feedback allows all of us to make every project better, and our work on every future project more efficient and streamlined.

I’m extremely pleased that we created a thriving culture of testing within Bornfight. And when new testers join our team, this is what really drives them. So yeah, that’s what we can all new members of our team – a unique culture that will enable their creativity to really shine. If software testing is something they really want to do, and they have the curiosity and passion for tech to back it up, Bornfight is where they’ll grow into amazing professionals.