Digital Transformation
Organizational culture
Who or what do you trust? Think about your relationship with people or products and tell us: do you trust someone or something you have no experience with? Speaking more specifically about products: do you trust them before performing basic tests? Put another way: would you buy a car if, when you turned the key or pressed the button, it didn't start?
As obvious as the above questions may sound, they lead us to an obvious conclusion: we trust a product, service, or even a brand only after they have been tested to some extent.
In general, trust is directly linked to whether our expectations are met. We’ve already discussed here on the blog how valuable automation is. Thanks to automation, we can make something happen in the future that we could previously only imagine. If we imagine the same thing about a product or service—if we assume it will work as we expect—then our expectations are met. Consequently, we’ll believe that it’s of high quality.
This is precisely why testing is the primary tool for Quality Engineering in the software industry. Thanks to testing, we can trust a system and feel confident in using it.
Broadly speaking, we can divide testing into two main categories. The first is “who” performs the tests: a human or a robot. Manual tests are performed by people, usually a QA analyst—short for “quality assurance” —while robots perform automated tests.
In the second type, “what” is tested: the parts and the relationships between them. In unit tests, we verify the functionality of parts of the system—often very small parts—while in integration tests, we combine several blocks of the application and test them as a group.
To help you navigate this world of knowledge, we’ve compiled on this page the content produced by Inmetrics on this topic. From here, you’ll be able to explore the history of testing, learn more about test manuals, experience-based tests, unit tests, and a well-known methodology for conducting them: test-driven development.
It may be hard to believe, but there was a time when people didn't test software to see if it worked—they just waited for it to fail.
This situation began to change in the 1950s, when testing and debugging came to be viewed as distinct activities. And in 1979, with the publication of *The Art of Software Testing*, the landscape of the field changed, gaining the prominence it holds today.
The book proposes a new, holistic way to verify whether the program is working and meeting the requirements. Instead of testing and confirming what worked, the goal of the activity became to run the system with the intention of finding errors, testing all the scenarios that could lead to an error.
Learn a little more about the history of testing in the software industry by clicking here!
Manual testing refers to tests performed by people, typically a QA analyst or quality analyst. Since these tests are conducted by individuals, many manual tests require the use of skills and abilities that are distinctly human: sensory abilities.
Most of our interactions with applications are limited to screens, and we use our sense of sight and touch to carry them out—whether to control a mouse, keyboard, or touchscreen. However, some applications emit sound or vibrate… Much of our sensory perception is engaged during manual testing.
In the age of artificial intelligence, QA analysts have been focusing on running those manual tests in which human cognition or creativity adds value and speeds up the process: exploratory tests or those centered on the user experience.
Click here to learn a little more about both the history of manual testing and its role in the age of artificial intelligence agents!
The whole exists only because there are parts that relate to one another. When we apply this line of thinking to applications, we see them as a set of screens containing buttons that perform functions, which in turn activate other functions… We can break down the entire application into very small parts, and to inspect them, we perform unit tests.
The main feature that distinguishes integrated tests from unit tests is their level of granularity. Unit tests are performed on isolated features, without any connection to other parts of the system, services, or external agents.
Of course, unit tests run faster and are easier to perform. However, despite their practicality, they are of enormous importance: it is through them that we detect bugs early on and, as a result, create a “safety net,” preventing errors from propagating to the upper layers of the applications.
Learn more about how unit tests are defined and how they improve efficiency in development projects!
In the software industry, we strive for a very valuable attribute: “enjoyable to use.” To achieve this, we conduct user experience tests to determine what “feeling” the system conveys when we use it.
As we discussed in this text, we can divide testing into two broad categories: the actors who perform the tests and “what” is being tested. However, beyond these categories, we can classify tests from different perspectives. For example, we can group usability, accessibility, and user experience testing under the umbrella of user-centered quality testing.
This observation is important because perhaps the easiest way to define experience tests is by distinguishing them from usability tests. While usability tests focus on interfaces—layout, clarity of information, navigation flow, and user behavior on the screen—and seek to assess how easy an application is to use, experience tests go beyond that. The goal is to examine how users “feel” about applications—what sensations and emotions are triggered by the interfaces.
Experience-based testing has become increasingly important in light of the exponential growth in activities being transferred to software. To learn more about them, click here!
Testing something before it even exists: it seems impossible, but, conceptually speaking, that is exactly what the test-driven development approach advocates.
To ensure that software is frequently updated, quality practices are applied from the conceptual phase through to the production environment. Systems undergo continuous and extensive validation at every stage, with each of their small components being developed in a compliant manner. This is only possible thanks to the test-driven development approach, a method for running unit and automated tests.
Developed by Kent Back at the turn of the 21st century, the approach that became known worldwide by the acronym TDD—which stands for Test-Driven Development —is one of the most widely used in the industry to increase system reliability at all stages of production, thereby reducing the amount of testing required during the launch phase.
Learn more about the test-driven development approach by reading the article here!
