II - III - Istqb CTFL

Luis Mercadal & Asociados
Curso Oficial de ISTQB Certified Tester Foundation Level

- Probador de Software Certificado de Nivel Fundamentos -
Pruebas a travs del Ciclo de Vida del Software + Tcnicas Estticas

Captulo II - Pruebas a travs del Ciclo de Vida del Software
Contenido
Captulo II - Pruebas a travs del ciclo de vida del software
II/01 Modelos de desarrollo de software

II/02 Niveles de prueba
II/03 Tipos de prueba
II/04 Pruebas de mantenimiento
II/01 Modelos de desarrollo de software
Modelos de desarrollo de software
El proceso de pruebas no existe aislado
Las actividades de prueba estn relacionadas con las actividades de desarrollo de software
Diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques de prueba
Un modelo involucra principalmente el orden en el cual las actividades son llevadas a cabo, y las
guas para hacer la transicin entre etapas
Modelos de ciclo de vida del software
Modelo en Cascada (Modelo Lineal Secuencial)
Modelo V (Modelo en V)
Modelo Iterativo-Incremental
Modelo en Cascada (Modelo Lineal Secuencial)
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve

fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma
puramente secuencial
www.luismercadal.com.ar | info@luismercadal.com.ar

Modelo V (Modelo en V)
El modelo V se desarroll para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional
Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que
las pruebas no se introducan hasta el final del proyecto
Modelo Iterativo-Incremental
El desarrollo iterativo-incremental es el proceso de establecer requerimientos, disear,

construir y probar un sistema en una serie de cortos ciclos de desarrollo
Prototipos, Desarrollo Rpido de Aplicaciones (Rapid Application Development, RAD),

Proceso Unificado de Racional (Rational Unified Process, RUP), Modelos de
Desarrollo gil (SCRUM)
Modelo V
Desarrollo y pruebas son dos ramas iguales
Cada nivel de desarrollo tiene su correspondiente nivel de pruebas
Los productos de trabajo generados por los desarrolladores y analistas de negocio durante
el desarrollo son las bases de las pruebas en uno o ms niveles.

Las pruebas (rama derecha) son diseadas en paralelo al desarrollo del software (rama
izquierda)
Las pruebas necesitan empezarse lo ms pronto posible y tienen lugar a travs de todo el ciclo
de vida
Las pruebas no son slo una actividad basada en la ejecucin

Rama de desarrollo del software (rama izquierda)
Definicin de Requisitos
- Especificaciones de requisitos
Diseo Funcional del Sistema
Diseo Tcnico del Sistema

- Definicin de arquitectura / interfaces
- Diseos de alto nivel
Especificacin de Componentes
- Estructura de los componentes
- Diseos detallados
Programacin
Especificaciones funcionales de los requisitos
Creacin de cdigo ejecutable
Rama de pruebas del software (rama derecha)
Pruebas de Aceptacin
- Pruebas formales de los requisitos del cliente
Pruebas de Sistema
- Sistema integrado, especificaciones
Pruebas de Integracin
Interfaces de componentes
Pruebas de Componente
- Funcionalidad del componente

Verificacin y Validacin (V & V)
Verificacin
Verificar - comprobar la evidencia, substanciar
Comprobacin de la conformidad con los requisitos establecidos
Se est construyendo el producto software de la manera correcta?
Hemos sumado 1 ms 1 correctamente?
Validacin
Validar - dar prueba de la aportacin de valor
Comprobacin de la idoneidad para el uso esperado
Se est construyendo el producto software correcto?
El objetivo era sumar 1 ms 1 o deberamos haber restado?
Verificacin
Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que le precede
El papel de la verificacin implica comprobar que el software est de acuerdo con su

especificacin. Debera comprobarse que satisface sus requisitos funcionales y no funcionales

Validacin
La validacin se refiere a la correccin de cada nivel de desarrollo
La validacin tiene como objetivo asegurar que el sistema satisface las expectativas del cliente
No solo comprobar que el sistema satisface su especificacin sino que adems demostrar que el
software hace lo que el cliente espera que haga
Modelos Iterativos e Incrementales

Caractersticas
-
Cada iteracin contribuye con una caracterstica adicional del sistema a desarrollar
Cada iteracin puede ser probada por separado
Las pruebas de regresin y la automatizacin de pruebas son elementos/ factores de gran

