936 Lacalidaddelsoftwareylosprocesosdetesting PDF

La Calidad del
Software y los
Procesos de
Testing
GFI Informática
La Calidad del Software y los Procesos de Testing
Índice
Introducción. Visión general del proceso de

pruebas.
Metodologías de pruebas alineadas con
procesos de desarrollo
Uso de herramientas OpenSource
Aspectos diferenciadores herramientas
comerciales frente a OpenSource
Factoría de pruebas
Índice
Introducción. Visión general del proceso

de pruebas.
comerciales frente a OpenSource
Introducción. Definición de calidad software
“La calidad del software es el grado con el que

un sistema, componente o proceso cumple los
requerimientos especificados y las necesidades o
expectativas del cliente o usuario”. (IEEE, Std.
610-1990).
“Concordancia del software producido con los
requerimientos explícitamente establecidos, con
los estándares de desarrollo prefijados y con los
requerimientos implícitos no establecidos
formalmente, que desea el usuario” (Pressman,
1998)
Introducción
Visión General del Proceso de Pruebas
El software lo desarrollan las personas, y éstas comenten errores; no
se puede prevenir completamente la introducción de éstos defectos,
pero si se puede trabajar para localizarlos especialmente los mas
críticos.
Decisiones de pruebas deberían basarse en satisfacción del cliente.
Este es el objetivo último.
Mayor parte de los defectos se concentran en las etapas tempranas
del proceso de desarrollo y el costo de corrección aumenta a medida
que permanece no detectado.
De perogrullo: los defectos mas costosos son aquellos que no se
detectan.
Introducción
Visión General del Proceso de Pruebas
El proceso de Pruebas es una parte del ciclo de vida del
Software.
Interviniendo desde la concepción detallada de la aplicación
y colaborando hasta su puesta final en producción, dando
así en su conjunto un alto nivel de calidad.
Planificación Estandar
Planificación Estandar Evolución Real
Evolución Ideal
Ideal Pruebas
Pruebas
Planificación Estandar Evolución Real Ideal Pruebas
INTEGRACIÓN
INTEGRACIÓN
INTEGRACIÓN
CODIFICACIÓN
CODIFICACIÓN
INTEGRACIÓNINTEGRACIÓN
CODIFICACIÓN
DETALLADO
PRUEBAS
PRUEBAS
PRUEBAS
DETALLADO
DISEÑO DETALLADO
NIVEL
ALTONIVEL
CODIFICACIÓN
DISEÑO ALTO NIVEL
INTEGRACIÓN
DISEÑO
DISEÑOALTO
PRUEBAS
DISEÑO
REQUISITOS
REQUISITOS
PRUEBAS
DISEÑO
REQUISITOS
PRUEBAS
Introducción – Algo mas que pruebas Software
Pruebas
Software
Gestión del
Ciclo de
Vida de la
Calidad
Software
Introducción
La falta de cualquiera de estos vertices implica
problemas evidentes:
Carencia Problema Metodología
Herramientas Falta de
Productividad
Metodología Proceso
caótico y no
repetible
Herramientas Recursos
Índice

pruebas.
comerciales frente a open-source
Metodologías de Pruebas alineadas con procesos de desarrollo
Introducción
La evolución de los modelos específicos de test aumenta
satisfactoriamente la calidad de dichos procesos y
consecuentemente, los coloca en una posición relevante dentro
de la ingeniería del software.
Los modelos y estándares de evaluación de procesos de
software ofrecen herramientas para establecer niveles de
madurez de desarrollo y mantenimiento del software. Sin
embargo, la sido constatado que estos modelos y estándares no
dirigen adecuadamente sus enfoques a los procesos de test. En
este sentido, se presentan, a continuación, tres modelos de
evaluación y mejora de procesos de test:
Acercamiento a la gestión de pruebas (Test Management
Approach, TMap)
Modelo de Mejora del Proceso de test (Test Process Improvement,
TPI)
Modelo de Madurez del Test (Test Maturity Model, TMM)
Metodologías de pruebas alineadas con procesos de desarrollo
TMap
TPI
TMM
Metodologías - TMap
La metodología TMAP, está basada en cuatro piedras

