foundation level syllabus (2010)spanish

Certified TesterFoundation Level Syllabus

International Software Testing Qualifications Board

Certified Tester Foundation Level Syllabus

Version 2005


Versin 2005 Spanish Software Testing Qualifications Board

1-88

Julio de2005



Copyright 2005, los autores (Thomas Mller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson y Erik Van Veendendal), todos los derechos reservados. Los autores estn transfiriendo el copyright al International Software Testing Qualifications Board (en adelante ISTQB). Los autores (como propietarios actuales del copyright) e ISTQB (como el propietario futuro del copyright) han acordado las siguientes condiciones de uso: 1) Cualquier compaa o grupo de compaas puede utilizar esta programacin o plan de estudio como base para el curso de aprendizaje si reconocen a los autores y al ISTQB como dueos de la fuente y del copyright del programa y a condicin de que cualquier anuncio de tal curso de aprendizaje puede mencionar la programacin nicamente despus de su presentacin para la acreditacin oficial de los materiales por parte de un equipo nacional ISTQB reconocido; 2) Cualquier persona o grupo de personas puede usar esta programacin como base para artculos, libros, u otros escritos si los autores y el ISTBQ son reconocidos como fuente y copyright de la propia programacin; 3) Cualquier equipo nacional ISTBQ reconocido (ISTQB-recognized National Board) puede traducir esta programacin y dar licencia de la misma (o su traduccin) a terceros.


2-88

Julio de2005



Histrico de revisionesVersin ISTQB 2005 ASQF V2.2 ISEB V2.0 Fecha 01-July-2005 July-2003 25-Feb-1999 Observacin Certified Tester Foundation Level Syllabus ASQF Syllabus Foundation Level Version 2.2 LehrplanGrundlagen des Softwaretestens ISEB Software Testing Foundation Syllabus V2.0 25 February 1999


3-88

Julio de2005



Tabla de contenidosHistrico de revisiones Tabla de contenidos Agradecimientos Introduccin al plan de estudio 1. Fundamentos del testing (K2) 1.1 Porqu es necesario el testing? (K2) 1.1.1 Contexto de los sistemas software (K1) 1.1.2 Causa de los defectos software (K2) 1.1.3 Role del testing en desarrollo software, mantenimiento y operaciones (K2) 1.1.4 Testing y calidad (K2) 1.1.5 Cunto testing es suficiente? (K2) 1.2 Qu es el testing? (K2) 1.3 Principios generales del testing (K2) 1.4 Procesos fundamentales del test (K1) 1.4.1 Planificacin del test y control (K1) 1.4.2 Anlisis y diseo de test (K1) 1.4.3 Implementacin y ejecucin del test (K1) 1.4.4 Evaluacin de los criterios de salida e informes (K1) 1.4.5 Actividades del cierre del test (K1) 1.5 La psicologa del testing (K2) 2. Testing a travs del ciclo de vida del software (K2) 2.1 Modelos de desarrollo software (K2) 2.1.1 V-model (K2) 2.1.2 Modelo de desarrollo iterativo (K2) 2.1.3 Test del modelo del ciclo de vida (K2) 2.2 Niveles de test (K2) 2.2.1 Test de componente (K2) 2.2.2 Test de integracin (K2) 2.2.3 Test de sistema (K2) 2.2.4 Test de aceptacin (K2) 2.3 Tipos de test: targets de los test (K2) 2.3.1 Test de funcionamiento o funcional (K2) 2.3.2 Test de caractersticas del producto software o test no funcional (K2) 2.3.3 Test de estructura-arquitectura del software o test estructural (K2) 2.3.4 Test relacionado con cambios o test de confirmacin o de regresin (K2) 2.4 Test de mantenimiento 3. Tcnicas estticas (K2) 3.1 Revisiones y el proceso de test (K2) 3.2 Proceso de revisin (K2) 3.2.1 Fases de una revisin formal (K1) 3.2.2 Roles y responsabilidades (K1) 3.2.3 Tipos de revisin (K2) 3.2.4 Factores de xito para revisiones (K2) 3.3 Anlisis esttico por herramientas (K2) Versin 2005 Spanish Software Testing Qualifications Board

03 04 07 08 11 12 12 12 12 12 13 14 16 17 17 18 18 19 19 20 22 23 23 23 24 25 25 26 26 27 29 29 30 30 31 32 33 34 35 35 35 36 37 38

4-88

Julio de2005



4. Tcnicas de diseo de test (K3) 4.1 Identificacin de las condiciones de prueba y diseo de los casos de prueba (K3) 4.2 Categoras de las tcnicas de diseo de pruebas (K2) 4.3 Tcnicas basadas en especificacin o de caja negra (K3) 4.3.1 Particionamiento por equivalencia (K3) 4.3.2 Anlisis de valores lmite (K3) 4.3.3 Pruebas de tablas de decisin (K3) 4.3.4 Pruebas de transicin de estado (K3) 4.3.5 Pruebas de casos de uso (K2) 4.4 Tcnicas basadas en estructura o de caja blanca (K3) 4.4.1 Pruebas de sentencia y cobertura (K3) 4.4.2 Pruebas de decisin y cobertura (K3) 4.4.3 Otras tcnicas basadas en estructura (K1) 4.5 Tcnicas basadas en la experiencia (K2) 4.6 Eleccin de las tcnicas de pruebas (K2) 5. Gestin de tests (K3) 5.1 Organizacin del test (K2) 5.1.1 Organizacin del test e independencia (K2) 5.1.2 Tareas del lder del test y el tester (K1) 5.2 Planificacin de test y estimacin (K2) 5.2.1 Planificacin del test (K2) 5.2.2 Actividades de planificacin del test (K2) 5.2.3 Criterios de salida (K2) 5.2.4 Estimacin del test (K2) 5.2.5 Tcnicas de test (estrategias de test) (K2) 5.3 Monitorizacin y control del progreso del test (K2) 5.3.1 Monitorizacin del proceso de test (K1) 5.3.2 Informe de test (K2) 5.3.3 Control de test (K2) 5.4 Gestin de configuracin (K2) 5.5 Riesgo y testing (K2) 5.5.1 Riesgo de proyecto (K1, K2) 5.5.2 Riesgo de producto (K2) 5.6 Gestin de incidencias (K3) 6. Herramientas de soporte para testing (K2) 6.1 Tipos de herramientas de test (K2) 6.1.1 Clasificacin de herramientas de test (K2) 6.1.2 Herramientas de soporte para la gestin de pruebas (K1) 6.1.3 Herramientas de soporte para tests estticos (K1) 6.1.4 Herramientas de soporte para test de especificacin (K1) 6.1.5 Herramientas de soporte para la ejecucin de test y carga (K1) 6.1.6 Herramientas de soporte para la ejecucin y control (K1) 6.1.7 Herramientas de soporte para reas especficas de aplicacin (K1) 6.1.8 Herramientas de soporte usando otras herramientas (K1) 6.2 Uso efectivo de herramientas: beneficios y riesgos (K2)

40 42 44 45 45 45 45 46 46 48 48 48 48 50 51 52 54 54 55 57 57 57 58 58 58 60 60 60 61 62 63 63 63 65 67 68 68 69 70 71 71 73 73 74 75


5-88

Julio de2005



6.2.1 Beneficios y riesgos potenciales de las herramientas de soporte para testing (K2) 6.2.2 Consideraciones especiales para algunos tipos de herramientas (K1) 6.3 Introducir una herramienta en una organizacin (K1) 7. Referencias Apndice A - Trasfondo del plan de estudio (syllabus) Apndice B - Objetivos del aprendizaje / Nivel de conocimiento Apndice C - Reglas aplicadas al plan de estudios de ISTBQ Foundation Apndice D - Informacin para los formadores

75 75 77 78 80 83 85 87


6-88

Julio de2005



AgradecimientosEste documento ha sido desarrollado por el ISTQB-FL: Thomas Mller (Presidente), Rex Black, Sigrid Eldh, Dorothy Gram., Klaus Olsen, Marte Pyhjrvi, Geoff Thompson y Eric van Veendendal. El equipo de trabajo quiere agradecer al grupo de revisin y a todas las plataformas nacionales sus aportaciones al actual plan de estudios. En particular agradecer a Anastasios Kyriakopoulos (Austria), Klaus Olsen, Christine Rosenbeck-Larsen (Dinamarca), Matthias Daigl, Uwe Hehn, Tilo Linz, Horst Pohlmann, Ina Schieferdecker, Sabine Uhde, Stephanie Ulrico (Alemania), Vipul Kocher (India), Shmuel Knishinsky, Ester Zabar (Israel), Anders Claesson, Mattias Nordin, Ingvar Nordstrm, Stefan Ohlsson, Kennet Osbjer, Ingela Skytte, Klaus Zeuge (Suecia), Armin Born, Sandra Harries, Silvio Moser, Reto Mller, Joerg Pietzsch (Suiza), Aran Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen Moore, Peter Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith, Richard Taylor, Neil Thompson, Pete Williams (Reino Unido) y Dale Perry (Estados Unidos).


7-88

Julio de2005



Introduccin al plan de estudiosPropsito de este documentoEl plan de estudios que presenta este documento constituye la base para la obtencin del nivel bsico Foundation Level del Internacional Software Testing Qualification. La Internacional Software Testing Qualification Board en adelante ISTQB, proporciona este documento a los organismos examinadores nacionales para que puedan acreditar a las entidades que imparten formacin en esta materia y para obtener una traduccin de las cuestiones de examen en la lengua local. Informacin acerca de la historia y antecedentes de este programa de formacin se encuentra en el Apndice A.

El Certificado de Tester (Nivel Bsico) en la prueba del SoftwareEl Nivel Bsico de calificacin est dirigido a cualquiera que est implicado en la prueba de Software. Esto incluye a personas que acten como probadores, analistas de test, ingenieros de test, especialistas en test, directores de test, probadores de aceptacin de usuarios y desarrolladores de software. Este nivel de calificacin es tambin apropiado para todo aquel que desee un conocimiento bsico de la prueba del software, como jefes de proyecto, gestores de calidad, gestores en desarrollo de software, analistas de negocio, directores en Tecnologas de Informacin y especialistas en gestin. La certificacin en el nivel bsico proporciona la posibilidad de acceder a un nivel superior en la Testing Software Qualification.

