INDUCCION A QA TESTER.pptx

CONTENIDO
 Fundamentos de pruebas
 Pruebas a traves del ciclo de vida de software
 Técnicas de diseño de casos de pruebas

FUNDAMENTOS DE PRUEBAS
¿Porqué son necesarias las pruebas?
• Mejora de la calidad de un producto software:
El proceso de pruebas ayuda a suministrar/aportar al software los atributos deseados, por ejemplo retirar
defectos que conducen a fallos
• Reducción del riesgo de detectar errores:
Actividades de pruebas software adecuadas reducirán el riesgo de encontrar errores durante la fase de
operaciones software
• Satisfacer compromisos:
La ejecución de pruebas puede ser un requisito obligatorio por parte del cliente, debido a normas legales
así como al cumplimiento de estándares propios de una industria
• El coste de los defectos
La detección de errores en etapas tempranas permite la corrección de los mismos a costes reducidos

Causa de fallos del software
• Error humano:
Un defecto ha sido introducido en el código software, en los
datos o en los parámetros de configuración
Causas de error humano
Plazos, demandas excesivas debidas a la complejidad, distracciones
• Condiciones ambientales:
Cambios en las condiciones ambientales
Causas de condiciones ambientales negativas/adversas
Radiación, magnetismo, campos electromagnéticos, polución,
manchas solares, fallo de discos duros, fluctuaciones en el suministro
de energía eléctrica

De acuerdo a la norma ISO/IEC 9126 la calidad software consiste en:
• Atributos funcionales de calidad
- Funcionalidad incluye
 Adecuación
 Exactitud
 Interoperabilidad
 Seguridad
 Cumplimiento de funcionalidad
• Atributos no-funcionales de calidad
- Fiabilidad
- Usabilidad
- Eficiencia
- Mantenibilidad
- Portabilidad

Caso de prueba (“test case”), base de prueba (“test basis”)
• Caso de prueba (“test case”) según IEEE Std 829:
La definición de un caso de prueba incluye, al menos, la siguiente información (según IEEE Std 610)
 Precondiciones
 Conjunto de valores de entrada
 Conjunto de resultados esperados
 Poscondiciones esperadas
 Identificador único
 Dependencia de otros casos de prueba
 Referencia al requisito que será
 Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados (opcional)
 Prioridad (opcional)

Caso de prueba (“test case”) según IEEE Std 829:
 Precondiciones (“preconditions”): situación previa a la ejecución de pruebas o características de un
objeto de pruebas antes de llevar a la práctica (ejecución) un caso de prueba
 Valores de entrada (“input values”): descripción de los datos de entrada de un objeto de pruebas
 Resultados esperados (“expected results”): datos de salida que se espera que produzca un objeto de
pruebas
 Poscondiciones (“post conditions”): características de un objeto de prueba tras la ejecución de
pruebas, descripción de su situación tras la ejecución de las pruebas
 Dependencias (“dependencies”): orden de ejecución de casos de prueba, razón de las dependencias
 Identificador distinguible (“distinct identification”): Identificador o código con el objeto de vincular, por
ejemplo, un informe de errores al caso de prueba en el cual ha sido detectado
 Requisitos (“requirements”): características del objeto de pruebas que el caso de prueba debe evaluar

Caso de prueba (“test case”), base de prueba (“test basis”)
• Base de prueba (“test basis” o “test base”):
Conjunto de documentos que definen los requisitos de un
componente o sistema. Utilizado como fundamento para el
desarrollo de casos de prueba.

Objetivos de las pruebas
• Detección de defectos
• Generación (logro) de confianza respecto del nivel de Calidad
• Aportación de información para la toma de decisiones
• Prevención de defectos

Pruebas y depuración (“debugging”)

Pruebas y depuración (“debugging”)
Probar y repetir la prueba (repetición de pruebas - “re-testing”)
son actividades propias del proceso de pruebas.
Las pruebas muestran los fallos
La repetición de pruebas (“re-testing”) verifica que el defecto
ha sido corregido
La depuración y la corrección de defectos son actividades propias del desarrollador
A través de la depuración los desarrolladores pueden reproducir
los fallos, analizar el estado del programa y detectar el defecto
correspondiente con el objeto de corregirlo

Proceso de pruebas básico
El proceso de pruebas está determinado por las siguientes fases:
• Planificación de pruebas y Control
• Análisis de pruebas y diseño de pruebas
• Implementación de pruebas y ejecución de pruebas
• Evaluación del criterio de finalización de pruebas y generación de informes de
pruebas
• Actividades de cierre de pruebas

