Ep1 | ¿Qué es probar? Fundamentos de ISTQB en español #CTFL #Probar #QA #ISTQB

Summary

El guion del video ofrece una visión detallada de las bases del testing de software, explicando su importancia, limitaciones y propósito. Se desentraña los mitos sobre las pruebas, destacando que no solo consisten en encontrar errores, sino que también implican verificar y validar que el software cumple con las expectativas del usuario. Se utiliza el ejemplo de un examen de conducir para ilustrar el proceso de testing, enfatizando la planificación, ejecución y evaluación de las pruebas. Además, se aclaran las diferencias entre 'verificar' y 'validar', y se resalta la necesidad de mejorar los procesos de desarrollo a través del análisis de la causa raíz de los defectos encontrados.

Takeaways

• 🔍 La prueba de software va más allá de simplemente encontrar errores; es un proceso completo que incluye planificación, ejecución y evaluación.
• 🛠️ La importancia de la prueba de software radica en asegurar la calidad del producto, reducir el riesgo de fallos y aumentar la confianza del cliente en la marca.
• 🚗 Se compara la prueba de software con la obtención de una licencia de conducir, donde se evalúan diferentes situaciones y se establecen criterios de aprobación.
• 📋 La prueba de software incluye tanto pruebas dinámicas (ejecución del software) como pruebas estáticas (revisión de documentos y código fuente).
• ⏱️ La planificación de las pruebas es crucial; implica definir qué se va a probar y cómo, considerando los tiempos limitados.
• 🔍📚 La revisión de documentos y requisitos es parte integral de las pruebas estáticas y es necesaria para garantizar que se estén cumpliendo las expectativas del cliente.
• 🔄 La diferencia entre 'verificar' y 'validar' es fundamental en pruebas de software: verificar se refiere a construir el software según los requisitos, mientras que validar es asegurar que el software satisface las necesidades del cliente.
• 🛑 Es común subestimar la importancia de las pruebas estáticas; sin embargo, son esenciales para detectar defectos temprano en el ciclo de vida del software.
• 🔎 La prueba de software no solo es encontrar errores, sino también comprender los riesgos asociados con el uso operativo del software y mejorar los procesos de desarrollo.
• 📈 El proceso de pruebas incluye la gestión de pruebas, selección de condiciones de prueba, diseño de casos de prueba y evaluación de resultados.
• 👥 La comunicación y colaboración entre los testers y otros miembros del equipo de desarrollo son fundamentales para el éxito de la prueba de software.

Q & A

¿Qué es la prueba de software y por qué es necesaria?

La prueba de software es una forma de 'asegurar la calidad' del producto y 'reduir el riesgo' de fallos durante su operación, lo que aumenta la confianza del cliente en el producto y, por ende, en la marca.

¿Cuál es la diferencia entre 'Verificar' y 'Validar' en el contexto de la prueba de software?

La 'Verificación' se refiere a si el software está bien hecho según los requisitos, mientras que la 'Validación' verifica si el software construido atiende a las expectativas del cliente y resuelve sus necesidades.

¿Qué es un 'test case' y cómo se relaciona con la prueba de un conductor de auto?

'Test case' son una serie de rutas o situaciones diseñadas para evaluar las habilidades del candidato, similar a las rutas que un examinador prepara para evaluar las habilidades de conducción de un candidato en una prueba de licencia de manejo.

¿Qué es un 'Test Results Report' y por qué es importante?

'Test Results Report' es un documento que registra los resultados de la prueba, especificando el número de aciertos y errores, así como su gravedad. Es importante porque permite tomar decisiones basadas en riesgos acerca de si el conductor aprueba o no la prueba.

¿Por qué la prueba de software no solo consiste en ejecutar el software y verificar los resultados?

La prueba de software incluye muchas actividades diferentes, como el análisis de resultados, la planificación de la prueba, el diseño de actividades de evaluación, la implementación y ejecución de las pruebas, y la generación del informe de resultados.

¿Qué son las 'pruebas estáticas' y cómo se diferencian de las 'pruebas dinámicas'?