Objetivos de aprendizaje/ Nivel de conocimientoLos niveles cognoscitivos estn expresados en cada seccin segn este plan de estudios: K1: recordar, reconocer, retirar; K2: entender, explicar, dar razones, comparar, clasificar, resumir; K3: Aplicar. Ms detalles y ejemplos acerca de los objetivos de aprendizaje se pueden encontrar en el Apndice B. Todos los trminos que aparecen al final de cada captulo bajo el encabezamiento Trminos deben ser recordados (K1), incluso cuando no aparezcan explcitamente mencionados en los objetivos de aprendizaje.


8-88

Julio de2005



El examenEl examen de certificacin en el nivel bsico estar basado en el presente plan de formacin. Las respuestas a las cuestiones de examen requieren el uso de material basado en ms de una de las secciones de este plan de estudios. Todas y cada una de las secciones de este documento estn sujetas a examen. El formato de examen es de seleccin mltiple. Los exmenes pueden ser realizados como parte de un curso de certificacin o de forma independiente en los centros de examen.

AcreditacinLos proveedores de cursos cuyo material sigue este plan de formacin, deben estar acreditados por una plataforma nacional reconocida por la ISTQB. Las directrices de acreditacin podrn ser obtenidas en la plataforma u organismo que lleva a cabo la acreditacin. Un curso acreditado es reconocido si se ajusta a este plan de estudios y permite la realizacin de un examen ISTQB como parte del curso.

Nivel de detalleEl nivel de detalle en este plan de estudios permite una enseanza y evaluacin consistente internacionalmente. Para conseguir esta meta, el plan de estudios se compone de: Objetivos generales de instruccin describiendo las intenciones del nivel bsico. Un ndice con la informacin a impartir, incluyendo una descripcin y referencias a fuentes adicionales si fuera necesario. Objetivos de aprendizaje para cada rea de conocimiento, describiendo el aprendizaje cognoscitivo resultante y el nivel de conocimiento que se alcanzar. Una lista de trminos que el estudiante debe ser capaz de entender y recordar. Una descripcin de los conceptos clave a ensear, incluyendo referencias/fuentes tales como literatura aceptada o estndares.

El contenido del plan de estudios no es una descripcin completa del rea de conocimiento de la prueba del software, si no que refleja el nivel de detalle que debe ser cubierto en los cursos de formacin del Nivel Bsico.

Como est organizado el plan de estudiosExisten seis captulos principales. Los encabezados de cada captulo muestran el nivel de los objetivos de aprendizaje que son cubiertos en el captulo y el tiempo que debe ser empleado en el mismo. Por ejemplo:


9-88

Julio de2005



2. Prueba durante el ciclo de vida del software (K2) | 135 minutos El ejemplo anterior muestra que el Captulo 2 tiene objetivos de aprendizaje K1 (se asume cuando aparecen niveles superiores) y K2 (pero no K3), y adems se prev un periodo de 135 minutos para ensear la materia del captulo. Dentro de cada captulo existen numerosas secciones. Cada seccin tambin tiene objetivos de aprendizaje y el tiempo requerido. Las sub-secciones que no tienen un tiempo determinado se incluyen dentro del tiempo de la seccin.


10-88

Julio de2005



1. Fundamentos de la prueba (K2) | 155 minutosObjetivos de aprendizaje para Fundamentos de la pruebaLos objetivos identifican lo que ser capaz de hacer al finalizar cada mdulo.

1.1 Por qu es la prueba necesaria? (K2) Describir, con ejemplos, la manera en el que un defecto en el software puede causar daos a una persona, al medioambiente o a la compaa. (K2) Distinguir entre la raz de la causa del defecto y sus efectos. (K2) Dar razones por las que la prueba del software es necesaria utilizando ejemplos. (K2) Describir por que la prueba forma parte de la garanta de calidad y dar ejemplos de cmo la prueba contribuye a aumentar la calidad. (K2) Recordar trminos errneos, defectos, fallos y correspondientes condiciones de error y bug. (K1)

1.2 Qu es la prueba? (K2) Recordar los objetivos comunes de la prueba. (K1) Describir el propsito de la prueba en el desarrollo de software, mantenimiento y operaciones como una forma de encontrar defectos, proporcionar confianza e informacin y prevenir defectos. (K2)

1.3 Principios generales de la prueba (K2) Explicar los principios fundamentales de la prueba. (K2)

1.4 Procesos fundamentales del test (K1) Recordar las actividades fundamentales del test desde la planificacin hasta el cierre de las actividades de test y las principales tareas de cada actividad. (K1)

1.5 La psicologa de la prueba (K2) Recordar que el resultado de la prueba est influenciada por factores psicolgicos (K1): o Objetivos claros; o Balance de la auto-prueba y la prueba independiente; o Reconocimiento de comunicacin corts y realimentacin sobre defectos. Contrastar la perspectiva de un probador con la de un desarrollador. (K2).


11-88

Julio de2005



1.1 Por qu es necesaria la prueba (K2) | 20 minutos TrminosBug, defecto, error, fracaso, fallo, equivocacin, calidad,, riesgo, software, prueba.

1.1.1 Contexto de los Sistemas Software (K1)Los sistemas software experimentan un auge importante en la vida diaria, desde aplicaciones de negocios (ej. Banca.) hasta productos de consumo (ej. automviles). Mucha gente ha tenido alguna experiencia con software cuyo funcionamiento no ha sido el esperado. El software que no funciona de la forma adecuada puede conducir a muchos problemas como, la prdida de capital, tiempo, reputacin en los negocios e incluso causar daos o la muerte a personas.

1.1.2 Causas de los Defectos Software (K2)El ser humano puede tener un error (equivocacin), que se traduce en un defecto (fallo, bug) en el cdigo, en el software, en un sistema o en un documento. Si un defecto en el cdigo se ejecuta, el sistema fallar al realizar aquello que debe hacer (o que no debe hacer), provocando un fallo. Los defectos en software, sistemas o documentos pueden traducirse en fallos aunque no siempre es as. Los defectos se originan debido a que el ser humano es falible y debido a la presin temporal, complejidad del cdigo o infraestructura, cambios tecnolgicos y/o multitud de interacciones entre sistemas. Los fallos pueden ser causados tambin por las condiciones ambientales: radiacin, magnetismo, campos elctricos y contaminacin. Estas condiciones pueden causar fallos en el firmware o influir en la ejecucin de software modificando las condiciones del hardware.

1.1.3 Role de la prueba en el desarrollo software, mantenimiento y operaciones (K2)La prueba rigurosa de los sistemas y la documentacin puede reducir el riesgo de problemas en un entorno operacional y contribuye a la calidad del sistema software, siempre que los defectos sean detectados y corregidos antes de que el sistema este finalizado y listo para su uso operacional. La prueba del software puede tambin ser requerida para cumplir con requisitos contractuales, legales o estndares industriales especficos.

1.1.4 Prueba y CalidadCon la ayuda de la prueba, es posible medir la calidad del software en trminos de defectos encontrados, tanto para caractersticas o requisitos software funcionales o no Versin 2005 Spanish Software Testing Qualifications Board

12-88

Julio de2005



funcionales (p. ej. Fiabilidad, usabilidad, eficiencia y mantenimiento). Para ms informacin de prueba no funcional mirar el captulo 2; para ms informacin sobre caractersticas software mirar Ingeniera del software- Calidad del producto Software (ISO 9126). La prueba puede proporcionar confianza en la calidad del software si detecta pocos o ningn defecto. Un test diseado de forma apropiada que resulte satisfactorio reduce el nivel de riesgo global del sistema. Cuando la prueba encuentra defectos, la calidad del sistema software se incrementa cuando esos defectos son solventados. Las lecciones deberan ser aprendidas de proyectos anteriores. Es decir, entendiendo la raz de la causa de defectos encontrados en otros proyectos, los procesos pueden ser mejorados, lo que debe evitar que esos defectos vuelvan a producirse y as, mejorar la calidad de sistemas futuros. La prueba debe estar integrada como una de las actividades de la garanta de calidad (ej. junto al desarrollo de estndares, formacin y anlisis de defectos.)

1.1.5 Cunta prueba es suficiente? (K2)La decisin de cuanta prueba es suficiente debe tener en cuenta el nivel de riesgos, incluyendo el producto y proyecto tcnico y de negocio, y las restricciones del proyecto en cuanto a tiempo y presupuesto. (Los riesgos son tratados en mayor detalle en captulo 5). La prueba debe proporcionar suficiente informacin a los responsables de tomar decisiones argumentadas respecto a la versin de software o sistema bajo test, para las prximas etapas de desarrollo o entregas a consumidores.


13-88

Julio de2005



1.2 Qu es prueba? (K2) | 30 minutosTrminosCdigo, depuracin, desarrollo (de software), requisitos, revisin, bases del test, caso de prueba, prueba, objetivos del test.