relevancia
En cada iteracin, la verificacin (relacin con el nivel precedente) y la validacin (grado de

correccin del producto dentro del nivel actual) se pueden efectuar por separado

Desarrollo gil
SCRUM
-
Proceso gil que se puede usar para gestionar y controlar desarrollos complejos de software y
productos usando prcticas iterativas e incrementales.
Se aplican de manera regular un conjunto de buenas prcticas para trabajar colaborativamente, en

equipo, y obtener el mejor resultado posible de un proyecto.
Un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta
de dos semanas, si as se necesita)
Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto final
que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.
Responsabilidades
Cliente (Product Owner)

Facilitador (ScrumMaster)
Equipo (Team)
Desarrollo de Software Guiado por Pruebas / Test Driven Development (TDD)
Tcnica de desarrollo de software que usa iteraciones de desarrollo cortas basadas en casos de
prueba escritos previamente que definen las mejoras deseadas o nuevas funcionalidades
Ciclo de desarrollo guiado por pruebas
Aadir una prueba

Ejecutar las pruebas y comprobar que la ltima que se ha aadido falla
Escribir algo de cdigo, realizar cambios en la implementacin
Ejecutar las pruebas automatizadas y ver que tienen xito
Refactorizar el cdigo para mejorar su diseo
Repetir el ciclo con una nueva prueba

Realizar un conjunto de pruebas unitarias que cubran todos los casos descritos en los requerimientos.
Una correcta aplicacin de la etapa de refactorizacin hace que el cdigo sea mas legible, optimo y fcil
de mantener

Herramientas para automatizar las pruebas unitarias
NUnit
MbUnit
xUnit.net
csUnit
JUnit
JsUnit
ASPUnit
Si se aplica mal o a medias el TDD pueden surgir los siguientes problemas:
Generar pruebas mal diseadas que no sirvan para determinar si los objetos tienen el
comportamiento esperado
La calidad de la prueba depende del conocimiento del desarrollador
Se puede invertir mucho tiempo en hacer pruebas y dejar corta la fase de construccin
(codificacin)
Disear pruebas poco representativas que no cumplan con una cobertura de cdigo y que en algn
momento dejen de usarse
Invertir mucho tiempo en hacer las pruebas y no darles mantenimiento, lo cual representa un gasto
intil de tiempo
Caractersticas de buenas pruebas en todo modelo
Para cada actividad de desarrollo existe una actividad de prueba correspondiente
Cada nivel de prueba tiene objetivos de prueba especficos para dicho nivel
Los procesos de anlisis y diseo de las pruebas para un nivel de prueba dado deben iniciarse
durante la actividad de desarrollo correspondiente
Los probadores deben iniciar su participacin en la revisin de los documentos en cuanto haya
borradores disponibles en el ciclo de vida de desarrollo
Los niveles de prueba pueden combinarse o reorganizarse en funcin de la naturaleza del

proyecto o de la arquitectura del sistema

II/02 Niveles de prueba
Pruebas de Componente
Objetivo
Encontrar defectos y verificar el funcionamiento de un componente
Un componente es la menor parte testeable de una aplicacin
Posible de ser probado de manera separada
Probados para determinar si estn aptos para su uso
Pruebas de Mdulo
Pruebas de Clase
Pruebas de Unidad o Unitarias
Pruebas de Desarrollador
Bases de prueba
Especificaciones de requisitos de componentes

Diseo detallado
Cdigo
Objetos de prueba tpicos
Componentes / clases / unidades / mdulos

Programas
Conversin de datos / migracin de programas
Mdulos de base de datos

Arns de Pruebas (Test Harness)
La ejecucin de pruebas de componente requiere frecuentemente controladores (drivers) y stubs
Un arns de Pruebas es un entorno de pruebas constituido por controladores y stubs necesarios

para llevar a cabo una prueba
Un controlador sustituye a un componente que asume el control y/ o la invocacin a un

componente o sistema
Crea las entradas (Inputs) necesarias para el componente a probar y despus lo invoca
Un stub sustituye a un componente llamado
Funciona como suplente del componente subordinado y proporciona el comportamiento

mnimo requerido para ese componente
Pruebas de Integracin
Prueban interfaces entre componentes, e interacciones con distintas partes de un mismo sistema
Bases de prueba
Diseo del software y del sistema

