International Software Testing Qualifications Board

Investigacin y desarrollo de temas de estudio

20/09/2013

Contenido
Contenido...................................................................................................................... i 1.Principios bsicos del proceso de pruebas.............................................................1 1.1Por qu es necesario el proceso de pruebas?....................................................1 1.1.1Contexto de los sistemas de software...........................................................1 1.1.2Causas de los defectos del software..............................................................2 1.1.3Funcin del proceso de pruebas en el desarrollo, mantenimiento y operaciones de software........................................................................................ 2 1.1.4Proceso de pruebas y calidad........................................................................2 1.1.5Con cuntas pruebas es suficiente?.............................................................3 1.2En qu consiste el proceso de pruebas?............................................................5 1.3Siete principios para las pruebas.........................................................................5 1.4Proceso bsico de pruebas.................................................................................. 7 1.4.1Planificacin y control de pruebas.................................................................7 1.4.2Anlisis y diseo de pruebas.........................................................................7 1.4.3Implementacin y ejecucin de pruebas.......................................................8 1.4.4Evaluacin de los criterios de salida e informes............................................8 1.5La psicologa de las pruebas................................................................................9 1.6Cdigo deontolgico............................................................................................ 9 2.1.1Modelo V (modelo de desarrollo secuencial)...............................................11 .................................................................................................................... 12 ............................................................................................................................ 12 Validacin Vs. Verificacin...................................................................................12 2.1.2Modelos de desarrollo iterativo-incremental................................................13 2.1.3Pruebas en un Modelo de Ciclo de Vida.......................................................14 2.2Niveles de prueba........................................................................................... 15 i

2.2.1Pruebas de componente.............................................................................. 15 2.2.2Pruebas de integracin................................................................................15 2.2.3Pruebas de sistema..................................................................................... 15 2.2.4Pruebas de aceptacin................................................................................ 16 2.3Tipos de prueba.............................................................................................. 17 2.3.1Pruebas de funciones (Pruebas funcionales)...............................................17 2.3.2Pruebas de caractersticas no funcionales del software (pruebas no funcionales)......................................................................................................... 18 2.3.3Pruebas de estructura / arquitectura de software (Pruebas estructurales)..19 2.3.4Pruebas asociadas a cambios: Repeticin de pruebas y pruebas de regresin............................................................................................................. 19 2.4Pruebas de mantenimiento............................................................................. 19 3.Tcnicas estticas................................................................................................ 20 3.1Las tcnicas estticas y el proceso de pruebas..............................................20 3.2Proceso de revisin......................................................................................... 20 3.2.1Actividades de una revisin formal..............................................................20 3.2.2Funciones y responsabilidades....................................................................21 3.2.3Tipos de revisiones...................................................................................... 22 3.2.4Factores de xito de las revisiones..............................................................22 3.3Anlisis esttico con herramientas.................................................................23 4.Tcnicas de diseo de pruebas............................................................................24 4.1Proceso de desarrollo de pruebas......................................................................24 Trazabilidad............................................................................................................ 25 Las pruebas deben ser trazables: Qu casos de prueba han sido incluidos en el catlogo de pruebas, basados en qu requisitos?..................................................25 4.2Categoras de tcnicas de diseo de pruebas. ..................................................26 4.3.1Particin de equivalencia. ...........................................................................29 ii

4.3.2Anlisis de valores lmite.............................................................................30 4.3.3Pruebas de tabla de decisin.......................................................................31 4.3.4Pruebas de transicin de estado..................................................................31 4.3.5Pruebas de caso de uso............................................................................... 32 4.4Tcnicas basadas en la estructura o tcnicas de caja blanca ..........................32 4.4.1Pruebas de sentencias y cobertura..............................................................33 4.4.2Pruebas de decisin y cobertura..................................................................33 4.4.3Otras tcnicas basadas en las estructura....................................................33 4.5Tcnicas basadas en la experiencia...................................................................33 4.6Seleccin de tcnica de prueba.........................................................................34 5.Gestin de pruebas.............................................................................................. 35 5.1Organizacin de pruebas................................................................................... 35 5.1.1Organizacin de pruebas e independencia..................................................35 5.1.2Tareas del Lder de Pruebas y del Probador.................................................38 5.2Planificacin y estimacin de pruebas...............................................................40 5.2.1Planificacin de pruebas.............................................................................. 40 5.2.2Actividades de planificacin de pruebas .....................................................42 5.2.3Criterios de entrada .................................................................................... 43 5.2.4Criterios de salida ....................................................................................... 43 5.2.5Estimacin de pruebas ...............................................................................43 5.2.6Estrategia de pruebas, enfoque de pruebas................................................44 5.3Seguimiento y control del progreso de las pruebas...........................................45 5.3.1Seguimiento del progreso de las pruebas....................................................45 5.3.2Informes de pruebas ................................................................................... 45 5.3.3Control de pruebas...................................................................................... 46 5.4Gestin de la configuracin...............................................................................46 iii

5.5Riesgo y pruebas............................................................................................... 46 5.5.1Riesgos del proyecto................................................................................... 46 5.5.2Riesgos del producto................................................................................... 47 5.6Gestin de incidencias ...................................................................................... 47 6.Herramientas de soporte de pruebas......................................................................49 6.1Tipos de herramientas de pruebas....................................................................49 6.1.1Significado y objetivo de las herramientas de pruebas...............................49 6.1.2 Clasificacin de herramientas de prueba....................................................50 6.1.3 Herramientas de soporte para la gestin de pruebas.................................50 6.1.4Herramientas de soporte para las pruebas estticas...................................51 6.1.5 Herramientas de soporte para la especificacin de prueba........................51 6.1.6 Herramientas de soporte para la ejecucin y el registro de pruebas..........51 6.1.7 Herramientas de soporte para el rendimiento y la monitorizacin.............51 6.1.8 Herramientas de soporte para necesidades de pruebas especficas..........52 6.2Uso efectivo de las herramientas: Ventajas potenciales y riesgos.....................52 6.2.1 Ventajas potenciales y riesgos de las herramientas de soporte de pruebas (para todas las herramientas).............................................................................. 52 6.2.2 Consideraciones especiales para algunos tipos de herramientas...............53 6.3Introduccin de una herramienta en una organizacin......................................53

iv

1. Principios bsicos del proceso de pruebas

1.1 Por qu es necesario el proceso de pruebas?
1. Para detectar defectos en el software. 2. Verificar la integracin adecuada de los componentes. 3. Verificar que todos los requisitos se han implementado correctamente. 4. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. 5. Disear casos de prueba que sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y esfuerzo (error humano, condicin ambiental). 6. Garantizar la calidad en el software de acuerdo a las especificaciones del cliente y las normativas. 7. Generar software intuitivo de fcil uso.

1.1.1 Contexto de los sistemas de software

Un software que no funciona correctamente puede causar muchos problemas, tanto econmicos como personales. La forma de identificar los problemas se clasifican en dos: Por el lado de desarrollo/pruebas, hay dos tipos: o Error: Es causado por humanos, por ejemplo, la lgica de programacin, la escritura de cdigo, mal entendimiento de requisitos, etctera. o Defecto: Sucede cuando el sistema falla en las funciones requeridas, por ejemplo, tiempo de respuesta durante la prueba. Por otra parte, del lado del cliente: 1

Fallos: Son todos aquellos errores y detectados no detectados durante la construccin y el periodo de pruebas, pero el cliente lo encuentra una vez liberado el sistema.

El costo de los defectos depende de la etapa en la que se detecta. Cuando es una etapa temprana, los costos pueden ser cero o muy bajos, conforme avance el desarrollo, el costo ser incremental, as pues, es ms sencillo y barato corregir un error en papel que hacerlo una vez que el software se ha compilado, ya que se requerira cambiar especificaciones, documentos y volver a capturar y compilar, lo que lleva mucho ms tiempo y dinero, ms an, en una etapa de produccin con el cliente, un fallo puede detener sus operaciones, generando prdidas millonarias.

1.1.2 Causas de los defectos del software

Existen diversas causas que pueden provocar defectos en el software, la principal es la confiabilidad del ser humano, que se ve propenso a presin, cdigos complejos, infraestructuras complejas y tecnologas cambiantes.

1.1.3 Funcin del proceso de pruebas en el desarrollo, mantenimiento y operaciones de software

Atributos funcionales Atributos no funcionales

Funcionabilidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

1.1.4 Proceso de pruebas y calidad

Las pruebas deben ser integradas en el proceso de calidad del software ya que gracias a stas se garantiza la fiabilidad del software. 2

Existen unas leyes que definen bsicamente la aplicacin de las pruebas de software y ayudan a refinar el producto de software a travs de las etapas involucradas. La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia. La principal dificultad del proceso de prueba es decidir cundo parar. Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo. Una parte necesaria de un caso de prueba es la definicin del resultado esperado. Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada vlidas y esperadas sino tambin para condiciones no vlidas e inesperadas. El nmero de errores sin descubrir es directamente proporcional al nmero de errores descubiertos. Esttico Revisiones / Revisiones guiadas (walktrought) Anlisis del flujo de control Anlisis de flujo de datos Mtricas del compilador/analizar Caja Negra Particin de equivalencia Anlisis de valores lmite Pruebas de transicin de estado Tablas de Decisin Pruebas de casos de uso Tcnicas basadas en la experiencia Caja Cobertura de sentencia Blanca. Cobertura de rama (Branch) Cobertura de condicin Cobertura de camino

Para determinar la cantidad de pruebas que se realizarn se deben de tomar en cuenta diferentes aspectos como son: Los riesgos tcnicos Los riesgos de seguridad 3

Dinmico

1.1.5 Con cuntas pruebas es suficiente?

Los riesgos comerciales El tiempo El presupuesto

