Testing – Conceptual Foundations

^{By way of introduction. We often use the word "tester" here as a term for the person who tests, although we know that testing and its planning can be carried out by various people. Sometimes for the purposes of this article we also use mental shortcuts and simplify descriptions. The topic is of course complex, and exceptions to the examples we give can certainly be found 😉}

‍

Competencies and experience

‍

What competencies and experience would be welcome in a testing team and/or in a person responsible for testing? Of course, depending on the role and management methodology in which they work, in our view these include:

-  planning skills (sometimes the tester plans the tests, sometimes the test lead or project manager)

-  ability to adapt the scope and types of tests that need to be and/or are worth performing — based on the goal defined by the Client and the functional and non-functional requirements defined by analysts,

- writing Use Cases based on boundary conditions — so that the testing process itself is efficient and does not strain the project budget excessively, while ensuring that the goal set by the Client is met.

‍

‍

‍

Planning, execution, and analysis

‍

Planning is really the key element of the entire software development process. Properly placing emphasis in specific areas of project execution guarantees achieving goals on time and within a defined budget. What does planning look like within testing itself?

1)  Requirements analysis and design

- requirements analysis — analyzing the specifications and requirements of the software to understand how it should work (if the tester is part of the development team, they are relatively up to date),

- test design — based on requirements and agreements, testers or those responsible design a set of test cases covering boundary conditions, various scenarios, and combinations of input data.

2)  Test execution. The tester/QA/designated person executes the designed test cases.

3)  Results analysis and possible retesting

- testers give feedback to the team about bugs found (i.e., broadly speaking, functionalities inconsistent with requirements). Testers can also assess the bugs, which can help the development team fix them faster and make further decisions about conducting retests (i.e., re-testing to check whether the bugs have been fixed).

Ok, we have the entire process planned. Thanks to in-depth work at the requirements analysis and design stage, as well as at the retesting stage, the person executing the tests will be able to decide which tests to use at a given project stage. And there is plenty to choose from 😉 Time to refer to experience and test typology.

‍

Types and kinds of tests

We can tentatively divide tests:

-  by method of execution: manual tests, automated tests, a combination of both,

-  in terms of the goal of selecting appropriate testing methods (types according to ISTQB): functional testing, testing of non-functional quality characteristics such as performance or reliability, testing the structure or architecture of the software or system, or testing related to changes — e.g., confirming that a defect has been fixed (confirmation tests) and looking for undesirable effects of changes (regression tests).

*It is unquestionably necessary to add an asterisk here, as the classification of tests is really very broad and the above does not exhaust the topic — however, for the purposes of this article we focus only on these two levels.

Manual and automated tests  

When it comes to the method of test execution, the matter seems simple. Tests can be performed manually — clicking through functionalities and checking systems — or by writing/using a test script for automated testing. The most common solution is a combination of both techniques. The advantages of manual testing are above all an intuitive approach, flexibility, and assessment of UX-related aspects. However, it is a time-consuming method prone to human error. It is difficult to imagine (though I'm not certain, given human creativity 😊) testing a multi-faceted application manually… First there's time, then money… Let us also recall — the fundamental assumption of testing is that it can reveal defects but cannot prove their absence.

‍

‍

There are types of tests that should be automated — such as unit tests (essential for implementing the CI/CD process) — but their goal is not to confirm that a functionality works; rather, the goal is to confirm that changes made to the code by a developer haven't broken already-working functionalities. The manual dimension allows for maintaining the vital interaction between the human and the software. In our view, manual testers can sleep soundly — they are and will be needed.

Many companies therefore opt for a combination of manual and automated testing. Automating tests can speed up the entire process.

We've considered how to test — now let's answer the question of what the tests should deliver, i.e., what their goal should be.

Structuring our knowledge will be helped by the division into types of testing.

Types of tests:

1) Functional testing: 

Black-box testing — involves testing the functionality of the system without knowledge of the internal structure of the code. Our analysis therefore stops at the interfaces available to the software.

2) Non-functional testing, e.g.:

• Performance testing — involves testing the performance of the system in terms of response time, load, scalability, and resource consumption.
• Reliability testing — involves testing the system for resistance to failures, data loss, and the ability to recover quickly.

3) Security testing — within this testing, an assessment is made of the system's vulnerability to threats. During testing, one can check whether it is possible to copy the application or data without authorization, or whether there is unauthorized access to the system.

4) Structural testing (white-box) — can be performed at all testing levels. Structural techniques are used to support measurements of testing precision by assessing the coverage of a given type of structure.

5) Regression testing — aims to check that introducing changes to the software has not caused regression — i.e., has not introduced bugs in previously tested functionality.

6) Integration testing — aims to check that individual software components cooperate with each other correctly when integrated into a larger whole.

7) Acceptance or acceptance/reception testing— can also be performed by the client. Acceptance testing is conducted to assess whether the software meets the client's requirements and is ready to be accepted by end users.

8) Others — depending on: the narrative, the testing school, experience, the tester's imagination, QA 🙂

Let's test

So — shall we test something together? 😎

An apple sales application. Why not — the season is just around the corner 😁 Unfortunately we don't have such an application in our portfolio, but if any orchard owner is reading this — feel free to get in touch 🙂

‍

Application details:
🍎 an apple sales application (available both on web and mobile)
🍏 users: buyers and sellers (people running fruit sales, orchard owners, buying stations)

‍

The basic functionalities and systems that should be ready at this initial project stage are:
✔ site registration (first name, last name, email address)
✔ login and logout
✔ activation link verification

The application will be further improved, but at this stage we need to check this section — focused, as you can see, mainly on UX/UI areas. What would you test?

Let's start with functional tests and check whether:
✔ the form field accepts numbers and letters and whether the regex used works. In the first name and last name field we should only be able to enter letters (upper and lower case); in the email field, letters and digits. We'll also check whether the application accepts an email without a dot and @.
✔ we can successfully register, log in, and log out on the site
✔ we receive an activation link, whether it redirects us to the application page, and whether identity confirmation is possible

We would then perform basic security tests (the application will process data, so we need to be sure it doesn't leak anywhere). We check, for example:
✔ whether the application uses security headers such as:
Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection,
mechanisms that hinder brute-force attacks.

✔ When testing login forms, we pay attention to how the application behaves after incorrect data is entered multiple times. A well-designed application will not allow a mass attack aimed at guessing the password.

‍

‍

As you can see from the apple sales application example, there are many types of tests, but we don't use all of them at once.

Summary

The topic of testing and being a tester or QA is truly complex. We tried to outline the basic aspects of this work and field for you. Much of the work of those responsible for testing involves planning. Based on their suggestions and reports, important changes can happen in the application; if detected later, they could cause significant losses for the team and the client. The tester must want to understand the aspects of the client's products that are important to them. It would be good if such a person tried to stay up to date and follow trends in the world of testing and QA.

We are aware that testing can be like an iceberg 😉 At first glance you only see a fragment of it, and only when you dive in do you see the enormity of the assumptions and guidelines. But we won't let ourselves be sunk 😁 In subsequent articles, we will look at specific types of tests, their use, and further analysis of the specifics of software testing.

So be sure to follow our blog 😉

‍

‍