Arquitectura
Flujos de trabajo (workflows)
Casos de uso
Subsistemas
Implementacin de base de datos
Infraestructura
Interfaces
Configuracin de sistema y de datos
10

Estrategias de Integracin
Ad hoc
Incremental
Ascendente (Bottom-Up)
Descendente (Top-Down)
Big Bang
Ad hoc
Objetivo
Los mdulos se conectan de la misma manera que se producen
Ventajas
Posibilidad de ganancias de tiempo
No se espera por el componente concreto que debe ser integrado
Desventajas
Estn listos para ser integrados
Se necesitan controladores (drivers) y stubs para las pruebas
Ascendente (Bottom-Up)
Objetivo
Los componentes de nivel ms bajo se integran primero y, a continuacin, se utilizan

para facilitar la integracin de componentes de nivel superior.
El proceso se repite hasta que se integra el componente de la parte superior de la
jerarqua
Ventajas
No hay necesidad de stubs

No se pierde tiempo esperando que todos los mdulos estn desarrollados
11

Desventajas
Descendente (Top-Down)
Objetivo
Los componentes en la parte superior de la jerarqua de componentes son integrados

en primer lugar, mientras que los componentes de nivel inferior son simulados por
stubs
Los componentes probados, a continuacin, se utilizan para integrar los componentes
de nivel inferior
El proceso se repite hasta que se integran los componentes de nivel ms bajo
Ventajas
No hay necesidad de controladores

No se pierde tiempo esperando que todos los mdulos estn desarrollados
Posibilidad de presentar al usuario un temprano prototipo
Desventajas
Mdulos crticos, en el nivel superior, que controlan el flujo de la aplicacin se

prueban al ltimo y pueden ser propensos a defectos.
Se puede utilizar solo para sistema de construccin jerrquica
Son necesarios controladores para reemplazar mdulos que estn arriba en la
jerarqua
Se puede utilizar solo para sistema de construccin jerrquica

Son necesarios varios stubs para reemplazar mdulos que estn abajo en la jerarqua
Big Bang
Objetivo
Los mdulos se integran cuando todos estn listos.

Todos los mdulos se integran a la vez.
Ventajas
No se necesitan ni controladores ni stubs

Todos los mdulos estn listos
12

Desventajas
La localizacin de defectos es dificultosa, y consume mucho tiempo

Es para sistemas pequeos
Pruebas de Sistema
Bases de prueba
Especificacin de requisitos
Casos de uso y procesos de negocio
Especificaciones funcionales
Informes de anlisis de riesgos
Manuales de sistema, usuario y operaciones
Se controlan escenarios completos de extremo a extremo, y la manera en que un usuario/

cliente podra usar el sistema
Configuracin del sistema

Datos de configuracin
Comprobar el cumplimiento de requisitos (funcionales y no funcionales) especificados
El alcance est definido en el Plan Maestro de Pruebas o en Plan de Pruebas de Nivel
La calidad del software es observada desde el punto de vista del usuario
Implementacin completa y correcta de los requisitos
Las caractersticas de la calidad de los datos son la base para las pruebas
El ambiente de pruebas debera coincidir con el ambiente real
No se realizan pruebas en el entorno real !
13

Pruebas de Aceptacin
Determinar si los requerimientos especificados fueron o no cumplidos
El objetivo es proporcionar la confianza de que el sistema entregado cumple con los requisitos de
negocio
Bases de prueba
Requisitos de usuario y de sistema

Casos de uso y procesos de negocio
Informes de anlisis de riesgo
Procesos de negocio en sistemas completamente integrados

Procesos de operaciones y mantenimiento
Procedimientos de usuario
Formularios e informes
Datos de configuracin
Aceptacin Contractual y de Regulacin
El software satisface todos los requisitos contractuales?
Con la aceptacin formal se cumplen hitos legales
comienzo de fase de garanta, hitos de abono (pago), acuerdos de mantenimiento,

etc.
Criterios de aceptacin verificables definidos en el momento del acuerdo contractual

constituyen una garanta para ambas partes
Las pruebas de aceptacin deben tener en cuenta normas y reglamentos gubernamentales,

