0% encontró este documento útil (0 votos)
171 vistas67 páginas

Qué significa ser un tester QA

Este documento presenta las siete máximas del testing, que son principios fundamentales para el testing de software. Estas máximas incluyen: 1) Las pruebas muestran la presencia de defectos, no su ausencia, 2) Las pruebas exhaustivas son imposibles, 3) Las pruebas tempranas ahorran tiempo y dinero. El documento también discute brevemente las responsabilidades de un tester manual, como evaluar condiciones de trabajo, verificar requisitos, y encontrar fallas y defectos.

Cargado por

cfc
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PPTX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
171 vistas67 páginas

Qué significa ser un tester QA

Este documento presenta las siete máximas del testing, que son principios fundamentales para el testing de software. Estas máximas incluyen: 1) Las pruebas muestran la presencia de defectos, no su ausencia, 2) Las pruebas exhaustivas son imposibles, 3) Las pruebas tempranas ahorran tiempo y dinero. El documento también discute brevemente las responsabilidades de un tester manual, como evaluar condiciones de trabajo, verificar requisitos, y encontrar fallas y defectos.

Cargado por

cfc
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PPTX, PDF, TXT o lee en línea desde Scribd

Clase 02.

Tester QA Manual

¿Qué significa ser un


tester?
Esta clase va a ser
grabada
Temario

01 02 03

¿Qué es el Testing? ¿Qué significa ser un ¿Cuáles son los


Tester? distintos tipos de
testing?
✓ Definición ✓ ✓
7 máximas del testin Tipos de testing
✓ Cualidades. g ✓ Niveles de
✓ Diferencias entre QA ✓ Responsabilidades de testing
y QC l tester
✓ Otras áreas de ✓ Técnicas de pruebas
calidad.
✓ Origen del rol
Principios del
testing
Las máximas del
Testing
Hace muchos años se han establecido 7 verdades absolutas dentro del
universo del testing, que siempre se regirán, sin importar el proyecto
en el que estés

Fuente: Foto de Pexels.


Las máximas del Testing

Estas máximas son:


1. Las pruebas muestran la presencia de defectos, no su ausencia.
2. Las pruebas exhaustivas son imposibles.
3. Las pruebas tempranas ahorran tiempo y dinero.
4. Los defectos se agrupan.
5. Cuidado con la paradoja del pesticida.
6. Las pruebas dependen del contexto.
7. La ausencia de errores es una falacia.
1 La prueba muestra la presencia
de defectos, no su ausencia

La prueba puede mostrar la presencia de defectos, La prueba reduce la probabilidad de que queden
pero no puede probar que no hay defectos. defectos no descubiertos en el software pero, incluso
si no se encuentran defectos, el proceso de prueba no
es una demostración de la corrección.
1 Ejemplo Primer Principio

El Samsung Galaxy Note 7


tenía una falla y hacía que se
prendiera fuego. Tuvo que
ser retirado del mercado.
Siempre puede haber una
falla.
2 La prueba exhaustiva es imposible

No es posible probar todo, excepto en casos triviales. En lugar de intentar realizar pruebas
exhaustivas se deberían utilizar el análisis de riesgos, las técnicas de prueba y las prioridades
para centrar los esfuerzos de prueba.
2 Ejemplo Segundo Principio

Aplicación de temperatura global.


Deberían probar los 195 países,
por cada provincia y por cada
ciudad… ¿Es un poco alta esa
cantidad de casuísticas no?
3 La prueba temprana ahorra
tiempo y dinero

Para detectar defectos de forma temprana, las actividades La prueba temprana en el ciclo de vida de desarrollo de
de prueba, tanto estáticas como dinámicas, deben software ayuda a reducir o eliminar cambios costosos.
iniciarse lo antes posible en el ciclo de vida de desarrollo
de software.
3 Ejemplo Tercer Principio

Según un estudio realizado por IBM, el costo de reparación de un defecto en su etapa


de post-producción es de hasta 30 veces más costoso, que en la etapa de diseño, y 3
veces más que en la etapa de testing.

Fuente:Link
4 Los defectos se agrupan

En general, un pequeño número de módulos contiene la Las agrupaciones de defectos observadas en la prueba o
mayoría de los defectos descubiertos durante la prueba producción son una aportación importante a un análisis
previa al lanzamiento, o es responsable de la mayoría de de riesgos utilizado para centrar el esfuerzo de la prueba.
los fallos operativos.
4 Ejemplo Cuarto Principio

El 80% de los defectos se


encuentra en el 20% de los
módulos, ya que son el puntapié
para desencadenar otros defectos
en el resto del producto.
5 Cuidado con la paradoja del
pesticida
Si las mismas pruebas se repiten una y otra vez, Para detectar nuevos defectos, es posible que sea
eventualmente estas pruebas ya no encontrarán ningún necesario cambiar las pruebas y los datos de prueba
defecto nuevo. existentes, y es posible que sea necesario redactar nuevas
pruebas.
5 Ejemplo Quinto Principio