Las 'pruebas estáticas' implican la revisión de documentos y código fuente sin necesidad de ejecutar el código, mientras que las 'pruebas dinámicas' implican la ejecución del software para revisar los resultados.

¿Qué es una 'prueba de teoría' y cómo se relaciona con la prueba de software?

'Prueba de teoría' es similar a la revisión de documentos en pruebas de software, donde se verifica si el conductor conoce las leyes de tráfico y qué hacer en diferentes situaciones mientras conduce, lo que en pruebas de software se traduce en la revisión de requisitos o el código fuente.

¿Cuáles son algunos de los mitos comunes sobre la prueba de software que se desacreditan en el guion?

Entre los mitos desacreditados se encuentran que la prueba de software consiste solo en ejecutar el software y verificar resultados, y que las pruebas solo se centran en verificar si el software cumple con los requisitos de los usuarios, sin considerar si los requisitos en sí满足了 los expectativas del usuario.

¿Qué es el 'International Software Testing Qualifications Board' (ISTQB) y qué hace?

El ISTQB es un comité internacional que se encarga de dividir la definición de prueba de software en dos partes: el proceso y los objetivos, destacando las frases claves para recordar y estableciendo estándares en la certificación de prueba de software.

¿Cómo se puede mejorar el proceso de desarrollo de software a través de la detección de defectos?

Identificar defectos no solo ayuda a comprender los riesgos asociados con el uso operativo del software y a mejorar la calidad del producto, sino que también, a través del análisis de causa raíz, ayuda a mejorar los procesos de desarrollo y a cometer menos errores en el futuro.

¿Cuáles son las actividades que se deben realizar durante el proceso de prueba de software según el guion?

Las actividades incluyen planificar la prueba, analizar las rutas a seguir, diseñar actividades de evaluación, implementar y ejecutar las pruebas, generar el informe de resultados, seleccionar condiciones de prueba y diseñar casos de prueba, y evaluar el software bajo prueba y criterios de finalización.

Outlines

00:00

😀 Introducción a los fundamentos de la prueba de software

El primer párrafo presenta una introducción al concepto de prueba de software, enfatizando la importancia de la calidad y la confianza del cliente en un producto. Se discute que la prueba no es solo encontrar errores, sino también asegurar la calidad y reducir el riesgo de fallos. Se utiliza el ejemplo de la prueba de manejo para ilustrar cómo se realiza una prueba, incluyendo la preparación de casos de prueba, la evaluación de desempeño y los criterios de aprobación. Además, se menciona la importancia de la planificación y la diferencia entre pruebas dinámicas y estáticas.

05:03

🤔 Mitos y errores comunes en la prueba de software

Este párrafo aborda los mitos y errores comunes asociados con la prueba de software. Se destaca que la prueba no consiste únicamente en ejecutar el software y verificar resultados, sino que incluye una serie de actividades como la planificación, diseño de casos de prueba, ejecución y generación de informes. También se aclara que la prueba tiene como objetivo verificar y validar que el software cumpla con los requisitos y que estos requisitos satisfagan las expectativas del usuario. Se utiliza el ejemplo de la prueba de manejo para comparar con la prueba de software, destacando la importancia de las pruebas teóricas y prácticas.

10:05

🔍 La distinción entre 'Verificar' y 'Validar' en la prueba de software

El tercer párrafo se enfoca en aclarar la diferencia entre la verificación y la validación en el contexto de la prueba de software. La verificación implica asegurarse de que el software esté construido de acuerdo con los requisitos especificados, mientras que la validación verifica que el software cumpla con las expectativas del cliente y que los requisitos sean correctos. Se utiliza un ejemplo de un vehículo de 4 ruedas para ilustrar la diferencia entre estos dos conceptos y se enfatiza la importancia de distinguir entre ellos en la certificación de prueba de software.

15:10

🛠 Proceso y objetivos de la prueba de software