legales, industriales y de otro tipo
Pruebas de Aceptacin de Usuario
El cliente selecciona casos de prueba para las pruebas de aceptacin
Las pruebas se realizan utilizando el entorno del cliente
El entorno del cliente puede producir nuevos fallos
14

Pruebas de Aceptacin Operativa
Requiere que el software sea adecuado para su uso en un entorno de produccin
Integracin del software en la infraestructura TI del cliente
Copias de seguridad / restauracin de sistemas, reinicio, instalacin, capacidad de

ser desinstalado, recuperacin en caso de desastres, etc.
Gestin de usuarios, interaccin con ficheros y estructuras de directorios en uso
Compatibilidad con otros sistemas
Tareas de mantenimiento
Tareas de carga y migracin de datos
Con frecuencia, las pruebas de aceptacin operativa son realizadas por el administrador de
sistemas del cliente
Pruebas Alfa
Pruebas realizadas por equipos de prueba independientes, clientes potenciales o interesados, en

instalaciones propias de desarrollo
Se realizan principalmente para software de distribucin masiva (Commercial Off-The-Shelf

software, COTS) como una forma de pruebas de aceptacin interna antes de mover el software
para pruebas beta
Pruebas Beta
Se realizan despus de las pruebas alfa, como pruebas de aceptacin externa de software de
distribucin masiva, para adquirir retroalimentacin del mercado
Pruebas realizadas por usuarios / clientes actuales o potenciales en una instalacin externa, sin la
actuacin de desarrollo
Se llevan a cabo en un ambiente no controlado por desarrollo
Se prueba si el software satisface las necesidades de negocio u operacionales de los cliente y

usuarios finales
15

II/03 Tipos de prueba
Tipos de Prueba
Un tipo de prueba se centra en un objetivo de prueba en particular
Prueba de una funcin a ser realizada por el software
Una caracterstica de calidad no funcional
La estructura o arquitectura del software o sistema
Pruebas de confirmacin y de regresin
Distintos tipos de prueba se aplican durante los distintos niveles de prueba
Tipos de prueba
Pruebas funcionales
Pruebas no funcionales
Pruebas estructurales
Pruebas asociadas al cambio
Pruebas funcionales
Objetivo
Probar la funcin / verificar los requisitos funcionales
La funcionalidad puede ser vinculada a los datos de entrada y salida de un objeto de

prueba
Los mtodos de caja negra se utilizan en el diseo de casos de prueba relevantes
Las pruebas funcionales se pueden llevar a cabo en todos los niveles de prueba
Pruebas de seguridad
Tipo de prueba funcional que aborda amenazas externas
Ataques maliciosos podran daar programas o datos
16

Pruebas no funcionales
Objetivo
Probar las caractersticas del producto
De qu forma el software lleva a cabo sus funciones?
Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad, Portabilidad
Las pruebas no funcionales se pueden llevar a cabo en todos los niveles
Pruebas no funcionales tpicas:
Pruebas de rendimiento, de carga, de volumen, de estrs
Prueba de fiabilidad y robustez
Pruebas de usabilidad, de configuracin
Prueba de rendimiento
Prueba de carga
Procesamiento de grandes cantidades de datos / ficheros
Prueba de estrs
Sistema bajo carga (carga mnima, ms usuarios / transacciones)
Prueba de volumen
Rapidez con la cual un sistema ejecuta una determinada funcin
Reaccin a la sobrecarga / recuperacin tras el retorno a un carga normal
Prueba de robustez
Reaccin a entradas errneas o datos no especificados
Reaccin a fallos hardware / recuperacin ante situaciones de desastre
17

Pruebas de cumplimiento
Pruebas de usabilidad
Cumplir normas y reglamentos (interno / externo)
Estructurado, comprensible, fcil de aprender por parte del usuario
Otros aspectos no funcionales de calidad
Portabilidad
Mantenibilidad
Fiabilidad (tolerancia a fallas)
Pruebas estructurales
Objetivo
Probar la estructura, la arquitectura software
Enfoque de prueba de 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
Las pruebas estructurales son posibles en todos los niveles de pruebas
La cobertura del cdigo se realiza de forma conjunta a las pruebas de componente y de

integracin mediante el uso de herramientas
El diseo de pruebas estructurales se finaliza tras haber sido diseadas las pruebas funcionales,
con el propsito de obtener un alto grado de cobertura
18