Roles y responsabilidades
• Rol: Desarrollador
 Implementa requisitos
 Desarrolla estructuras
 Diseña y programa el software
 Su éxito consiste en la creación de un producto
• Rol: Probador (“Tester”)
 Planifica las actividades de
 pruebas.
 Diseña casos de prueba
 Su única preocupación es encontrar defectos
 Encontrar errores producidos por un desarrollador es su éxito

Características personales de un buen probador (“tester”)
• Aptitudes para la comunicación
 Necesarias para llevar malas noticias a los desarrolladores
 Necesarias para vencer estados de frustración
 Tanto cuestiones técnicas como prácticas, relativas al uso del
 sistema, deben ser entendidas y comunicadas
 Una comunicación positiva puede ayudar a evitar o facilitar
 situaciones difíciles
 Para establecer una relación de trabajo con los desarrolladores a corto plazo
• Experiencia
 Factores personales influyen en la ocurrencia de errores
 La experiencia ayuda a identificar dónde se pueden acumular errores

PRUEBAS A TRAVÉS DEL CICLO DE VIDA SOFTWARE
Modelos de desarrollo software
• Pruebas a través del modelo-V general (Modelo de desarrollo secuencial):
El modelo-V general es el modelo de desarrollo software más
utilizado
Desarrollo y pruebas son dos ramas iguales
Cada nivel de desarrollo tiene su correspondiente nivel de pruebas

o Rama de desarrollo software
 Definición de requisitos
 Documentos de especificación
 Diseño funcional del sistema
 Diseño del flujo funcional del programa
 Diseño técnico del sistema
 Definición de arquitectura / interfaces
 Especificación de los componentes
 Estructura de los componentes
 Programación
 Creación de código ejecutable

o Rama de pruebas software
 Pruebas de aceptación
 Pruebas formales de los requisitos del cliente
 Pruebas de sistema
 Sistema integrado, especificaciones
 Pruebas de integración
 Interfaces de componentes
 Pruebas de componente
 Funcionalidad del componente

Verificación dentro del modelo-V general

Validación dentro del modelo-V general

• Pruebas en el modelo-W

• Modelos iterativos: tipos de modelos iterativos:
 Modelo prototipado: desarrollo rápido de una representación del sistema que pudiera ser objeto de
uso, seguida de modificaciones sucesivas hasta que el sistema sea finalizado
 Desarrollo rápido de aplicaciones (“Rapid Application Development” - (RAD)): La interfaz de usuario se
implementa utilizando una funcionalidad previamente construida (“out-of-thebox ”) simulando la
funcionalidad que posteriormente será desarrollada
 Proceso unificado (“Rational Unified Process” - (RUP)): modelo orientado a objeto y producto de la
compañía Rational/IBM. Principalmente aporta el lenguaje de modelado UML y soporte al Proceso
Unificado
 Programación extrema (“Extreme Programming” - (XP)): el desarrollo y las pruebas tienen lugar sin una
especificación de requisitos formalizada
 SCRUM – descripción del proceso: Scrum es una metodología de trabajo iterativa e incremental para la
gestión de proyectos, desplegado principalmente en el desarrollo ágil de software

• Modelos iterativos: Características:
 Cada iteración contribuye con una característica adicional del sistema a desarrollar
 Cada iteración puede ser probada por separado
 Las pruebas de regresión y la automatización de pruebas son elementos/factores de gran
relevancia
 En cada iteración, la verificación (relación con el nivel precedente) y la validación (grado de
corrección del producto dentro del nivel actual) se pueden efectuar por separado

Niveles de prueba
Pruebas de componente:
Alcance
• Sólo se prueban componentes individuales
- Un componente puede estar constituido por un conjunto de
unidades más pequeñas
- Los objetos de prueba no siempre pueden ser probados en solitario
(de forma autónoma)
• Cada componente es probado de forma independiente
- Descubriendo fallos producidos por defectos internos
- Los efectos cruzados entre componentes quedan fuera del alcance
de estas pruebas
• Los casos de prueba podrán ser obtenidos a partir de:
- Especificaciones de componente
- Diseño software
- Modelo de datos