Este párrafo describe el proceso de prueba de software y sus objetivos generales. Se resalta que la prueba es un proceso que abarca todo el ciclo de vida del desarrollo de software y no una actividad aislada. Se discuten las actividades de planificación antes, durante y después de la ejecución de las pruebas, la selección de las pruebas a realizar, la verificación de resultados y la evaluación del software bajo prueba. Además, se mencionan los objetivos de la prueba, como la verificación y validación de la conformidad con los requisitos, la detección de defectos para comprender los riesgos y mejorar la calidad del producto, y el análisis de la causa raíz para mejorar los procesos de desarrollo.

20:12

📚 Resumen y recursos para el aprendizaje de la prueba de software

El último párrafo ofrece un resumen de los conceptos clave discutidos en el script y proporciona recursos adicionales para el aprendizaje. Se resumen los dos errores comunes sobre la prueba de software, la diferencia entre verificación y validación, y se explica brevemente la definición de la prueba de software. Se anima a los espectadores a participar en la discusión, a descargar los materiales de estudio mencionados y a suscribirse para recibir notificaciones sobre futuras publicaciones. Además, se invita a seguir al canal en LinkedIn para mantenerse actualizado con discusiones activas.

Keywords

💡Pruebas de software

Las pruebas de software son un conjunto de actividades diseñadas para asegurar la calidad del producto y reducir el riesgo de fallos durante su operación. En el video, se enfatiza que las pruebas no son solo encontrar errores, sino también verificar y validar que el software cumple con los requisitos y satisface las expectativas del usuario. Este concepto es central en todo el script, ya que es la base para entender la importancia y el alcance del testing en el desarrollo de software.

💡Q.A.

Q.A. es la abreviatura de 'Quality Assurance', que se traduce como 'Garantía de Calidad'. En el contexto del video, se menciona que el protagonista se promueve a Q.A., lo que implica un paso adelante en su carrera hacia una mayor responsabilidad en la aseguración de la calidad del software. La mención de Q.A. destaca la importancia de la calidad en el proceso de testing y cómo este rol es clave para mejorar los productos.

💡Errores

Los errores son fallas o defectos en el software que pueden causar que el programa no funcione como se espera. En el video, se discute cómo las pruebas de software son una forma de detectar estos errores y reducir el riesgo de fallos, lo que a su vez aumenta la confianza del cliente en el producto y en la marca. Los errores son un tema recurrente a lo largo del guion, ya que son el objetivo principal de las actividades de testing.

💡Requerimientos

Los requerimientos son especificaciones detalladas que describen lo que el software debe hacer y cómo debe comportarse. En el video, se destaca la importancia de verificar y validar los requerimientos, para asegurarse de que el software construido cumpla con lo que el cliente espera y necesita. Los requerimientos son fundamentales en el proceso de testing, ya que son la base para el diseño y la ejecución de las pruebas.

💡Verificación

La verificación es el proceso de asegurarse de que el software está construido de acuerdo con los requerimientos establecidos. En el video, se explica que la verificación implica 'construir el software bien hecho', es decir, que se ha seguido fielmente lo que se especificó en los documentos de requerimientos. La verificación es una parte crucial del proceso de testing, ya que garantiza que el producto construido cumpla con los estándares definidos.

💡Validación

La validación es el proceso de asegurarse de que el software construido cumple con las expectativas del cliente y resuelve sus necesidades. En el video, se aclara que la validación es diferente a la verificación y se enfoca en 'construir el software correcto'. La validación es esencial para garantizar que el software sea útil y efectivo para el usuario final, más allá de simplemente cumplir con los requerimientos técnicos.

💡Pruebas dinámicas

Las pruebas dinámicas son aquellas en las que se ejecuta el software para revisar los resultados. En el video, se menciona que estas pruebas son solo una parte del proceso de testing, y que incluyen la ejecución práctica del programa y la revisión de su funcionamiento en diferentes situaciones. Las pruebas dinámicas son importantes para evaluar directamente el rendimiento y la estabilidad del software.

💡Pruebas estáticas

Las pruebas estáticas implican revisar documentos y el código fuente sin necesidad de ejecutar el software. En el video, se describe cómo estas pruebas permiten encontrar defectos sin tener que correr el programa, lo que puede ser una forma más eficiente de detectar problemas temprano en el proceso de desarrollo. Las pruebas estáticas son una parte integral del testing que complementa las pruebas dinámicas.