Las pruebas deben facilitar la informacin suficiente para adoptar las decisiones que mejor convengan a las partes interesadas en el software. Los tipos de prueba son: Pruebas basadas en riesgo (risk-based testing). Pruebas basadas en plazos y presupuestos (time and budget testing).

1.2 En qu consiste el proceso de pruebas?

El proceso de prueba puede tener los siguientes objetivos: Identificar defectos Aumentar la confianza en el nivel de calidad Facilitar informacin para la toma de decisiones Evitar la aparicin de defectos

Y para ello se debe considerar: Seleccionar qu es lo que debe medir la prueba, es decir, cul es su objetivo, para qu exactamente se hace la prueba. Decidir cmo se va a realizar la prueba, es decir, qu clase de prueba se va a utilizar para medir la calidad y qu clase de elementos de prueba se deben usar. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarn para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se est midiendo. Determinar cules deberan ser los resultados esperados de los casos de prueba y crear el documento que los contenga. Ejecutar los casos de prueba.

El principal objetivo puede ser provocar el mximo nmero de defectos para de sta manera subsanarlos antes de que el producto llegue al usuario. Otro objetivo puede ser el evaluar la calidad o facilitar informacin sobre las caractersticas del sistema.

1.3 Siete principios para las pruebas.

1. Las pruebas demuestran la presencia de defectos, no lo ausencia de ellos. Las pruebas reducen la probabilidad de la presencia de defectos que permanezcan sin ser detectados. La ausencia de fallos no demuestran la correccin de un producto. 5

El mismo proceso de pruebas puede contener errores. Las condiciones de prueba pueden ser inapropiadas.

2. Las pruebas exhaustivas no existen, se deben realizar anlisis de riesgos y prioridades para centralizar los esfuerzos de las pruebas. No es posible realizar pruebas exhaustivas por condiciones como el tiempo, costo, esfuerzo y dificultad de las mismas. 3. Pruebas tempranas, desde el inicio del ciclo de vida del software o del desarrollo del sistema. Cuanto ms temprana es la deteccin de un defecto, menos costosa es su correccin (antes de la implementacin) La preparacin de pruebas tambin consume tiempo.

4. Agrupacin de defectos ya que la mayora de los fallos operativos se concentran en un nmero reducido de mdulos. Vale la pena investigar un mismo mdulo donde se ha detectado un defecto ya que aparecen agrupados como hongos. 5. La paradoja del pesticida. Cuanto ms se ejecute una misma prueba, menor cantidad de defectos sern encontrados (con esa misma prueba). Los casos de prueba deben revisarse peridicamente y deben escribirse pruebas nuevas y diferentes para poder detectar ms defectos. 6. Las pruebas se llevan a cabo de diferente manera segn el contexto. 7. La falacia de la Ausencia de Errores. La deteccin y correccin de defectos depende de la usabilidad y si cumple con las expectativas y necesidades del usuario. En la mayora de los casos el proceso de pruebas no detectar todos los defectos del sistema, pero los defectos ms importantes deberan ser detectados.

1.4 Proceso bsico de pruebas

1.4.1 Planificacin y control de pruebas

La planificacin es la actividad de definir los objetivos de pruebas y la especificacin de actividades de pruebas. Toma en cuenta la retroalimentacin del monitoreo y control de actividades. El control es la actividad de comparar el progreso actual dentro de lo planificado y reportar estados.

1.4.2 Anlisis y diseo de pruebas

Incluye las siguientes tareas: Revisar los requerimientos, nivel de integridad del software, arquitectura, diseo y especificaciones). Habilidad de realizar pruebas sobre la base y objetos. Identificar y priorizar condiciones. 7

Diseo y priorizacin de casos de prueba.

1.4.3 Implementacin y ejecucin de pruebas

Incluye las siguientes tareas: Finalizar, implementar y priorizar casos de prueba. Desarrollar y priorizar procedimientos de prueba. Crear casos de prueba para su ejecucin. Verificar que el ambiente de pruebas ha sido configurado correctamente. Guardar el resultado de ejecucin de pruebas y las versiones del software. Comparar resultados actuales con resultados esperados.

1.4.4 Evaluacin de los criterios de salida e informes

Es la actividad donde se compara la ejecucin de pruebas y la definicin de objetivos. Incluye las tareas: 1.4.5 Verificar logros de pruebas Escribir resmenes de pruebas

Actividades de cierre de pruebas

Incluye las siguientes actividades: Verificar que los entregables planificados sean liberados Cierre de reporte de incidentes Documentar la aceptacin del sistema Analizar lecciones aprendidas para determinar cambios necesarios en futuras versiones

1.5 La psicologa de las pruebas

Por regla general se transfiere la responsabilidad de probar a personas diferentes a las que desarrollaron (Probador independiente), pero si mantiene una actitud correcta el mismo desarrollador puede probar su software. Pueden establecerse varios niveles de independencia:

Debido a que puede ser mal interpretada la realizacin de las pruebas, creyendo que es una especie de sabotaje hacia el software, se debe mejorar la comunicacin entre las personas que prueban y los dems: Empezar juntos Comunicar hallazgos Ser empticos Corroborar que se haya entendido lo que se ha querido comunicar

1.6 Cdigo deontolgico

Se utiliza para garantizar que la informacin no se usa de manera indebida. Para ingenieros ACM e IEEE el ISTQB establece el siguiente cdigo: Pblico Los probadores de software certificados actuarn en coherencia con el inters del pblico Los probadores de software certificados 9

Cliente y empleador

actuarn en el mejor de los intereses de su cliente y empleador, en coherencia con el inters pblico Producto Los probadores de software certificados garantizarn que los productos entregables que proporcionan se ajustan a los ms altos estndares profesionales Los probadores de software certificados mantendrn la integridad y la independencia en su criterio profesional Los jefes y lderes de pruebas de software certificados suscribirn y fomentarn un enfoque tico en la gestin de las pruebas de software Los probadores de software certificados aumentarn la integridad y la reputacin de la profesin en coherencia con el inters pblico Los probadores de software certificados sern equitativos y apoyarn a sus compaeros fomentando la cooperacin con los desarrolladores de software Los probadores de software certificados participarn en un aprendizaje a lo largo de toda la vida por lo que respecta a la prctica de su profesin y fomentarn la adopcin de un enfoque tico en la prctica de su profesin.

Criterio

Gestin

Profesin

Compaeros

Nivel individual

10

2.

Pruebas durante todo el ciclo de vida del software

2.1

Modelos de desarrollo de software

Las actividades de pruebas estn asociadas a actividades de desarrollo que requieren diferentes enfoques de pruebas.

2.1.1 Modelo V (modelo de desarrollo secuencial)

Se basa en 4 niveles de pruebas correspondientes a los niveles de desarrollo Pruebas de componentes (unitarias) Pruebas de integracin Pruebas de sistemas Pruebas de aceptacin

11

Validacin Vs. Verificacin

Verificar es comprobar si los requisitos y definiciones en niveles previos han sido implementados correctamente. Validar significa comprobar lo adecuado de los resultados de un nivel de desarrollo.

12

2.1.2 Modelos de desarrollo iterativo-incremental

Es el proceso de establecer requisitos, disear, establecer y probar un sistema. Constituye un sistema parcial creciente que tambin debe ser probado.

Ejemplos de modelos iterativos: 13

Modelo prototipado: desarrollo rpido de una representacin seguida de modificaciones sucesivas hasta que el sistema sea finalizado.

Desarrollo rpido de aplicaciones: La interfaz de usuario se implementa usando una funcionalidad que posteriormente ser desarrollada.

Proceso unificado: Modelo orientado a objeto y producto de la compaa Rational/IBM que aporta el lenguaje de modelado UML y soporte al proceso unificado.

Programacin extrema: el desarrollo y las pruebas tienen lugar sin una especificacin de requisitos especificada.

Caractersticas de los modelos iterativos: Cada iteracin contribuye con una caracterstica adicional al sistema a desarrollar. Cada iteracin puede ser probada por separado. Las pruebas de regresin y la automatizacin de pruebas son de gran relevancia. En cada iteracin la verificacin y validacin se puede efectuar por separado.

2.1.3 Pruebas en un Modelo de Ciclo de Vida

Los niveles de prueba pueden combinarse o reorganizarse en funcin de la naturaleza del proyecto o de la arquitectura del sistema.

14

2.2

Niveles de prueba
2.2.1 Pruebas de componente

Datos de configuracin Tienen por objetivo localizar defectos y comprobar el funcionamiento; para ello pueden utilizarse controladores y simuladores. Se llevan a cabo mediante el acceso al cdigo y con la participacin del programador. Dadas las convenciones de cada lenguaje de programacin para la asignacin de nombres a sus respectivos componentes, se podr hacer referencia a un componente como: Prueba de mdulo (module test, en lenguaje C), prueba de clase (class test por ejemplo en Java) o prueba de unidad (unit test por ejemplo en Pascal).

2.2.2 Pruebas de integracin

Datos de configuracin Se ocupa de probar las interfaces entre los componentes, las interacciones con las partes de un mismo sistema (sistema operativo, sistema de archivos y hardware) y las interfaces entre varios sistemas. Puede hacer ms de un nivel de pruebas de integracin y pueden llevarse a cabo en objetos de prueba de diferente tamao:

De componentes De sistema

Prueba las interacciones componentes del software.

entre

los

Prueban las interacciones entre los distintos sistemas o entre el hardware y el software.

2.2.3 Pruebas de sistema

Datos de configuracin 15

Pueden incluir pruebas basadas en riesgo y/o en especificaciones de requisitos, procesos de negocio, casos de uso u otras descripciones de texto de alto nivel o modelos de comportamiento de sistema, interacciones con el sistema operativo y recursos del sistema.

2.2.4 Pruebas de aceptacin