angulares:
Proceso de desarrollo relacionado con el modelo de
ciclo de vida para las actividades de pruebas (L)
Sólida Organización (O)
Recursos e Infraestructura (I)
Técnicas utilizables para varias actividades de
pruebas (T)
Modelo de ciclo de vida de Pruebas

Técnicas
Infraestructura y Herramientas
Organización
TMap
TPI
TMM
Metodologías - TPI
El modelo TPI está basado en las mejores prácticas de la industria
relativas a la mejora del proceso de pruebas. El modelo incluye guías
prácticas para evaluar el nivel de madurez de pruebas de una
organización así como los pasos para mejorar el proceso.
El propósito de tales mejoras podría ser alcanzar el nivel 3 del SEI-
CMM ( Capability Maturity Model ).
El modelo se compone de 20 Áreas
Clave, cada una con diferentes
niveles de madurez. Los niveles de
todas las Áreas Clave están integrados
en una Matriz de Madurez. Cada
nivel está descrito por varios Puntos
de Verificación. También forman
parte del modelo algunas
Sugerencias de Mejora que ayudan
a alcanzar el nivel deseado.
Metodologías - TPI
Niveles
Puntos de Verificación
Los requisitos para cada nivel están
definidos en forma de Puntos de
Verificación ( Checkpoints ): son
preguntas que necesitan ser respondidas
afirmativamente para poder calificar a
dicho nivel. A partir de las listas de
verificación se puede evaluar un proceso
de pruebas y se puede determinar para
cada Área Clave el Nivel alcanzado. A
medida que se considera mejorada cada
Área Clave, los Puntos de Verificación
son acumulables: para poder clasificar
para el nivel B, el proceso de pruebas
necesita responder afirmativamente
tanto a los Puntos de Verificación del
nivel B como del nivel A.
Metodologías - TPI
Matriz de Madurez
Todos los Niveles y Áreas Clave
están interrelacionados en una
Matriz de Madurez de Optimizada (11-13)
Pruebas. Se ha concebido como
una buena manera de expresar
las prioridades internas y Eficiente (6-10)
dependencias entre Niveles y
Áreas Clave. Controlada (1-5)
No existe graduación entre
Niveles: mientras que un
proceso de pruebas no esté
clasificado enteramente como
nivel B, permanecerá en el nivel
A.
El propósito principal de la matriz es mostrar los puntos fuertes y débiles del
actual proceso de pruebas y ofrecer una ayuda a la hora de determinar la prioridad
de las acciones de mejora.
Metodologías - TPI
Aplicación del Modelo TPI
El proceso de mejora de pruebas es similar a
cualquier otro proceso de mejora. La figura
siguiente muestra las diferentes actividades de un
proceso de mejora.
TMap
TPI
TMM
Metodologías - TMM
El modelo TMM es un modelo de

evaluación del proceso de test,
guiado por el conjunto básicos de
conceptos del CMM y compuesto
por dos componentes
principales: un conjunto de
niveles de madurez y un
modelo de evaluación.
Metodologías – TMM: Conjunto de Niveles
Se describe cada nivel considerando los objetivos de la organización y la
capacidad de test.
La estructura de cada nivel (excepto el primero), consiste en un conjunto
de objetivos de madurez soportado por sub-objetivos (o metas) de
madurez que son alcanzados por las actividades, tareas y
responsabilidades.
Las actividades y tareas
representan las acciones que deben
ser desempeñadas en cada nivel
con el propósito de mejorar la
capacidad del test
Se asignan responsabilidades para
las actividades y tareas, a los
gestores, a los desarrolladores y
testers y a los usuarios y clientes
Metodologías – TMM: Modelo de Evaluación
El Modelo de Evaluación consiste en un método

que permite a la organización evaluar y mejorar sus
procesos de test, basándose en un cuestionario de
evaluación, un procedimiento de evaluación y el
entrenamiento y criterios de selección del equipo de
evaluación.
Los objetivos de este componente son: proveer un
esquema de evaluación de procesos de test de
software y un fundamento para la mejora de
dichos procesos a través de análisis de datos y
planteamiento de acciones, así como contribuir con la
ingeniería del proceso de software.
Índice

pruebas.
comerciales frente a open-source
Uso de Herramientas Opensource
Gestión del Ciclo de Pruebas

Automatización de Pruebas Funcionales
Pruebas de Carga
Inspección de Código
Pruebas Unitarias