Conocimientos previosUna percepcin comn de la prueba es que slo consiste en la ejecucin de tests, por ejemplo ejecutar el software. Esto es parte de la prueba, pero no todas las actividades de la prueba. Las actividades de test existen antes y despus de la ejecucin del test, actividades como la planificacin y control, eleccin de las condiciones del test, diseo de los casos de prueba y chequeo de resultados, criterios de evaluacin de las conclusiones, informes sobre los procesos de test y los sistemas bajo test y la finalizacin o cierre (p.ej. despus de completar la fase de test). La prueba tambin implica la revisin de documentos (incluyendo el cdigo fuente) y el anlisis esttico. Tanto la prueba dinmica como la esttica pueden ser utilizadas como estrategia para alcanzar objetivos similares, y proporcionarn informacin til para mejorar el sistema a testear y los procesos de desarrollo y test. Pueden existir diferentes objetivos del test: Encontrar defectos; Ganar confianza acerca del nivel de calidad y proporcionar informacin; Evitar defectos. La idea del proceso de diseo de test temprano en el ciclo de vida (verificando las bases del test a travs de su diseo) puede ayudar a prevenir la introduccin de defectos en el cdigo. La revisin de documentos (ej. requisitos) tambin pueden ayudar a prevenir la aparicin de defectos en el cdigo. Diferentes puntos de vista en la prueba tienen en cuenta diferentes objetivos. Por ejemplo, en el desarrollo del test (ej. componentes, integracin y sistema de test), el principal objetivo puede ser causar tantos fallos como sean posibles para que los defectos en el software sean identificados y solventados. En el test de aceptacin, el principal objetivo puede ser confirmar que el sistema trabaja de la forma esperada, para obtener confianza en que se ajusta a los requisitos. En algunos casos el principal objetivo del test puede ser valorar la calidad del software (sin la intencin de solventar defectos), para proporcionar informacin a los responsables de riesgos y determinar la publicacin del sistema en el momento adecuado. El test de mantenimiento a menudo testea que nuevos errores no han sido introducidos durante el desarrollo de cambios. Durante el test operacional, el principal objetivo puede ser valorar caractersticas del sistema como fiabilidad y disponibilidad. Versin 2005 Spanish Software Testing Qualifications Board

14-88

Julio de2005



Los procesos de depuracin y test son diferentes. La prueba puede mostrar fallos que son causados por defectos. El proceso de depurado es la actividad de desarrollo que identifica la causa de un defecto, permite reparar el cdigo y chequea que el defecto ha sido rectificado correctamente. La prueba de confirmacin subsecuente realizado por un probador asegura que la correccin efectivamente a resuelto el fallo. La responsabilidad es diferente para cada actividad, ej. Los probadores hacen test y los desarrolladores depuran. El proceso de prueba y sus actividades se explican en la seccin 1.4.


15-88

Julio de2005



1.3 Principios generales de la prueba (K2) | 35 minutosTrminosPrueba exhaustiva.

PrincipiosNumerosos principios de la prueba han sido sugeridos a lo largo de los ltimos 40 aos y ofrecen una gua general comn para toda la prueba. Principio 1- La prueba muestra la presencia de defectos La prueba puede mostrar que los defectos estn presentes, pero no pueden probar que no existen defectos. La prueba reduce la probabilidad de existencia de defectos no descubiertos pero, incluso cuando los defectos no son encontrados, eso no demuestra su ausencia. Principio 2-la prueba exhaustiva es imposible Probar todo (todas las combinaciones de entrada y precondiciones) no es factible excepto para casos triviales. En lugar de test exhaustivos, utilizamos riesgos y prioridades para enfocar los esfuerzos del test. Principio 3-Prueba temprana Las actividades de test deben comenzar tan pronto como sea posible en el ciclo de vida del desarrollo del software o sistema y deben ser enfocados sobre objetivos definidos. Principio 4 Agrupamiento de Defectos Un nmero pequeo de mdulos contienen la mayora de los defectos descubiertos durante la prueba, o muestran la mayora de los fallos operacionales. Principio 5- La paradoja del pesticida Si el mismo test se repite una y otra vez, eventualmente el mismo grupo de casos de test ya no encontrar nuevos errores. Para vencer esta paradoja del pesticida, los casos de prueba necesitan ser regularmente revisados y estudiados, y se necesitan escribir nuevos casos de prueba para ejercitar diferentes partes del software o sistema para encontrar mas defectos potenciales. Principio 6-La prueba depende del contexto La prueba se realiza de manera diferente en diferentes contextos. Por ejemplo, el software de seguridad crtico se prueba de forma diferente a la de un sitio de comercio electrnico. Principio 7- La falacia de la ausencia de errores Encontrar y solventar defectos no ayuda si el sistema construido est inutilizado y no satisface las necesidades y expectativas de los usuarios.


16-88

Julio de2005



1.4 Procesos fundamentales del test (K1) |35 minutosTrminosPrueba de confirmacin, criterio de salida, incidente, Prueba de regresin, bases del test, condiciones del test, cobertura del test, datos del test, ejecucin del test, registro del test, planificacin del test, estrategia del test, informe resumen de test, componentes del test.

Conocimientos previosLa parte ms visible del test es su ejecucin, pero para ser efectivo y eficiente, la planificacin debe incluir tambin el tiempo que se debe invertir en su planificacin, diseo de los casos de prueba, preparacin de su ejecucin y evaluacin del estado. El proceso fundamental del test consiste en las siguientes actividades principales: planificacin y control; anlisis y diseo; implementacin y ejecucin; evaluacin de criterios de salida e informes; cierre de las actividades de test. Aunque son lgicamente secuenciales, las actividades durante el proceso de test pueden solaparse o tener lugar de manera concurrente.

1.4.1 Planificacin del test y control (K1)La planificacin del test es la actividad que identifica la misin del test, definiendo los objetivos del test y la especificacin de las actividades de cara a cumplir los objetivos y completar la misin. El control del test es la actividad en curso que compara el progreso actual con la planificacin, informando de su estado y las desviaciones respecto a la planificacin. Esto implica iniciar las acciones necesarias para ajustarse a la misin y objetivos del proyecto. De cara al control del test, estas acciones deben ser monitorizadas a lo largo del proyecto. La planificacin del test tiene en cuenta la realimentacin de las actividades de monitorizacin y control. La planificacin del test posee las tareas fundamentales: Determinacin del alcance y riesgos, e identificacin de objetivos de la prueba. Determinacin de la propuesta del test (tcnicas, tems, cobertura, identificacin y definicin de la interfaz entre los equipos implicados en la prueba, componentes del test). Determinacin de los recursos requeridos (ej. personal, entorno del test, PCs). Implementacin de las polticas del test y/o la estrategia. Planificacin del anlisis del test y las tareas de diseo. Planificacin de la implementacin del test, ejecucin y evaluacin. Versin 2005 Spanish Software Testing Qualifications Board

17-88

Julio de2005



Determinacin del criterio de salida.

El control del test se basa en las siguientes tareas fundamentales: medida y anlisis de resultados; monitorizacin y documentacin del progreso, cobertura del test y criterios de salida; iniciacin de acciones de correccin. toma de decisiones.

1.4.2 Anlisis y diseo de test (K1)El anlisis y diseo de test es la actividad donde los objetivos generales de la prueba son transformados en condiciones de test tangibles y diseos de test. El anlisis y diseo del test contiene las siguientes tareas fundamentales: Revisin de las bases del test (requisitos, arquitecturas, diseo, interfaces). Identificacin de las condiciones de test o requisitos y datos requeridos del test basados en los tems del test, la especificacin, comportamiento y estructura. Diseo del test. Evaluacin de testeabilidad? de los requisitos y sistema. Diseo del entorno de test e identificacin de cualquier infraestructura o herramienta requerida.

1.4.3 Implementacin y ejecucin del test (K1)La implementacin y ejecucin del test es la actividad donde las condiciones son transformadas en casos de prueba y componentes, y se configura el entorno de pruebas. La implementacin y ejecucin contiene las siguientes tareas fundamentales: Desarrollo y priorizacin de los casos de prueba, creacin de los datos, escribir procedimientos del test y opcionalmente preparar el aprovechamiento de los test y generacin de scripts. Creacin de grupos a partir de los casos de prueba para una ejecucin eficiente. Ejecucin de los casos de prueba de forma manual o utilizando herramientas para su ejecucin, de acuerdo con la secuencia planificada. Registro de los resultados de la ejecucin del test y grabacin de identidades y versiones del software bajo test, herramientas de test y componentes del test. Comparar resultados actuales con los resultados esperados. Documentar discrepancias e incidencias y analizarlas para establecer su causa (p.ej. un defecto en el cdigo, en el especificacin de los datos del test, en la documentacin, o un error en el proceso seguido en la ejecucin del test). Repetir las actividades del test en funcin de las decisiones tomadas para cada discrepancia. Por ejemplo, repetir la ejecucin de un test que ha fallado Versin 2005 Spanish Software Testing Qualifications Board

18-88

Julio de2005



previamente con el objetivo de confirmar su correccin (test de confirmacin), ejecucin de un test corregido y/o ejecucin de pruebas para asegurar que no se han introducido defectos en las reas modificadas del software o que los defectos corregidos no propician otros defectos (test de regresin).

1.4.4 Evaluacin de los criterios de salida e informes (K1)Evaluar los criterios de salida es la actividad donde la ejecucin del test se contrasta con los objetivos definidos. La evaluacin de los criterios de salida posee las siguientes tareas: Chequeo de los registros del test contrastndolos con los criterios de salida especificados en la planificacin del test. Valorar si son necesarios ms test o si los criterios de salida deben ser modificados. Generar un informe resumido del test para los responsables.

1.4.5 Actividades del cierre de test (K1)Las actividades de cierre del test recogen todos los datos de las actividades de test completadas para consolidar experiencia, testware, hechos y nmeros. Por ejemplo, cuando un sistema software se publica, se ha completado (o cancelado) un proyecto de test, se ha alcanzado un hito o se ha completado una etapa de mantenimiento. Las actividades de cierre de test incluyen las siguientes tareas: Chequear que entregables planificados han sido entregados, el cierre de los informes de incidencias o aumento de los registros de cambio para cualquier informe que contine abierto y documentacin de la aceptacin del sistema. Finalizacin y archivo del testware, el entorno de test y su infraestructura para su futura reutilizacin. Entrega del testware a la organizacin de mantenimiento. Anlisis de las lecciones aprendidas para futuras revisiones y proyectos, y la mejora de la experiencia en test.


19-88

Julio de2005



1.5 La psicologa de la prueba (K2) | 35 minutosTrminosPrueba independiente.