Niveles de prueba
Pruebas de integración:
Alcance
• Las pruebas de integración asumen que los componentes ya han sido probados
• Las pruebas de integración comprueban la interacción mutua entre componentes (subsistemas) software entre sí:
- Interfaces con otros componentes
- Interfaces GUIs / MMIs
• Las pruebas de integración comprueban las interfaces con el entorno del sistema
- En la mayoría de los casos la interacción probada es el comportamiento del componente y el entorno simulado
- En condiciones reales factores adicionales del entorno pueden influir en el comportamiento del componente
• Los casos de prueba podrán ser obtenidos a partir de:
- Especificación de interfaces
- Diseño de la arquitectura (diseño)
- Modelo de datos

Niveles de prueba
Pruebas de integración:
Alcance
• Será probado un (subsistema) sistema compuesto de componentes individuales
- Cada componente tiene una interfaz externa y/o interna que interactúa con otro componente del
(subsistema) sistema
• Son necesarios controladores de prueba (“drivers”) (los cuales
- aportan el entorno al proceso del sistema o subsistema)
- - Con el objeto de permitir o producir entradas y salidas del
- (subsistema) sistema
- Con el objeto de registrar datos
• Los controladores de pruebas (“drivers”) del componente podrán ser reutilizadas en estas
pruebas

Niveles de prueba
Pruebas de sistema:
Alcance
• Prueba de un sistema integrado desde el punto de vista del Usuario
- Implementación completa y correcta de los requisitos
- Despliegue en el entorno real del sistema con datos reales
• El entorno de pruebas deberia coincidir con el entorno real
- No son necesarios stubs o controladores (“drivers”)
- Todas las interfaces externas son probadas en condiciones reales
- Emulación próxima al futuro entorno real del sistema

Niveles de prueba
Tres enfoques para probar requisitos funcionales:
• Pruebas basadas en procesos de negocio:
- Cada proceso de negocio sirve como fuente para derivar/generar
pruebas
- El orden de relevancia de los procesos de negocio pueden ser aplicados para asignar prioridades a los casos de prueba
• Pruebas basadas en casos de uso:
- Los casos de prueba se derivan/generan a partir de las secuencias de usos esperados o razonables
- Las secuencias utilizadas con mayor frecuencia reciben una prioridad más alta
• Pruebas basadas en requisitos:
- Los casos de prueba se derivan de la especificación de requisitos
- El número de casos de prueba variará en función del tipo/profundidad de las pruebas basadas en la especificación de
requisitos

Niveles de prueba
Pruebas de aceptación: Pruebas de aceptación de usuario
• Normalmente el cliente selecciona casos de prueba para las pruebas de aceptación
- Normalmente se verifica la adecuación al uso del sistema por parte de usuarios de negocio, “los clientes conocen su negocio”
• Las pruebas se realizan utilizando el entorno del cliente.
- El entorno del cliente puede producir nuevos fallos

Niveles de prueba
Pruebas de aceptación: Pruebas de aceptación operativa
• Requiere que el software sea adecuado para su uso en un entorno de producción
- Integración del software en la infraestructura TI del cliente (Copias de seguridad/restauración de sistemas, reinicio, instalación,
capacidad de ser desinstalado, recuperación en caso de desastres, etc.)
- Gestión de usuarios, interacción con ficheros y estructuras de directorios en uso
- Compatibilidad con otros sistemas (otros ordenadores, servidores de base de datos, etc.)
- Tareas de mantenimiento
- Tareas de carga y migración de datos
- Comprobaciones periódicas de vulnerabilidades de seguridad
• Con frecuencia, las pruebas de aceptación operativa son realizadas por el administrador de sistemas del cliente

Niveles de prueba
Pruebas de aceptación: Pruebas alpha y pruebas beta
• El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio
cotidianos en las dependencias del proveedor [pruebas alpha – (“alpha testing”)] o en
sus propias dependencias [pruebas beta - (“beta testing”)]
• Se aporta información (“feedback”) respecto de problemas detectados, usabilidad, etc.
• Ventajas de las pruebas alpha y beta
- Reduce el costo de las pruebas de aceptación
- Se utilizan distintos entornos
- Involucran a un alto número de usuarios

Tipos de pruebas
A. Pruebas funcionales (Objetivo: probar la función)
B. Pruebas no funcionales (Objetivo: probar las características del
producto)
C. Pruebas estructurales (Objetivo: probar la
estructura/arquitectura software)
D. Pruebas de asociadas al cambio (Objetivo: probar
después de cambios)

Tipos de pruebas
A. Pruebas funcionales (Objetivo: probar la función)
- Los métodos de caja negra (“black box”) se utilizan en el diseño de
casos de prueba relevantes
- Las pruebas son para verificar los requisitos funcionales (establecidos
en las especificaciones, conceptos, casos de estudio, reglas de
negocio o documentos relacionados)

