Software testing basics: why theory doesn’t always align with practice

About the author: Natallia Brych is a QA Manager with more than ten years of hands-on professional experience. Her list of clients includes large banks, government agencies, and global enterprises. At ObjectStyle, Natallia leads the QA department, mentors young talent, manages projects, and shares her honest opinion on all things QA in the form of occasional blog posts.

There are a couple of reasons why I decided to write this post about testing basics among thousands of existing ones. First of all, I strongly believe that definitions help to avoid misunderstanding, and this article is an attempt to share our QA vision with potential customers and team members. The second reason is to discuss this with you or maybe even collect some statistics if you’re interested, too.

This article is not a scientific paper and its goal is to explain what we mean by the terms mentioned on our QA page. I don’t split testing into test types/levels/approaches/… here deliberately.

Before talking about testing types let’s define what testing is. First of all, testing is a process. Let’s draw parallels between these terms:

As any process, testing could be one-time, recurrent or periodic. It depends on testing goals and resources – people and budget.

Now let’s look through our Quality Assurance page and check what’s mentioned on it.

Prototype testing

A set of activities for customers who care about their spendings. It’s not a secret that testing during early development stages helps to reduce bug fixing cost 6x.

How to perform:
– Read
– Analyze and compare
– Draw and count
– Find ambiguities and contradictions in a prototype
– Find ambiguities and contradictions in integration of the prototype to the system

The output:

A list of ambiguities and contradictions. Saved money because developers’ time.

Test Design

It is well known that a task takes all the assigned time. So the only chance to avoid poking aimlessly around an application is test planning. What for, why, when, what, who and how are your best friends here.

Getting 1000 minor issues and no time to test major functionality means your team has problems with test design.

To “test everything” takes a whole life. And I have a strong feeling that you’d like to deliver your project to end users earlier.

The output:

Transparent testing process. Testing level is agreed upon by and clear to all stakeholders.

Application testing

In all agreed environments, from the most important to the least as quickly and carefully as possible.

The output:

Bug reports, readable and useful.

Not one major issue after release.

Version control

Just to be sure that tested code will be delivered.

Which branch do you use for testing? Which branch will be used for production release? How can you ensure that nobody changes anything without skipping testing?

Maintenance and support

We know how to transform “nothing works” into detailed bug reports with logs, screenshots and queries, and offer several workarounds for customers to save time for developers for bug fixing. What about you?

Testing Types

Web application testing

It is important to ensure that your software works as expected for online users across browsers (Chrome, Safari, Firefox, Opera, Edge,…) and verify that the app’s speed and performance meet predefined requirements

We’re checking browser and server logs here, writing and running sql queries.
We deploy using CI/CD and check all the deployment logs carefully.

Desktop application testing

We install the app on machines with different operating systems (Windows, Linux, Mac OS X) and ensure that it works according to the expected result and performs well on system versions that matter to you and your customers.

We also check usability and registration, installation and update processes.

Mobile testing

We use emulators and real devices, checking if the design is indeed responsive, and look at system logs. Storage, network, computation, handling user messages, etc.

Automated testing

In automated testing, the tester writes a script that performs a test case autonomously – as opposed to a human doing it by hand. Since supporting automated tests takes time and resources, it only makes sense to do it when it leads to optimizing development costs. Testing frameworks, nice reports, CI/CD integration – we do it all.

Usability testing

We do this for web, desktop and mobile applications.

The goal of usability testing is to ensure that your application’s UI is intuitive and easy-to-navigate. We go through your software’s interface, report any redundant steps and problematic areas that we encounter, and make suggestions as to how the user experience can be improved.

Localization Testing

Applicable for web, desktop and mobile applications.

When an app is available in multiple languages, it is essential to check that all local interfaces are translated in full. Also, remember to make sure that the user can interact with the program in their language (e.g., that they can use Simplified Chinese characters in the Chinese version of the program).

Security Testing

Applicable for web, desktop and mobile applications.

Nothing is more damaging to your reputation than an unexpected data breach. During security testing, the QA assesses how well-protected your software is against unauthorized access. They also make sure that your online transactions are completely secure.

API Testing

In today’s world of APIs, it’s important to have QA professionals who can test your API(s). API testing consists in ensuring that (A) your API returns correct data and (B) works as intended.

We already have an automation approach for this.

Requirements Testing

Unclear, ambiguous requirements may inflate development costs. For example, how exactly should a requirement like this be fulfilled, “Notify user of successful password change”? Did the person who wrote this requirement mean a popup message, an email, or anything else?

Testing helps prevent such discrepancies by finding inconsistencies in your requirements.

As a conclusion, I’d like to say that questions about testing types are relevant at an interview to make the interviewee feel more confident, especially if they are new to the profession, because the majority of testing courses drill testing types and other theoretical concepts into the beginners’ heads. I like to pose questions about testing types, levels, etc. to advanced professionals, too, when I want to know what they think about these things and how they can support their point of view. It’s a QA professional’s responsibility to explain their position about the expected result, a testing approach and so on to other team members and stakeholders.

There are plenty of approaches to testing type definitions, and you can use whichever you like on your team, if all team members and stakeholders agree on them.

So what do you think about this? Do you use testing theory in your professional life? Let’s discuss it in the comments down below 😉

Looking for a reliable partner to take care of application testing?Hire our testers