Conocimientos previosLa mentalidad a utilizar durante la prueba y la revisin es diferente a la utilizada durante el anlisis o desarrollo. Con la mentalidad correcta los desarrolladores son capaces de probar su propio cdigo, pero la separacin de esta responsabilidad para un probador es tpicamente utilizada para ayudar a dirigir el esfuerzo y proporcionar beneficios adicionales, como la visin independiente a travs de unos medios de prueba formados y profesionales. La prueba independiente debe ser practicada a cualquier nivel de test. Un cierto grado de independencia (evitando el prejuicio del autor) es a menudo efectivo en la bsqueda de defectos y fallos. Sin embargo, la independencia no es una sustitucin de la familiaridad, por lo que los desarrolladores pueden encontrar de forma eficiente muchos defectos en su propio cdigo. Se pueden definir diferentes niveles de independencia: Tests diseados por la persona(s) que escribi el software bajo test (bajo nivel de independencia). Tests diseados por otra persona(s) (p. ej. del grupo de desarrollo). Tests diseados por una(as) persona(s) de otro grupo diferente (ej. un equipo de test independiente). Tests diseados por una persona(s) de una organizacin o compaa independiente (ej. outsourcing o certificacin por una entidad externa). Los proyectos y la gente se mueven por objetivos. La gente tiende a ajustar sus planes a los objetivos marcados por la direccin y otros responsables, por ejemplo, encontrar defectos o confirmar que el software funciona. Por tanto, es importante clarificar el estado de los objetivos de la prueba. Identificar fallos durante la prueba puede ser interpretada como una crtica contra el producto o su autor. De esta manera, la prueba se percibe a menudo como una actividad destructiva, aunque es muy constructivo en el manejo de riesgos del producto. La bsqueda de fallos en un sistema requiere curiosidad, pesimismo profesional, una visin crtica, atencin a los detalles, buena comunicacin con los desarrolladores y experiencia como base para intuir/adivinar errores. Si los errores, defectos o fallos se comunican de una manera constructiva, se pueden evitar fricciones entre los probadores y los analistas, diseadores y desarrolladores. Esto se aplica tanto en la revisin como en la prueba. El tester y su lder necesitan buenas tcnicas interpersonales para comunicar informacin de facto acerca de defectos, progreso y riesgos, de una forma constructiva. Para el autor del software o documentacin, la informacin de defectos puede ayudarle a Versin 2005 Spanish Software Testing Qualifications Board

20-88

Julio de2005



mejorar sus habilidades. Los defectos encontrados y solventados durante la prueba supondrn un ahorro en tiempo y dinero y una reduccin en los riesgos. Los problemas de comunicacin pueden ocurrir, particularmente si los probadores son vistos solamente como mensajeros de malas noticias sobre defectos. Sin embargo, existen diversos caminos para mejorar la comunicacin y relacin entre probadores y otros: Comenzar con colaboracin en lugar de batallas mentalizar a todos con la meta comn de sistemas de calidad. Comunicar fallos del producto de una manera neutral, orientada al hecho sin criticar la persona que realiz el producto, por ejemplo, escribir objetivo e informe de incidente hallado y revisin de fallos. Intentar entender cmo piensa la otra persona y por qu reacciona de tal manera. Confirmar que la otra persona ha comprendido aquello que t has querido decir y viceversa.

Referencias1.1.5 Black, 2001, Kaner, 2002 1.2 Beizer, 1990, Black, 2001, Myers, 1979 1.3 Beizer, 1990, Hetzel, 1998, Myers, 1979 1.4 Hetzel, 1998 1.4.5 Black, 2001, Craig, 2002 1.5 Black, 2001, Hetzel, 1998


21-88

Julio de2005



2. Pruebas a travs del ciclo de vida del software (K2) | 135 minutosObjetivos de aprendizaje para las pruebas a travs del ciclo de vida del software.Los objetivos identifican lo que ser capaz de hacer al finalizar cada mdulo.

2.1 Modelos de desarrollo software (K2) Entender la relacin existente entre el desarrollo, las actividades de test, y el trabajo en el ciclo de vida de desarrollo de productos, y dar ejemplos basados en proyectos, caractersticas del producto y el contexto.(K2) Reconocer el hecho de que los modelos de desarrollo software deben ser adaptados al contexto del proyecto y las caractersticas del producto.(K1) Recodar los diferentes niveles de prueba, y las caractersticas de un test correcto en cualquier modelo del ciclo de vida.(K1)

2.2 Niveles de test (K2) Comparar los diferentes niveles de test o prueba en cuanto a: objetivos importantes, objetos tpicos de la prueba, tpicos targets de la prueba (Ej. funcional o estructural) y de productos relacionados con el trabajo, la gente que prueba, los tipos de defectos y fallos que deben ser identificados.(K2)

2.3 Tipos de test: targets del test (K2) Comparar cuatro tipos de test de software (funcional, no funcional, estructural y change-related) mediante ejemplos.(K2) Reconocer que pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de test. (K1) Identificar y describir los tipos no funcionales de test basados en requisitos no funcionales. (K2). Identificar y describir los tipos de test basados en el anlisis estructural o de arquitectura del sistema software. (K2). Describir el propsito de la prueba de confirmacin (confirmation testing) y de la prueba de regresin (regresin testing). (K2).

2.4 Prueba de mantenimiento Compara la prueba de mantenimiento (que testea un sistema existente) al utilizado para testear una nueva aplicacin con respecto a los tipos de test, a los disparadores de los test (triggers) y a la cantidad de pruebas. (K2). Identificar las razones por las que se utilizan las pruebas de mantenimiento (modificacin, migracin y retiro). (K1). Describir el papel (rol) de la prueba de regresin y el anlisis de impacto en mantenimiento. (K2).


22-88

Julio de2005



2.1 Modelos de desarrollo software (K2) | 20 minutosTrminosSoftware con fines comerciales (COTS), modelo incremental de desarrollo, nivel de prueba, validacin, verificacin, V-model.

Conocimientos previosEl test no existe aislado, las actividades de prueba se relacionan con las actividades del desarrollo del software. Para distintos modelos del ciclo vital del desarrollo se necesitan diversos enfoques de prueba.

2.1.1 V-model (K2)Aunque existen distintas variantes del V-model, un tipo comn de V-model utiliza cuatro niveles de prueba, correspondientes a los cuatro niveles del desarrollo. Los cuatro niveles usados en el plan de estudios (syllabus) son: Prueba de componente (component testing). Prueba de integracin (integration testing). Prueba de sistema (system testing). Prueba de aceptacin (acceptance testing). En la prctica, un V-model puede tener ms, menos o distintos niveles de desarrollo y de prueba, dependiendo del proyecto y del producto software. Por ejemplo, puede haber pruebas de integracin de componente despus de las pruebas de componente, y prueba de integracin de sistema despus de una prueba de sistema. Los trabajos en productos software (tales como escenarios de negocio o casos de uso, especificaciones de requisito, documentos del diseo y cdigo) llevados a cabo durante el desarrollo son a menudo la base de las prueba, en unos o ms niveles de test. Las referencias para los productos genricos de trabajo incluyen Capability Maturity Model Integration (CMMI) o procesos del ciclo de vida del sotware (Software lifecycle processes, IEEE/IEC 12207).La verificacin y la validacin (y el diseo temprano de pruebas) se pueden realizar durante el desarrollo de los productos software.

2.1.2 Modelo de desarrollo iterativo (K2)El desarrollo iterativo es el proceso de establecer requisitos, de disear, de construir y de probar un sistema, realizado como una serie de progresos ms pequeos. Los ejemplos son: desarrollo orientado a prototipos, desarrollo de aplicaciones rpido (RAD), proceso unificado racional (RUP) y modelos de desarrollo gil. El incremento producido por una iteracin puede ser probado en varios niveles como parte de su desarrollo. Un incremento, aadido a otros desarrollados previamente, forma un sistema parcial cada vez mayor, que debe tambin ser probado. La prueba de regresin es cada vez ms importante en todas las


23-88

Julio de2005



iteraciones tras la primera. La verificacin y la validacin se pueden realizar en cada incremento.

2.1.3 Pruebas dentro del modelo de ciclo de vida (K2)En cualquier modelo de ciclo de vida se distinguen las siguientes caractersticas para un buen test: Para cada actividad del desarrollo tiene que existir una actividad de prueba. Cada nivel de test tiene objetivos especficos del nivel. El anlisis y diseo de los tests para un nivel dado de la prueba debe comenzar durante la actividad correspondiente del desarrollo. Los testadores deben estar implicados en la revisin de los documentos tan pronto como los borradores estn disponibles en el ciclo de vida del desarrollo. Los niveles de test se pueden combinar o reorganizar dependiendo de la naturaleza del proyecto o la arquitectura del sistema. Por ejemplo, para la integracin de un producto de software con fines comerciales (COTS) en un sistema, el comprador puede realizar la prueba de integracin a nivel de sistema (Ej. integracin a la infraestructura y a otros sistemas, o al despliegue del sistema) y prueba de aceptacin (funcional y/o no funcional, y el usuario y/o la prueba operacional).


24-88

Julio de2005



2.2 Niveles de test (K2) | 60 minutosTrminosPrueba alfa (alfa testing), prueba beta (beta testing), prueba de componente (component testing, tambin conocido como unidad, mdulo o programa a probar), prueba de aceptacin del contrato, drivers, prueba de campo (field testing), requisitos funcionales, integracin, prueba de integracin (integration testing), requisitos no funcionales, prueba operacional o de aceptacin (operational testing), prueba de aceptacin de norma, prueba de robustez, stubs, prueba de sistema, test-driven development, entorno de prueba, prueba de aceptacin de usuarios.

Conocimientos previosPara cada uno de los niveles de prueba se pueden identificar los siguientes aspectos: objetivos genricos, productos de trabajo que hacen referencia para derivar los casos de la prueba (base del test), el objeto de la prueba (qu se est probando), los defectos y las fallos de ser encontrado, los requisitos que sustentan el test y la ayuda de la herramienta, y enfoques especficos y las responsabilidades.