Pruebas asociadas al cambio
Objetivo
Probar despus de cambios
Despus de que un objeto de pruebas o el ambiente de su sistema ha sido objeto de

modificacin
Criterios para la seleccin de casos de prueba de regresin:
Casos de prueba de prioridad alta

Probar solamente la funcionalidad estndar, saltarse casos y variaciones especiales
Probar solamente la configuracin utilizada con mayor frecuencia
Probar solamente subsistemas / zonas seleccionadas del objeto de pruebas
II/04 Pruebas de mantenimiento
Pruebas posteriores a la aceptacin del producto
El cliente ha aprobado el producto y es puesto en produccin
El ciclo de desarrollo inicial, incluidas las pruebas asociadas, ha sido completado
El mismo software se encuentra al comienzo del ciclo de vida:
Ser utilizado por muchos aos, ser ampliado
Es muy probable que an contenga defectos, por lo tanto ser modificado y corregido
Necesitar adaptarse a nuevas condiciones y deber integrarse a nuevos entornos
Necesitar cambiar o extender los datos de configuracin
Ser retirado, se extraer del entorno de produccin
Cualquier nueva versin del producto, cada nueva actualizacin y cada cambio del software
requiere pruebas adicionales!
19

El mantenimiento de software cubre dos campos diferenciados:
Mantenimiento tal como: correccin de errores o implementacin de hot-fixes, que han

sido parte de la versin inicial del software
Distribuciones de software planificados: adaptaciones como resultado una modificacin /

cambio del entorno o nuevos requisitos del cliente
Alcance de las pruebas de mantenimiento:
Hot-fixes y la correccin de defectos requieren la repeticin de pruebas
La ampliacin de la funcionalidad requiere nuevos casos de prueba
La migracin a otra plataforma requiere pruebas operativas
Adicionalmente, son necesarias pruebas de regresin intensivas
El alcance de las pruebas depende del impacto del cambio
El anlisis de impacto se utiliza para determinar las reas afectadas con el objeto de
decidir la cantidad de pruebas de regresin
Pueden ocurrir problemas si la documentacin del software antiguo falta o es incompleta
Retirada del software
Las pruebas tras la retirada del software pueden incluir:
Pruebas de migracin de datos
Verificacin del archivo de datos y programas
Pruebas en paralelo de sistemas nuevo y su antecedente
20

Captulo III - Tcnicas Estticas
Contenido
Captulo III - Tcnicas estticas
III/01 Tcnicas estticas y el proceso de pruebas

III/02 Proceso de revisiones
III/03 Anlisis esttico con herramientas
III/01 Tcnicas estticas y el proceso de pruebas
Tcnicas estticas
No se ejecuta el cdigo
Manuales - Revisiones
Automatizadas - Anlisis Esttico
Las tcnicas estticas complementan los mtodos dinmicos
Las pruebas estticas detectan causas de fallas (defectos) en lugar de fallas
Los conceptos tambin son analizados, no slo el cdigo ejecutable
Los defectos / desviaciones son detectados en una fase temprana
Las pruebas estticas pueden descubrir defectos que no son detectables en las pruebas
dinmicas
Documentos de alta calidad conducen a productos de alta calidad
Incluso si una especificacin revisada no contiene ningn defecto, la interpretacin de la

especificacin y creacin del diseo pueden ser defectuosas
21

Objetivos de las revisiones
Las revisiones se realizan con el objeto mejorar la calidad del producto
Defectos tpicos:
Desviaciones de los estndares

Defectos de requisito
Defectos de diseo
Mantenibilidad insuficiente
Especificaciones de interface incorrectos
Ventajas y desventajas de las revisiones
Ventajas
Costos ms bajos y un alto potencial de ahorro
Los defectos en la documentacin son detectados y corregidos de forma temprana
Los documentos de alta calidad mejoran el proceso de desarrollo
Mejora el ndice de comunicacin / intercambio de conocimiento
Desventajas
Se podran presentar situaciones de tensin en el caso de enfrentamientos directos con el

autor
Los expertos involucrados en las revisiones deben adquirir conocimientos especficos del
producto, es necesaria una buena preparacin
Inversin considerable de tiempo (del 10% - 15% del presupuesto total)
Moderador y participantes influyen directamente en la calidad de la revisin
22