Datos de configuracin Su objetivo es crear confianza en el sistema, partes del sistema o caractersticas especficas no funcionales del sistema. Evala la buena disposicin de un sistema para su despliegue, a pesar de no ser el ltimo nivel de prueba. Las pruebas de aceptacin pueden adoptar las siguientes formas: Pruebas de aceptacin del usuario (por parte de los usuarios comerciales) Pruebas operativas de aceptacin (pruebas de backup/restauracin, recuperacin de desastres, gestin de usuarios, tarea de mantenimiento, carga de datos y tareas de migracin, comprobaciones peridicas de vulnerabilidades de seguridad) Pruebas de aceptacin contractual y normativa Pruebas alfa y beta (o de campo) Pruebas de componente Requisitos componentes Diseo de detalle Cdigo Pruebas de sistema Especificacin de requisitos de sistema y software Casos de uso Especificaciones funcionales Informes de anlisis de riesgos Componentes Implementacin Manuales de Programas de bases de sistema, usuario y Conversin de datos / datos de funcionamiento programa de subsistemas Configuracin de migracin Infraestructura sistema Interfaces Pruebas de integracin de Diseo de software Arquitectura Flujos de trabajo Casos de uso Pruebas de aceptacin Requisitos de usuario Requisitos de sistema Casos de uso Procesos de negocio Informes de anlisis de riesgo Procesos de negocio en sistemas completamente integrado Procesos operativos y de mantenimiento Procedimiento de usuario Formularios Informes

Base de pruebas

Objetos de prueba tpicos

16

2.3

Tipos de prueba
2.3.1 Pruebas de funciones (Pruebas funcionales)

Estn basadas en funciones y caractersticas. Deben ser descritas como una especificacin de requerimientos, casos de uso o especificaciones funcionales. Caractersticas a ser probadas: Adecuacin (suitability): Las funciones implementadas son adecuadas para su uso esperado? Exactitud (accuracy): Las funciones presentan los resultados correctos? Interoperabilidad (Interoperability): Las interacciones con el entorno del sistema presentan algn problema? Seguridad (secury): estn protegidos los datos contra accesos no aprobados o prdida? Cumplimiento de funcionalidad (compliance): El sistema cumple con normas y reglamentos aplicables? Tres enfoques para probar los requisitos funcionales: Pruebas basadas en procesos de negocio: Cada proceso de negocio sirve como fuente generar derivar/generar pruebas. Estos pueden asignar prioridades a los casos de prueba. Pruebas basadas en casos de uso: Los casos de prueba se derivan/generan a partir de la secuencia de usos esperados o razonables. Las secuencias usadas con mayor frecuencia reciben una prioridad ms alta. Pruebas basadas en requisitos: Los casos de prueba se derivan de la especificacin de requisitos.

17

El nmero de casos de prueba variar en funcin del tipo/profundidad de las pruebas basadas en la especificacin de requisitos.

2.3.2 Pruebas de caractersticas no funcionales del software (pruebas no

funcionales)
Incluyen pero no estn limitadas a: pruebas de performance, pruebas de carga, pruebas de estrs, pruebas de usabilidad y pruebas de portabilidad. Pueden ser realizadas en todos los niveles. Pruebas de caractersticas de software no funcionales. Prueba de carga (load test): Sistema bajo carga (carga mnima, ms

usuarios/transacciones). Prueba de rendimiento (performance test): Rapidez con la cual un sistema ejecuta una determina instruccin. Prueba de volumen (Volume test): Procesamiento de grandes cantidades de datos/ficheros. Prueba de estrs (stress test): Reaccin a la sobrecarga/recuperacin tras el retorno a una carga normal. Prueba de estabilidad (stability test): Rendimiento modo de operacin continua. Prueba de robustez (test for robustness): Reaccin a entradas errneas o datos no especificados. o Reaccin a fallos hardware/recuperacin ante situaciones de desastre.

Pruebas de cumplimiento: Cumplir con normas y reglamentos (interno/externo). Pruebas de usabilidad: Estructurado, comprensible, fcil de aprender por parte del usuario.

Otros aspecto no funcionales de calidad:

18

Portabilidad:

Adaptabilidad,

reemplazabilidad,

instalabilidad,

coexistencia,

cumplimiento de portabilidad. o Mantenibilidad: Analizabilidad, modificabilidad, estabilidad, testabilidad,

cumplimiento de mantenibilidad. o Fiabilidad: Madurez, tolerancia a fallos, recuperabilidad, cumplimiento de fiabilidad.

2.3.3 Pruebas de estructura / arquitectura de software (Pruebas

estructurales)
Tambin llamadas de caja blanca. Pueden tambin aplicarse a nivel de sistema, integracin de sistema o pruebas de aceptacin.

2.3.4 Pruebas asociadas a cambios: Repeticin de pruebas y pruebas de

regresin
Es la repeticin de testeo en un programa que ya ha sido testeado, despus de una modificacin, a fin de descubrir cualquier defecto introducido o no cubierto por los cambios realizados. Pueden ser realizados en todos los niveles de testeo. Son ejecutadas muchas veces y por lo general evolucionan lentamente.

2.4

Pruebas de mantenimiento

Una vez que el sistema ha sido liberado, su ambiente es corregido, cambiado o extendido. Se realizan en sistemas operacionales y son ocasionadas por las modificaciones, migraciones o retiro del software. Cualquier nueva versin del producto, cada nueva actualizacin y cada cambio del software requiere pruebas adicionales, tales como: Configuracin: Composicin de un componente o de un sistema definido como el nmero, naturaleza e interconexiones de las partes que lo constituyen. Anlisis de impacto: Valoracin del cambio en las capas de documentacin de desarrollo, documentacin de pruebas y componentes.

19

Pruebas de mantenimiento: Prueba de los cambios de un sistema en operacin o el impacto de un entorno modificado para un sistema en operacin.

3. Tcnicas estticas
3.1

Las tcnicas estticas y el proceso de pruebas

Se basan en las revisiones y el anlisis automatizado del cdigo o de cualquier otra documentacin sin ejecutar el cdigo. Tienen por objetivo identificar el defecto, con diferentes tcnicas pueden encontrar diferentes defectos de una manera eficiente y efectiva.

3.2

Proceso de revisin

La forma en la que se hace una revisin depende de los objetivos que se tienen previstos.

3.2.1 Actividades de una revisin formal

Incluye: Planificar (definir los criterios de revisin, seleccionar al personal y asignar funciones) Definir los criterios de entrada y salida (seleccionar las partes del documento que se van a revisar) Inicio (Repartir los documentos, explicar los objetivos, procesos y documentos) Comprobar los criterios de entrada Preparacin individual Prestar atencin a los posibles defectos Examen/evaluacin/registro de los resultados Examinar, evaluar y registrar durante las reuniones fsicas Adaptar 20

Corregir los defectos detectados Hacer un seguimiento Comprobar los criterios de salida

3.2.2 Funciones y responsabilidades

Una revisin formal implica las siguientes funciones: Jefe Decide sobre las ejecuciones Asigna tiempos en el calendario Determina si se han logrado los objetivos Moderador Lidera la revisin de los documentos Es la persona de la que depende el xito de la revisin Autor Revisores Es la persona con la mxima responsabilidad de los documentos Identifican y describen las conclusiones sobre el producto objeto de la revisin Deben seleccionar de manera que se representen las distintas perspectivas y funciones del proceso de revisin Escriba Documenta todo lo que se ha revisado durante la reunin

21

3.2.3 Tipos de revisiones

3.2.4 Factores de xito de las revisiones

Las revisiones tienen objetivos claros y predefinidos Participacin de las personas adecuadas Los probadores contribuyen a la revisin y aprenden del producto Los defectos se expresan de manera objetiva Se afrontan los problemas de personal Atmsfera de confianza Tcnicas de revisin Se utilizan listas de comprobacin 22

Se ofrece formacin sobre las tcnicas La direccin respalda la implementacin de un buen proceso de revisin. Se hace hincapi en el aprendizaje y en la mejora del proceso

3.3

Anlisis esttico con herramientas

Estas herramientas analizan el cdigo del programa y las salidas generadas. El valor del anlisis esttico es: La deteccin temprana de defectos Advertencia temprana sobre aspectos sospechosos del cdigo o diseo Detectar dependencias e inconsistencias Mantenibilidad del cdigo y del diseo Prevencin de defectos

Defectos ms comunes: Referenciar una variable con un valor indefinido Interfaces inconsistentes entre mdulos o componentes Variables que no se utilizan o que se declaran en forma incorrecta Cdigo inaccesible Ausencia de lgica o lgica errnea Construcciones demasiado complicadas Vulnerabilidad de seguridad Infracciones de sintaxis del cdigo y modelos de software 23

4. Tcnicas de diseo de pruebas.

4.1

Proceso de desarrollo de pruebas

El proceso de desarrollo de pruebas se lleva a cabo durante el anlisis de los requisitos del sistema para as entender sus objetivos, sus alcances, sus datos de entrada y salida y los resultados esperados de los mismos. Forma parte de la documentacin y el nivel de especificacin puede ser bsico o complejo, dependiendo de diversos factores como el mismo sistema, la madurez del equipo de desarrollo y/o pruebas, herramientas a utilizar, el tiempo del proyecto, entre otros. Obtencin de casos de prueba a partir de requisitos. El diseo de casos de prueba debe ser un proceso controlado. Los casos de prueba pueden ser creados formal o informalmente, dependiendo de las caractersticas del proyecto y la madurez del proceso en uso.

Objeto de pruebas y requisitos sobre el objeto de pruebas

Definici n de requisit os de las pruebas y criterios de pruebas

Caso de prueba Caso 1 de prueba Caso 1 de prueba Caso 1 de prueba Caso 1 de prueba 1

Caso de prueba Caso1 de prueba 1 Caso de prueba Caso1 de prueba 4 Escenario de

24 Caso Caso de de prueba prueba 1 1