2.2.1 Prueba de componente (component testing) (K2)La prueba de componente realiza la bsqueda de defectos y verificacin del funcionamiento del software que puede ser testeado por separado (Ej. mdulos, programas, objetos, clases, los etc.). Puede ser llevado a cabo sin tener en cuenta el resto del sistema, dependiendo del contexto del ciclo de vida del desarrollo y del sistema. Pueden utilizarse stubs, drivers y simuladores. La prueba de componente puede incluir pruebas de funcionalidad, de caractersticas especficas no funcionales, tales como recurso-comportamiento (Ej. escapes de la memoria) o prueba de robustez, as como prueba estructural (Ej. cobertura de rama, branch coverage). Los casos de prueba se derivan de elaboraciones del producto tales como una especificacin del componente, el diseo software o el modelado de datos Normalmente, la prueba de componente ocurre con arreglo al cdigo que es probado y con la ayuda del entorno del desarrollo, tal como un marco de prueba de unidad o una herramienta de puesta a punto, y generalmente implica en la prctica al programador que escribi el cdigo. Los defectos son usualmente fijos y son encontrados con facilidad, sin informe formal de incidencia. Un enfoque de la prueba de componente es preparar y automatizar casos de prueba antes de introducir cdigo. Esto se llama un primer enfoque de prueba (test-first approach) o un desarrollo de prueba dirigido (test-driven development). Este enfoque es altamente iterativo y se basa en los ciclos de desarrollo de los casos de la prueba, y una vez se van construyendo e integrando nuevas porciones de cdigo, se ejecutan las pruebas del componente hasta que pasan.


25-88

Julio de2005



2.2.2 Prueba de integracin (integration testing) (K2)La prueba de integracin se encarga de probar la interconexin entre los componentes, interacciones a diversas partes de un sistema, tales como sistema operativo, sistema de ficheros, hardware o interfaces entre sistemas. Puede haber ms de un nivel de prueba de integracin y se puede realizar con objetos de prueba de diferentes tamaos. Por ejemplo: Una prueba de integracin de componentes testea las interacciones entre los componentes software, y se hace despus de llevar a cabo las pruebas de componentes. Una prueba de integracin de sistemas testea las interacciones entre diversos sistemas y deben ser hechas despus de probar del sistema. En este caso, la organizacin del desarrollo debe controlar solamente un lado del interfaz, pues los cambios pueden producir desestabilizacin. Los procesos de negocio implementados como flujos de trabajo (workflows) pueden implicar a un conjunto de sistemas. Las ediciones multiplataforma pueden ser significativas.

Cuanto mayor es el alcance de la integracin, mas complejo se vuelve aislar los fallos de un componente especfico o del sistema, lo que puede conducir a un riesgo creciente. Las estrategias sistemticas de integracin se pueden basar en la arquitectura del sistema (tanto top-down como bottom-up), en las tareas funcionales, en las secuencias del tratamiento transaccional, o en otros aspecto del sistema o del componente. Para reducir el riesgo de descubrir defectos con tarda, la integracin debe normalmente ser incremental ms que un "big ban". Las pruebas de caractersticas no funcionales especficas (Ej. funcionamiento) pueden ser incluida en las pruebas de integracin. En cada etapa de la integracin, los testadores se concentran solamente en la integracin s misma. Por ejemplo, si estn integrando el mdulo A con el mdulo B se interesan en la prueba de comunicacin entre mdulos, no por la funcionalidad de cualquiera de ellos. Pueden utilizarse tanto enfoques funcionales como estructurales. Idealmente, los testadores deberan entender la arquitectura y la influencia de la planificacin de la integracin. Si las pruebas de integracin se planifican antes de que se construyan los componentes o los sistemas, stos podran ser construidos en orden conseguir pruebas ms eficientes.

2.2.3 Prueba de sistema (system testing) (K2)La prueba de sistema se refiere al comportamiento de un sistema-producto completo segn lo definido en el alcance del proyecto o programa.


26-88

Julio de2005



En la prueba de sistema, el entorno de prueba debe corresponder al entorno final o entorno de produccin tanto como sea posible para reducir al mnimo el riesgo de fallos especficos del entorno que no sean encontrados en las pruebas. La prueba de sistema puede incluir pruebas basadas en riesgos y/o en especificaciones de requisitos, procesos de negocio, casos de uso, u otras descripciones del comportamiento del sistema, interacciones de alto nivel con el sistema operativo, y recursos de sistema. En la prueba de sistema se deben probar los requisitos funcionales y no funcionales del sistema. Los requisitos pueden estar especificados mediante texto y/o con modelos. Los testadores tambin necesitan ocuparse de requisitos incompletos o no documentados. La prueba de requisitos funcionales del sistema har uso de las tcnicas ms apropiadas (caja negra) en funcin de los aspectos que se desean probar del sistema. Por ejemplo, se puede crear una tabla de decisin con las combinaciones de los efectos descritos en reglas de negocio. Las tcnicas basadas en estructura (caja blanca) se pueden utilizar para probar con minuciosidad un elemento estructural, como por ejemplo una estructura de men o navegacin de una pgina Web. (Vase el Captulo 4.) La prueba de sistema es realizado a menudo por un equipo independiente de test.

2.2.4 Prueba de aceptacin (acceptance testing) (K2)La prueba de aceptacin es responsabilidad de los usuarios finales (clientes), aunque otros stakeholders pueden estar involucrados. La meta de la prueba de aceptacin es establecer confianza en el sistema, en partes del mismo o en las caractersticas no funcionales especficas del sistema. Encontrar defectos no es el objetivo principal de la prueba de aceptacin. La prueba de aceptacin puede determinar la preparacin del sistema para su despliegue y uso, aunque no es necesariamente el ltimo nivel de pruebas. Por ejemplo, una prueba de integracin de un sistema a gran escala puede llevarse a cabo despus de una prueba de aceptacin. La prueba de aceptacin puede llevarse a cabo en ms de un simple nivel de test, por ejemplo: Un producto software con fines comerciales debe pasar una prueba de aceptacin cuando es instalado o integrado. Durante la prueba de componente se puede realizar una prueba de aceptacin de la usabilidad del mismo. Puede realizarse una prueba de aceptacin de una nueva funcionalidad incorporada antes de probar el sistema (prueba de sistema). La forma tpica de prueba de aceptacin incluye lo siguiente: Prueba de aceptacin de usuario (User acceptance testing) Verifica tpicamente la aptitud para el uso del sistema de los usuarios de negocio.


27-88

Julio de2005



Prueba de aceptacin del funcionamiento (Operacional acceptance testing) La aceptacin del sistema por parte de los administradores del mismo incluye: Prueba de copia de seguridad y restauracin del sistema Recuperacin ante desastre Gestin de usuarios Tareas de mantenimiento Chequeos peridicos de las vulnerabilidades de seguridad. Prueba de aceptacin del contrato y normativa (Contract and regulation acceptance testing) La prueba de aceptacin del contrato se realiza segn los criterios de aceptacin de un contrato para producir software de cliente. Los criterios de aceptacin deben ser definidos cuando se acuerda el contrato. La prueba de aceptacin de la normativa se realiza segn cualquier regulacin a las cuales deba ser adherido, por ejemplo regulaciones gubernamentales, legales o de seguridad. Pruebas alfa y beta En los productos software con fines comerciales, o COTS, se requiere a menudo la obtencin de las observaciones de los clientes potenciales o existentes en su mercado antes de que el producto software salga a la venta comercialmente. Una prueba alfa se realiza en la propia organizacin desarrolladora. Una prueba beta es realizada por la gente en sus propias localizaciones. Ambas son realizadas por clientes potenciales, no por los desarrolladores del producto. Las organizaciones pueden utilizar otros trminos, como por ejemplo, prueba de la aceptacin de fbrica (factory acceptance testing) y prueba de aceptacin en su emplazamiento (site acceptance testing), para sistemas que son testados antes y despus de llevarse al emplazamiento del cliente.


28-88

Julio de2005



2.3 Tipos de test: targets de las pruebas (K2) | 60 minutosTrminosAutomatizacin, prueba de caja negra, cobertura del cdigo, prueba de confirmacin, prueba funcional, prueba de interoperabilidad, prueba de carga, prueba de capacidad de mantenimiento, prueba de funcionamiento, prueba de portabilidad, prueba de regresin, prueba de confiabilidad, prueba de seguridad, prueba basada en especificacin, prueba de tensin (stress testing), prueba estructural, test suite, prueba de usabilidad, prueba de caja blanca.

Conocimientos previosUn grupo de actividades de test se puede dirigir a verificar el sistema de software (o una parte de un sistema) basada en una razn o target especfico a probar. Un tipo de test se centra en un objetivo particular a probar, pudindose tratar, por ejemplo, de una prueba de funcionalidad del software, de una caracterstica de calidad, como confiabilidad o usabilidad, de la estructura o alguna arquitectura no funcional del software o sistema, o relacionado con los cambios, es decir confirmando que los defectos han estado fijados (prueba de confirmacin) y buscando los cambios involuntarios (prueba de regresin). Un modelo de software se puede desarrollar y/o utilizar en una prueba estructural y funcional. Por ejemplo, en una prueba funcional se puede utilizar un modelo de flujo de procesos, un modelo de transicin de estados o una especificacin en lenguaje llano, y en una prueba estructural se puede utilizar un modelo de flujo de control o un modelo de estructura de men.

2.3.1 Prueba de funcionamiento o funcional (test of function o functional testing) (K2)Las funciones que un sistema, subsistema o componente deben realizar se pueden describir en documentos de trabajo tales como una especificacin de requisitos, casos de uso, o una especificacin funcional, o bien no estar documentadas. Las funciones definen "qu" hace el sistema. Las pruebas funcionales se basan en estas funciones y caractersticas (descritas en documentos o entendidas por los testadores), y se pueden realizar en todos los niveles de prueba (Ej. las pruebas de componentes estn basados en las especificaciones de los componentes). Las tcnicas basadas en especificacin se pueden utilizar para derivar condiciones de prueba y para probar casos de la funcionalidad del software o del sistema. (Vase El Captulo 4.) La prueba funcional considera el comportamiento externo del software (prueba de caja negra).


