Colombia

Bogota Headquarters

93rd Street #16-46, Office 404, Zenn Office PH Building
Medellin
Cra 43rd No. 7-50, Office 1102 - Dann Carlton Business Center
Cali
Cra 100B #11A -19 Office 516 Pance Tower

Espain

Madrid

Calle Conde de peñalver, 45, entre planta oficina 2, 28006, Madrid

USA

Miami-Florida

1000 Brickell Av, PMB 5137

Mexico

Mexico DF

Av. Rio Misisipi 49 Int. 1402, Cuauhtémoc

Panama

City of Panama

Calle 50, edificio, torre BMW, San Francisco

Understanding the software testing process: an ISTQB approach

Discover how the software testing process, based on the ISTQB approach, transforms requirements into results, ensuring that every line of code meets expectations.

pruebas de software istqb

See more articles

What holds AI back in Latin America is neither cost nor access

On October 6, the World Bank. On October 20, ECLAC and Chile’s National Center for AI. Two distinct assessments reached the exact same conclusion: the bottleneck lies not in the tool itself, but in the organizational capacity to absorb it. An academic concept originating in 1990 brings order to what today’s numbers describe.

Mexico claims to have saved 14 billion pesos by building its own software. The other half of the bill is missing

Organizations currently celebrating what they avoided spending will, in a year or two, have to account for what it costs to maintain what they built.

77% of large enterprises trust that they know all their AI agents. Only 44% have a way to prove it

The challenge is not merely implementing AI agents. It is knowing precisely which ones are running, who bears accountability for them, how their outputs are validated, and how swiftly they can be shut down when something fails.

We Warned You in Our Webinar, and Bre-B Confirmed It

There is no way to guarantee that a participant in an interoperable payment ecosystem will never fail again; that exceeds what any single institution can control.

Autonomous AI Agents Making Purchases: Who Is Liable When They Fail?

Applying agentic AI to payments requires the exact same level of rigor as any system handling third-party funds—extended to a type of actor that did not exist two years ago: one that decides and executes, rather than merely recommends.

680 customers exposed without a single line of code being breached

The same neobank that just received its full banking license in Colombia confirmed, three days earlier, a data breach that didn’t involve a single hacked server.

The ISTQB Foundation Level book provides a comprehensive view of the software testing process, addressing how it is set up and adapted to different development lifecycle models. In this article, we will understand the context and various activities that make up this process, which help identify what needs to be done at each step. Understanding these fundamentals is essential for any professional aiming to ensure software quality.

Context of the testing process

There is no universal software testing process applicable to all situations. Instead, the testing process adapts depending on various contextual factors, including:

Lifecycle Models and Project Methodologies The choice of software lifecycle (e.g., Agile, Waterfall, DevOps) influences the approach and structure of the testing process.
Testing Levels and Types The combination of test unit, integration, system, and acceptance testing defines how testing activities are organized.
Product and Project Risks Risks associated with software and projects impact the planning and focus of testing.
Business Domain Industry-specific requirements may dictate certain testing needs and regulations.
Operational Constraints Factors like budgets, timelines, and complexity affect how testing is conducted.
Organizational Policies and Practices Internal and external standards influence the methodologies and testing standards applied.
Testing activities and tasks

The testing process is organized into several groups of activities, each with specific tasks. These activities are often implemented iteratively, especially in Agile methodologies, although they can be organized sequentially in more traditional approaches.

Here is a summary of the testing activities presented in Chapter 1 of the ISTQB Foundation Level:

Test planning

This defines the objectives and scope or focus for achieving these objectives, considering contextual constraints. It includes specifying testing techniques, formulating a testing schedule, and preparing for design and execution. Test plans are adjusted based on feedback obtained during monitoring and control.

Test monitoring and control

Monitoring compares actual progress against the test plan using defined metrics, while control involves taking actions to adjust the testing process as needed. Exit criteria are evaluated to determine if testing objectives have been met or if further testing is required. Progress is communicated through test reports.

Test analysis

During analysis, the test basis (documentation) is reviewed to identify what needs to be tested and define test conditions. This analysis covers requirement specifications, design information, implementation, and risk analysis. Defects such as ambiguities and inconsistencies are identified, and test conditions are defined based on the test basis analysis.

Test design

Test design transforms test conditions into test cases and sets of test cases. It includes designing and prioritizing test cases, identifying necessary data, designing the test environment, and capturing traceability between the test basis, test conditions, and test cases.

Test implementation

Test implementation involves creating and preparing test products for execution. This includes developing test procedures or scripts (defined structure), organizing test sets, validating the test environment, and preparing the necessary data.

Test execution

During execution, test cases are executed as per the established schedule. This includes recording test item versions, executing manual or automated tests, comparing results, and analyzing defects. Defects are reported, and test results are recorded.

Test completion

Completion involves collecting data from testing activities to consolidate experience and test products. Defect reports are reviewed, test products (documents created at each phase) are stored and handed over to other teams, and lessons learned are analyzed to improve future projects.

In conclusion, Chapter 1 of ISTQB provides a solid foundation for understanding the software testing process, highlighting its importance in the quality of tests performed. By addressing key testing activities, this article emphasizes how a well-defined structure can be tailored to the specific needs of each project, adopting a comprehensive approach to testing activities. This not only improves efficiency but also contributes to the delivery of more robust and reliable software products.

 

To explore more about this article, I invite you to visit the following link where you can learn about each testing activity in detail according to ISTQB through a video: (https://www.youtube.com/watch?v=6_ZIVBV7yhg) 

Press enter or click outside to cancel.

Puedes configurar tu navegador para aceptar o rechazar cookies en cualquier momento. Si decides bloquear las cookies de Google Analytics, la recopilación de datos de navegación se verá limitada. Más información.