Si utilizamos los mismos


métodos una y otra vez, estos
dejan de surtir efecto, de la
misma forma que el pesticida
deja de surtir efectos en las
plagas.
6 Las pruebas depende del contexto

Las pruebas se realizan de distintas maneras en diferentes contextos. Comprendiendo que el


contexto va a indicar herramientas que pueden utilizarse para probar, ambiente o tipo de
objeto que se prueba, metodología implementada por la empresa, o cualquier otro contexto
que pueda existir.
6 Ejemplo Principio

Tenemos 3 tostadoras en la
imagen. ¿Creen que van a tener
que hacer las mismas pruebas
para las tres? ¿O cada tostadora
tendrá su propio set de pruebas
distinta a las otras?
7 La ausencia de errores es una
falacia
Algunas organizaciones esperan que los tester puedan realizar todas las pruebas posibles y encontrar todos los
defectos posibles, pero los principios 2 y 1, respectivamente, nos dicen que esto es imposible. Además, es una
creencia equivocada esperar que sólo con encontrar y corregir un gran número de defectos se asegure el éxito de
un sistema.
7 Ejemplo Séptimo Principio

Sabemos que el cliente espera


entregar un x-wing al “no
encontrar errores” pero...

...nos encontramos con uno de papel al dejar


de lado la usabilidad, no cumplir con las
necesidades y es de menor calidad que la
competencia.
¿Cuáles son las
responsabilidades
de un tester manual?
Para pensar
¿Cuál creen que es la responsabilidad del tester?
¿Calidad de un producto, encontrar bugs o ser
el enemigo de los desarrolladores?

Contesta la encuesta de Zoom


Responsabilidad en Calidad

En la clase pasada se explicó que significa la Nuestra responsabilidad como aseguradores de la


calidad, y quizá hacemos mucho hincapié en ello, calidad, es que el producto sea lo más confiable para
pero es el punto más importante del QA, y por ello el cliente.
hacemos todas las pruebas necesarias para alcanzar
el máximo nivel de calidad.
Máximo nivel de Calidad

Al encontrar errores y reportarlos al área de No es nada malo que existan errores en el software,
Desarrollo, estos volverán corregidos por lo que se siempre y cuando el tester los encuentre.
probará nuevamente y en cada ciclo de testing el
producto va a ir mejorando y tendrá mayor calidad.
Objetivos de Probar
✓ Evaluar condiciones del trabajo a realizar ✓ Generar confiabilidad en el nivel de calidad
como diseño, requisitos, código y/o historias del programa.
de usuario. ✓ Prevenir defectos.
✓ Verificar que se cumplen los requisitos ✓ Encontrar fallas y defectos a su previa
funcionales. implementación.
✓ Validar si lo que se prueba funciona como ✓ Entregar suficiente información a todos los
debe, y cómo los usuarios y otros implicados implicados en la toma de decisiones.
esperan. ✓ Cumplir con requisitos contractuales, legales,
✓ Reducir la posibilidad de funcionamientos reglamentarias, y/o verificar el cumplimiento
inadecuados del software. de dichos requisitos por parte del sistema.
Validar vs Verificar

Validar Verificar
✓ El software debería ajustarse a lo que el ✓ El software debería ajustarse a su
cliente realmente pidió especificación.
✓ Responde a la pregunta: ¿estamos ✓ Responde a la pregunta: ¿estamos
construyendo el sistema correcto? construyendo el sistema correctamente?
¿Cómo probamos?

La actividad de realizar pruebas se divide en dos Las pruebas dinámicas es la propia acción de
etapas fundamentales. Las pruebas dinámicas y las probar un sistema.
pruebas estáticas. Las pruebas estáticas son la acción de leer
documentación.

*Nota: En las siguientes clases se verá con detalle las pruebas dinámicas y estáticas
¿Qué es la
Documentación?
Es toda la información que nos va a respaldar y es muy
importante que exista en un Proyecto.
Existen muchos tipos de documentación, aca detallaremos los más
importantes:
✓ Historias de usuario.
✓ Plan de pruebas.
✓ Manuales.
✓ Criterios de Aceptación.

*Nota: En las siguientes clases se verá con detalle los tipos de documentación

Fuente: Foto de Pexels.


Importancia de la
Documentación
El trabajo del tester es bastante invisible, ya que no se puede palpar
en sí mismo, para eso entra en juego la documentación.
Es nuestro respaldo como profesionales para indicar que pudimos
corroborar, que cosas se probaron, en base a que estándares, quien los
pidió, y cualquier otro tipo de afirmación escrita.