29-88

Julio de2005



Un tipo de prueba funcional, es un test de seguridad, en el que se investiga las funciones (Ej. un cortafuego) referentes a la deteccin de amenazas, tales como virus, o intrusos malvolos.

2.3.2 Prueba de caractersticas del producto software o prueba no funcional (test of software producto characteristics or non-functional testing) (K2)La prueba no funcional incluye, pero no se limita a, prueba de funcionamiento, prueba de carga, prueba de tensin (stress testing), prueba de usabilidad, prueba de interoperabilidad, prueba de mantenimiento, prueba de confiabilidad y prueba de portabilidad. La prueba no funcional testea cmo trabaja el sistema. La prueba no funcional se puede realizar en todos los niveles de test o prueba. El concepto de prueba no funcional describe las pruebas requeridas para medir caractersticas de los sistemas y del software que se pueden cuantificar en una escala variable, viendo como responde en tiempo a las pruebas de funcionamiento. Estas pruebas se pueden referir a un modelo de calidad, como por ejemplo el definido en la normativa ISO 9126 de Ingeniera del Software - Calidad del Producto Software (Software Engineering Software Product Quality).

2.3.3 Prueba de la estructura-arquitectura de software o prueba estructural (Testing of software structure-architecture or structural testing) (K2)La prueba estructural (caja blanca) se puede realizar en todos los niveles de test o prueba. Las tcnicas estructurales se utilizan mejor despus de tcnicas basadas en especificacin, con el propsito de ayudar a medir con detalle la prueba por medio del clculo de la cobertura de un tipo de estructura. La cobertura es el grado que una estructura ha sido ejercitada por test suite, expresada como porcentaje de los elementos que se han cubierto. Si la cobertura no es del 100%, entonces se pueden disear ms tests para probar los elementos que fallaron y, por lo tanto, aumentar la cobertura. Las tcnicas de cobertura se detallan en el captulo 4. En todos los niveles de test, pero especialmente en las pruebas de componente y en la prueba de integracin de componentes, se pueden utilizar estas herramientas para medir la cobertura del cdigo de los elementos, tales como declaraciones o decisiones. La prueba estructural se puede basar en la arquitectura del sistema, tambin denominada jerarqua. Los enfoques de las pruebas estructurales se pueden aplicar tambin al sistema, a la integracin de sistema o a los niveles de prueba de aceptacin (Ej. en los modelos de negocio o las estructuras de men).

2.3.4 Pruebas relacionadas con cambios, o prueba de confirmacin o de regresin (testing related to changes, confirmation and regresin testing) (K2)Versin 2005 Spanish Software Testing Qualifications Board

30-88

Julio de2005



Cuando un defecto se detecta y se resuelve (fixed) entonces el software debe ser reexaminado para confirmar que el defecto original se ha eliminado con xito. A este tipo de prueba se le denomina prueba de confirmacin. La eliminacin de los errores, resolucin del defecto (defect fixing), es una actividad del desarrollo, no una actividad de prueba. La prueba de regresin (regression test) es la prueba repetida de un programa ya probado, despus de alguna modificacin, para descubrir cualquier defecto introducido como resultado de los cambios. Estos defectos pueden estar en el software que es probado, o en otro componente software relacionado o sin relacin. Se realiza cuando se cambia el software, o su entorno. El grado de la prueba de regresin se basa en el riesgo de no encontrar defectos en el software con el que trabajaba previamente. Los tests deben ser repetibles si van a utilizarse como parte de las pruebas de confirmacin o regresin. La prueba de regresin se puede realizar en todos los niveles de prueba, y se aplica en pruebas funcionales, no funcionales y estructurales. Los test suites de regresin se ejecutan muchas veces y se desarrollan por lo general lentamente, as pues se establece como un fuerte candidato para automatizacin.


31-88

Julio de2005



2.4 Prueba de Mantenimiento (K2) | 15 minutosTrminosAnlisis de impacto, prueba de mantenimiento, migracin, modificaciones y retirada.

Conocimientos previosUna vez que est desplegado un sistema de software est a menudo en servicio por aos o dcadas. Durante este tiempo el sistema y su entorno normalmente son corregidos, cambiados o ampliados. La prueba de mantenimiento se realiza sobre un sistema operacional existente, y es accionado al llevarse a cabo modificaciones, migracin, o retirada del software o del sistema. Las modificaciones incluyen ampliaciones planificadas (Ej. released-based), cambios correctivos y de emergencia, y cambios de entorno, tales como mejoras previstas del sistema operativo o de la base de datos, o parches para las vulnerabilidades aparecidas o descubiertas del sistema operativo. La prueba de mantenimiento para la migracin (Ej. cambio de plataforma) debe incluir pruebas operacionales del nuevo entrono, as como del software que ha cambiado. La prueba de mantenimiento para la retirada de un sistema puede incluir la prueba de migracin de datos o el almacenamiento de la informacin requeridos tras largos perodos de retencin de datos. Adems de probar lo que se ha cambiado, la prueba de mantenimiento incluye la prueba de regresin extensiva (extensive regresion testing), que testea las partes del sistema que no se han cambiado. El alcance de la prueba de mantenimiento se relaciona con el riesgo de cambio, el tamao del sistema existente y con el tamao del cambio. Dependiendo de los cambios, la prueba de mantenimiento se puede hacer para niveles cualesquiera o para todos los niveles de prueba, y para cualesquiera o todos los tipos de la prueba. La forma de determinar cmo el sistema existente puede verse afectado por los cambios se llama anlisis del impacto, y se utiliza para ayudar a decidir la cantidad de pruebas de regresin que es necesario llevar a cabo. La prueba de mantenimiento puede ser difcil si faltan especificaciones o estn anticuadas.

Referencias2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207 2.2 Hetzel, 1998 2.2.4 Copeland, 2004, Myers, 1979 2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004 2.3.2 Black, 2001, ISO 9126 Versin 2005 Spanish Software Testing Qualifications Board

32-88

Julio de2005



2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998 2.3.4 Hetzel, 1998, IEEE 829 2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829


33-88

Julio de2005



3. Tcnicas estticas (K2) | 60 minutosObjetivos de aprendizaje para tcnicas estticasLos objetivos identifican lo que ser capaz de hacer al finalizar cada mdulo.

3.1 Revisiones y el proceso de test (K2) Reconocer los productos software que puedan ser examinados mediante las diferentes tcnicas estticas.(K1) Describir la importancia y el valor de considerar tcnicas estticas para el asesoramiento de productos software.(K2) Explicar la diferencia entre tcnicas estticas y dinmicas.(K2)

3.2 Proceso de revisin (K2) Repasar las fases, roles y responsabilidades de una revisin formal tpica.(K1) Explicar las diferencias entre los diferentes tipos de revisin: revisin informal, revisin tcnica, walkthrough e inspeccin.(K2) Explicar los factores para un funcionamiento de revisiones satisfactorio.(K2)

3.3 Anlisis esttico por herramientas (K2) Describir los objetivos del anlisis esttico y compararlos con las pruebas dinmicas.(K2) Repasar los defectos tpicos y los errores identificados por el anlisis esttico y compararlos con las revisiones y las pruebas dinmicas.(K1) Enumerar los beneficios tpicos del anlisis esttico.(K1) Enumerar los defectos tpicos del cdigo y diseo que se hayan podido identificar mediante herramientas de anlisis esttico.(K1)


34-88

Julio de2005



3.1 Revisiones y procesos de prueba (K2) | 15 minutos TrminosPruebas dinmicas, revisiones, anlisis esttico.

Conocimientos previosLas tcnicas de prueba estticas no ejecutan el software que est siendo probado; son manuales (revisiones) o automticas (anlisis esttico). Las revisiones son una forma de probar productos software (incluyendo cdigo) y pueden ser ejecutadas antes de la ejecucin de la prueba dinmica. Los defectos detectados durante las revisiones al inicio del ciclo de vida son a menudo, mucho ms fciles de eliminar que aquellos detectados durante las pruebas en ejecucin (Ej. defectos encontrados en requisitos). Una revisin podra hacerse completamente como una actividad manual, aunque tambin hay herramientas de soporte. La principal actividad manual es la de examinar un producto y hacer comentarios sobre el. Cualquier producto software puede ser revisado, incluyendo la especificacin de requisitos, especificacin de diseo, cdigo, plan de pruebas, especificacin de pruebas, casos de uso, scripts de prueba, manual de usuario o pginas Web. Los beneficios de las revisiones incluyen la pronta deteccin de defectos y su correccin, mejoras en la productividad del desarrollo, escalas de tiempo de desarrollo reducidas, coste de pruebas y de tiempo reducidos, reducciones en el coste del ciclo de vida, menos defectos y una comunicacin mejorada. Las revisiones pueden encontrar omisiones, por ejemplo, en los requerimientos, que son improbables de encontrar en las pruebas dinmicas. Revisiones, anlisis estticos y pruebas dinmicas tienen el mismo objetivo identificacin de defectos. Son complementarios: las diferentes tcnicas pueden encontrar diferentes tipos de defectos efectivamente y eficientemente. En contraste a las pruebas dinmicas, las revisiones encuentras defectos ms que fallos. Los defectos tpicos que son ms fciles de encontrar en las revisiones que en las pruebas dinmicas son: desviaciones de estndares, defectos de requisitos, defectos de diseo, mantenibilidad insuficiente y la especificacin de la interfaz incorrecta.


35-88

Julio de2005



3.2 Proceso de revisin (K2) | 25 minutos TrminosCriterios de entrada, criterios de salida, revisin formal, revisin informal, inspeccin, kick-off, mtricas, moderador/lder de inspeccin, revisin par, revisor, reunin de revisin, proceso de revisin, scribe, revisin tcnica, walkthrough. Conocimientos previos Las revisiones varan de informales a muy informales (bien estructuradas y reguladas). La formalidad de un proceso de revisin est relacionada con factores como la madurez del proceso de desarrollo, cualquier requisito regulador o legal o la necesidad de un rastro para la auditoria. La manera en la que una revisin se lleva a cabo depende del objetivo acordado de la revisin (Ej. Encontrar defectos, ganar entendimiento, o discusin y decisin por consenso).