💡Criterios de aprobación

Los criterios de aprobación son las reglas utilizadas para determinar si una prueba ha sido exitosa o no. En el video, se ilustra con el ejemplo de un examen de conducir, donde estos criterios pueden basarse en la cantidad y gravedad de las infracciones cometidas. En el contexto de las pruebas de software, estos criterios son fundamentales para evaluar si el software cumple con las expectativas y requisitos establecidos.

💡Pruebas de regresión

Las pruebas de regresión son un tipo de prueba que se realizan para verificar que los cambios realizados en el software no han afectado negativamente las funcionalidades existentes. Aunque en el video no se menciona directamente el término 'pruebas de regresión', es un concepto relevante en el testing de software y se relaciona con la validación continua del software a medida que se realizan mejoras y actualizaciones.

Highlights

Testing no solo es encontrar errores, sino también asegurar la calidad del producto y reducir el riesgo de fallos.

La importancia de la confianza del cliente en la marca y cómo la calidad afecta la percepción de seguridad.

La definición de testing según diferentes fuentes y su simplificación en el diccionario de Google y la Real Academia Española.

Un ejemplo práctico del testing de software comparado con un examen de conducir.

La importancia de los 'criterios de salida' o 'aprobación' en la evaluación del desempeño del conductor.

Los errores comunes sobre el testing de software y cómo el testing no es solo ejecutar el software y verificar resultados.

La diferencia entre 'verificar' y 'validar' en el contexto del testing de software.

El testing como proceso que incluye tanto pruebas dinámicas como estáticas.

La planificación del testing y su importancia en el ciclo de vida del desarrollo de software.

La necesidad de gestionar las actividades de testing antes y después de la ejecución de las pruebas.

El objetivo del testing de garantizar que el software cumpla con los requisitos y ser adecuado para su uso.

La identificación de defectos como un medio para entender los riesgos y mejorar los procesos de desarrollo.

La estructuración de los objetivos del testing y su relación con los diferentes niveles de pruebas.

Un resumen de 60 segundos que sintetiza los conceptos clave del testing de software.

El testing como proceso que va más allá de simplemente ejecutar pruebas y encontrar errores.

La importancia de la retroalimentación y discusión para el aprendizaje y la mejora en el campo del testing.

La oferta de material de estudio gratuito y la invitación a seguir el curso para niveles avanzados de ISTQB.

Transcripts

Chapter 1 - Episode 1: It is testing just finding errors?

Argg! Such a stress! When I get promote to Q.A., everything will be easier.

Overall, it is just testing that there are no errors.

Hehehehehe !! Really? Do you think testing is just finding bugs?

A surprise awaits you as you move to the dark side of the force!

What is Test?

Whenever we ask this question the answer seems simple enough,

and if you are a person who does not dedicate yourself to

being Tester / QA maybe seems enough,

but if we want to speak properly to demolish myths on the subject,

or simply exercise in the best way

possible this profession, we will need to go deeper.

So if the previous answer seemed appropriate, being that it is quite imprecise

to say the least then join me

during this first part that will serve as a starting point!

Hello everyone and welcome to this first episode!

Throughout Chapter 1 I'll talk about the fundamentals of testing,

why testing is necessary, its limitations, its purpose, the principles behind

of the tests, the process to be followed and the psychological factors that the testers

Testers should consider in their work.

What is testing?

We are constantly surrounded by electronic devices, from the Smart TV

going through lights that turn on by a voice command, the vehicle,

or just the cell phone.

All of these devices work thanks to the software designed for this purpose, and is

most likely most people have experienced problems

with a device that did not work as expected: a stuck elevator, the bank page

not loading, or washer stopped in the middle of a cycle.

These failures are never pleasant and in some cases the consequences are

significant enough to affect the credibility of a brand.

Many people buy equipment just because of the brand, because they are more confident that it will not fail, they are even available to pay more

just for the "security" they provide. For some it is not an option to switch to another brand, even if it offers the same quality in half

of money. Why? Because they have "Confidence" in the low probability of failure.

"Peace of mind" is not something negotiable for most people.