Pruebas de Carga
Pruebas Unitarias
Gestión del Ciclo de Pruebas - Algunas Claves
Documentar las pruebas
Casos de prueba, estrategia de pruebas, ejecuciones …
Registrar los problemas encontrados
Separar entornos y manejar configuraciones
Ensayando la implementación
Definir casos de prueba durante el análisis es una
forma de documentar el producto
Es una forma de adelantarnos al problema
Testing independiente
El que desarrolla no prueba
Mayor experiencia y concentración
Nadie está motivado para encontrar sus propios errores
Herramientas Opensource – Herramienta de Gestión
La gestión de las pruebas, requiere que la herramienta con

la que se trabaje cumpla algunas características como:
Soportar en paralelo el desarrollo de la aplicación y la gestión de las
pruebas
Trazabilidad de requisitos a pruebas gestionando ejecuciones así como
defectos y su resolución
Mejora la predictibilidad del proyecto
Acceso en cualquier momento y lugar a pruebas e informes de ejecución
Control centralizado
Mejora la colaboración y comunicación entre equipos y proyectos
Potencia la reutilización de objetos de prueba
Acceso protegido a elementos del proyecto
Sistema de informes
Como ejemplo, se muestra la herramienta TestLink.
TestLink, permite de manera intuitiva, la elaboración de casos

de prueba, con los pasos a seguir para su posterior ejecución,
así como de los resultados esperados, quedándose todo
ordenado y accesible a través de un árbol de navegación.
Durante todo el ciclo de vida se pueden obtener métricas tanto

del los casos de prueba generados como de estado de la
ejecución de los mismos.

Pruebas de Carga
Pruebas Unitarias
Herramientas Opensource – Automatización Pruebas Funcionales
Las herramientas de Automatización de pruebas

funcionales cumplen el siguiente ciclo de trabajo:
Planificación de pruebas automáticas
Registro de las acciones de usuario
Control y verificación de los Checkpoints
Comprobación resultado esperado = resultado obtenido
Gestión del mapa de interfaz de usuario
Testing modular y batch
Como ejemplo, tenemos la

herramienta Selenium, que nos
permite la operativa de trabajo
descrita.
Primeramente, se graban las

acciones del usuario sobre la
aplicación, quedándose éstas
recogidas en la aplicación para
su posterior tratamiento, que
se realizará modificando el
código generado
Prácticamente la totalidad de
las herramientas Opensource,
trabajan solo sobre
aplicaciones Web.
Los casos de prueba,

pueden ser modificados
para introducir puntos de
control, pausas,
verificaciones, etc.
La ejecución de los
mismos se puede
planificar, agrupando casos
y programándolos.
Se obtienen informes
sobre los resultados de las
ejecuciones.

Pruebas de Carga
Pruebas Unitarias
Herramientas Opensource – Pruebas de Carga
Las herramientas para la realización de pruebas de

Carga, tiene las siguientes funcionalidades
Planificación de pruebas de carga
Creación de los escenarios de prueba
Simulación de n usuarios concurrentes
Análisis de resultados de ejecución de los distintos
escenarios
A continuación podemos ver

la operativa ejemplificada
con la herramienta OpenSta
Para la ejecución del test, se introducen datos como

número de usuarios, scripts que compondrán la
ejecución y elementos a ser testados como %
Cpu,memoria, etc...
Durante la ejecución de la prueba, se puede

monitorizar todos los recursos que sean de nuestro
interés.
Posteriormente a la ejecución, se pueden obtener tanto log

como gráficas con las estadísticas de la prueba. Algunas de
ellas son las de puntos de medida respecto del tiempo,
puntos de medida respecto del número de usuarios, número
de usarios activos, errores HTTP, etc

Pruebas de Carga
Pruebas Unitarias
Uso de Herramientas Opensource . Inspección de Código
Las inspecciones del código tienen el objetivo de detectar
aspectos que influyen en la calidad de éste:
Errores de ejecución
Mermas de rendimiento
Código muerto
Redundancia de código
Incumplimiento de arquitectura
Incumplimiento de estándares técnicos a nivel de codificación.
Mantenibilidad del código
Metodología de trabajo:
Priorización: Se suele aplicar orientación al riesgo.
Medición: Uso de herramientas de análisis. Se obtienen métricas de
nivel técnico que permiten la detección de incumplimientos y/o
deficiencias, cuyo conjunto se expresa en:
Informes de auditoria.
Plan de mejora. Informe de recomendaciones para la mejora.
Entrega de una nueva versión
Nueva versión Publicar Integración Generación Publicación
software versión continua informes informes
Notificación vía Generación