Tipos de pruebas
B. Pruebas no funcionales (Objetivo: probar las características del
producto)
- Pruebas no funcionales típicas:
- Pruebas de carga(“load testing”) / pruebas de rendimiento
(“performance testing”) / pruebas de volumen (“volume testing”) /
pruebas de estrés (“stress testing”)
- Pruebas de las características de seguridad (efectos adversos) del
software(“Testing of safety features”)
- Prueba de fiabilidad y robustez (“reliability and robustness testing”)
- Pruebas de usabilidad (“usability testing”) / pruebas de configuración
(“configuration testing”)

Tipos de pruebas
B. Pruebas no funcionales (Objetivo: probar las características del producto)
• Prueba de carga (“load test”)
- Sistema bajo carga (carga mínima, más usuarios/transacciones)
• Prueba de rendimiento (“performance test”)
- Rapidez con la cual un sistema ejecuta una determinada función
• Prueba de volumen (“volume test”)
- Procesamiento de grandes cantidades de datos / ficheros
• Prueba de estrés (“stress test”)
- Reacción a la sobrecarga / recuperación tras el retorno a una carga
normal
• Prueba de estabilidad (“stability test”)
- Rendimiento en “modo de operación continua”
• Prueba de robustez (“test for robustness”)
- Reacción a entradas erróneas o datos no especificados
- Reacción a fallos hardware / recuperación ante situaciones de
desastre

Tipos de pruebas
B. Pruebas no funcionales (Objetivo: probar las características del producto)
• Pruebas de cumplimiento
- Cumplir normas y reglamentos (interno / externo)
• Pruebas de usabilidad
- Estructurado, comprensible, fácil de aprender por parte del usuario
• Otros aspectos no funcionales de calidad:
- Portabilidad: adaptabilidad, reemplazabilidad, instalabilidad, coexistencia, cumplimiento de
portabilidad
- Mantenibilidad: analizabilidad, modificabilidad, estabilidad, testabilidad, cumplimiento de
mantenibilidad
- Fiabilidad: madurez, tolerancia a fallos, recuperabilidad, cumplimiento de fiabilidad

Tipos de pruebas
C. Pruebas estructurales (Objetivo: probar la estructura/arquitectura software)
Objetivo: Cobertura
- Análisis de la estructura de un objeto de prueba (enfoque: caja blanca)
- La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido
cubierto por los casos de prueba

Tipos de pruebas
D. Pruebas de asociadas al cambio (Objetivo: probar después de cambios)
- Objetivo: probar el objeto después de cambios
- Después de que un objeto de pruebas o el entorno de su sistema ha sido objeto de modificación los
resultados de pruebas asociadas al cambio resultan inválidos: las pruebas deben ser repetidas
- Dos razones para modificar el software
- Corrección de errores
- Extensión funcional
- Debido a los efectos secundarios de la funcionalidad extendida o nueva, es necesario también repetir
pruebas de áreas adyacentes

TÉCNICAS DE DISEÑO DE PRUEBAS
Categorías de las técnicas de diseño de prueba
Pruebas de caja negra (“black box”) y caja blanca (“White box”)
- Las pruebas dinámicas se dividen en dos categorías/grupos.

Técnica: caja negra (“black box”)
• El probador observa el objeto de prueba como una caja negra
- La estructura interna del objeto de prueba es irrelevante o
desconocida
• Los casos de prueba se obtienen a partir del análisis de la especificación
(funcional y no funcional) de un componente o sistema
- Prueba del comportamiento entrada / salida (“input / output”)
• ¡La funcionalidad es el foco de atención!
• La técnica de caja negra también se denomina

Técnicas basadas en la especificación o de caja negra
• Métodos de caja negra:
- Partición de equivalencia (segmentación de equivalencia) o clase de equivalencia
- Análisis de valores límite
- Tablas de decisión & gráficos causa-y-efecto
- Pruebas de transición de estado
- Pruebas de caso de uso

o Partición de equivalencias
 Consiste en clasificar las entradas de datos del sistema en grupos que presentan un
comportamiento similar, por lo cual serán procesados de la misma forma.
 Se pueden definir particiones tanto para datos válidos como no válidos (datos que deben ser
rechazados por el sistema).
 Las particiones también pueden definirse en función de las salidas de datos, valores internos,
valores relacionados antes o después de ciertos eventos, y también para los valores que
reciben las interfaces.
 A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos
