Ep1 | ¿Qué es probar? Fundamentos de ISTQB en español #CTFL #Probar #QA #ISTQB
Summary
TLDREl 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
😀 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.
🤔 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.
🔍 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.
🛠 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.
📚 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.
Mindmap
Keywords
💡Pruebas de software
💡Q.A.
💡Errores
💡Requerimientos
💡Verificación
💡Validación
💡Pruebas dinámicas
💡Pruebas estáticas
💡Criterios de aprobación
💡Pruebas de regresión
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!
Voir Plus de Vidéos Connexes
Ep2 | Pruebas y Depuración ¿Para que sirven las pruebas de Software? Fundamentos de Prueba #ISTQB
¿Qué es el testing unitario? Por qué DEBERÍAS aprenderlo + Ejemplos fáciles de entender
[SER222] Empirical Analysis (1/8): The Empirical Process
Aprende qué es Desarrollo de Software y sus etapas ( Clase fácil )
💻 Validar FORMULARIO de REGISTRO con JAVASCRIPT
Diseño de un factor con Minitab 18 (One way - ANOVA)
5.0 / 5 (0 votes)