III/02 Proceso de revisiones
Revisiones Informales y Formales
Informales
Ocurren espontneamente entre pares
Los revisores no tienen necesariamente ninguna responsabilidad, y no tienen que producir

un informe de la revisin
Formales
Son cuidadosamente planificadas
Los revisores son responsables por su participacin, y se genera un informe de la revisin

que contiene elementos de accin
Actividades de una Revisin Formal
* Planificacin
* Definir los criterios de la revisin
* Seleccionar el personal
* Asignar los roles
* Definir los criterios de entrada y de salida
* Seleccionar las partes del documento a revisar
* Controlar los criterios de entrada
* Inicio (Kick-off)
* Distribuir documentos
* Explicar los objetivos, procesos y documentos a los participantes
* Preparacin individual
* Revisar los documentos antes de la reunin de revisin
* Anotar potenciales defectos, preguntas y comentarios
23

* Reunin de revisin
* Discutir o registrar, con resultados documentados o minutas
* Anotar defectos, dar recomendaciones sobre el manejo de los defectos,
realizar decisiones sobre los defectos
* Examinar, evaluar y registrar los temas durante reuniones fsicas o
realizar el seguimiento de comunicaciones electrnicas de grupo
* Correccin del trabajo (Rework)

* Corregir los defectos encontrados
* Registrar el estado actualizado de los defectos
* Seguimiento (Follow-up)
* Comprobar que los defectos han sido tratados
* Recopilar mtricas
* Comprobar los criterios de salida
Roles y Responsabilidades
Roles de una Revisin Formal tpica
Jefe de Proyecto (Manager, Gerente)
Decide sobre la ejecucin de las revisiones

Asigna tiempo en el calendario del proyecto
Determina si se han cumplido los objetivos de la revisin
Moderador
Lidera la revisin del o de los documentos

Planifica la revisin, ejecuta la reunin, y realiza el seguimiento posterior
Puede mediar entre los varios puntos de vista
Sobre quien recae la responsabilidad del xito de la revisin
24

Autor
Redactor o principal responsable de los documentos a ser revisados

Expone su trabajo a la crtica, lleva a cabo los cambios recomendados
Revisores (Inspectores, Comprobadores, Chequeadores)
Personas con un bagaje tcnico o de negocio especfico
Despus de la preparacin necesaria, identifican y describen los descubrimientos (por

ejemplo, defectos) en el producto bajo revisin
Deben ser elegidos para representar diferentes perspectivas y roles en el proceso de

revisin
Deben tomar parte en cualquier reunin de revisin
Escriba (Redactor, Registrador)
Documenta todos los asuntos, problemas y puntos abiertos que fueron identificados
durante la reunin
Tipos de Revisiones
1. Revisin Informal (Informal Review)

2. Revisin Guiada (Walkthrough)
3. Revisin Tcnica (Technical Review)
4. Inspeccin (Inspection)
IEEE STD 1028-2008 - IEEE Standard for Software Reviews and Audits
25

1. Revisin Informal
Ningn proceso formal
Propsito principal: Forma econmica de obtener algn beneficio
Programacin por pares

Lder tcnico revisando diseos y cdigo
Los resultados pueden ser documentados
Su utilidad varia dependiendo de los revisores
2. Revisin Guiada
Reunin liderada por el autor

Escenarios, ensayos generales, participacin de grupo de pares
Sesiones abiertas
Preparacin pre-reunin de los revisores (Opcional)

Preparacin de reporte de revisin (Opcional)
Escriba(Opcional)
Propsitos principales: Aprender, Comprender, Encontrar defectos
De muy informal a formal
3. Revisin Tcnica
Proceso de deteccin de defectos documentado y definido que incluye pares y expertos

Puede ser realizada como una revisin entre pares sin la participacin de la gestin
Idealmente conducida por un moderador entrenado
Propsitos principales: Discutir

Tomar decisiones
Evaluar alternativas
Encontrar defectos
Solucionar problemas tcnicos y comprobar conformidad
Preparacin pre-reunin de los revisores

Uso de listas de comprobacin (Opcional)
Preparacin de un reporte de revisin
De muy informal a formal
26

4. Inspeccin
Liderada por un moderador entrenado

Usualmente conducida como un examen entre pares
Roles definidos
Incluye recopilacin de mtricas
Proceso formal basado en reglas y listas de comprobacin
Propsito principal: Encontrar defectos
Criterios de entrada y de salida para la aceptacin del software