Trazabilidad Las pruebas deben ser trazables: Qu casos de prueba han sido incluidos en el catlogo de pruebas, basados en qu requisitos? Las consecuencias de los cambios en los requisitos sobre las pruebas a realizar pueden ser identificadas directamente. La trazabilidad tambin ayuda a determinar la cobertura de requisitos. Caso de prueba Caso 1 de prueba Caso 1 de prueba Caso 1 de prueba Caso 1 de prueba 1 Caso de prueba Caso 1 de prueba 1 Caso de prueba Caso 1 de prueba 1

Objeto de pruebas y requisitos sobre el objeto de pruebas

Definici n de requisit os de las pruebas y criterios de pruebas

Escenario de

Definiciones Objeto de prueba (test object): Elemento a ser revisado: un documento o una pieza de software en el proceso de desarrollo de software. Condicin de prueba (test condition): Elemento o evento: una funcin, una transaccin, un criterio de calidad o un elemento en el sistema. Criterios de prueba (test criteria): El objeto de prueba debe cumplir los criterios de prueba con el propsito de superar la prueba.

25

Calendario de ejecucin de prueba (test execution Schedule): Un esquema para la ejecucin de procedimientos de prueba. Los procedimientos de prueba estn incluidos en el calendario de ejecucin de prueba en sus contextos y en el orden en el cual deben ser ejecutados. Descripcin de un caso de prueba segn el estndar IEEE 829 Precondiciones (Preconditions): situacin previa a la ejecucin de pruebas o caractersticas de un objeto de pruebas antes de llevar a la prctica (ejecucin) un caso de prueba. Valores de entrada (input values): descripcin 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): caractersticas de un objeto de prueba tras la ejecucin de pruebas, Dependencias (dependencies): orden de ejecucin de casos de prueba, razn de las dependencias. Identificador distinguible (distinct identification): identificador o cdigo con el objeto de vincular, por ejemplo, un informe de errores al caso de prueba en ele cual ha sido detectado. Requisitos (requeriments): caractersticas del objeto de pruebas que el caso de prueba debe evaluar.

Combinacin de casos de prueba Una especificacin de procedimiento de prueba: define la secuencia de acciones para la ejecucin de un caso de prueba individual o un juego de pruebas. Es un script (guin) o guin cinematogrfico para la prueba describiendo los pasos, tratamiento y/o actividades necesarias para la ejecucin de la prueba. El plan de prueba (dinmico) establece la secuencia de las pruebas planificadas, quien debe realizarlas y cuando. Se deben considerar las restricciones como las prioridades, la disponibilidad de recursos, la infraestructura de prueba.

4.2

Categoras de tcnicas de diseo de pruebas.

Durante el desarrollo de pruebas se especifican los casos de prueba, en los cuales se encuentran pruebas tanto de caja negra (tambin conocidas como tcnicas basadas en la 26

especificacin) y/o caja blanca (tambin conocidas como tcnicas basadas en la estructura), en las primeras, solamente se conocen los datos de entrada y sus respectivas salidas sin conocer cmo funciona internamente (cdigo) un sistema, mientras que en el segundo tipo, se conocen los aspectos del sistema. Algunas de las caractersticas del diseo de tcnicas de diseo de pruebas basadas en especificacin son: El problema a solucionar, el software o sus componentes se basan en modelos. En base a modelos sistemticos pueden obtenerse los casos de prueba.

Pruebas de caja negra (black box) y caja blanca (White box) Aseguramiento de la calidad analtico Dinmico Caja negra Particin de equivalencia. Anlisis de valores lmite. Pruebas de transicin de estado. Tablas de decisin.

Algoritmo dual (pairwise) Tcnicas basadas en la experiencia Caja blanca Cobertura de sentencia. Esttico Cobertura de rama. Cobertura de condicin.

Cobertura de camino. Revisiones/ Revisiones guiadas (walkthroughs) Anlisis del flujo de control Anlisis de flujo de datos Mtricas compilador / analizador.

Tcnica de caja negra (Black Box) El probador observa el objeto de prueba como una caja negra. Los casos de prueba se obtienen a partir de anlisis de la especificacin (funcional y no funcional) de un componente o sistema. La funcionalidad es el foco de atencin. 27

Diseo de caso de prueba. Casos de prueba basados en especificaciones. Estructura interna del programa irrelevante Prueba todas las combinaciones entrada/salida de datos seleccionadas respectivamente.

Caja negra

Tcnica de caja blanca (White Box). El probador conoce la estructura interna del programa / cdigo. Los casos de prueba son seleccionados en base a la estructura interna del programa / cdigo. La estructura del programa es ele foco de atencin.

Diseo de caso de prueba. Casos de prueba basados en la estructura del programa. - El proceso de pruebas es controlado externamente - Anlisis del flujo de control dentro del objeto de prueba a lo largo de la ejecucin de pruebas. Mtodos basados en la especificacin: El objeto de prueba ha sido seleccionado de acuerdo con el modelo funcional; la cobertura de la especificacin puede ser medida. Mtodos basados en la estructura: La estructura interna del objeto de prueba es utilizada para disear los casos de prueba; el porcentaje de cobertura es medido y utilizado como fuente para la creacin de casos de prueba adicionales. Mtodos basados en la experiencia: El conocimiento y experiencia respecto a los objetos de prueba y su entorno son las fuentes para el diseo de casos de prueba

4.3

Tcnicas basadas en la especificacin o tcnicas de caja negra.

28

4.3.1 Particin de equivalencia.