mail informe SAC
Se realiza la entrega de una nueva

versión de software por parte del
proveedor.
Publicación de la nueva versión

mail informe SAC
Herramientas:
El jefe de proyecto
publica el entregable en
• CVS:
el repositorio común Implementa un sistema de gestión de
CVS
versiones.
Mantiene el registro de todo el trabajo y los
cambios en la implementación de un
proyecto, permitiendo la colaboración entre
distintos desarrolladores.
Es un referente en software libre de gestión
de versiones .
Proceso de integración continua

mail Informe SAC
El proceso de integración
continua (automático) Herramientas:
detecta la nueva versión
en el repositorio y
• Continuum v1.0.2:
ejecuta un conjunto de Servidor de integración continua.
tareas programadas
Realiza tareas programadas sobre
proyectos basados en java.
Alto grado de integración con Maven.
Notificación vía mail

mail Informe SAC
Se notificará por mail, al conjunto de

usuarios definidos, la nueva entrega.:
Jefe de proyecto.
SAC.
Etc.
Generación de informes automáticamente

mail informe SAC
Herramientas:
• Changelog v1.8.2 Se generarán
• QALab v0.7.2 automáticamente
• CheckStyle v2.5 los informes de
• JavaDoc Reporte v1.7 calidad
• Jcoverage v1.0.9 programados.
• Jdepend v1.5
• NCSS v1.3
• Pmd v1.6
• FindBugs v0.9.2
• File-Activity 1.5.2
Publicación de Informes

mail informe SAC
Herramientas:
• Maven v1.0.2:
Se publicarán de forma
Herramienta para la gestión y comprensión de proyectos java.
automática los informes
Estándar de mercado en el mundo free. generados en el portal de
Metodología XP. calidad
Herramientas:
• Apache v utilizada por explotación:
Servidor http referente del mercado.
Generación de resumen

mail informe SAC
El SAC generará un informe con los resultados de las

inspecciones realizadas al código:
• Resumen ejecutivo (dirección).
• Detalle técnico (equipo técnico).
Arquitectura
Internet Internet
CVS Continuum Apache

desarrollo
Equipo SAC
desarrollo
Responsable CVS Maven

proyecto SAC
Desarrollo
(entregas)
Gestió
Gestión Recursos Frontal
versiones SAC
Preexplotación Explotación

Pruebas de Carga
Pruebas Unitarias
Herramientas Opensource – Pruebas Unitarias
El peso de la generación de las pruebas unitarias recae

sobre el equipo de desarrollo.
La responsabilidad del equipo de SQA es la de ejecutar el
conjunto de pruebas unitarias, validar los resultados y
medir el grado de cobertura de las mismas.
El conjunto de pruebas unitarias proporcionadas por el
equipo de desarrollo debe cumplir los siguientes normas:
Ejecutables de forma automática.
Independencia del entorno.
Autocontenidas.
⌧Preprocesamiento.
⌧Ejecución.
⌧Postprocesamiento.
A continuación se muestra un ejemplo de la labor del
equipo de SQA en un conjunto de pruebas basadas en
Junit y Cobertura.
Junit es un framework ampliamente

utilizado para la automatización de
pruebas unitarias.
El equipo SQA ejecutará
las pruebas unitarias
proporcionadas por el
equipo de desarrollo
obteniendo un informe
con el resultado de la
ejecución de las mismas.
Cobertura es una herramienta opensource

que mide la cobertura de las pruebas por
medio de la instrumentalización del código y
la posterior medición de las líneas de código
ejecutadas por el conjunto de casos de
prueba unitarios.
El equipo de SQA instrumentalizaría el código
y posteriormente ejecutaría el conjunto de
pruebas unitarias analizando los resultados.
A continuación se muestra una salida

estándar de la herramienta:
Cobertura calcula la cobertura de las