Preparacin pre-reunin
Reporte de inspeccin incluyendo lista de descubrimientos
Proceso formal de seguimiento
Mejora de proceso y lector (Opcional)
Factores de xito de una revisin
Cada revisin tiene un claro objetivo predefinido
Estn involucradas las personas adecuadas para los objetivos de la revisin
Los probadores son revisores valorados que contribuyen a la revisin y tambin aprenden sobre el
producto
Los defectos encontrados son bienvenidos y expresados objetivamente
Los problemas de las personas y los aspectos psicolgicos son tratados
La revisin es conducida en una atmsfera de confianza
Se aplican las tcnicas de revisin adecuadas
Listas de comprobacin o roles son usados para aumentar la identificacin de defectos
Se brinda entrenamiento en tcnicas de revisin
La gestin da soporte a un buen proceso de revisin
Existe un nfasis en el aprendizaje y en la mejora del proceso
27

III/03 Anlisis esttico con herramientas
Anlisis Esttico
Analizar un objeto de prueba sin ejecutar el objeto de prueba

Todos los objetos de prueba deben tener una estructura formal
Principalmente cuando se utilizan herramientas de pruebas
Con el uso de herramientas, se requiere menos esfuerzo que en una revisin para revisar un
programa
Compiladores
Analizadores
Valor del anlisis esttico
Deteccin temprana de defectos antes de la ejecucin

Deteccin temprana sobre aspectos sospechosos del cdigo o diseo
Identificacin de defectos difcilmente encontrados por las pruebas dinmicas
Detectar dependencias e inconsistencias en los modelos de software
Mantenibilidad mejorada del cdigo y del diseo
Prevencin de defectos, si las lecciones son aprendidas en el desarrollo
Defectos tpicos descubiertos por las herramientas
Referencia a una variable con un valor indefinido

Interfaces inconsistentes entre mdulos y componentes
Variables que no se usan o estn declaradas en forma incorrecta
Cdigo inalcanzable (muerto)
Lgica faltante y errnea (bucles potencialmente infinitos)
Construcciones excesivamente complicadas
Violaciones de estndares de programacin
Vulnerabilidades de seguridad
Violaciones de sintaxis de cdigo y de modelos de software
28

Las mtricas
Ciertos aspectos de la calidad de un programa pueden ser medidos utilizando mtricas
La complejidad esttica de un programa puede ser medida
Mtricas diferentes tratan aspectos diferentes de la complejidad de programa
Tamao del programa (por ejemplo, lneas de cdigo)
Estructuras de control del programa (por ejemplo, nmero ciclomtico)
Es difcil comparar dos mtricas diferentes, incluso cuando ambas abordan el mismo
atributo del programa!
Las mtricas - Nmero Ciclomtico (CC)
Nmero ciclomtico v(G) - McCabe -
v (G ) = e n + 2 p
Mide la complejidad esttica de un programa basada en su grafo de flujo de control
Testeabilidad y Mantenibilidad
El nmero ciclomtico se define de la siguiente forma:
Nmero de aristas: e (edges)
Nmero de nodos: n (nodes)
Nmero de componentes conectados: p (normalmente es igual a 1)
Hasta 10 es aceptable
29

v(G ) = e n + 2 p
El grfico de la derecha tiene:
1 partes independientes: p = 1
9 nodos:
n=9
10 aristas:
e = 10
Esto conduce al nmero ciclomtico:

v(G)= e n + 2p
v(G)= 3
IF P = T
CARRY OUT THIS
IF X = 10
CARRY OUT THE OTHER
ELSE
CARRY OUT THAT
ENDIF
ENDIF
* Grfico de Flujo de Control / Control Flow Graph (CFG)
El CFG tiene 2 regiones, 4 nodos y 5 aristas.
N de Regiones + 1
N de Aristas - N de Nodos + 2
CC = 3
30