Fuente: Foto de Pexels.


Herramientas para
documentar
Casos de prueba: Capturas de pantalla:
✓ Excel ✓ Lightshot
✓ TestLink ✓ ApowerSoft
✓ TestRail ✓ Greenshot
Bugs:
✓ Mantis
✓ Bugzilla
✓ Jira

Fuente: Foto de Pexels.


Métricas
Las métricas son otra de nuestras herramientas de Es un estándar de medida que nos permite tomar
trabajo, ya que es lo que usamos para medir y decisiones.
presentar la cantidad de trabajo realizado. Ejemplos de métricas en el Testing:
Se realizan métricas en base a casos realizados, bugs ✓ Cantidad de errores encontrados con severidad
encontrados, tiempo de trabajo implementado, etc... alta
✓ Cantidad de casos de prueba que fallaron
✓ Cantidad de errores por tipo y criticidad
✓ Cantidad de ciclos de testing

Break
¡10 minutos y volvemos!
Técnicas de
Prueba
Introducción

El objetivo de una técnica de prueba es ayudar a En general, cuando se crean casos de prueba, los
identificar las condiciones de prueba, los casos de probadores utilizan una combinación de técnicas de
prueba y los datos de prueba. prueba para lograr los mejores resultados a partir del
Algunas técnicas son más adecuadas para ciertas esfuerzo de prueba.
situaciones y niveles de prueba; otras se pueden
aplicar en todos los niveles de prueba.
Técnicas de Prueba y sus
Características
Las técnicas de prueba se clasifican:

Caja negra.

Caja blanca

Basadas en la experiencia.
Caja negra
Definición
También llamadas técnicas conductuales o basadas en el comportamiento, se basan en un análisis de la
base de prueba adecuada (por ejemplo, documentos de requisitos formales o historias de usuarios). Estas
técnicas son aplicables tanto a la prueba funcional como a la no funcional.
Las técnicas de prueba de caja negra se concentran en las entradas y salidas del objeto de prueba sin
referencia a su estructura interna.

Fuente: Panel.es
Técnicas de prueba de caja negra

✓ Partición de Equivalencia
✓ Análisis de Valores de Frontera
✓ Prueba de Tabla de Decisión
✓ Prueba de Transición de Estado
✓ Prueba de Caso de Uso
Partición de
Equivalencia
✓ Consiste en clasificar las entradas de datos del sistema
en grupos que representan un comportamiento similar.
✓ Se pueden definir particiones tanto para datos válidos
(aceptados por el sistema) como no válidos (no aceptados
por el sistema)
✓ Para lograr una cobertura del 100% con esta técnica, los
casos de prueba deben cubrir todas las particiones
identificadas utilizando, como mínimo, un valor de cada
partición.

Fuente: Foto de Pexels.


Ejemplo

✓ Tenemos un sistema electoral donde personas de un país deberán votar.


Analizaremos la variable “edad”.
✓ Dividimos en dos grupos “mayores de edad” y “menores de edad”

Menores Mayores
1….17 18….n
Análisis de Valores
Frontera
Es una extensión de la partición de equivalencia, pero sólo se
puede utilizar cuando la partición está ordenada, y consiste en
datos numéricos o secuenciales.
Los valores mínimo y máximo de una partición son sus valores
frontera.
El análisis de valores frontera se puede aplicar en todos los niveles de
prueba. Esta técnica se utiliza generalmente para probar los
requisitos que requieren un rango de números, fechas y horas.

Fuente: Foto de Pexels.


Ejemplo 1

Fuente: Educación con TIC


Ejemplo 2
✓ Un campo de un formulario solo acepta números del 1 al 5.

Partición de equivalencia Valores frontera

Inválida Válida Inválida Inválida Válida- Inválida


(demasiado (demasiado (demasiado (demasiado
baja) alta) baja)-Válida alta)

0 1,2,3,4,5 6,7,8,9 0y1 5y6


Prueba de Transición
de Estado
REEMPLAZAR
POR IMAGEN Un diagrama de transición de estado muestra los posibles estados
del software, así como la forma en que el software entra, sale y
realiza las transiciones entre estados.
Una transición se inicia con un evento. El evento resulta en una
transición.
El cambio de estado puede provocar que el software tome una acción.
Prueba de Caso de
Uso
Las pruebas se pueden obtener a partir de casos de uso, que son
una forma específica de diseñar interacciones con elementos
software, incorporando requisitos para las funciones del
software representadas por los casos de uso. Los casos de uso
están asociados con actores y sujetos.
Ejemplo en vivo

1. Abriremos la página Zodiaco Mágico