Testing Software is a way to "assure quality" of the product and "reduce the risk" of

fail when operating,

and with this increase the customer's confidence in the product, and consequently in the brand.

If we are looking for alternative sources of information to ISTQB,

we see some definition of tests quite simplified:

According to the Google dictionary Testing means:

"To put something or someone to the test"

According to the Royal Spanish Academy:

"Use a thing or put it to the test to verify its effectiveness, to know how it works or what result it produces"

"Test something" means to check that everything is OK, that it works as expected.

However, it is not a sufficiently detailed definition to

the concept of software testing. To explain it better I will use an example from life

real taken from Rex Black's book: Fundamentals of Software Testing.

In a test to obtain a driver's license, the examiner evaluate in detail

the exam candidate, noting every mistake made during the test by large or

small that is. The examiner must prepare in advance

a series of routes that we will call "test cases", where the candidate can face

the different "scenarios" a driver usually encounters,

for example:intersections with different difficulty levels, vehicle control,

attention to the road, threats on the road, etc.

You will have to try extreme situations such as simulating an emergency braking by hitting

the dashboard of the vehicle, having to stop quickly and safely

without losing control. At the end of the test, the driver is evaluated and it is determined if he passed

or it failed the test based on something we will call "exit criteria"

or "approval criteria". The results will be recorded in a document

which we will call "Test Results Report".

The "approval criteria" is based on the number and severity of the offenses committed,

and also if the driver was able to fulfill the test requests.

A single serious offense may mean that you failed the exam, however a small

number of minor fouls may still mean you passed. Besides this, many

Minor faults can "reduce the confidence" of the examiner in the candidate's ability

to drive, to the point where you will fail the test.

Let's review the important points about this case:

Before the test a series was planned of routes to cover the activities

key to evaluating the candidate, and this we call "test cases"

The candidate does not know the routes or the activities to be carried out.

The test must assess whether the candidate is confident enough to drive a

vehicle without being damaged or damaging other people or property. I mean, there is a clear

pass or fail criteria, based on in the number and severity of the offenses

committed, the examiner's confidence in the conductor it is also taken into account.

The test is designed to "demonstrate that the driver meets the requirements

established "and that you can indeed drive a vehicle.

The test is done in a set period of time, it is not an evaluation

complete driver skills, it is a representation that allows

make a decision based on risk about the driver.

All candidates to obtain the license driving are evaluated objectively,

Whoever passes the test gets a driver's license, and whoever fails will get a "results report"

with the list of successes, failures and aspects to improve before taking the test again

if necessary.

In addition to the practical test, the driver must take a "theory test to verify

who knows the traffic laws "and what to do in various situations while driving.

That is, the driver reviewed a set of documents that allow you to acquire

knowledge about the challenges to overcome during the test.

We could call these documents "test bases", since they establish

the bases to consider to pass the test.

Did you ever consider the job of a examiner from this perspective?

Well, the tester's job software looks quite similar,

adding a certain level of complexity, although sometimes it is trivialized.

Let's look at some beliefs that are often repeated:

Common mistakes about Software Testing

Among the wrong beliefs about Software Testing we have to:

1. Software testing only consists of in running the software and checking results.

This is a common mistake. Run tests software includes many different

activities. The results review it's just one of those activities.

When you are going to take the exam for the driver's license, the examiner does not

just sit back and wait for you to take control of the vehicle, start the car

and take the road, but the test consists in a series of activities to assess

driver skills, before, during and after starting the vehicle.

In the same way that the test drive is divided into two: a practical assessment and

other theoretical, software testing can be divided into two types:One part involves

run the software to review results, these are called "dynamic tests".

On the other hand, the document review requirements or source code,

they are called "static tests". We will learn this in detail in Chapters 3 and 4.

Recap of the process for a objective assessment of driver quality,

we can conclude that the following activities:

Planning the test: Remember that time is limited, you must plan

activities that test skills at a specific time. Not planning implies

that key points may remain without evaluating, because time is up.

Additionally, the techniques to be used,

as the Theoretical and Practical component that have been mentioned.

The analysis of the routes to follow so that fit the goal