3.2.1 Fases de una revisin formal (K1)Una revisin formal tpica tiene las siguientes fases principales: Planificacin: seleccin del personal, asignacin de roles; definicin de criterios de entrada y salida para otros tipos de revisin formal (Ej. inspeccin); y seleccionar las partes del documento a las que mirar. Kick-off: distribucin de documentos; explicacin de los objetivos, procesos y documentos a los participantes; y comprobando los criterios de entrada (para ms tipos de revisin formal). Preparacin individual: trabajo realizado por su cuenta de cada participante antes de la reunin de revisin, haciendo notar defectos en potencia, preguntas y comentarios. Reunin de revisin: discusin, con resultados documentados o minutos (para ms tipos de revisin formal). Los participantes reunidos pueden simplemente anotar defectos, hacer recomendaciones para manejar los defectos, o hacer decisiones sobre los defectos. Rework: arreglar los defectos encontrados, normalmente hecho por el autor. Follow-up: comprobacin de los defectos que se hayan definido, recogida de mtricas y chequeo de los criterios de salida (para ms tipos de revisin formal).

3.2.2 Roles y responsabilidades (K1)Una tpica revisin formal incluira los roles siguientes: Manager: decide sobre la ejecucin de las revisiones, gestiona el tiempo en la programacin del proyecto y determina si los objetivos de la revisin se han cumplido.


36-88

Julio de2005



Moderador: la persona que lidera la revisin del documento o del conjunto de documentos, incluyendo la planificacin de la revisin, preparar la reunin, y quedarse al tanto despus de la reunin. Si fuera necesario, el moderador puede mediar entre varios puntos de vista y ser a menudo la persona sobre la que dependa el xito de la reunin. Autor: el escritor o persona encargada responsable de la revisin de los documentos. Revisores: individuos con conocimientos tcnicos o de negocio (tambin denominados comprobadores o inspectores) que, despus de una preparacin necesaria, identifican y describen los descubrimientos (Ej. defectos) en el producto que esta bajo revisin. Los revisores deben ser seleccionados para representar las diferentes perspectivas y roles el proceso de revisin y toman parte el las reuniones de revisin. Scribe (o grabador): documenta todas las cuestiones, problemas y cuestiones sin resolver identificadas en la reunin.

Mirando a los documentos desde diferentes perspectivas, y usando checklists, se pueden hacer las revisiones ms efectivas y eficientes, por ejemplo, un checklist basado en perspectivas como usuario, mantenedor, probador o operaciones, o un checklist tpico de problemas de requisitos.

3.2.3 Tipos de revisin (K2)Un simple documento puede ser el objetivo de ms de una revisin. Si se usa ms de un tipo de revisin, el orden puede variar. Por ejemplo, una revisin informal se puede llevar a cabo antes de una revisin tcnica, o una inspeccin se puede llevar a cabo debido a la especificacin de un requisito antes de un walkthrough con clientes. Las principales caractersticas, opciones e intenciones de los tipos de revisin comunes son: Revisin informal Caractersticas clave: No hay proceso formal. Puede haber programacin en pareja o un lder tcnico revisando el diseo y el cdigo. Opcionalmente puede ser documentado. Puede variar su utilidad dependiendo del revisor. Propsito principal: manera econmica de obtener algn resultado. Walkthrough: Caractersticas clave: Reunin liderada por el autor; Escenarios, dry runs, grupos peer; Sesiones open-ended; Opcionalmente una preparacin de la reunin previa de los revisores, documento de revisin, lista de descubrimientos y scribe (que no es el autor). Puede variar en la prctica de algo formal a muy formal. Versin 2005 Spanish Software Testing Qualifications Board

37-88

Julio de2005



Propsitos principales: aprender, ganar entendimiento, averiguacin de defectos.

Revisin tcnica Caractersticas clave: documentado, proceso de deteccin de defectos definido que incluya peers y expertos tcnicos. Puede ser realizado como una revisin peer sin la participacin de un jefe; Idealmente liderado por un moderador preparado(no el autor); Preparacin antes de la reunin; Opcionalmente el uso de checklists, documento de revisin, listado de averiguaciones y participacin de jefes. Puede variar en la practica de algo formal a muy formal; Propsitos principales: discusiones, toma de decisiones, evaluacin de alternativas, averiguacin de defectos, resolucin de problemas tcnicos y comprobacin de validez con las especificaciones y los estndares. Inspeccin Caractersticas clave: liderado por un moderador preparado(no el autor); generalmente examinaciones peer; roles definidos; mtricas incluidas; proceso formal basado en reglas y checklists con criterios de entrada y salida; preparacin previa a la reunin; documento de inspeccin, lista de averiguaciones; proceso formal follow-up; opcionalmente, mejora del proceso y lector; Propsito principal: encontrar defectos.

3.2.4 Factores de xito para revisiones (K2)Los factores de xito para las revisiones incluyen: Cada revisin tiene un objetivo predefinido claro. Las personas involucradas para la revisin son las adecuadas. Los defectos encontrados son bienvenidos, y expresados objetivamente. Se trata con los problemas de las personas y los aspectos psicolgicos (Ej. hacindolos una experiencia positiva para el autor). Las tcnicas de revisin son aplicadas tal que sean adecuadas al tipo y nivel de los productos software y revisores. Checklists y roles son usados apropiadamente para incrementar la efectividad de la identificacin de defectos. Se da una preparacin en las tcnicas de revisin, especialmente las tcnicas formales, como la inspeccin. Versin 2005 Spanish Software Testing Qualifications Board

38-88

Julio de2005



La gestin soporta un buen proceso de revisin (Ej. mediante la incorporacin de tiempo adecuada para las actividades de revisin en la programacin de proyectos). Hay un nfasis en aprender y mejorar el proceso.

3.3 Anlisis esttico por herramientas (K2) | 20 minutos TrminosCompilador, complejidad, control de flujo, flujo de datos, anlisis esttico.

Conocimientos previosEl objetivo del anlisis esttico es el de encontrar defectos en el cdigo fuente del software y el los modelos software. El anlisis esttico se realiza sin necesidad de ejecutar el software examinado por la herramienta; las pruebas dinmicas si ejecutan el cdigo software. El anlisis esttico puede localizar defectos que son difciles de encontrar en las pruebas. Como con las revisiones, el anlisis esttico encuentra defectos ms que fallos. Las herramientas de anlisis esttico analizan el cdigo del programa (Ej. control de flujo y control de datos), al igual que generan una salida como HTML y XML. El valor del anlisis esttico es: Deteccin temprana de defectos antes de la ejecucin de pruebas. Avisos tempranos sobre aspectos sospechosos del cdigo o el diseo, mediante el clculo de mtricas, como las medidas de gran complejidad. Identificacin de defectos difcilmente encontrados por las pruebas dinmicas. Deteccin de dependencias e inconsistencias en los modelos software, como enlaces. Mantenibilidad mejorada del cdigo y del diseo. Prevencin de defectos, si las lecciones son aprendidas durante el desarrollo. Defectos tpicos descubiertos por las herramientas de anlisis esttico incluyen: referenciar una variable con un valor indefinido; interfaz inconsistente entre mdulos y componentes; variables nunca usadas; cdigo inalcanzable(muerto); violaciones de programa estndar; vulnerabilidades de seguridad; violacin de la sintaxis de cdigo y modelos software.

Las herramientas de anlisis esttico son tpicamente usadas por desarrolladores (comprobando contra reglas predefinidas y estndares de programacin) antes y durante las pruebas de componentes y de integracin, y por diseadores durante el modelado del software. Las herramientas de anlisis esttico pueden producir un alto nmero de mensajes de aviso, que debern ser bien gestionados para permitir el uso ms efectivo de la herramienta.


39-88

Julio de2005



Los compiladores pueden ofrecer soporte para el anlisis esttico, incluyendo los clculos de mtricas.

Referencias3.2 IEEE 1028 3.2.2 Gilb, 1993, van Veenendaal, 2004 3.2.4 Gilb, 1993, IEEE 1028 3.3 Van Veenendaal, 2004


40-88

Julio de2005



4. Tcnicas de diseo de test (K3) | 255 minutosObjetivos de aprendizaje para tcnicas de diseo de testLos objetivos identifican lo que ser capaz de hacer al finalizar cada mdulo.

4.1 Identificacin de las condiciones de test y diseo de los casos de prueba (K3) Diferenciar entre la especificacin del diseo de test, especificacin de los casos de prueba y especificacin del procedimiento de test (K1). Comparar los trminos condiciones de prueba, casos de prueba y procedimiento de prueba (K2). Escribir los casos de prueba: (K3) - mostrar una trazabilidad clara de los requisitos - incluir un resultado esperado Traducir los casos de prueba a una especificacin de procedimientos de prueba bien estructurados, con nivel de detalle acorde a los conocimientos de los probadores. Redactar una secuencia de ejecucin de pruebas para un determinado conjunto de casos de prueba, considerando las prioridades as como las dependencias lgicas y tcnicas.

4.2 Categoras de las tcnicas de diseo de pruebas (K2) Recordar las razones tanto las basadas en especificacin (caja negra) como en estructura (caja blanca) que sean tiles para el diseo de casos de prueba, y hacer una lista de las tcnicas comunes para cada uno. (K1) Explicar las caractersticas y diferencias entre pruebas basadas en especificacin, en estructura y en experiencia. (K2).

4.3 Tcnicas basadas en especificacin o de caja negra (K3)Escribir los casos de prueba para un determinado modelo software usando las siguientes tcnicas de diseo de pruebas: (K3) - Particionado equivalente - Anlisis y acotacin de valores - Tablas de decisin - Diagramas de transicin de estado Comprender el propsito de cada una de las cuatro tcnicas, el nivel y tipo de pruebas que puede usar la tcnica, y cmo ha de ser ponderada la cobertura (K2). Comprender el concepto de usar casos de prueba y sus beneficios (K2).