2. Definiremos la técnica de partición de equivalencias para el signo de “Leo”
3. Analizaremos los valores de frontera para este mismo signo
4. Verificamos los resultados obtenidos
Caja blanca
Definición
También llamadas técnicas estructurales o basadas en la estructura, se basan en un análisis de la
arquitectura, el diseño detallado, la estructura interna o el código del objeto de prueba. A
diferencia de las técnicas de prueba de caja negra, las técnicas de prueba de caja blanca se
concentran en la estructura y el procesamiento dentro del objeto de prueba.

REEMPLAZAR
POR IMAGEN

Fuente: Panel.es
Para pensar
¿Cuáles son las principales diferencias de las técnicas
de caja negra y caja blanca?

Contesta la pregunta en el chat


Caja Blanca / Caja Negra

Fuente: Link
Basadas en la experiencia
Definición

Las técnicas de prueba basadas en la experiencia aprovechan la experiencia de


desarrolladores, probadores y usuarios para diseñar, implementar y ejecutar pruebas. A
menudo, estas técnicas se combinan con técnicas de prueba de caja negra y caja blanca.
Técnicas de prueba basadas en la
experiencia
✓ Predicción de Errores.
✓ Prueba Exploratoria.
✓ Prueba Basada en Listas de Comprobación.
Predicción de Errores

Es una técnica utilizada para anticipar la ocurrencia de


equivocaciones, defectos y fallos, basada en el conocimiento del
probador, incluido:
✓ Cómo ha funcionado la aplicación en el pasado.
✓ Qué tipo de equivocaciones tienden a cometer los
desarrolladores.
✓ Fallos que se han producido en otras aplicaciones.

Fuente: Foto de Pexels.


Prueba Basada en
Listas de
Comprobación
REEMPLAZAR
POR IMAGEN En la prueba basada en listas de comprobación, los probadores
diseñan, implementan y ejecutan pruebas para cubrir las
condiciones de prueba que se encuentran en una lista de
comprobación.
Estas listas de comprobación pueden elaborarse basándose en la
experiencia, el conocimiento de lo que es importante para el usuario o
la comprensión de por qué y cómo falla el software.

Fuente: Foto de Pexels.


Prueba Exploratoria

Se diseñan, ejecutan, registran y evalúan de forma dinámica REEMPLAZAR


pruebas informales durante la ejecución de la prueba. Los POR IMAGEN
resultados de la prueba se utilizan para aprender más sobre el
componente o sistema, y para crear pruebas para las áreas que
pueden necesitar ser probadas con mayor intensidad.
Esta prueba es más útil cuando las especificaciones son escasas o
inadecuadas.

Fuente: Foto de Pexels.


Ejemplo en vivo
A continuación veremos un pequeño ejemplo de
pruebas exploratorias.
Pasos a seguir:
✓ Abriremos una página web
✓ Realizaremos la búsqueda de un bug
✓ Reportamos un bug
Actividad colaborativa
Testing exploratorio
¿Te animás a realizar un testing exploratorio y reportar
un bug?

Duración: 20 minutos
ACTIVIDAD COLABORATIVA

Acuerdos
Presencia Apertura al aprendizaje
✓ Participar y “estar” en la clase, que tu ✓ Siempre, pero siempre puedes seguir
alrededor no te distraiga aprendiendo. Compartir el conocimiento es
válido, la construcción colaborativa es la
propuesta.
Escucha activa
✓ Escuchar más allá de lo que la persona está
expresando directamente Todas las voces
✓ Escuchar a todos, todos podemos reflexionar.
Dejar el espacio para que todos podamos
participar.
ACTIVIDAD COLABORATIVA

Testing exploratorio
Consigna:
● Abriremos una página web en este caso: https://www.demoblaze.com/index.html
● Realizaremos la búsqueda de un bug
● Reportamos un bug

NOTA: usaremos los breakouts rooms. El tutor/a tendrá el rol de facilitador/a.


CLASE N°2

Glosario
Verificar: cuando el software se ajusta a su Pruebas dinámicas: es la propia acción de probar
especificación. un sistema.

Validar: cuando el software se ajusta a lo que el Caso de Prueba: conjunto de pasos y resultados
cliente realmente pidió esperados que se crean a partir de los requerimientos
del software que se va a probar.
Pruebas estáticas: son la acción de leer
documentación. Métricas: es un estándar de medida que nos permite
tomar decisiones.
¿Quieres saber más?
Te dejamos material ampliado
de la clase
MATERIAL AMPLIADO

Recursos multimedia
Título
Título

✓ Ejemplos de los 7 Principios de Testing | ✓ Ejemplo prueba exploratoria | Enlace


Enlace
✓ Documento ISTQB en Español - Página 70 a
78 | Enlace
¿Preguntas?
Resumen
de la clase hoy
✓ 7 máximas del testing
✓ Responsabilidades del tester
✓ Técnicas de prueba
Opina y valora
esta clase

También podría gustarte