The design of the activities that will allow evaluating the skills of the driver in specific situations

The implementation and execution of driving tests

The generation of the results report

specifying the number of hits and

mistakes, as well as gravity

thereof.

All of this derives from an evaluation of the quality of driver performance,

taking note of the errors, successes and possible improvements reflected in a results report.

As we can see, testing does not only consist in running tests.

Other error common is usually to think that

2. The tests only focus on "Verifying" that the software meets the requirements

of users, user stories or other specifications given.

When it actually also consists of "Validate" if the specifications meet

user expectations. That is, 1. We think that testing software is

run the code; and 2, Verify that the results you get are those that appear

described as approval criteria in the user specifications.

Remember that the "approval criteria" are the rules we use to determine whether

a test has been successful or not.

It may turn out that if the software satisfies what is written in the documents of

specifications, but that such complex software has been built, that

difficult to use or response times make it impossible to use.

It can also happen that the software was built to specifications, but these are not

correct. In other words, the objective of every project is to deliver software that meets the

specified requirements and to satisfy the user's need a

correct specification. At this point it is essential to differentiate between the concepts

of "Verify and Validate" the software product.

And so we have an understanding alert here.

Of course I Know it, or I think I know it.

The intent of this section is to ensure that understand any concept you may

used in a wrong way, either because of the similarity that exists with another concept or due

to wrongly acquired customs.

Verify vs. Validate

On many occasions these are used 2 concepts exchanging their meaning,

and people fail to notice it, but it is important to be able to distinguish them

appropriately, especially for the exam certification.

Verification: Did we build the software well made? Was the software built according to the requirements?

And using the example I gave at the beginning,

Did the driver meet the expectations as stipulated by the examiner?

Validation: Did we build the software according to the client expectations? Did the software solving the client's needs?

Again, using the example of the driving test

Were the examiner's requirements aligned with what is specified in the traffic laws?

To make the point clearer I will use a simpler analogy as support.

Let's imagine that a user has the need to build a 4-wheel vehicle to travel in any direction at 50 km / h

A requirement is created indicating that it be manufactured a 4-wheeler only towards forward up until 50 km/h

For this case "Verify" would be: Count the number of wheels and observe

the vehicle travel ONLY TOWARDS FORWARD up to 50 km/h, according

upon request this would be correct. Now, "Validate" would be:

Does it reach the speed of 50 km / h In any direction?

The answer is NO, and this is due to a bad requirement.

In this case we should correct the requirement, the implementation

vehicle, and run the tests again.

Let's go back, "Verify" is to make sure that the requirement, what is written in

the documentation is complied with to the letter. But "Validate" guarantees that the spirit of

what is requested by the user is fulfilled, and in this way it can be used as expected.

Seeing how complex the process of software testing, the International Committee

software testing qualification (ISTQB), divides the

definition in two parts, highlighting the sentences key to remember.

The first would be the process itself.

Testing is a process rather than a single activity, there are a number of activities involved.

That takes place throughout the software development life cycle.

The later in the life cycle we find errors, the more expensive they are

to fix them. If we can find and correct defects at the requirements stage

we will build the correct software, with the correct techniques and at a lower overall cost

Therefore, the test analysis and design process at the beginning of the life cycle

can help prevent flaws from being introduced into your code.

This will be discussed in depth in Chapter 2.

In addition to the tests that the software code runs, called

"dynamic testing", we can also test and find defects without need

of running the source code, this is called a "static test", this test includes the

review of documents and source code and we will see it in depth in chapter 3.

Planning activities take place before and after the test run. Erroneously,

is usually thought that it is only planned before. You must manage the tests,

plan what you want to do, control test activities,

report about the test progress and the status of the software under test

and end testing when a phase is complete.

These test management activities are covered in Chapter 5.

Choose what tests to do, select test conditions

and design test cases. Chapter 4 covers test design activities.

In addition to running the test, the result should be verified,

evaluate software under test and completion criteria,

which helps to decide if the tests have been completed and if the software product has approved them.

Not only code is tested, requirements are tested, specifications

design and related documents, such as operation and training material.

Static and dynamic tests are necessary to cover the range of products to be tested.