válidos y datos inválidos.
 Es aplicable a entradas de datos realizadas por personas o vía interfaces con otros sistemas.

o Análisis de valores limites
 Parte del principio que el comportamiento al borde de una partición de datos tiene
mayores probabilidades de presentar errores (bugs).
 Los valores máximos y mínimos de una partición son sus valores borde.
 Aplican tanto para datos inválidos como inválidos.
 Al incluirlas en el diseño de casos de prueba, se define una prueba por cada valor
borde.
 La capacidad de identificar defectos de esta técnica es alta, ser pueden revisar las
especificaciones funcionales para identificar datos interesantes.

o Tablas de decisión
 Las tablas de decisión son una herramienta útil para documentar reglas de negocio de alta
complejidad que el sistema debe cumplir.
 Las tablas de decisión se crean a partir del análisis de la especificación funcional y la
identificación de estas reglas de negocio.
 Las condiciones de entrada y acciones se expresan a menudo en términos de verdadero o
falso.
 La tabla de decisión contienen las condiciones desencadenantes, que son la combinación de
valores de verdadero o falso para cada entrada de datos, así como la acción que resulta de
cada combinación.
 Cada columna de la tabla corresponde con una regla de negocio que representan la
combinación de condiciones, y las acciones que resultan.

o Transición entre estados
 Un sistema puede presentar diferentes comportamientos según su estado actual o
eventos previos.
 Este aspecto del sistema se puede representar en un diagrama de transición entre
estados.
 El diagrama de estados, permite al Tester visualizar los estados, transiciones, entradas
de datos o eventos que las desencadenan y las acciones que pueden resultar.
 Una tabla de estados, muestra las relaciones entre los estados y las entradas de datos.
Puede ayudar a identificar posibles transacciones inválidas.

o Pruebas de casos de uso
 Los casos de uso describen las interacciones entre actores (que pueden ser usuarios o
sistemas) que producen un resultado que agrega algún valor. A partir de estos se
pueden derivar casos de prueba.
 Tienen precondiciones que deben cumplirse para que estos funcionen de forma exitosa.
 Los casos de uso terminan con post-condiciones, que son resultados observables y
estado del sistema después de la ejecución.
 Son útiles para definir las pruebas de aceptación, en las que participa el usuario o
cliente.

Técnicas basadas en la estructura o de caja blanca (“White box ”)
• Técnicas de caja blanca (“white box”):
- Se centran en los detalles procedimentales del software, por lo que su diseño está
fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores
de entrada para examinar cada uno de los posibles flujos de ejecución del programa y
cerciorarse de que se devuelven los valores de salida adecuados.
- Sólo se puede probar código existente. Habiendo funciones faltantes, este hecho no
puede ser detectado. Sin embargo el código muerto o superfluo puede ser detectado
con las pruebas de caja blanca
- Principalmente, los métodos de caja blanca son utilizados en pruebas de bajo nivel
como pruebas de componente o pruebas de integración

• Técnicas de caja blanca (“white box”):
- Pruebas de sentencia y cobertura (“statement testing and coverage”)
- Pruebas de decisión y cobertura (“decision testing and coverage”)
- Pruebas de condición y cobertura (“condition testing and coverage”)
- Pruebas de cobertura de camino y (“path testing coverage”)

• Principales Tipos de Cobertura
- Cobertura de sentencia (“statement coverage”)
 -Porcentaje de sentencias ejecutables que han sido practicadas por los casos de prueba
 También puede ser aplicado a módulos, clases, elementos de un menú, etc.
- Cobertura de decisión (= cobertura de rama) (“decisión coverage = branch coverage”)
 Porcentaje de resultados de decisión que han sido practicados por los casos de prueba
- Cobertura de camino (“path coverage”)
 Porcentaje de caminos de ejecución que han sido practicados por casos de prueba
- Cobertura de condición (“condition coverage”)
 Porcentaje de todos los resultados individuales de condición que afectan de forma independiente al
resultado de una decisión que ha sido practicada por casos de prueba
 La cobertura de condición se presenta en distintos grados, por ejemplo, cobertura de condición simple,
cobertura de condición múltiple y cobertura de condición múltiple mínima

INDUCCION A QA TESTER.pptx

Recomendados

Recomendados

Más contenido relacionado

Similar a INDUCCION A QA TESTER.pptx

Similar a INDUCCION A QA TESTER.pptx (20)

Último

Último (20)

INDUCCION A QA TESTER.pptx