La particin en clases de equivalencia es intuitivo, se observan dos posibles valores, los de entrada (input) y los de salida (output). Esta tcnica consiste en dividir los datos de entrada del sistema en clases relacionadas entre si y esperar un resultado, ya sea vlido o no vlido y/o manejo de excepciones (errores inesperados en la ejecucin), por ejemplo, cuando el dato debe ser un tipo numrico, se pueden agrupar los enteros con enteros, los de coma flotante con los de coma flotante, los que se encuentren en un rango (ya sea inferior, superior o dentro de), los que de tipo booleano (un solo estado, por ejemplo (s o no), caracteres estndar contra especiales, entre otros. Por ejemplo. Se desea probar la funcionalidad de un validador de fechas en el formato mm/dd/aa, para lo cual, el mes se debe escribir en nmeros del 1 al 12, para el da se especifica a dos nmeros, si son los primeros das debe anteponerse un 0 y dependiendo del mes y ao, se podr poner 28, 29, 30 o 31 das, y para el ao, que sean mayores al 2000 pero menores al 2050 (00-50). Las equivalencias, por ejemplo, quedaran de la siguiente manera: Para el mes, se probarn intentando escribir (con letras) el mes, esto no debe ser permitido, se introducirn valores 0, se dejarn en blanco, se escribirn nmeros menores a 1 y mayores a 12. Para el da, se intentar poner un mes 02, con 31 das. Para el ao, se intentarn escribir 4 dgitos, se intentarn introducir valores mayores a 50. Cabe mencionar que todas estas particiones pueden ser medidas, entre el nmero de clases de equivalencia entre el nmero de clases de equivalencia definidos, para obtener un porcentaje:

Algunos beneficios son: 29

Mtodo sistemtico para el diseo de casos de prueba, es decir, con una mnima cantidad de casos de prueba se puede esperar un valor de cobertura especfico.

La particin del rango de valores en clases de equivalencia a partir de las especificaciones cubre los requisitos funcionales.

La asignacin de prioridades a clases de equivalencia puede ser utilizada para la asignacin de prioridades a los casos de prueba (los valores de entrada utilizados con poca frecuencia deben ser los ltimos en ser probados).

Las pruebas de las excepciones conocidas est cubierta por los casos de prueba de acuerdo con las clases de equivalencia negativas.

La particin de equivalencia es aplicable a todos los niveles de prueba. Puede ser utilizada para lograr objetivos de cobertura de entradas y salidas. Puede ser utilizada para entradas manuales (humanas) o va interfaces de un sistema o parmetros de interfaces en pruebas de integracin.

4.3.2 Anlisis de valores lmite.

Tambin conocidos como valores frontera, consiste en el anlisis de los rangos que requiere el sistema para arrojar un resultado esperado, ya sea que el valor sea vlido o invlido, el cmo se tratar dicho valor debe ser previsto. Cuando se presentan stos casos, aparecen tres tipos de rangos: Por debajo de lo requerido. Dentro del rango. Por arriba del rango.

Por ejemplo, si se requiera validar una edad determinada para poder ser sujeto de un crdito bancario, la persona debe ser mayor de 18 aos pero menor de 70 aos, por lo tanto, aparecen tres posibles situaciones: Por debajo de lo requerido. El sujeto tiene 15 aos de edad, es decir, menor de 18. Dentro del rango. El sujeto tiene 35 aos de edad, es decir, entra en el rango de 18 y 70. Por arriba del rango. El sujeto tiene 75 aos de edad, es decir, es mayor de 70. 30

Como puede verse, es una tcnica sencilla pero muy eficaz con la cual pueden encontrarse errores de forma rpida, inclusive, dichos errores pueden ser previsibles durante la planeacin y especificacin del caso de prueba. Cabe mencionar, que los rangos por arriba y por debajo pueden ser inmediatos (lmite +1, o bien, lmite-1) ya que una entrada mucho mayor o mucho menor son indistintos y puede volverse engorroso.

4.3.3 Pruebas de tabla de decisin.

Son aquellas pruebas en las que dependiendo de un tipo de dato de entrada, el sistema debe tomar una decisin en influir en el resultado esperado, tpicamente se trata de tipos bolanos, es decir, el dato solo puede tomar un valor ya sea si o no, 0 1, positivo o negativo, es decir, puede ser uno u otro pero nunca los dos. Si bien es cierto que la mayora de estas condiciones son bolanos, las condiciones nos necesariamente deben elegirse entre dos elementos, pueden dos o ms pero siempre respetando el hecho de que es uno u otro pero nunca ms de uno. Por ejemplo, suponiendo que un alumno termina su carrera y para obtener el ttulo universitario requiere de aprobar el examen profesional, en caso contrario, no lo obtendr. Se presentan dos situaciones, que el alumno apruebe el examen, o bien, que repruebe el examen. Como puede verse, el obtener el ttulo ser influenciado por el resultado del examen.

4.3.4 Pruebas de transicin de estado

Para realizar esta prueba se necesita de un prerrequisito, que dependiendo ste el sistema debe tomar una decisin y el resultado final es influenciado por dicho resultado. Por ejemplo, suponiendo que se desea probar el comportamiento de un control remoto para televisin, en el cual se quiere probar el cambio de un canal a otro, para ello, se deben cumplir dos condiciones previas, que el televisor est encendido y el canal actual sea diferente al que se desea cambiar. Para sta prueba se presentan las siguientes situaciones. Si el televisor est apagado no se validar el canal y por tanto, no har el intento de cambiar el mismo. Si el televisor est encendido, validar que el canal actual sea diferente al que se desea cambiar, pero dicho canal es igual, por lo que no realizar. 31

Si el televisor est encendido, validar que el canal actual sea diferente al que se desea cambiar y ste es diferente, intentar hacer el cambio.

Como puede observarse, el que pueda o no cumplirse una prueba depende de estados previos o pre-condiciones. sta prueba puede estar muy relacionada con las tablas de decisin y siempre debe tenerse en cuenta que los estados del sistema u objeto de prueba son independientes, identificables y finitos en nmero.

4.3.5 Pruebas de caso de uso

Un Caso de uso es una especificacin paso a paso de cmo evoluciona el sistema en base a la interactividad y condiciones que suceden, su nivel de detalle puede ser muy tcnico o de propsito general, tpicamente describe un flujo correcto que presenta las condiciones ideales (llamado Happy Path) y escenarios alternos que pueden detallar las diferentes situaciones que pueden presentarse durante la evolucin de la ejecucin y cmo deben manejarse. Cuando se hacen pruebas de caso de uso, se tiene un flujo esperado y posibles situaciones alternas, son muy tiles en pruebas de aceptacin de usuario.

4.4

Tcnicas basadas en la estructura o tcnicas de caja blanca

Algunas de las caractersticas de las tcnicas basadas en estructura son: Informacin sobre cmo debe utilizarse el software construido para obtener los casos de prueba, tales como el cdigo o informacin detallada en la documentacin. Puede medirse el alcance de la cobertura de los casos de prueba existentes y puede obtenerse otros casos de prueba de manera sistemtica para aumentar la cobertura. Las pruebas basadas en la estructura o de caja blanca se basan en una estructura identificada del software o del sistema, segn se demuestra en los siguientes ejemplos: Nivel de componente: la estructura de un componente de software, es decir, sentencias, decisiones, ramas o incluso caminos distintos. Nivel de integracin: la estructura puede ser un rbol de llamadas (un diagrama en el que los mdulos llaman a otros mdulos).

32

Nivel de sistema: La estructura puede ser una estructura de mens, procesos de negocio o una estructura de pgina web.

4.4.1 Pruebas de sentencias y cobertura

Una prueba de sentencia tiene como objetivo medir la cantidad sentencias (lneas de cdigo) que se han ejecutado y probado, comprobando que su funcin sea la correcta. Dicha medida se obtiene en porcentajes, tomando como 100% el total de sentencias, conforme aumente el avance de lneas ejecutadas, se aumenta la cobertura de la prueba.

4.4.2 Pruebas de decisin y cobertura

La prueba de decisin, relacionadas a las pruebas de ramificacin (Branch Test), se basa en la cantidad de flujos o escenarios que pueden presentarse cuando en el cdigo existen condicionales tipo IF. Por ejemplo, en sistema se probar la incapacidad de un empleado, dependiendo del sexo del mismo se puede o no otorgar una incapacidad por maternidad, por tanto, si se prueba para el sexo masculino entonces nicamente se habr cubierto un 50% de la decisin if, de igual manera, si nicamente se ha probado el sexo femenino se habr cubierto el otro 50% de la decisin if, sin embargo, al probar ambos sexo, se habr cubierto el 100% de la condicin if. Cabe destacar que las pruebas de decisin constituyen una forma de pruebas de flujo de control ya que siguen un flujo especfico de control a travs de los puntos de decisin. La cobertura de decisin es ms fuerte que la cobertura de sentencia; un 100% de cobertura de decisin garantiza un 100% de cobertura de sentencia, pero no al contrario.

4.4.3 Otras tcnicas basadas en las estructura

Existen niveles ms fuertes de cobertura estructural adems de la de decisin, por ejemplo, la cobertura de decisin y la cobertura de condicin mltiple.

4.5

Tcnicas basadas en la experiencia.

Como su nombre lo dice, este tipo de pruebas se basa mayormente en la experiencia de uno o varios probadores con respecto a un sistema, o bien, segn experiencias en diversos proyectos. Por ejemplo, un tester que ha manejado sistemas nmina y obtenido grandes conocimientos al respecto puede predecir los errores que podran suceder cuando se desea emplear y/o actualizar un nuevo sistema de nminas; o bien, si un tester ha trabajo con pruebas por medio 33

de guiones de prueba (scripts) para pruebas automatizadas con un sistema propietario, puede usar su experiencia para realizar las mismas pruebas automatizadas en un sistema libre. Este tipo de pruebas pueden ayudar a agilizar las pruebas cuando se tiene poco tiempo para completar el proyecto, cuando existen tester novatos o desconocen el sistema a probar, cuando no existe una documentacin detallada o sencillamente no existe, entre muchas otras. La efectividad de dicha tcnica depende mucho del tester y su experiencia y conocimiento, es recomendable que no sea la nica tcnica usada y por el contrario, utilizarla como complemento a una serie de pruebas formales, o bien, pruebas al azar una vez que todos los casos de prueba han sido probados.

4.6

Seleccin de tcnica de prueba

Antes de que se comiencen a ejecutar las pruebas, tiene que decidirse qu tipo de tcnicas se usarn para poder realizar las pruebas, para ello, se deben tomar en cuenta muchos factores, tales como el tiempo disponible en el proyecto, el costo del mismo, el costo y/o viabilidad del uso de herramientas, la experiencia de los probadores, si existe o no documentacin y el nivel de detalle con que se cuente, la complejidad del sistema, incluso deben considerarse aspectos como los recursos disponibles tanto en tiempo, personal y equipos de cmputo. Es comn que algunas tcnicas de pruebas sean aplicables a prcticamente cualquier sistema, mientras que habr algunas otras en las que no puedan aplicarse, sin embargo, durante la realizacin de los casos de prueba es comn la combinacin de diferentes tcnicas para lograr un mayor rango de pruebas.

34

5. Gestin de pruebas.
5.1

Organizacin de pruebas
5.1.1 Organizacin de pruebas e independencia

La gestin de pruebas como parte del proceso de pruebas La gestin d pruebas es la gestin del proyecto de los proyectos de pruebas. El proceso de pruebas es una actividad que cubre por completo el proceso de desarrollo de software. Las actividades propias de la gestin de pruebas son necesarias a lo largo de todo el proceso de pruebas. Actividad Concepcin de pruebas Planificacin de pruebas Control de pruebas Pruebas de aceptacin Producto resultado del trabajo Plan de pruebas (esttico) Plan de pruebas (dinmico) Informe de estado, accin de control Entrega (release) del producto software

La organizacin del equipo de pruebas depende en gran medida del tipo de proyecto que se est llevando a cabo, sin embargo, existen ventajas al tener probadores externos al equipo de trabajo que contribuyen a la efectividad de las pruebas as como el nivel de calidad que se busca. As pues, algunos de los beneficios relacionados con la independencia de las personas quienes prueban y a quienes ser entregado son: Objetividad en los resultados. La tarea de un desarrollador es la de crear, la de un probador es destruir, encontrar fallos que harn fracasar al programa, por tanto, se realizan pruebas exhaustivas para lograr dicho fin, despus de todo, es su trabajo. Prediccin de errores. Cuando existen probadores en los equipos de desarrollo, la experiencia de los primeros puede encontrar errores incluso antes de que se cometan, ahorrando tiempo y costos. 35

Se realiza el software segn la visin del cliente. Al tener probadores provenientes de la parte de negocio, o bien, la comunidad de usuarios se afinan detalles y acciones de acuerdo a la medida del cliente, ya que en papel no es tan sencillo compartir una visin del producto final, sin embargo, al tener a dichos probadores, se garantiza un producto a la medida.

Especializacin. Se pueden tener probadores especialistas para pruebas especficas, tales como pruebas de usabilidad, de carga, seguridad o de certificacin segn estndares y normativas.

Sin embargo, nos es conveniente tener completamente un equipo conformado por externos/independientes ya que pueden estar completamente aislados del proyecto y pueden ser vistos como cuellos de botella, pudiendo o no generarlos en realidad. Perfiles del personal de pruebas. Jefe de pruebas o director de pruebas (Test Manager). o Planifica y da seguimiento y control al proyecto. Debe tener habilidades para gestionar y otorgar calidad al software; requiere experiencia como jefe de proyecto. Diseador de pruebas (Test designer). o Disea los casos de pruebas necesarios y establece un orden. Entre sus conocimientos figuran el desarrollo y pruebas, ingeniera de software, especificaciones tcnicas y requisitos funcionales. Ingeniero de automatizacin de pruebas (test automation engineer). o Evala las posibilidades de automatizacin. Entre sus competencias se encuentra la experiencia como probador, conocimiento tcnico en el mbito de diseo y automatizacin de pruebas, conocimientos de programacin y amplios conocimiento en el uso de las herramientas utilizadas. Administrador de pruebas (test administrator)/ Administrador del sistema de pruebas (test system administrator). o Prepara y opera el entorno de pruebas (debe cumplir los requisitos del sistema de pruebas). Sus competencias necesarias son la administracin de sistemas, 36

conocimientos de herramientas de desarrollo y pruebas, y si aplica, bases de datos, redes, instalacin y operacin de software de sistema. Probador (tester). o Ejecuta las pruebas de acuerdo con la especificacin de casos de prueba,, las competencias necesarias incluye conocimiento bsico del software y de pruebas, operacin de herramientas de pruebas as como su ejecucin y conocimiento respecto a los objetos de prueba. Experto tcnico (technical expert). o Asiste al equipo de pruebas cuando se requiere, debe conocer la administracin de bases de datos, ser experto en interfaces de usuario as como experto en redes. Competencias no tcnicas (soft skills): Trabajo en equipo: instinto (poltico y) diplomtico. Disposicin a preguntar sobre hechos aparentemente obvios. Persistencia, fuerte personalidad. Meticulosidad y creatividad. Capacidad para tratar situaciones complejas. Capacidad de aprender rpidamente.

37

5.1.2 Tareas del Lder de Pruebas y del Probador

Tpicamente las tareas del lder de prueba pueden incluir: Coordinar la estrategia y el plan de prueba con los gestores de proyecto y otros. Escribir o revisar una estrategia de prueba para el proyecto y probar la poltica para la organizacin. Contribuir la perspectiva de prueba a las otras actividades del proyecto, tales como la planificacin de integracin. Planear las pruebas considerando el contexto y comprendiendo los riesgos incluyendo seleccionar los enfoques de prueba, estimar el tiempo, esfuerzo y el costo de las pruebas, adquirir recursos, definir los niveles, ciclos, enfoque y objetivos de prueba, y planificar la gestin de incidentes;

38

Iniciar la especificacin, preparacin, implementacin y ejecucin de pruebas, y monitorear y controlar la ejecucin. Adaptar la planificacin basada en el progreso y los resultados de prueba (a veces documentados en los repostes de estado) y tomar cualquier accin necesaria para compensar por problemas.

Establecer la gestin de configuracin adecuada del testware para trazabilidad. Introducir las mtricas apropiadas para medir el progreso de la prueba y evaluar la calidad de las pruebas y del producto. Decidir que debe ser automatizado, hasta qu grado y cmo. Elegir las herramientas para apoyar las pruebas y organizar cualquier entrenamiento en el uso de herramientas para los probadores. Decidir sobre la implementacin del entorno de prueba. Programar las pruebas. Escribir informes de resumen de prueba basados en la informacin reunida durante las pruebas.

Las tareas tpicas del probador pueden incluir: Revisar y contribuir a los planes de prueba. Analizar, revisar y evaluar los requisitos de usuario, especificaciones y modelos para testabilidad. Crear especificaciones de prueba. Configurar el entorno de prueba (a menudos coordinado con la administracin del sistema y la gestin de red). Preparar y adquirir datos de prueba. Implementar las pruebas en todos los niveles de prueba, ejecutar y registrar las pruebas, evaluar los resultados y documentar las desviaciones de los resultados esperados. Usar la administracin de prueba o las herramientas de gestin y probar las herramientas de prueba como sea requerido. Automatizar las pruebas (puede ser apoyado por un desarrollador o un experto en automatizacin de pruebas). Medir el rendimiento de los componentes y sistemas (de ser aplicable). Revisar las pruebas desarrolladas por otros. 39

Las personas que trabajan en anlisis de prueba, diseo de prueba, tipos de prueba especficos o en automatizacin de prueba pueden ser especialistas en estos roles. Dependiendo del nivel de prueba y de los riesgos relacionados con el producto y el proyecto, diferentes personas pueden encargarse del rol de probador, manteniendo algn grado de independencia. Tpicamente los probadores a nivel de componente e integracin seran desarrolladores, probadores al nivel de prueba de aceptacin seran usuarios y expertos del negocio, y los probadores para pruebas de aceptacin operacionales seran operadores.

5.2

Planificacin y estimacin de pruebas

5.2.1 Planificacin de pruebas
El inicio de la fase de pruebas siempre debe comenzar por la planificacin de pruebas, la cual ofrece una visin global del proyecto ya que debe incluir las estrategias a seguir, los tiempos establecidos para el proyecto y la administracin de los recursos tanto profesionales como tecnolgicos. La forma de realizar las pruebas varan de proyecto a proyecto as como de la empresa, pueden tomarse diversos planes para cada etapa, o bien, realizar un plan maestro (PMP) para definir un plan incluyente. Algunos elementos que influyen son las polticas de la empresa, los riesgos, la cantidad de recursos disponibles, la criticidad del proyecto, entre otros. Cabe destacar, que la planificacin es un tarea constante, que si bien, se establece al comienzo del proyecto, debe recibir retroalimentacin constante para actualizar el plan y tener una meta ms objetiva y real apegada a las prcticas que lleva el proyecto.

40

Se puede encontrar la estructura y contenidos de un plan de calidad en el estndar IEEE 730 (con informacin adicional del estndar IEEE 983). Elementos de un plan de aseguramiento de la calidad de acuerdo con el estndar 730: planificacin y descripcin de: Organizacin del proyecto. Documentos que cubren el ciclo de vida de desarrollo. Estndares, mtodos y convenciones de la misma manera que un mecanismo que asegure que aquellos son seguidos (cumplidos). Revisiones y auditorias durante el ciclo de vida de desarrollo. Proceso de pruebas. Documentacin de errores, acciones correctivas.

Plan de pruebas maestro Esttico (master test plan) Despus de definir roles, el proceso de pruebas comienza con su fase de planificacin. El primer paso es la creacin de un plan de pruebas maestro que cubre todas las fases del proceso de pruebas y se fijan las reglas segn los objetivos de pruebas. Posteriormente el plan es ampliado basado en retroalimentacin debido a que se puede especificar o detallar ms el proceso o puede extenderse el ciclo. El estndar IEEE 829 aporta una estructura de plan de pruebas maestro acreditada.

Plan de pruebas de acuerdo al estndar IEEE 829 41

1. Introduccin 2. Suposiciones. 3. Elementos de prueba.

9. Entregables de pruebas. 10. Tareas de pruebas. 11. Necesidades relativas al entorno.

4. Caractersticas/prestaciones sujetas a 12. Responsabilidades. pruebas. 5. Caractersticas/prestaciones no sujetas 13. Dotacin de personal y formacin. a pruebas. 6. Enfoque 7. Criterios de paso / fallo 8. Criterios de suspensin / reanudacin. 14. Calendario. 15. Riesgos y contingencias. 16. Aprobacin.

5.2.2 Actividades de planificacin de pruebas

Las actividades de planificacin deben contener: Determinar el alcance de las pruebas e identificacin de riesgos en caso de no realizar las pruebas. En esta primera etapa deben tenerse los objetivos fijados as como la estrategia que se tomar para alcanzar dichos objetivos. Determinar el nivel de detalle de las pruebas as como la documentacin de la misma. Anlisis y diseo de las pruebas. Programar recursos profesionales y tecnolgicos, as como establecer la ambientacin y resultados esperados, es decir, los datos de entrada y de salida, los cuales sern los insumos del sistema. Establecimiento de mtricas. Establecer una retroalimentacin, y de ser necesario, una actualizacin contina.

Actividades a realizar Las actividades en el desarrollo de pruebas son: Estategia de pruebas (test strategy). o Describe el nivel de pruebas y su intensidad as como mtricas y evala los riesgos. Es muy til cuando un sistema no se puede probar completamente. 42

Planificacin de recursos (Resource planning). o Estima los esfuerzos necesarios as como los profesionales designados a cada tarea. Cuanta con un calendario.

Prioridad de pruebas (priority test). Soporte de herramientas (tool support).

5.2.3 Criterios de entrada

Criterios de Entrada (Entry Criteria): Se asegura que el entorno est en su sitio y que el sistema entero soporta los procesos de testing. Algunos ejemplos: Todo el hardware est correctamente instalado, configurado y funcionando adecuadamente. Todos los diseos funcionales estn revisados y firmados. La preparacin de datos est lista. Todas las herramientas estn preparadas para las pruebas. etc

5.2.4 Criterios de salida

Criterios de Salida (Exit Criteria): Asegura que los requisitos del entorno han sido cumplidos antes de subir al siguiente entorno y las pruebas realizas completas satisfactoriamente. Algunos ejemplos: 100% de la ejecucin de los test cases completados. 90% pasados satisfactoriamente.(PASSED) 100% de los defectos de prioridad crtica resueltos. Estos son slo algunos ejemplos, pero es de suma importancia tener definidos apropiadamente estos criterios en nuestras estrategias y comunicarlos a toda la organizacin para que no haya ninguna duda sobre los criterios que todo el mundo debe cumplir.

5.2.5 Estimacin de pruebas

La estimacin de las pruebas consiste en la asignacin de tiempos en los cuales se realizar el ciclo de pruebas, tomando en cuenta el anlisis, diseo y ejecucin de pruebas as como la correccin de errores en caso de presentarse y su posterior revisin. Existen dos criterios en los cuales apoyarse para realizar la estimacin, las cuales son: 43

Mtricas: En estas, los tiempos se estiman en base a proyectos similares o anteriores, o bien, en valores tpicos. Experiencia: El enfoque de un experto o el propietario del sistema ofrece valores para estimar el esfuerzo.

Algunas recomendaciones son: Reserva un tiempo extra: En ocasiones, los proyectos se retrasan y obligan a consumir tiempo de las pruebas, por lo que ste tiempo de reserva es de gran ayuda. Depuracin de errores: Existen momentos en los que las estructuras del sistema son inestables, y el repararlo lleva tiempo, mismo que debe ser considerado en el plan, Recursos para el periodo planeado: Se deben considerar das de descanso de los recursos y los das feriados, as como un par de das por si el profesional requiera una incapacidad o tiempo para entender parte del sistema. Pruebas paralelas: Si existen versiones o mdulos independientes que no se afectan mutuamente (excluyentes) se podran realizar la prueba de ambos en el mismo tiempo. Las estimaciones pueden equivocarse: Constantemente obtener retroalimentacin de la ejecucin y los estados en los que se mantiene el reparar un error son fundamentales para re-calcular los tiempos asignados. Esto tambin es de gran ayuda para siguientes estimaciones. La experiencia previa puede ayudar: El tener un expertis sobre el sistema a probar o uno anterior puede ayudar a identificar problemas no considerados y que ocasionaran prdida de tiempo que podra traducirse en atrasos del proyecto.

5.2.6 Estrategia de pruebas, enfoque de pruebas

Enfoque de pruebas es la implementacin de la estrategia de pruebas definida para un proyecto especfico. En general sta incluye las decisiones tomadas en funcin de los objetivos del proyecto (desde el punto de vista del proceso de pruebas) y la evaluacin de riesgo llevada a cabo, puntos de entrada respecto del proceso de pruebas, las tcnicas de diseo de pruebas a aplicar, criterios de salida y tipos de pruebas a ejecutar. Enfoques de pruebas:

44

Enfoque analtico (analytical approach): Se realiza un anlisis previo a las pruebas, por ejemplo, pruebas basadas en riesgos (risk-based-testing).

Enfoque heurstico (heuristic approach): Las pruebas son ms reactivas, por ejemplo, pruebas exploratorias.

5.3

Seguimiento y control del progreso de las pruebas

5.3.1 Seguimiento del progreso de las pruebas
Consiste en conocer el avance de las pruebas ejecutas y por ejecutar as como los resultados obtenidos de las mismas ya sean positivos o negativos, esto con el fin de retroalimentar el proyecto y compararlo contra el plan de pruebas, y de ser necesario, reajustar los tiempos y recursos, adems de poder tomar nota sobre las lecciones aprendidas. Algunas de las estadsticas que obtienen son: Nmero de casos de prueba ejecutados Nmero de casos de prueba aprobados Nmero de casos de prueba no aprobados, en reparacin y correccin. Porcentaje del cdigo cubierto. Porcentaje real del trabajo en horas-humano. Informacin de los defectos encontrados.

5.3.2 Informes de pruebas

Es el informe que recoge la informacin ms destacable de lo acontecido durante la ejecucin de los servicios acordados en el Plan de Testing para la entrega. Entre otros datos muestra el resultado de cada servicio, acompaado de las estadsticas que lo justifican. Normalmente ste informe se entrega al finalizar la ejecucin de todos los servicios acordados en el Plan de Testing, aunque en ocasiones puede ser demandado antes para analizar la situacin del Testing de la entrega y la calidad observada hasta ese momento.

45

5.3.3 Control de pruebas

Son observaciones que se aplican como resultado de la informacin obtenida mediante las mtricas definidas en el plan de pruebas, con las cuales se controlan los incidentes presentados as como tiempos y recursos.

5.4

Gestin de la configuracin
La gestin de la configuracin es establecer y mantener la integridad de los productos del sistema a lo largo del ciclo de vida del mismo; lo que en algunas ocasiones debe garantizar que la documentacin del sistema sea clara, concisa, completa y posible de dar mantenimiento as como disponible para el equipo de pruebas, el cliente y auditoria, por tanto, todos los elementos a probar se han identificado plenamente y se ha llevado a cabo por lo menos una prueba al mismo.

5.5

Riesgo y pruebas
Un riesgo es la posibilidad de ocurrir un peligro o amenaza y el no controlarlo puede causar problemas serios en el desarrollo del sistema. El nivel de riesgo es medido conforme a la probabilidad de que ste suceda y/o bajo qu circunstancias.

5.5.1 Riesgos del proyecto

Los riesgos se identifican como internos y externos al proyecto, es decir, aspectos tcnicos como el cdigo sera interno, mientras que aspectos organizacionales seran externos. Algunos ejemplos: Tcnicos: El desarrollo del sistema no cumple con las especificaciones. Las pruebas no se llevan a cabo debido a que el tiempo se ha consumido prematuramente por causas diversas. No se ha establecido el tiempo suficiente para pruebas y no se han completado. Organizacional: Falta de capacitacin o personal incapaz Mala cultura organizacional Omisin de errores a costa de liberar el proyecto a tiempo. 46

Si se trabaja con externos, pueden surgir problemas con el entendimiento del negocio, o problemas con presupuestos y contratos.

5.5.2 Riesgos del producto.

Las posibles reas de fallos (eventos futuros adversos o peligros) en el software o sistema son riesgos del producto. Entre los riesgos se pueden identificar: Pobre calidad en el software Mal entendimiento de los requerimientos, por tanto, el software no hace lo que debera. Falta de pruebas. Problemas con el sistema en el que se implementar, tales como rendimiento, compatibilidad, seguridad, etc.

5.6

Gestin de incidencias
La Gestin de Incidencias tiene como objetivo resolver, de la manera ms rpida y eficaz posible, cualquier incidente que cause una interrupcin en el servicio. La Gestin de Incidencias no debe confundirse con la Gestin de Problemas, pues a diferencia de esta ltima, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelacin entre ambas. Los objetivos principales de la Gestin de Incidencias son: Detectar cualquier alteracin en los servicios TI. Registrar y clasificar estas alteraciones. Asignar el personal encargado de restaurar el servicio segn se define en el SLA correspondiente. Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios debe jugar un papel esencial en el mismo. El siguiente diagrama resume el proceso de Gestin de Incidencias:

47

Aunque el concepto de incidencia se asocia naturalmente con cualquier mal funcionamiento de los sistemas de hardware y software, segn el libro de Soporte del Servicio de ITIL una incidencia es: Cualquier evento que no forma parte de la operacin estndar de un servicio y que causa, o puede causar, una interrupcin o una reduccin de calidad del mismo. Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, a excepcin las Peticiones de Servicio tales como concesin de nuevas licencias, cambio de informacin de acceso, etc. Cualquier cambio que requiera una modificacin de la infraestructura no se considera un servicio estndar y requiere el inicio de una Peticin de Cambio (RFC) que debe ser tratada segn los principios de la Gestin de Cambios. Los principales beneficios de una correcta Gestin de Incidencias incluyen: Mejorar la productividad de los usuarios. Cumplimiento de los niveles de servicio acordados en el SLA. Mayor control de los procesos y monitorizacin del servicio. Optimizacin de los recursos disponibles. Una CMDB ms precisa, pues se registran los incidentes en relacin con los elementos de configuracin. Y principalmente: mejora la satisfaccin general de clientes y usuarios. 48

Por otro lado una incorrecta Gestin de Incidencias puede acarrear efectos adversos tales como: Reduccin de los niveles de servicio. Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolucin de la incidencia. Se pierde valiosa informacin sobre las causas y efectos de las incidencias para futuras reestructuraciones y evoluciones. Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestin de sus incidencias. Las principales dificultades a la hora de implementar la Gestin de Incidencias se resumen en: No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos. No existe un margen operativo que permita gestionar los picos de incidencias, por lo que stas no se registran adecuadamente e impiden la correcta operacin de los protocolos de clasificacin y escalado.

6.
6.1

Herramientas de soporte de pruebas

Tipos de herramientas de pruebas
6.1.1 Significado y objetivo de las herramientas de pruebas.
Las herramientas de prueba son aquellas que contribuyen a la ejecucin y administracin en el proceso de pruebas, pueden ser propietarias o libres y la eleccin de las mismas depende del proyecto. Sus caractersticas son: Administracin: Son aquellos que llevan la gestin de la ejecucin, las estadsticas, las bitcoras, seguimiento de defectos, calendarizacin, entre otros.

49

Ejecucin: Son aquellas auxiliares en la ejecucin de las pruebas para facilitar o apoyar a la realizacin de los casos de prueba, dependiendo del tipo de pruebas pueden ser suits (o frames) completas o herramientas sencillas.

Otras: Son herramientas que si bien, no tienen como propsito la dedicacin en el rea de pruebas, son tiles para otros mbitos, algunos ejemplos son las hojas de clculo, editores de texto, captores de pantalla, entre otros.

6.1.2 Clasificacin de herramientas de prueba.

Entre las herramientas de pruebas existen algunas con propsitos especficos y pueden clasificarse como tal. As pues, se pueden clasificar basndose en diversos criterios, tales como los objetivos a cumplir, si es de cdigo libre o abierto, shareware (para compartir), la tecnologa usada. Ejemplo de los propsitos son las pruebas automatizadas que requieren cdigo script que dar las instrucciones, herramientas de cargas que simularn la carga que tendra el sistema en el mundo real, herramientas de seguridad que exploran vulnerabilidades en el sistema para prevenir que usuarios malintencionados puedan explotarlas.

6.1.3 Herramientas de soporte para la gestin de pruebas.

Son catalogadas de la siguiente manera: Herramientas de gestin de pruebas: Ofrecen interfaces para ejecutar pruebas, localizar defectos y gestionar requisitos, adems de dar soporte al anlisis cuantitativo y a la elaboracin de informes sobre los objetos de prueba. Herramientas de gestin de requisitos: Almacenan sentencias de requisitos, almacenan los atributos de los requisitos (incluida la prioridad), proporcionan identificadores nicos y facilitan la localizacin de los requisitos para pruebas individuales. Herramientas de gestin de la configuracin: A pesar de no ser estrictamente una herramienta de prueba, stas son necesarias para el almacenamiento y la gestin de versiones de productos de soporte de software y software asociado, especialmente a la hora de configurar ms de un entorno de hardware/software en trminos de versiones del sistema operativo, compiladores, navegadores, etc.

50

6.1.4 Herramientas de soporte para las pruebas estticas

Herramientas de revisin. Son tiles en el proceso de revisin, lista de comprobacin y directriz de revisin. Normalmente se utilizan para la comunicacin de defectos y comentarios, elimina problemas como equipos de trabajo que no estn fsicamente en un lugar adems de poder manejar equipos grandes. Herramientas de anlisis esttico. De gran apoyo para la planificacin y anlisis de riesgos incluso antes de la codificacin, por lo que la prevencin reduce costos de solucionar errores en etapas tempranas del proyecto. Por sus caractersticas pueden ayudar a establecer mtricas de avance. Herramientas de modelado. Estas herramientas sirven para la creacin de casos de prueba.

6.1.5 Herramientas de soporte para la especificacin de prueba.

Herramientas de diseo de pruebas: Funcionan como generadores de datos de entrada de prueba, o bien, pruebas ejecutables. Herramientas de preparacin de datos de prueba: Se utilizan para el manejo de bases de datos, archivos o transmisiones de datos.

6.1.6 Herramientas de soporte para la ejecucin y el registro de pruebas.

Herramientas de ejecucin de pruebas: Mediante la creacin de scripts con algn lenguaje para ese propsito permite ejecutar pruebas automticamente o semi-automticamente. Su efectividad depende de la lgica de programacin de quien desarrolle el script. Arns de pruebas / Herramientas de trabajo de pruebas unitarias. Facilitan el proceso de prueban en componente o partes del sistema simulando situaciones reales a las que ser sometido dicho componente. Comparadores de pruebas. Como su nombre lo menciona, compara dos o ms archivos para el empate de los mismo o para encontrar las diferencias entre los mismos, muy til en las pruebas de regresin.

6.1.7 Herramientas de soporte para el rendimiento y la monitorizacin.

Herramientas de anlisis dinmico. Estas sirven para realizan exploraciones dinmicas al software que no pueden ser encontradas tan fcilmente cuando se hacen de forma esttica, ya que caractersticas como el tiempo de respuesta, prdidas de memoria o el formato de salida nicamente son evidentes cuando se ejecutan las pruebas. Herramientas de pruebas de rendimiento/ pruebas de carga/ pruebas de estrs. Son aquellas que simulan el comportamiento de usuarios y la carga que puede generar, desde un solo 51

usuario hasta una gran cantidad para ver el comportamiento del sistema, es decir, cmo maneja la informacin, tiempo de respuesta, si falla en actualizar bases de datos, si se pierde conexin, entre otros.

6.1.8 Herramientas de soporte para necesidades de pruebas especficas

Evaluacin de calidad de los datos. Consiste en validar que los datos de entrada a utilizar realmente sean tiles para su propsito, por ejemplo, con un cierto formato, que se basen en plantillas, que se presenten de cierta forma, etc.

6.2

Uso efectivo de las herramientas: Ventajas potenciales y riesgos.

6.2.1 Ventajas potenciales y riesgos de las herramientas de soporte de pruebas (para todas las herramientas)
Alguna de las ventajas al obtener una herramienta de pruebas: El esfuerzo se puede disminuir, sobre todo si es repetitivo. Se obtiene seguridad ya que en el proceso la intervencin humana es mnima o nula. Generacin automtica de estadsticas. Evaluacin por medio de mtricas Pueden facilitar la comunicacin entre el grupo de trabajo. Puede incluir a todos los participantes del equipo para conocer los estatus del proyecto, por lo que todos estn siempre informados y en tiempo real.

Algunos riesgos: Se debe aprender a usar una nueva herramienta, lo cul puede llevar tiempo y capacitacin generando retrasos en el proyecto. La herramienta tiene limitantes no esperadas o no especificadas. Pueden aumentar los costos del proyecto debido a las licencias, o bien, la ayuda y/o soporte no son de ayuda.

52

Subestimacin de tiempos y esfuerzos debido a los requerimientos de la herramienta y el sistema.

Se requiere experiencia para conocer cmo se comporta la herramienta para poder estimar tiempos correctamente, en caso contrario, puede retrasar el proyecto.

En ocasiones requiere ms esfuerzo usar una herramienta que el necesario para un ingeniero de pruebas.

6.2.2 Consideraciones especiales para algunos tipos de herramientas.

Herramientas de ejecucin de pruebas. Si bien es cierto que existen opciones de grabar las acciones al ejecutar una prueba, cuando stos son largos y en ocasiones requieren muchas intervenciones, su viabilidad disminuye notablemente y requerir de opciones ms especficas, tales como la programacin de un script que puede basarse en propiedades o especificaciones del sistema, sin embargo, requiere de un mayor conocimiento e incluso deben probarse que funcionen hasta de ponerlos en marcha, por lo que el proyecto puede hacerse an ms largo. Herramientas de anlisis esttico. La exploracin esttica del cdigo puede ayudar a sujetarse a un estndar, sin embargo, eso no garantiza que sea correcto y viceversa. Herramientas de gestin de pruebas. Debido a que interactan con uno o varios sistemas, debe existir primeramente un soporte e interactividad, cuestiones muy importantes para poder obtener el mayor provecho.

6.3

Introduccin de una herramienta en una organizacin

Entre las consideraciones principales al seleccionar una herramienta existen: Costo-Beneficio Segn las necesidades de la empresa, una herramienta puede ser muy bsica o muy complicada, por lo que debe considerarse realmente qu se necesita. El soporte del fabricante si se trata de una herramienta propietaria o bien, soporte por parte del grupo si se trata de una herramienta libre. Si la herramienta es intuitiva o no, puede requerir capacitacin por parte del desarrollador de la herramienta.

53

Siempre es recomendable utilizar proyectos piloto para conocer el comportamiento de una herramienta y verificar que es realmente lo que se necesita, los objetivos de dicho piloto son: Conocer detalladamente la herramienta. El costo de implementarlo. El costo de la herramienta o del soporte. Si la herramienta se ajusta a las necesidades o no de la empresa.

Los factores de xito para el despliegue de la herramienta dentro de una organizacin incluyen: Hacer extensiva la herramienta al resto de la organizacin de una manera incremental. Adaptar y mejorar los procesos segn se requiera para la herramienta. Impartir capacitacin. Hacer un seguimiento de los beneficios y desventajas que presenta la herramienta. Difundir las lecciones aprendidas as como la informacin recaba para que todo el equipo puede valorarla y ofrecer su visin.

54

Glosario:
Error (error) (IEEE 610): Accin humana que produce un resultado incorrecto. Ejemplo: un error de programacin. Software (IEEE610): Programas de ordenador, procedimientos y posiblemente documentacin y datos pertenecientes a la operacin de un sistema basado en una computadora. Calidad de software (ISO/IEC 9126): La totalidad de la funcionalidad y presentaciones de un producto software que estn relacionadas con su capacidad de satisfacer las necesidades explcitas o implcitas. Calidad (IEEE 610): Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas del usuario/cliente. De acuerdo a la norma ISO/IEC 9126 la calidad software consiste en: Atributos funcionales Atributos no funcionales Funcionabilidad Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad

Funcionalidad: Correccin: la funcionalidad satisface los atributos / capacidades requeridos Completitud: la funcionalidad satisface todos los requisitos (funcionales) Segn ISO/IEC 9126 incluye: Adecuacin (suitability) Exactitud (accuracy) Interoperabilidad (interoperability) Seguridad (security) Cumplimiento de funcionalidad (funcionality complience)

Caso de prueba (Test case) (IEEE 829) Incluye: 55

Precondiciones Conjunto de valores de entrada Conjunto de resultados esperados Pos condiciones 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)

