Discover Cloud Solutions with HostingerGet a special discount.

hostingerLearn More
Published on

Getting Started in Testing: Basic Concepts

Authors
  • avatar
    Name
    Esneyddis Guerrero
    Twitter

Overview

Do you want to become a Tester and don't know how to start... Well then, this article is for you !!!

Sometimes and due to the amount of information we have on the internet regarding testing, it is difficult to find all the documentation we need, in this article we will walk together the paths of testing where I will show you the basic knowledge that you must dominate, to start your career as a tester ... without further ado let's start ...

When I am asked What is testing? What does a QA do? sometimes I keep thinking and the truth is I don't know where to start, because as a QA we perform several tasks, because when we test we are evaluating the software in question, to ensure that it meets the defined requirements and also that it works properly, making testing one of the most important activities in the software development cycle.

Is the tester the only one who must watch over the quality of the software? No, this is team work, where at each stage we must support each other because in the end, we are all responsible for ensuring quality.

As QAs, we carry out different activities along the testing process where we cover planning, control, analysis, design, implementation, execution and completion ISTQB. In each of these activities we generate different types of documentation, which helps us to achieve a better organization and traceability of the tests performed.

Test levels

In the testing process, testing is performed at different levels to ensure the quality of the software. These levels are as follows

Unit tests

Unit or component tests where in most cases (not to generalize) are carried out by the application developer, this test is focused on testing individual units or components of the software, to verify that they work correctly in isolation, here the responsibility is the developer to implement as many unit tests as possible.

Example:

In a web application, a unit test could be to verify that the user registration function works correctly when adding a new user to the database.

Integration tests, which we have

  • Component integration tests performed mostly by developers, i.e., in the unit test the component was tested independently, and in this test we are going to integrate them to verify their behavior.
  • System integration tests: Which are performed by testers and where it is verified that the integration works correctly, here the focus would be to evaluate the interaction and interface between systems, subsystems, packages and microservices and also interaction with external systems.

Example:

In an e-commerce application, an integration test might be to verify that the checkout process works correctly when adding a product to the cart and completing the purchase.

System tests

  • System testing focuses on testing the software as a whole to verify that it meets the specified requirements, for this test we evaluate the complete system taking into account all the tasks that the system can perform and its correct operation.

Example:

In an email application, a system test could be to verify that you can send, receive and delete emails correctly.

Acceptance tests

  • Acceptance tests these tests are usually performed by real or representative users of the end user together with the tester, they are performed to validate that the software meets the requirements of the end user, in these tests one of its main objectives is to establish confidence in the quality of the complete system ISTQB.

Example:

In a mobile application, an acceptance test could be to verify that the user interface is intuitive and easy to use for the end user.

Practical example:

Suppose you are working on a task management application, and you have to perform tests at different levels. In unit tests, we verify that each function of the application, such as adding a task or marking a task as completed, works correctly in isolation. In integration tests, we verify that when adding a task it is correctly displayed in the task list. In system testing, we verify that the application can handle a large number of tasks without errors. And finally, in acceptance testing, an end user would test the application to make sure that it is easy to use and meets their needs.

Types of testing and testing techniques

For each of the test levels mentioned above, different types of tests can be performed, within which we have functional, non-functional, white box and associated to change tests to which we will be dedicating a separate section ISTQB. Each of these tests has its specific focus and purpose.

To support the execution of these tests, different input documents or work products are used, which allow us to have a better understanding of what we are going to test, such as requirements, user stories, design, and code. In addition to this, different testing techniques are also used, which allow us to achieve a better organization in the definition of the scenarios that will be tested, taking into account input and output conditions and possible combinations, and this is what we call test case design.

For example, the white box technique examines the internal structure and logic of the software, while the black box technique focuses on the external behavior of the system (used in system testing, system integration testing and acceptance testing), both techniques (white box and black box) can be combined to cover in greater depth what we want to test, and the experience-based technique where based on the experience of similar tests performed by the developer or tester the necessary test cases are implemented.

Bug reporting and its importance

When we execute the test cases, and the expected result does not correspond with the actual one, we identify a bug or defect in the software, which must be reported and fixed by the developer, to report it, we must provide detailed information such as a unique identifier, a descriptive title, steps to reproduce it, expected and actual result, evidence of the error, test environment and its priority, helping the developer and the whole team to understand clearly and concisely what was the defect found and how it can be reproduced, in other sessions we will see the life cycle of a bug and the different states it can go through after being discovered.

Conclusions

So, what do we do as Qas? Well, we take care that the quality testing process is carried out correctly, with the goal of having, as a final product, a fully functional software or system, with the least amount of error possible and that meets the requirements specified by the customer.