Los grficos de flujo de control no deben mostrar ninguna instruccin, pero para facilitar la comprensin,
pueden mostrarse instrucciones, tal como se muestra en el grfico de la derecha:
1 IF P = T
2 CARRY OUT THIS
3 IF X = 10
4
CARRY OUT THE OTHER
ELSE
5
CARRY OUT THAT
6 ENDIF
7 ENDIF
El CFG tiene 2 regiones, 7 nodos y 8 aristas.
N de Regiones + 1
N de Aristas - N de Nodos + 2
CC = 3
Nmero ciclomtico
El grafo de la derecha tiene:
1 partes independientes: p = 1
6 nodos:
n=6
7 aristas:
e=7
Esto conduce al nmero ciclomtico:

v(G)= e n + 2p
v(G)= 3
Nmero de Decisiones + 1
31

Por ejemplo: IF A=1 AND B=1
Mtodo de McCabe = CC = CC1 => +1
Mtodo Extendido = CC2 = Complejidad Ciclomtica Extendida = ECC => +2
Operadores lgicos / booleanos => CC2 = CC1 + Booleanos
CC3 = Complejidad Ciclomtica sin Cases = Complejidad Ciclomtica Modificada
32

II - III - Istqb CTFL

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

II - III - Istqb CTFL

Hochgeladen von

Copyright:

Verfügbare Formate

Luis Mercadal & Asociados

Curso Oficial de ISTQB Certified Tester Foundation Level

Pruebas a travs del Ciclo de Vida del Software + Tcnicas Estticas

Luis Mercadal & Asociados

Captulo II - Pruebas a travs del Ciclo de Vida del Software

II/01 Modelos de desarrollo de software

II/01 Modelos de desarrollo de software

Modelos de desarrollo de software

El proceso de pruebas no existe aislado

Diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques de prueba

Modelos de ciclo de vida del software

Modelo en Cascada (Modelo Lineal Secuencial)

Modelo en Cascada (Modelo Lineal Secuencial)

El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve

Luis Mercadal & Asociados

El desarrollo iterativo-incremental es el proceso de establecer requerimientos, disear,

Prototipos, Desarrollo Rpido de Aplicaciones (Rapid Application Development, RAD),

Desarrollo y pruebas son dos ramas iguales

Cada nivel de desarrollo tiene su correspondiente nivel de pruebas

Luis Mercadal & Asociados

Las pruebas no son slo una actividad basada en la ejecucin

Diseo Funcional del Sistema

Diseo Tcnico del Sistema

Especificaciones funcionales de los requisitos

Creacin de cdigo ejecutable

Rama de pruebas del software (rama derecha)

Luis Mercadal & Asociados

Verificacin y Validacin (V & V)

Verificar - comprobar la evidencia, substanciar

Comprobacin de la conformidad con los requisitos establecidos

Se est construyendo el producto software de la manera correcta?

Hemos sumado 1 ms 1 correctamente?

Validar - dar prueba de la aportacin de valor

Comprobacin de la idoneidad para el uso esperado

Se est construyendo el producto software correcto?

El objetivo era sumar 1 ms 1 o deberamos haber restado?

El papel de la verificacin implica comprobar que el software est de acuerdo con su

Luis Mercadal & Asociados

La validacin se refiere a la correccin de cada nivel de desarrollo

Modelos Iterativos e Incrementales

Las pruebas de regresin y la automatizacin de pruebas son elementos/ factores de gran

En cada iteracin, la verificacin (relacin con el nivel precedente) y la validacin (grado de

Luis Mercadal & Asociados

Se aplican de manera regular un conjunto de buenas prcticas para trabajar colaborativamente, en

Cliente (Product Owner)

Desarrollo de Software Guiado por Pruebas / Test Driven Development (TDD)

Ciclo de desarrollo guiado por pruebas

Aadir una prueba

Repetir el ciclo con una nueva prueba

Luis Mercadal & Asociados

Herramientas para automatizar las pruebas unitarias

Si se aplica mal o a medias el TDD pueden surgir los siguientes problemas:

La calidad de la prueba depende del conocimiento del desarrollador

Caractersticas de buenas pruebas en todo modelo

Para cada actividad de desarrollo existe una actividad de prueba correspondiente

Los niveles de prueba pueden combinarse o reorganizarse en funcin de la naturaleza del

Luis Mercadal & Asociados

II/02 Niveles de prueba

Encontrar defectos y verificar el funcionamiento de un componente

Un componente es la menor parte testeable de una aplicacin

Posible de ser probado de manera separada

Probados para determinar si estn aptos para su uso

Pruebas de Unidad o Unitarias