Revisin (review) (IEEE Std 1028): Evaluacin de un producto para detectar discrepancias respecto de los resultados planificados y para recomendar mejoras. (IEEE 1028) Evaluacin de un producto o del estado de un proyecto para detectar discrepancias con los resultados planificados y para recomendar mejoras. Algunos ejemplos incluyen la revisin de gestin, revisin de gestin, revisin informal, revisin tcnica, inspeccin y revisin guiada. Requisito / Requerimiento (requirement) (IEEE 610): Condicin o capacidad necesaria para un usuario con el objeto de solucionar un problema o lograr un objetivo que debe ser alcanzado o posedo por un sistema o componente de un sistema, para satisfacer un contrato, estndar, especificacin u otro documento impuesto formalmente. Especificacin de procedimiento depruebas (test procedure specification) (escenario de prueba test scenario) (IEEE829): Documento que especifiaca la secuencia de acciones para la ejecucin de una prueba. Tambin conocido como script de prueba manual. Registro de prueba (test log) (protocolo de prueba- test protocol; informe de pruebas-test report) (IEEE 829): Registro cronolgico de los detalles relevantes respecto a la ejecucin de pruebas: cundo se desarrollaron las pruebas, qu resultados fueron generados. Verificacin (ISO 9000): Comprobacin con los requisitos establecidos. Validacin (ISO 9000): comprobacin de la idoneidad para el uso esperado.

56

Fuentes consultadas: http://www.ecured.cu/index.php/Pruebas_de_software http://formandobits.com/2013/07/los-siete-principios-de-las-pruebas-software/ http://materias.fi.uba.ar/7548/PruebasSoftware.pdf http://jorgemontanoblog.files.wordpress.com/2011/10/control-de-calidad-de-software-final.pdf http://itilv3.osiatis.es/operacion_servicios_TI/gestion_incidencias/introduccion_objetivos.php http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/344 http://www.softqanetwork.com/criterios-de-entrada-y-salida-en-software-testing http://www.softqanetwork.com/criterios-de-entrada-y-salida-en-software-testing http://www.dovinet.com/es-do/verArticulo.aspx?Id=73 http://calidadysoftware.blogspot.com/2012/04/testing-ii-planificacion-de-las-pruebas.html http://www.softqanetwork.com/software-testing-life-cycle http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf http://dc.exa.unrc.edu.ar/rio2013/sites/default/files/notas-03.pdf http://indalog.ual.es/mtorres/LP/Prueba.pdf http://www.lsi.us.es/docencia/get.php?id=361

57