pruebas contabilizando:
Número de líneas de código ejecutadas.
Número de ramas ejecutadas.
Adicionalmente Cobertura calcula la
complejidad ciclomática (Mc-Cabe) de
cada una de las clases.
La herramienta permite
realizar drill-down para
visualizar la cobertura de
las clases pertenecientes a
un determinado paquete
Y llegar al máximo detalle

visualizando las líneas de
código ejecutadas en una
determinada clase
Esta herramienta permite al equipo de SQA

validar el porcentaje de cobertura de las
pruebas unitarias realizadas por el
equipo de desarrollo, identificando
módulos poco probados o no probados.
Los resultados de la herramienta permiten
ampliar el plan de prueba unitario con
casos de prueba específicos que cubran el
código no testeado.
También permite identificar porciones de
código “muerto” que no es posible
ejecutar.
Índice

pruebas.
comerciales frente a Opensource
Aspectos diferenciadores Herramientas comerciales frente a Opensource
Ventajas OpenSource
¡Coste licencias es nulo!
Construidas con los mismos principios que las comerciales:
⌧ Arquitectura
⌧ Metodología/Técnicas
Extensibles/Integrables (Código abierto)
En algunos casos y para ciertos entornos, ¡son más potentes que las comerciales!
Inconvenientes OpenSource
Normalmente sólo disponibles para entornos web/java
Entornos de desarrollo “espartanos”
En ocasiones, lenguajes propietarios
En su desarrollo prima la funcionalidad básica frente a la avanzada y/o
utilidades/gadgets
El aprendizaje suele ser costoso
⌧ Material de formación muy básico o inexistente
⌧ No suele disponerse de guidelines metodológicos
Estabilidad/Fiabilidad
El soporte suele ser una incógnita (comunidades de usuarios/desarrolladores).
Normalmente es escaso o nulo
Ventajas Comerciales
Multientorno: web/java, middleware, C/S, legacy (mainframe)
Entornos de desarrollo
⌧ IDE gráficos plenos de utilidades
⌧ Lenguajes abiertos
Entornos de ejecución con herramientas de análisis, monitorización, diagnóstico, …
Robustez y Escalabilidad
⌧ Arquitecturas tolerantes a fallos
Metodología/Técnicas: El fabricante aporta las suyas propias
Integradas
⌧ Por supuesto las de un mismo fabricante
⌧ En muchas ocasiones, entre fabricantes
Integrables (mediante APIS)
Herramientas de Reporting potentes
⌧ Integradas con paquetes ofimáticos con su correspondiente plantillaje
⌧ Dashboards ejecutivos (Web)
Soporte técnico solvente (¡cuesta, pero existe!)
Inconvenientes Comerciales
Coste licencias. ¡Suele asustar!
Conclusiones:
Empezar con opensource no es mala idea:
En entornos web/java exclusivamente
Las herramientas funcionan
Parte del conocimiento adquirido es reaprovechable.
¡Pero ojo, hay que tener en cuenta los costes!
Hay un sobreesfuerzo asociado al uso de opensource con
respecto a comerciales (la productividad no es la misma)
que hay que tener en cuenta:
⌧ Un proyecto grande o varios proyectos pequeños pueden
justificar la inversión en comerciales
Migrar de opensource a comerciales tiene un coste de
reciclaje técnico
Definitivamente, en algún momento tendremos que
adquirir alguna herramienta comercial:
Por adecuación al entorno
Por limitaciones en la funcionalidad de las opensource
Por necesidades de reporting avanzado
¿Por capricho? ¿A quién no le gusta el Ferrari?
Herramientas Comerciales
Gestión de
Pruebas
Automatiza- Carga y
ción Estrés
Reporte de Pruebas
Incidencias Manuales
Índice

pruebas.
comerciales frente a Opensource
Factoría de Pruebas - Conceptos
Grupo dedicado que provee testing como un servicio

compartido
Emplea un conjunto de personas que se especializan
en uno o múltiples tipos de testing o uno o mas
dominios de negocio o tecnológicos.
Entre los roles de una Factoría de Pruebas se pueden
incluir:
Definición de los procesos y estándares de testing a ser
adoptados por los proyectos
Implantación de los procesos y estándares definidos
Provisión de personal cualificado y entrenado a los proyectos
Planificación y ejecución de testing para varios proyectos
Factoría de Pruebas- Tradicional vs FdP
Acercamiento Tradicional Factoría de Pruebas

