This article will try to debate the controversial dilemma of hard and soft skills in the Software Testing field. I’m sure that in any field/industry we may perform we encountered this dilemma at least once. So, which one do we think weighs more: hard or soft skills?

Software Testing – Basics

First of all, let’s take a short journey through the world of Software Testing and its categories.

Software Testing, quoting IBM’s definition: “Software testing is the process of evaluating and verifying that a software product or application does what it is supposed to do. The benefits of testing include preventing bugs, reducing development costs, and improving performance.” A very straightforward and comprehensive description, which I agree with.

Now that we know what software testing is, we also need to understand what lies under this “wide” umbrella and also the main components and capabilities that need to be covered by software testers. Not all types of software testing are performed by testers and this topic will be covered in the following sections.

At the macro-level we have two main categories:

• Black Box Testing – is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure and implementation details. Black Box Testing mainly focuses on the input and output of software applications and it is entirely based on software requirements and specifications.
• White Box Testing – is a software testing technique in which internal structure, design, and coding of software are tested to verify the flow of input-output and to improve the design and security. In white-box testing, code is visible to testers so it is also called Glass Box testing. Another important thing that we need to know about white-box testing is that it is mostly performed by Software Engineers (aka developers or programmers).

Since White Box Testing is mostly performed by developers, let’s stick to the Black Box testing. And here we also have two main categories:

• Functional testing or “what does the system do?” – verifies that each **function **of the software application operates in conformance with the requirement specification. This involves checking user interface, APIs, database, security, client/server applications, etc;
• Non-functional testing or “how the system works?” – verifies the non-functional metrics of an application/system such as performance, usability, reliability.

Both main categories can be performed in two ways: manually and automatically.

How does manual testing work? Manual testing represents the tester’s interaction with the application as an end-user, comparing the expected and the actual behavior and whether the behavior meets the requirements. Manual testing can cover all functional and non-functional types of testing.

How does automated testing work? In automated testing, testers write code/test scripts to automate test execution. Testers use appropriate automation tools to develop test scripts and validate the software. Automated testing can cover only partially the functional and even less the non-functional part. The most common testing types covered by automated testing are UI functional testing, Performance, Integration, and API testing.

Which team are you – hard or soft?

For Automated testing, programming skills are necessary because you will have to write a script in order to “simulate” interaction with the system. Here are a few examples of “nice to have” skills when we talk about automated testing:

• SQL
• HTML + CSS (elements & selectors)
• API & HTTP requests
• Working with command-line terminals
• Programming languages (Java, JavaScript, C#, Python… etc)
• DevOps
• Agile methodology

In addition to this, the skills mentioned above are not a “must” for manual testing, but always a “nice to have” mostly at a basic level.

Although we know the importance of technical skills, surprisingly they represent only 50% of the “whole package” that makes a “good tester”. To complete the other 50%, well, we just need to be a little human and show a bit of these soft skills:

• Empathy (End User and Team)
• Patience
• Team player & very good communication skills
• Adaptability
• Eagerness to learn
• Critical & analytical thinking
• An explorer spirit

We may think that in order to fully understand how a software application/system works or how to test it, we need to learn “how to code”. But most of the time we do not have access to the code and perform “black box” testing (no access to the code/implementation) so programming skills will not be very helpful.

Look at the bigger picture

Circling back to the key question, based on what we learned so far, not all types of testing require a set of “hard technical” skills, at least not the non-functional ones which check how the system works. So in order to verify if a system is performing well or not, if it’s user-friendly, there is no need to write a script or to read one. It only needs a very important soft skill which is “care” or end-user empathy. Didn’t expect that, right?

In these difficult times when every “offline” business is forced to move “online”, when our face-to-face interactions are increasingly rare, we need to pay attention to details even more. Let’s not forget about people with special needs that have visual, hearing, mobility, or cognitive impairments who are “forced” to use systems and apps that are not suited for their needs. These needs are usually covered in accessibility testing.

This is only a small part of the non-functional testing universe. Another important part is the User Experience, especially if you have an E-commerce application. The user journey needs to be very smooth, fluid, compatible with multiple devices, browsers, and at the same time, very intuitive even for elders, otherwise, your potential customer can be lost in just a second.

Considering the context and these new perspectives, have you ever tried to actually see the bigger picture? We are not just stakeholders, POs, PMs, developers, or testers on a project. We are facilitators for those on the other side of the screen. And yes, it is also our job to think and work with empathy, even if this is not written down in our job description.

Is writing code enough to be good?

To sum up a bit, labeling a tester as being “good” only if he/she can write code is debatable. It depends very much on the nature of the projects, the experience with different tools, and technologies from various industries.

But what we can say is that a good tester can adapt to every encountered challenge, and brings complementary support to the team, and colleagues. Also, a good tester shows empathy to the End-User as well as to all of the team members, because after all the tester is not a stand-alone position. Without the team effort, we wouldn’t be able to validate any quality parameters.

Therefore, do we have the answer to the key question: “does a good tester write code”? Not quite. Writing code is not a mandatory asset to label a tester as being “good”, nor is it enough. There are several other attributes or skills that can make you a “better and better” tester: continuous learning and improvement, and most important – finding the right spot where your abilities and skills are valued and fit the organization’s needs.

Don’t forget to follow our blog for more articles on interesting subjects.