41-88

Julio de2005



4.4 Tcnicas basadas en estructura o de caja blanca (K3)Describir el concepto e importancia de la cobertura de cdigo (K2) Explicar los conceptos de cobertura de estado y decisin, y ayudan a entender que estos conceptos pueden ser tambin usados en otros niveles de prueba adems de las pruebas de componentes (por ejemplo, en procedimientos de negocio a nivel de sistema) (K2) Escribir los casos de prueba de un control de flujo dado usando las siguientes tcnicas de diseo de pruebas: (K3) - pruebas de estado - pruebas de decisin Valorar la cobertura de estado y decisin (K3)

4.5 Tcnicas basadas en la experiencia (K2) Escribir casos de prueba basados en la intuicin, experiencia y conocimiento de fallos tpicos (K1) Comparar las tcnicas de prueba basadas en la experiencia con las tcnicas basadas en especificacin

4.6 Eleccin de las tcnicas de prueba (K2) Hacer una lista de factores que influyen en la seleccin de la tcnica de diseo de pruebas apropiada para un determinado problema, tal como tipo de sistema, riesgos, modelado de casos de uso, requerimientos de los modelos o conocimientos del probador. (K2)


42-88

Julio de2005



4.1 Identificacin de las condiciones y diseo de los casos de prueba (K3) | 15 minutos TrminosCasos de prueba, especificacin de casos de prueba, condiciones de prueba, datos de prueba, especificacin del procedimiento de pruebas, script de pruebas, trazabilidad.

Conocimientos previosEl proceso de identificacin de las condiciones y diseo de pruebas consiste en una serie de pasos: Diseo de las pruebas mediante la identificacin de condiciones de prueba, Especificacin de los casos de prueba, Especificacin de los procedimientos de pruebas El proceso se puede realizar de distintas maneras, puede ser desde informal con documentacin escasa o inexistente, hasta muy formal (como se describe en este apartado). El nivel de formalizacin depende del contexto de las pruebas, incluyendo la organizacin, la madurez de los procesos de prueba y desarrollo, restricciones temporales y el personal involucrado. Durante el diseo de las pruebas, se analiza la documentacin bsica para determinar qu hay que probar, ej. identificar las condiciones de prueba. Una condicin de prueba se define como un elemento o evento que puede ser verificado mediante uno o varios casos de prueba (ej. una funcin, una transaccin, una cualidad caracterstica o un elemento estructural). Establecer la trazabilidad desde las condiciones de prueba hacia la especificacin y requisitos permite tanto el anlisis de impactos, cuando los requisitos cambien, como la cobertura de requisitos a determinar por un conjunto de pruebas. Durante el diseo de pruebas se implementa el esquema detallado de las pruebas, basndose entre otras consideraciones, en los riesgos que se hayan identificado (para ver ms sobre anlisis de riesgo, consultar el Captulo 5). Durante la especificacin de casos de pruebas, los casos de prueba y los datos de las pruebas se desarrollan y describen en detalle mediante tcnicas de diseo de pruebas. Un caso de prueba consiste en un conjunto de valores de entrada, precondiciones de ejecucin, resultados esperados y/o condiciones post-ejecucin, desarrollados para cubrir determinadas condiciones de prueba. La documentacin del Estndar para pruebas de software (IEEE 829) describe el contenido de las especificaciones para el diseo de casos de prueba. Los resultados esperados deben formar parte de la especificacin de un caso de prueba e incluir salidas, cambios de datos y estados, y cualquier otra consecuencia de la prueba. Si los resultados esperados no se definen, puede ocurrir que un resultado de la Versin 2005 Spanish Software Testing Qualifications Board

43-88

Julio de2005



prueba aparentemente correcto, pero errneo, sea interpretado como bueno. Los resultados esperados deben ser definidos antes de la ejecucin de la prueba. En la especificacin del procedimiento de pruebas, se ponen los casos de prueba en orden de ejecucin. El procedimiento de pruebas (o manual del script de pruebas) especifica la secuencia de acciones para la ejecucin de una prueba. Si las pruebas se ejecutan usando alguna herramienta de ejecucin de pruebas, la secuencia de acciones se especifica en un script de pruebas (que es un procedimiento de pruebas automatizado). Las distintas pruebas y scripts de automatizacin de pruebas se estructuran dentro de una secuencia de ejecucin de pruebas que define el orden en que los distintos procedimientos de pruebas, y los posibles scripts de automatizacin, son ejecutados, cuando son llevados a cabo por alguien. La secuencia de ejecucin de pruebas tendr en cuenta factores tales como pruebas de regresin, priorizacin y dependencias tcnicas y lgicas.


44-88

Julio de2005



4.2 Categoras de las tcnicas de diseo de pruebas (K2) | 15 minutos TrminosTcnicas de caja negra, tcnicas basadas en la experiencia, tcnicas basadas en especificacin, tcnicas basadas en estructura, tcnicas de caja blanca

Conocimientos previosEl propsito de las tcnicas de diseo de prueba es identificar las condiciones de prueba y los casos de prueba. La denominacin de las tcnicas de prueba como de caja negra o de caja blanca es una distincin clsica. Las tcnicas de caja negra (tambin conocidas como tcnicas basadas en especificacin) son un modo de seleccionar y modificar condiciones o casos de prueba basndose en la documentacin bsica de las pruebas, ya sean funcionales o no, de un componente o sistema sin tener en cuenta su estructura interna. Las tcnicas de caja blanca (tambin conocidas como tcnicas estructurales o basadas en estructura) se basan en el anlisis de la estructura interna del componente o sistema. Algunas tcnicas pertenecen claramente a una nica categora, otras tienen elementos pertenecientes a ms de una categora. Este manual de estudios hace referencia a las tcnicas basadas en especificacin o basadas en experiencia como tcnicas de caja negra, y a las tcnicas basadas en estructura como tcnicas de caja blanca. Caractersticas comunes de las tcnicas basadas en especificacin Los modelos, tanto los formales como los informales, se usan para especificar el problema a resolver, el software o sus componentes. A partir de estos modelos, los casos de prueba se obtienen sistemticamente. Caractersticas comunes de las tcnicas basadas en especificacin La informacin de cmo est hecho el software se usa para implementar los casos de prueba, por ejemplo, el cdigo y diseo. La extensin de la cobertura del software puede medirse para algunos casos de prueba, pudindose obtener casos de prueba futuros que incrementen la cobertura. Caractersticas comunes de las tcnicas basadas en la experiencia El conocimiento y experiencia de las personas se usan para obtener los casos de prueba: - Conocimientos de los probadores, desarrolladores y usuarios del software, se usa en este entorno - Conocimiento de errores comunes y su distribucin


45-88

Julio de2005



4.3 Tcnicas basadas en especificacin o de caja negra (K3) | 120 minutos TrminosAnlisis de valores lmite, tabla de decisin de pruebas, particionamiento por equivalencia, pruebas de transicin de estado, pruebas de casos de uso.

4.3.1 Particionamiento por equivalencia (K3)Las entradas del software o del sistema se dividen en grupos de los que se espera un comportamiento similar, por los que se procesarn de forma parecida. Las particiones por equivalencia (o por clases) se pueden hallar tanto para datos correctos como incorrectos, por ejemplo, valores que deben ser rechazados. Tambin se pueden identificar particiones para las salidas, valores internos, valores relacionados con el tiempo (por ejemplo, antes o despus de un evento) y para parmetros de interfaces (por ejemplo, durante las pruebas de integracin). Las pruebas se pueden disear para cubrir las particiones. La particin por equivalencia (EP) se aplica a todos los niveles de prueba. La particin por equivalencia, como tcnica en s, puede ser usada para conseguir cobertura de entrada y salida. Se puede aplicar a las entradas de usuarios, entradas va interfaces del sistema, o parmetros de interfaz en las pruebas de integracin.

4.3.2 Anlisis de valores lmite (K3)El comportamiento en las fronteras de cada particionamiento de equivalencia puede ser incorrecto, por eso la acotacin de valores trata de corregir defectos. Los valores mximo y mnimo de una particin son sus valores lmite. Un valor lmite de una particin vlida es un valor lmite vlido. Los lmites de una particin no vlida son valores lmite no vlidos. Las pruebas pueden ser diseadas para cubrir tanto valores lmite vlidos y no vlidos. Cuando se disean casos de prueba, se elige un valor en cada lmite. El anlisis de valores lmite es aplicable a todos los niveles de prueba. Es relativamente fcil de aplicar, y tiene gran capacidad de encontrar defectos. Esta tcnica es considerada a menudo como una extensin de la particin por equivalencia y puede ser usada para entradas de usuarios tales como, por ejemplo, temporizacin o tablas de lmites. Los valores lmite deben ser tambin usados para las pruebas de seleccin de datos.

4.3.3 Pruebas de tablas de decisin (K3)Las tablas de decisin son un buen mtodo de capturar requisitos del sistema que contengan condiciones lgicas, as como para documentar el diseo interno del sistema. Deben usarse para guardar reglas complejas de negocio que se van a implementar por un sistema. Se analizan las especificaciones, y se definen las condiciones y acciones del sistema. Las condiciones de entrada y las acciones ms indicadas son en muchas ocasiones Versin 2005 Spanish Software Testing Qualifications Board

46-88

Julio de2005



combinaciones de estados distintos de un simple verdadero o falso. La tabla de decisin contiene condiciones de disparo, combinaciones de verdadero y falso para todas las condiciones de entrada, y las acciones resultantes para cada combinacin de condiciones ejecutadas. El convenio ms usado para el uso de pruebas de tablas de decisin es tener al menos una prueba por columna, que tpicamente cubre todas las combinaciones de condiciones de disparo. La fuerza de las pruebas con tablas de decisin es que crea comb

foundation level syllabus (2010)spanish

Documents

testing k2

los test k2

pruebas k2

test y estimacin k2

revisin k2

desarrollo software

testing y calidad k2

uso k2