Se contrata al equipo de test por proyecto, Se contrata al equipo de test para múltiples
dependiendo de la disponibilidad de los proyectos basados en compromisos
recursos
Los desarrolladores se emplean como Se emplean tester especializados con
testers durante las últimas etapas del habilidades y que han sido entrenados para
proyecto realizar testing
Se dedican diferentes testers durante las Se dedica un pool de recursos de testing
diferentes etapas del proceso de testing o a para uno o mas proyectos
través de diferentes proyectos
Los procesos de testing son implementados Se aprovechan los procesos de testing a
inconsistentemente a través de los través de los diferentes proyectos –
proyectos Consistencia
Posible duplicación de habilidades y Se aprovecha óptimamente las diversas
entrenamiento a través de los diferentes habilidades a través de los diferentes
proyectos proyectos
Factoría de Pruebas – Requisitos de una Factoría de Pruebas
Centro de pruebas externo Entregar código fuente

Proyectos de Pruebas Entornos altamente emulables
Interlocución a través del cliente
Pruebas 80% caja negra
Ciclo de vida iterativo –
incremental
Factoría de Pruebas – Funcionalidad
Gestión de la configuración SW
Aseguramiento de la Calidad
Help Desk
Gestión de Clientes
Gestión de Pruebas
Seguridad
Factoría de Pruebas – Operativa
Factoría de Pruebas – Perfil del Proveedor
Experiencia probada en:

Trabajar (“testear”) en el entorno de negocio del Cliente
Trabajar en formato Factoría de Pruebas, con todas sus implicaciones
⌧ Comunicación
⌧ Gestión del proceso
⌧ Gestión de la Infraestructura
⌧ Formación
Alcance de su experiencia
Tipos de Test
Entornos de Test
Testing basado en riesgo
Experiencia en su dominio específico del negocio
Empleados propios y con experiencia en testing
Disponibilidad de equipamiento, infraestructura, herramientas
Flexibilidad y adaptabilidad
Niveles de servicio ofrecidos
Factoría de Pruebas – Composición del Equipo
Factorías de Pruebas focalizadas en el cliente
Equipo base + recursos bajo demanda

Diferentes acercamientos
Focalizados en tipo de testing
⌧ Web Testing, Load and Performance testing, Localización
Focalizados en herramientas
Focalizados en Tecnologías
⌧ Web, .Net, Java, Cliente/Servidor, Mainframe
Mayores ventajas hacia nuestros clientes en términos
de:
Competencias técnicas
Reutilización de infraestructuras, test wares...
Retención de conocimiento
Optimización de los procesos
Factoría de Pruebas – Que ha funcionado con los clientes
Desafíos iniciales
Justificación de costos iniciales para el cliente
Falta de sinergia a través de diferentes áreas de negocio del cliente
Sin certeza de por donde empezar y como proceder
Conflictos entre estandarización del proceso y el ahorro del costo a
través del outsourcing
Como los superamos
Fase Piloto/Pruebas de concepto (área de bajo riesgo)
Establecimiento de un modelo compartido de servicios de testing,
recursos del cliente y del proveedor trabajando muy cerca
Se comienza en pequeño, llevando un área cada vez al modelo de
Factoría de Pruebas.
⌧Opción A: Se comienza con una evaluación, a través de las diferentes áreas
para analizar y recomendar estandarización de procesos
⌧Opción B: Un área o aplicación en concreto, en base a las prioridades
existentes
Se comienza a incrementar la carga de trabajo/proyectos/áreas a
medida que la confianza va creciendo
Factoría de Pruebas – Flexibilidad bajo demanda
Mejorar el uso de los recursos internos optimizando los

periodos de sobrecarga
Introducir su producto en el mercado mas rápido
Arranque inmediato
Absorber los retrasos y cambios repetitivos
Factoría de Pruebas – SLA: Acuerdo de Nivel de Servicio
FASE DE ANALISIS DISEÑO Y CONSTRUCCIÓN
Criticidad Indicador Valor Objetivo
=0% requisitos no incorporados en la solución =100%
1
≤3 iteraciones >90%
=10% requisitos no incorporados en la solución =100%
2
FASE DE PRUEBAS
≤20% sobre el total de pruebas en el plan de pruebas >90%
1
≤40% sobre el total de pruebas en el plan de pruebas >90%