The second part of the definition covers some of the "general objectives of the test,

the reasons why we do it.

The design should be reviewed to see if it meets the requirements, and then we could

run the code to verify that it conforms to the design. If the product complies with

the specifications, we can provide that information to help customers

interested to judge the quality of the product and decide if it is ready for use.

Remember that the specified requirements may be incorrect or be incomplete.

This is slightly different from the previous point, because by saying

'Fit for purpose' we analyze whether the software does enough to

help users execute their tasks.

We tend to think of testing as a means of detecting errors or defects

which in operational use will cause failure. Finding defects helps us understand

risks associated with operational use of the software, and correcting defects improves

the quality of products. However, identifying defects has another benefit

with root cause analysis they also help us improve development processes

and make fewer mistakes in the future.

This is a definition of test suitable for any level of testing,

knowing that depending on the phase of the testing process where you are,

there are levels and objectives associated with each level.

In Chapter 2, we will cover the different levels of testing, their objectives,

and how they fit into the life cycle of the software development.

Who says 60 seconds is not enough?

In this section I will try to summarize in 1 minute the totality of what has been discussed,

I don't guarantee that I always will, but here we go.

We have 2 common mistakes about Software Testing:

1. They just consist of running the software and checking results.

2. They focus on validating that the software complies with the requirements verification.

Verification and Validation are different things

Verification: Did we build the software WELL according to the requirements?

Validation: Did we build the RIGHT software based on the RIGHT requirements?

The definition of Software Testing is divided into 2 parts: The Process and objectives

Regarding the process: Testing is a process not an activity, it involves the entire development life cycle.

It covers both static and dynamic tests. It is planned before, during and after the execution of the tests.

Tests must be prepared, the result is verified

The Code and related work products are tested.

Regarding the objectives: Compliance with the requirements is verified and validated.

By detecting defects we understand risks, we improve the quality of the products,

we analyze the root cause and improve development processes.

The time has come to show what you have learned!

What is verification?

A. Check we are building the perfect software for the customers

B. Be sure the design is good

C. Check twice to be sure about the quality

D. Check we are building the software according to the specifications

Option D is the correct answer, remember that the verification takes care of

ensure compliance with the requirements established

What is to test?

A. It is the activity of finding errors.

B. It is the process that assure the correct test execution

C. It guarantees the system is free of errors

D. Show the developer he is always wrong

The correct option is option B.

It is important to be clear that Testing is a process that includes several activities

for the correct execution of the tests and not just an activity.

What is Validation?

A. Run Regression Test

B. It is the process to guarantee the right way to run tests.

C. Check we are building the software the customers want.

D. Check we are building the software the customers according to the specifications.

Option C is the correct answer.

Option A is unrelated to the topic.

Option B is the concept of Test.

Option D is the Verify concept.

Which two of the following sentences are true.

A. Verify consists in check whether the software was build according to the requirements described in the documentation.

B. Verify consists in check whether the requirements described in the documentation fulfilled the client's needs.

C. Validate consists in check whether the software was build according to the requirements described in the documentation.

D. Validate consists in check whether the requirements described in the documentation fulfilled the client's needs.

A and D are the correct answers.

Option B and C have reversed the respective concepts.

After all this analysis we can now clearly see why the common perception

that Testing only consists of running tests or running the software, it is not

all complete, these are only part of the activities, but not the entire testing process.

Remember the 60-second summary?

Well, I have captured all these points as memory cards so that

you can review them just before taking the certification exam.

Below in the description you will find the link of my page

where you can download these documents for free.

If you have any questions or suggestions on this topic, do not hesitate to leave a comment, I will be

attentive to helping you, remember that surely you will not be the only one with that same doubt and with

This exercise encourages discussion and we can all learn.

If you consider that this content may be useful to someone in their process of

learning to be a Tester, then share it.

If you want to be aware every time I publish the rest of the chapters of this

course or Advanced levels of ISTQB then subscribe and activate the notifications.

And if you finally enjoyed the video then please like it.

Don't forget to follow me on LinkedIn to stay up to date on any active discussions.

See you in the next chapter. Bye!