2
FASE DE IMPLANTACIÓN/PASO A PRODUCCIÓN

≤10% nº de componentes instalados respecto a la planificación >90%
1
≤20% nº de componentes instalados respecto a la planificación >90%
2
Factoría de Pruebas – Conclusiones
Las Factorías de Pruebas son un concepto focalizado en

el outsourcing estratégico del testing
Las Factorías de Pruebas centradas en el cliente pueden
ofrecer significativos beneficios ya que están enfocados
a mejorar continuamente en base a la experiencia y el
conocimiento
El valor del negocio del test outsourcing puede ser
medido y mejorado a través de un programa de
métricas consensuado
Ruegos y Preguntas
Validación Pruebas de
Funcional Carga
Test de caja negra basados Conjunto de pruebas
en los requisitos y las dinámicas que aseguran el
especificaciones funcionales comportamiento del sistema
en determinados escenarios
Automatización Test de
del Servicio Usabilidad
Automatización de las Validación del diseño y
actividades de SQA: análisis facilidad de uso de los
de código, ejecución de interfaces de usuario,
casos, reporte de defectos, siguiendo los estándares de
gestión de pruebas mercado
Revisión de la seguridad Test de

del código Inspección Caja Blanca
Revisión de la seguridad de documental Revisión del diseño y
las aplicaciones, Validación, verificación y codificación de las distintas
principalmente web ante las trazabilidad de requisitos y capas: Interfaz de usuario,
vulnerabilidades conocidas documentación funcional datos e integración
Gracias

936 Lacalidaddelsoftwareylosprocesosdetesting PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

936 Lacalidaddelsoftwareylosprocesosdetesting PDF

Cargado por

Copyright:

Formatos disponibles

La Calidad del

Introducción. Visión general del proceso de

Introducción. Visión general del proceso

“La calidad del software es el grado con el que

Introducción. Visión general del proceso de

La metodología TMAP, está basada en cuatro piedras

Modelo de ciclo de vida de Pruebas

El modelo TMM es un modelo de

El Modelo de Evaluación consiste en un método

Introducción. Visión general del proceso de

Gestión del Ciclo de Pruebas

Gestión del Ciclo de Pruebas

La gestión de las pruebas, requiere que la herramienta con

TestLink, permite de manera intuitiva, la elaboración de casos

Durante todo el ciclo de vida se pueden obtener métricas tanto

Gestión del Ciclo de Pruebas

Las herramientas de Automatización de pruebas

Como ejemplo, tenemos la

Primeramente, se graban las

Los casos de prueba,

Gestión del Ciclo de Pruebas

Las herramientas para la realización de pruebas de

A continuación podemos ver

Para la ejecución del test, se introducen datos como

Durante la ejecución de la prueba, se puede

Posteriormente a la ejecución, se pueden obtener tanto log

Gestión del Ciclo de Pruebas

Notificación vía Generación

Se realiza la entrega de una nueva

Notificación vía Generación

Notificación vía Generación

Notificación vía Generación

Se notificará por mail, al conjunto de

Notificación vía Generación

Notificación vía Generación

Notificación vía Generación

El SAC generará un informe con los resultados de las

CVS Continuum Apache

Responsable CVS Maven

Gestión del Ciclo de Pruebas

El peso de la generación de las pruebas unitarias recae

Junit es un framework ampliamente

Cobertura es una herramienta opensource

A continuación se muestra una salida

Cobertura calcula la cobertura de las

Y llegar al máximo detalle

Esta herramienta permite al equipo de SQA

Introducción. Visión general del proceso de

Introducción. Visión general del proceso de

Grupo dedicado que provee testing como un servicio

Acercamiento Tradicional Factoría de Pruebas

Centro de pruebas externo Entregar código fuente

Experiencia probada en:

Equipo base + recursos bajo demanda

Mejorar el uso de los recursos internos optimizando los

≤40% sobre el total de pruebas en el plan de pruebas >90%

FASE DE IMPLANTACIÓN/PASO A PRODUCCIÓN

Las Factorías de Pruebas son un concepto focalizado en

Revisión de la seguridad Test de

También podría gustarte