Apuntes ISTQB Foundation Formandobits

APUNTES ISTQB CTFL (Certified Tester Foundation Level)

v. 2!"#$ Ada%ta&i'n realiada %or Forando*its.&o Basada en el Pro+raa de estudio nivel *,si&o de SSTQB (sst-*.es)  ISTQB (ist-*.or+) ISTQ ISTQB B es una una ar& ar&a a re+i re+ist stra rada da del del Inte Intern rnat ation ional al Soft Soft/a /are re Test Testin in+ + Qualifi&ations Board Se %erite la re%rodu&&i'n total o %ar&ial de este do&uento indi&ando las referen&ias indi&adas en este a%artado.

1

0N1ICE 1. Principios básicos del proceso de pruebas..................................................................5 1.1 ¿Por qué es necesario el proceso de pruebas?........................................................5 1.1.1 Contexto de los sistemas sistemas software (K1........................................................... 5 1.1.! Causas de los defectos de software (K!.......................................................... 5 1.1." #unci$n del proceso de pruebas en el desarrollo% mantenimiento & operaciones de software (K!......................................................................................................5 1.1.' Proceso de pruebas & calidad (K!.................................................................. 1.1.5 ¿Con cuántas pruebas es suficiente? (K!........................................................ 1.! ¿)n qué consiste el proceso de pruebas? pruebas? (K!....................................................... . 1." *iete principios para para las pruebas (K!................................................................... + 1.' Proceso básico de pruebas (K1..........................................................................., 1.'.1 Planificaci$n & control de pruebas (K1............................................................1.'.! nálisis & dise/o de pruebas (K1...................................................................1.'." 0mplementaci$n & eecuci$n de pruebas (K1.................................................12 1.'.' )3aluaci$n de los los criterios de salida e informes (K1..................................... ...12 1.'.5 cti3idades de cierre de pruebas (K1...........................................................12 1.5 4a psicolo6a de las pruebas (K!.......................................................................11 1. C$dio deontol$ico (K!..................................................................................11 !. Pruebas durante todo el ciclo de 3ida del software (K!............................................ ..1" !.1 7odelos de desarrollo de software (K!...............................................................1" !.1.1 7odelo 8 (7odelo de desarrollo secuencial secuencial (K!.............................................1' (K!........................................ .....1' !.1.! 7odelo de desarrollo desarrollo iterati3o9incremental iterati3o9incremental (K!.......................................... (K!.................................. ............15 ....15 !.1." Pruebas en un 7odelo de Ciclo de 8ida (K!...................................................15 !.! :i3eles de prueba (K!.....................................................................................15 !.!.1 Pruebas de componente;unitarias (K!..........................................................1+ !.!.! Pruebas de interaci$n (K!.........................................................................1, !.!." Pruebas de sistema (K!.............................................................................1!.!.' Pruebas de aceptaci$n (K!.........................................................................1!." epetici$n de pruebas & pruebas de reresi$n (K! .......................................................................................................................!' !.' Pruebas de mantenimiento (K!.........................................................................!5 ". <écnicas estáticas (K!.........................................................................................!+ ".1 4as técnicas estáticas & el proceso de pruebas (K!..............................................!+ ".! Proceso de re3isi$n (K!...................................................................................!, ".!.1 cti3idades cti3idades de una re3isi$n formal (K1....................................................... ..!".!.! #unciones & responsabilidades (K1............................................................... (K1............................................................... !".!."
'. <écnicas de dise/o de pruebas (K'........................................................................"5 '.1 )l proceso de desarrollo desarrollo de pruebas (@"......................................................... ...."5 '.! Cateor6as de técnicas de dise/o de pruebas (K! ................................................"+ '." <écnicas basadas en la especificaci$n especificaci$n o técnicas de caa nera (K" .................. ......... ..............", .....", '.".1 Partici$n (Clase de equi3alencia (K"............................................................", '.".! nálisis de 3alores l6mite (K"......................................................................"'."." Pruebas de tabla de decisi$n (K".................................................................'2 '.".' Pruebas de transici$n de estado (K"............................................................'2 '.".5 Pruebas de caso de uso (K!........................................................................'1 '.' <écnicas basadas en la estructura o técnicas técnicas de caa blanca (K'............................ (K'.................... ........'! '! ntecedentes.....................................................................................................'" '.'.1 Pruebas de sentencias & cobertura (K'.........................................................'" '.'.! Pruebas de decisi$n & cobertura (K'............................................................'" '.'." Atras técnicas basadas en la estructura (K1..................................................'' '.5 <écnicas basadas en la experiencia..................................................................... experiencia..................................................................... '' '. *elecci$n de técnica de prueba (K!...................................................................'5 5 Besti$n de pruebas (K".........................................................................................' 5.1 Araniaci$n de pruebas (K!............................................................................' 5.1.1 Araniaci$n de pruebas e independencia (K!...............................................' 5.1.! iesos & pruebas............................................................................................55 ntecedentes.....................................................................................................55 5.5.1 >iesos de pro&ecto pro&ecto (K! ............................................................................ 55 5.5.! >iesos de producto (K!............................................................................5 5. Besti$n de incidencias (K"...............................................................................5+  Derramientas de soporte soporte de pruebas (K!.............................................................. ...5.1
"

.1.5 Derramientas de soporte para la especificaci$n de prueba (K1.........................! .1. Derramientas de soporte para la eecuci$n & el reistro de pruebas (K1............! .1.+ Derramientas de soporte para el rendimiento & la monitoriaci$n (K1................" .1., Derramientas de soporte para necesidades de pruebas espec6ficas (K1........... ..." .! Eso efecti3o de las erramientas= 8entaas potenciales & riesos (K!.....................' .!.1 8entaas potenciales & riesos de las erramientas de soporte de pruebas (para todas las erramientas (K!................................................................................' .!.! Consideraciones especiales para alunos tipos de erramientas (K1..................5 ." 0ntroducci$n de una erramienta en una oraniaci$n (K1............................ ........ :)FA 0))) ,!- :A>7 P> 4 GACE7):<C0H: G) P>E)I* *A#)................., *ecciones plantilla de especificaci$n de dise/o de pruebas................................... ....., *ecciones plantilla de especificaci$n de caso de prueba............................................, *ecciones plantilla de especificaci$n de procedimiento de prueba..............................., *ecciones del plan de pruebas ............................................................................., *ecciones informe de resumen de pruebas ............................................................*ecciones reistro de pruebas .............................................................................0nforme de transmisi$n de los 6tems de pruebas (comnmente llamado Lnotas de 3ersionesM .......................................................................................................0nforme de incidencias........................................................................................-

'

!. Prin&i%ios *,si&os del %ro&eso de %rue*as !.! Por -u3 es ne&esario el %ro&eso de %rue*as4 )rror;)qui3oca ci$n Gefecto;#alta;I u

#allo;#alla

Acción humana que produce un resultado incorrecto.

Imperfección en un componente o sistema que puede causar que el componente o sistema falle al desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos incorrectas. Si se localiza u n defecto durante una ejecución puede causar un fallo en el componente o sistema.

Desviación del componente o del sistema respecto de prestación, servicio o resultado esperado.

Calidad

Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas  del usuario/cliente.

>ieso

Factor que puede resultar en futuras consecuencias negativas, expresada normalmente como impacto y probabilidad.

!.!.! Conte5to de los sisteas soft/are (6!) 

*oftware que no funciona correctamente



Pérdida de dinero% tiempo% renombreN

!.!.2 Causas de los defe&tos de soft/are (62) 

 

Persona 999 puede cometer un error;equi3ocaci$n 999 puede producir un defecto;falta;bu en c$dio o un documento 999 si se eecuta el defecto en c$dio pro3oca un comportamiento no esperado= fallo;falla :o todos los defectos dan luar a fallos (nunca llean a eecutarse;descubrirse. Causas defectos= 4as personas somos falibles O trabao bao presi$n. Compleidad del c$dio;infraestructuras.


!.!.7 Fun&i'n del %ro&eso de %rue*as en el desarrollo8 anteniiento 9 o%era&iones de soft/are (62) Pruebas riurosas= >educen el rieso de fallo (si los defectos se detectan & corrien antes de la operaci$n del sistema. 

o

5

o


!.!." Pro&eso de %rue*as 9 &alidad (62) Calidad= )l rado en el cual un componente% un sistema o un proceso cumple los requisitos especificados &;o las necesidades & las expectati3as del usuario;cliente. Pruebas miden la calidad software= se puede medir en términos de los defectos detectados respecto a requisitos% caracter6sticas funcionales & no funcionales. 0*A -1! ; 0*A !5222= Calidad de producto software (cataloa las caracter6sticas del software. *i las pruebas detectan pocos o ninn defecto= aportan fiabilidad a la calidad del software. *i una prueba se pasa correctamente= reduce el ni3el de rieso de un sistema. *i las pruebas detectan defectos= su correcci$n incrementa la calidad software. seuramiento;arant6a de la calidad= 7eora de procesos al entender las causas ra6 de los defectos detectados en pro&ectos pre3ios. 0ntera acti3idades de pruebas% desarrollo de estándares% formaci$n & análisis de defectos. 



o



o

o



o

o

!.!.: Con &u,ntas %rue*as es sufi&iente4 (62) Da& que tener en cuenta= :i3eles de rieso (técnicos% de seuridad% comerciales%N. 4imitaciones del pro&ecto (tiempo% presupuesto. 4as pruebas deben aportar informaci$n a los interesados para=
o o



o o

!.2 En -u3 &onsiste el %ro&eso de %rue*as4 (62) Gepuraci$n >equisito

>e3isi$n

Caso de prueba

Probar;Pruebas



Proceso de encontrar, analizar y eliminar las causas de los fallos en el softare.

!ondición o capacidad necesaria para un usuario con el o"jeto de s olucionar un pro"lema o lograr un o"jetivo que de"e ser alcanzado o pose#do por un sistema o componente de un sistema, para satisfacer un contrato, est$ndar, especificación u otro documento impuesto formalmente.

%valuación de un producto o del estado de un proyecto para detectar discrepancias con los resultados planificados y para r ecomendar mejoras. &lgunos ejemplos' revisión de gestión, revisión informal, revisión t(cnica, inspección y revisión guiada.

!onjunto de valores de entrada, precondiciones de ejecución, resultados esperados y postcondiciones de ejecución, desarrollado con un o"jetivo en particular o condición de prue"a, tales como pro"ar un determinado camino de ejecución o para verificar el cumplimiento de un requisito determinado.

Proceso que consiste en todas las actividades del ciclo de vida softare, tanto est$ticas como din$micas, concernientes con la planificación, preparación y evaluación de productos softare y los productos de tra"ajo relacionados para determinar que (stos satisfacen los requisitos especificados, para demostrar que se ajustan al propósito y para detectar defectos.

Abeti3o de prueba





)azón o propósito para el diseño y la ejecución de una prue"a.

Proceso de pruebas= no solo eecutar pruebas% sino también todas las acti3idades que se dan antes & después (planificaci$n & control% elaboraci$n de informesN as6  como otro tipo de acti3idades (re3isi$n de documentos inclu&endo el c$dio fuente9% análisis estáticos%N. ;*
o

o



o

o

o

!.7 Siete %rin&i%ios %ara las %rue*as (62) Pruebas exausti3as

%nfoque de prue"as donde el conjunto de prue"as a"arca todas las com"inaciones de valores de entrada y precondiciones .

!. Las %rue*as deuestran la %resen&ia de defe&tos. Pero no pueden demostrar que no los a&= que no se detecte ninn defecto no es e3idencia de correcci$n. >educen la probabilidad de que a&a defectos. 2. Las %rue*as e5>austivas no e5isten. Probar todo (%rue*as e5>austivas= todas las &o*ina&iones de entradas 9 %re&ondi&iones es imposible (sal3o en casos tri3iales. nálisis de riesos & prioridades para centraliar los esfueros de las pruebas. 7. Prue*as te%ranas. *e deben identificar los defectos en una etapa temprana= se iniciarán las pruebas lo antes posible en el ciclo de 3ida del software. ". A+ru%a&i'n de defe&tos. 4a ma&or6a de defectos detectados durante las pruebas pre3ias al lanamiento & la ma&or6a de fallos operati3os se concentran en un nmero reducido de m$dulos. 4as pruebas deben concentrarse de manera proporcional en la densidad esperada% & más tarde obser3ada% de los defectos de los m$dulos. :. Parado
















+

?. Las %rue*as de%enden del &onte5to. 4as pruebas se lle3an a cabo de manera diferente sen el contexto (la forma de probar un software cr6tico para la seuridad 3ariará de la de un sitio de comercio electr$nico. @. Fala&ia de la ausen&ia de errores 4a detecci$n & correcci$n de defectos no ser3irá de nada si el sistema construido no es usable & no cumple las expectati3as & necesidades de los usuarios. 



!." Pro&eso *,si&o de %rue*as (6!) Pruebas de confirmaci$n  ; >epetici$n de pruebas Criterios de salida

0ncidencia Pruebas de reresi$n

Iase de prueba

Condici$n de prueba

Cobertura de pruebas Gatos de prueba )ecuci$n de pruebas >eistro de pruebas Plan de pruebas

,

Prue"as que ejecutan aquellos casos de prue"a que *u"ieran fallado la +ltima vez que fueran ejecutados con el o"jetivo de verificar el (xito de acciones correctivas.

!onjunto de condiciones gen(ricas y espec#ficas, acordadas con los involucrados en el proyecto, para permitir que un proceso sea considerado concluido ofi cialmente. %l propósito de los criterios de salida es evitar que una tarea se considere concluida cuando existen partes de la tarea pendientes que no *ayan sido finalizadas. os criterios de salida son utili zados para planificar cu$ndo parar las prue"as e informar so"re esto.

!ualquier ocurrencia de un suceso que requiere investigación

Prue"as de un programa previamente pro"ado que *a sufrido modificaciones, para asegurarse que no se *an introducido o descu"ierto defectos en $reas del softare que no *an sido modificadas como resultado de los cam"ios realiz ados. Se realiza cuando el softare o su entorno *an sido modificados.

-odos los documentos de donde los requisitos de un componente o sistema pueden ser inferidos. a documentación en la que se "asan los c asos de prue"a. Si un documento puede ser modificado sólo por medio de un procedimiento de cam"io formal, entonces la "ase de las prue"as se denomina "ase de prue"a congelada.

%lemento o evento de un componente o sistema que de"er#a ser verificado por uno o m$s casos de prue"a, por ejemplo una función, transacción, caracter#stica, atri"uto de calidad o elemento estructural.

rado, expresado como un porcentaje, en el que un elemento de co"ertura especificado *a sido practicado por un juego de prue"as.

atos que existen 0por ejemplo en una "ase de datos1 antes de que una prue"a sea ejecutada y que afectan o son afectados por el componente o sistema en prue"as.

Proceso de practicar una prue"a so"re el componente o sistema en prue"as, produciendo resultado0s1 reales.

)egistro cronológico de los detalles relevantes respecto a la ejecución de prue"as.

ocumento que descri"e el alcance, enfoque, los recursos y planificaci ón de las actividades de prue"as previstas. 2dentifica, entre otros, los el ementos de prue"a, las prestaciones a ser pro"adas, las tareas de prue"as, quien realiza cada tarea, el grado de independencia del pro"ador, el entorno de prue"as, las t(cnicas de diseño de prue"as y los criterios de entrada y salida a utilizar, y los motivos para cada elección, y cualquier riesgo que requiera un plan de contingencia. %s un registro del proceso de planificación de prue"as.

()specificaci$n Procedimiento pruebas

de de

Pol6tica de pruebas

ocumento de alto nivel que descri"e los principios, el enfoque y los principales o"jetivos de la organización en lo referente a las prue"as.

Conunto;Queo (casos de prueba

de

0nforme pruebas

de

resumen

Producto de soporte de prueba (testware

rnés de pruebas



ocumento que especifica la secuencia de acciones para la ejecuci ón de una prue"a. -am"i(n conocido como script de prue"a o script de prue"a manual.

!onjunto de casos de prue"a para un componente o sistema en prue"as, donde la poscondición de una prue"a es a menudo usada como precondición de la siguiente.

ocumento que resume las activi dades y resultados de l as prue"as. -am"i(n contiene una evaluación de los correspondientes elementos de prue"a respecto de los criterios de salida.

 &rtefactos producidos durante el proceso de prue"as necesarios para la planificación, el diseño y la ejecuci ón prue"as, tales como la documentación, scripts, entradas, resultados esperados, procedimientos de configuración y despejado, arc*ivos, "ases de datos, entorno y cualquier softare o utili dades adicionales utilizadas en prue"as.

%ntorno de prue"as constituido por stu"s y controladores necesarios para llevar a ca"o una prue"a.

A&tividades %rin&i%ales (pueden solaparse= 1. Planificaci$n & control. !. nálisis & dise/o. ". 0mplementaci$n & eecuci$n. '. )3aluaci$n de los criterios de salida e informes. 5. cti3idades de cierre de pruebas.

!.".! Planifi&a&i'n 9 &ontrol de %rue*as (6!) 



Planifi&a&i'n de %rue*as= cti3idad de definir los obeti3os de las pruebas & la especificaci$n de las acti3idades de pruebas con 3istas a cumplir estos obeti3os. Control de %rue*as= cti3idad constante de comparar el proreso real con el plan pre3isto% e informar sobre el estado de las pruebas (inclu&endo des3iaciones sobre lo planificado. 0mplica la adopci$n de medidas necesarias para cumplir los obeti3os del pro&ecto (la planificaci$n de pruebas tiene en cuenta el feedbac@ de la acti3idad de control. o

!.".2 An,lisis 9 diseo de %rue*as (6!) cti3idad durante la cual los obeti3os de las pruebas se transforman en condiciones de prueba & casos de prueba tanibles. Tareas %rin&i%ales= 1. >e3isar la base de pruebas (


-

!.".7 I%leenta&i'n 9 eeistrar los resultados de la eecuci$n de las pruebas & reistrar las identidades & las 3ersiones del software probado% as6 como las erramientas de prueba & los productos de soporte de pruebas. ,. Comparar los resultados reales con los resultados esperados. -. >eportar las discrepancias en forma de incidencias & analiarlas con 3istas a establecer sus causas (por eemplo% defectos en el c$dio% defectos en documentos de prueba%N. 12. >epetir las acti3idades de pruebas como resultado de una medida adoptada para cada discrepancia (por eemplo% la repetici$n de una prueba que a fallado anteriormente con 3istas a confirmar su correcci$n  pruebas de confirmaci$n 9R la eecuci$n de una prueba correida &;o la eecuci$n de pruebas con 3istas a arantiar que los defectos no se an introducido en áreas no modificadas del software o que la subsanaci$n del defecto no a re3elado la existencia de otros defectos pruebas de reresi$n9. 



!."." Evalua&i'n de los &riterios de salida e infores (6!) cti3idad que e3ala la eecuci$n de pruebas (para cada ni3el de prueba contra los obeti3os definidos. Tareas %rin&i%ales= 1. Comprobar los reistros de pruebas con los criterios de salida pre3istos en la planificaci$n de la prueba. !. )3aluar si se requieren más pruebas o si deber6an modificarse los criterios de salida especificados. ". )laborar un resumen de las pruebas para las partes interesadas. 



!.".: A&tividades de &ierre de %rue*as (6!) >ecopilaci$n de los datos de aquellas acti3idades de pruebas finaliadas con el obeti3o de consolidar la experiencia% los productos de soporte de pruebas% los ecos & las cifras.




12

!.: La %si&olo+a de las %rue*as (62) Predicci$n de error

0ndependencia pruebas 





-(cnica de diseño de prue"as donde la experiencia de quien prue"a es utilizada para anticipar qu( defectos podr#an estar presentes en el componente o sistema en prue"a como resultado de los errores cometidos, y diseñar prue"as espec#ficas para ponerlos al descu"ierto.

(de

Separación de responsa"ilidades, que fomenta la realización de prue"as o"jetivas.

Principio de sereaci$n de tareas ; 0ndependencia de las pruebas= quien prueba o re3isa es diferente al que desarrolla. 4a independencia de las pruebas 8* conocimiento del trabao= ser independiente no arantia efecti3idad a la ora de detectar defectos. Giferentes ni3eles de independencia (de menor a ma&or= Pruebas dise/adas por las mismas personas que escribieron el software. Pruebas dise/adas por otros miembros del mismo equipo de desarrollo. Pruebas dise/adas por una persona de otro rupo de la oraniaci$n (por eemplo% un equipo de pruebas independiente o un especialista de la oraniaci$n en pruebas de usabilidad o rendimiento. Pruebas dise/adas por personas de otra oraniaci$n o empresa (externaliaci$n o certificaci$n por parte de un oranismo externo. )s importante establecer los obeti3os de las pruebas= las personas tienden a austar sus planes a los obeti3os establecidos (detectar errores? Confirmar el cumplimiento de requisitos?. )l proceso de pruebas a menudo se considera una acti3idad destructi3a (como una cr6tica contra el producto o el autor% pero es una acti3idad constructi3a para la esti$n de los riesos del producto. En probador requiere curiosidad% pesimismo profesional% oo cr6tico% atenci$n al detalle% buena comunicaci$n con los compa/eros de desarrollo & experiencia sobre la que basar la predicci$n de error. Da& que comunicar los errores% defectos o fallos de manera constructi3a para e3itar malentendidos. #ormas de meorar la comunicaci$n & relaciones entre los probadores & los demás= !. )mpear untos en luar de enfrentados= existe un obeti3o comn que es conseuir sistemas de meor calidad. 2. Comunicar los allaos del producto de una manera neutral & centrada en los ecos% sin criticar a las personas que lo crearon% por eemplo% redactando informes de incidencias obeti3os & re3isando las conclusiones. 7. 0ntentar comprender c$mo se siente la otra persona & porqué reacciona de esa manera. ". Confirmar que la otra persona a entendido lo que usted a dico & 3ice3ersa. o o o

o











!.? C'di+o deontol'+i&o (62) 









11

PBLIC;= 4os probadores de software certificados actuarán en coerencia con el interés pblico. CLIENTE D EPLEA1;= 4os probadores de software certificados actuarán en el meor de los intereses de su cliente & empleador% en coerencia con el interés pblico. P;1UCT;= 4os probadores de software certificados arantiarán que los productos entreables que proporcionan (por lo que respecta a los productos & sistemas que prueban se austan los más altos estándares profesionales. CITEI;= 4os probadores de software certificados mantendrán la interidad & la independencia en su criterio profesional. GESTIHN=  4os efes & l6deres de pruebas de software certificados suscribirán & fomentarán un enfoque ético en la esti$n de las pruebas de software.







1!

P;FESIHN= 4os probadores de software certificados aumentarán la interidad & la reputaci$n de la profesi$n en coerencia con el interés pblico. C;PAE;S= 4os probadores de software certificados serán equitati3os & apo&arán a sus compa/eros fomentando la cooperaci$n con los desarrolladores de software. NIJEL IN1IJI1UAL= 4os probadores de software certificados participarán en un aprendiae a lo laro de toda la 3ida por lo que respecta a la práctica de su profesi$n & fomentarán la adopci$n de un enfoque ético en la práctica de su profesi$n.

2. Prue*as durante todo el &i&lo de vida del soft/are (62) 2.! odelos de desarrollo de soft/are (62) *oftware de distribuci$n masi3a (CA<* 9 !ommercial softare

3ff4-*e4S*elf 

7odelo en 8 (7odelo de desarrollo secuencial

7odelo de iterati3o

desarrollo

7odelo de incremental

desarrollo

8erificaci$n

Producto softare que es desarrollado para el mercado general, por ejemplo, para un gran n+mero de clientes, y es distri"uido a muc*os clientes en formato idéntico.

5arco de tra"ajo para descri"ir las actividades del ciclo de vida de desarrollo softare desde la especificación de requisitos *asta el mantenimiento. %l modelo46 ilustra cómo las actividades de del proceso de prue"as pueden ser integradas dentro de cada fase del ciclo de vida de desarrollo softare.

!iclo de vida del desarrollo donde un proyecto es dividido en un n+mero de iteraciones, generalmente grande. 7na iteración es un ciclo completo de desarrollo que tiene como resultado una entrega (interna o externa de un producto e!ecutable, un su"conjunto del producto final en desarrollo, que crece de iteración en iteración para convertirse en el producto final.

!iclo de vida de desarrollo softare en el cual un proyecto es descompuesto en una serie de incrementos, cada uno de los cuales suministra una porción de la funcionalidad respecto de la totalidad de los requisitos del proyecto. os requisitos tienen asignada una prioridad y son entregados seg+n el orden de prioridad en el incremento correspondiente. %n algunas 0pero no en todas1 versiones de este modelo de ciclo de vida, cada su"proyecto sigue un 8mini4modelo 69 con sus propias fases de diseño, codificación y prue"as. ◦

Jerifi&a&i'n= Confirmaci$n por examen & a tra3és de la aportaci$n de e3idencia obeti3a que se >an satisfe&>o los re-uisitos es%e&ifi&ados. ▪

▪

8alidaci$n

◦

¿)stamos constru&endo el sistema correctamente?

Jalida&i'n= Confirmaci$n por examen & a tra3és de la aportaci$n de e3idencia obeti3a que >an sido satisfe&>os los re-uisitos %ara un uso o a%li&a&i'n %revistos. ▪

▪

1"

Iuscar defectos en el sistema% basándose en los entreables de las fases% comprobando que >eos se+uido el %ro&eso &orre&taente.

Iuscar defectos en el sistema% basándose en los entreables de las fases% comprobando que el sistea tiene &alidad desde la %ers%e&tiva del &liente . ¿)stamos constru&endo el sistema correcto?

2.!.! odelo J (odelo de desarrollo se&uen&ial) (62)



*e basa en cuatro ni3eles de pruebas correspondientes a los cuatro ni3eles de desarrollo= !. Pruebas de componente;unitarias. 2. Pruebas de interaci$n. 7. Pruebas de sistema. ". Pruebas de aceptaci$n.



Base de %rue*as de un nivel (o varios niveles) de %rue*as=  productos de trabao de software que se elaboran en la fase de desarrollo (casos de uso% especificaciones requeridas% documentos de dise/o% c$dio fuente% N. >eferencias a productos de trabao enéricos= Capabilit& 7aturit& 7odel 0nteration (C770 o norma de SProcesos del ciclo de 3ida del softwareS (0)));0)C 1!!2+. o

1'

:i3eles C770= !. Ini&ial= pro&ectos impre3isibles% controlados incorrectamente% reacti3os. 2. Gestionado= Procesos establecidos a ni3el de pro&ecto pero a menudo reacti3amente. 7. 1efinido= Procesos establecidos a tra3és de la oraniaci$n & por lo eneral proacti3amente. ". Gestionado &uantitativaente= 4os procesos son medidos & controlados en el ni3el de la oraniaci$n. :. ;%tiia&i'n= )nfoque en la meora continua% eneralmente diriido por datos. *ecciones 0)));0)C 1!!2+= !. Al&an&e 2. eferen&ias norativas 7. 1efini&iones ". A%li&a&i'n del est,ndar a los %ro&esos del &i&lo de vida% inclu&endo su adaptaci$n & auste a la oraniaci$n. :. Los %ro&esos %rin&i%ales del &i&lo de vida  para la adquisici$n% el suministro% el desarrollo% la operaci$n & el mantenimiento. ?. Los %ro&esos de a%o9o (publicaciones técnicas% esti$n de la confiuraci$n% el aseuramiento de la calidad% la 3erificaci$n & 3alidaci$n% las auditor6as & la resoluci$n de problemas. @. Los %ro&esos del &i&lo de vida or+ania&ional como la esti$n% la infraestructura% el meoramiento & la capacitaci$n. 4a verifi&a&i'n 9 valida&i'n (& el dise/o temprano de pruebas pueden realiarse durante el desarrollo de los productos de trabao de software. o











o

   









2.!.2 odelo de desarrollo iterativo#in&reental (62) 

1esarrollo iterativo#in&reental= proceso de establecer requisitos% dise/ar% establecer & probar un sistema% realiado como una serie de ciclos de desarrollo más cortos (iteraciones que producen incrementos. )emplos= Prototipado% >apid pplication Ge3elopment (>G% >ational Enified Process (>EP & modelos de desarrollo áil. E


o o

 

2.!.7 Prue*as en un odelo de Ci&lo de Jida (62) Buenas %r,&ti&as en %rue*as (independientemente del modelo de ciclo de 3ida= !. Para cada acti3idad de desarrollo existe una acti3idad de prueba asociada. 2. Cada ni3el de prueba tiene obeti3os de prueba espec6ficos para dico ni3el. 7. 4os procesos de análisis & dise/o de las pruebas para un ni3el de prueba dado deben iniciarse durante la acti3idad de desarrollo correspondiente. ". 4os probadores deben iniciar su participaci$n en la re3isi$n de los documentos en cuanto a&a borradores disponibles en el ciclo de 3ida de desarrollo. :. 4os ni3eles de pruebas pueden combinarse o reoraniarse (¿quién ace cada prueba? en funci$n de la naturalea del pro&ecto o de la arquitectura del sistema. 

2.2 Niveles de %rue*a (62) Pruebas operacionales;operati

15

Prue"as dirigidas a evaluar a un componente o sistema en su entorno de operaciones.

3as Pruebas alfa

Prue"as simuladas u operacionales realizadas por usuarios/clientes potenciales o por un equipo de prue"as independiente en las dependencias de desarrollo, pero fuera de la organización de desarrollo. as prue"as alfa son utilizadas con frecuencia para softare de distri"ución masiva como una forma de prue"as de aceptación internas.

Pruebas beta;Pruebas de campo Prue"as operacionales realizadas por usuarios/clientes potenciales y/o existentes, en un sitio externo no relacionado de ninguna manera con los desarrolladores, para determinar si un componente o sistema satisface o no las necesidades del usuario/cliente y se ajusta a los procesos de negocio. !on frecuencia las prue"as "eta se emplean como una forma de prue"a de aceptación externa para softare de distri"ución masiva con el o"jetivo de o"tener la respuesta del mercado.

Pruebas de componente;unitarias Controlador (Gri3er  L*tubM 

!omponente softare o *erramienta de prue"as que susti tuye a un componente que asume el control y/o la invocación a un componente o sistema.

2mplantación estructural 0esqueleto1 o de propósito especial de un componente softare, usado para desarrollar o pro"ar un componente que es dependiente de (l de alg+n modo. Sustituye a un componente llamado.

rnés de pruebas

%ntorno de prue"as constituido por stu"s y controladores necesarios para ll evar a ca"o una prue"a.

>equisito funcional

)equisito que especifica una función que un componente o sistema de"e cumplir.

0nteraci$n Pruebas interaci$n

Prue"as de componentes softare individuales.

Proceso de com"inar componentes o sistemas en estructuras m$s amplias.

de

>equisito no funcional Pruebas de robuste

Prue"as realizadas con el o"jeto de poner en evidencia defectos en l as interfaces e interacciones entre componentes o sistemas integrados. 6(ase tam"i(n prue"as de integración de componente, prue"as de integración de sistema.

Prue"as de atri"utos de un componente o sistema que no se refieren a la f uncionalidad, por ejemplo fia"ilidad, eficiencia, usa"ilidad, manteni"ilidad y porta"ilidad.

Prue"as para determinar la ro"ustez de un producto softare. )o"ustez' rado en el cual un componente o sistema puede funcionar correctamente en presencia de entradas no v$lidas o condiciones de entorno de estr(s. 6(ase tam"i(n tolerancia al error, tolerancia a faltas. -olerancia al error' !apacidad de un sistema o componente para continuar su operación normal a pesar de la presencia de entradas erróneas. -olerancia a faltas' !apacidad del producto softare para mantener un nivel especificado de rendimiento en caso de producirse faltas 0defectos1 en el softare o i nfracción de su interfaz especificada. 6(ase tam"i(n fia"ilidad, ro"ustez.

#iabilidad

1

:a"ilidad de un producto softare para llevar a ca"o aquellas funciones requeridas en condiciones esta"lecidas para un per#odo de tiempo espec#fico, o para un n+mero

espec#fico de operaciones.

Pruebas de sistema )ntorno de pruebas :i3el de prueba

Gesarrollo uiado por pruebas (
Pruebas de aceptaci$n de usuario

*imulador

%l proceso de prue"as un sistema integrado para verificar que cumple l os requisitos especificados.

%ntorno que contiene *ardare, instrumentación, simuladores, *erramientas sofare y otros elementos de soporte necesarios para realizar una prue"a.

rupo de actividades que est$n organizadas y gestionadas de forma conjunta. 7n nivel de prue"a esta vinculado con las responsa"ilidades en un proyecto. %jemplos de niveles de prue"as son las prue"as de componente, prue"as de integración, prue"as de sistema y prue"as de aceptación.

5odalidad de desarrollo softare donde los casos de prue"a son desarrollados, y a menudo automatizados, antes de que el softare sea desarrollado para ejecutar esos casos de prue"a.

Prue"as formales con respecto a las necesidades de usuario, requisitos y procesos de negocio dirigidas a determinar si el sistema satisfac e o no los criterios de aceptación y a *a"ilitar al usuario, cliente u otra entidad autorizada a determinar si ac epta o no el sistema.

ispositivo, programa o sistema usado durante las prue"as, que se comporta u opera como un sistema dado cuando se le proporciona un conjunto de entradas controladas.

Ante&edentes



Cara&tersti&as de un nivel de %rue*as= ;*erraientas Enfo-ues es%e&fi&os 9 res%onsa*ilidades. o o

o o o o

2.2.! Prue*as de &o%onenteKunitarias (62) 

;*equisitos de componentes. Gise/o del software. 7odelo de datos. C$dio. ;*


o o o o



o o o o



o o o

1+



e-uisitos de arn3s de %rue*as 9 so%orte de >erraientas= >erraientas = cceso al c$dio obeti3o de las pruebas. *opo *oport rtee de un ento entorn rno o de desa desarr rrol ollo lo (mar (marco co de prue prueba bass de unida unidad% d% erramienta de depuraci$n. Enfo-ues es%e&fi&os 9 res%onsa*ilidades= res%onsa*ilidades= Participaci$n del proramador que escribi$ el c$dio. 4os defectos se corrien en el momento en que se detectan% sin estionarlos formalmente. 1esarrollo +uiado %or las %rue*as (Test 1riven 1evelo%ent  T11)= T11) = Primero se elaboran & automatian los casos de prueba & después se desarrolla el c$dio obeto de las pruebas. )nfoque altamente iterati3o= !. Ciclos de desarrollo de casos de prueba. 2. Construir e interar peque/as partes del c$dio. 7. )ecutar las pruebas de componente. ". Corre Correir ir proble problemas mas e itera iterarr asta asta que se supere superen n todos los casos de prueba. o o



o o

o





2.2.2 Prue*as de inte+ra&i'n (62) 



;*


o o o o



o

o

o

o



o

o o o o

o

o

o



1,

2.2.7 Prue*as de sistea (62) 



;*


o o



Pruebas basadas en= >iesos &;o especificaciones de requisitos. Procesos de neocio. Casos de uso. Atr Atras des descrip cripci cio ones nes tex textual tuales es de alt alto ni3 ni3el o model odelos os de comportamiento de sistema. Pruebas funcionales ; no funcionales (para cubrir los requisitos de cada tipo. Pruebas funcionales= <écn <écnic icas as basa basada dass en la espe especi cifi fica caci ci$n $n (ca (caaa ner nera a== Etili Etiliaci aci$n $n de tablas tablas de decisi decisi$n $n (combi (combinac nacion iones es de los efectos descritos en las normas de neocio. <écn <écnic icas as basa basada dass en la estr estruc uctu tura ra (ca (caaa blan blanca ca= = )3al )3alua uaci ci$n $n de la exausti3idad de las pruebas por lo que respecta a un elemento estructural (por eemplo% una estructura de men o la na3eaci$n de una páina Jeb. Enfo-ues es%e&fi&os 9 res%onsa*ilidades= res%onsa*ilidades= )l entorno de pruebas debe coincidir en la máxima medida posible con el obeti3o final o con el entorno de producci$n (se busca minimiar el rieso de no identificar fallos espec6ficos del entorno durante las pruebas. Proble Problema= ma= 4os probad probadore oress se enfren enfrentan tan a requis requisito itoss incom incomple pletos tos o no documentados.  menud menudo o las las prue prueba bass de sist sistem emaa las las real reali iaa un equi equipo po de prue prueba bass independiente. o

   

o





o



o

o

o

2.2." Prue*as de a&e%ta&i'n (62) 

;*equisitos del usuario. >equisitos del sistema. Casos de uso. Procesos de neocio. 0nformes de análisis de riesos. r iesos. ;*




o o o o o



o o o o

1-

0nformes. Gatos de confiuraci$n. Ti%os de %rue*as= %rue*as= 4as pruebas de aceptaci$n pueden darse en distintos oentos del &i&lo de vida% vida% tales como= 1es%u3s de la instala&i'n o inte+ra&i'n  inte+ra&i'n   (por eemplo% en un producto de software comercial de distribuci$n masi3a 9 CA<*. 1urante 1urante las %rue*as %rue*as de &o%onen &o%onenteKun teKunitaria itariass (por eemplo% eemplo% pruebas de aceptaci$n de la usabilidad de un componente. Antes Antes de las %rue*a %rue*ass de siste sistea a (por (por eemp eemplo lo%% prueba pruebass de aceptaci$n de una nue3a meora funcional. 4as pruebas de aceptaci$n %ueden ado%tar8 entre otras8 las si+uientes foras= foras= Prue*as de a&e%ta&i'n de usuario= usuario = 8erifican la idoneidad del uso del sistema por parte de los usuarios comerciales. Prue*as o%erativas (de a&e%ta&i'n)= a&e%ta&i'n) = 4a aceptaci$n del sistema por por parte parte de los admini administr strado adores res del sistem sistema% a% entre entre las que se inclu&en= Pruebas de bac@up;restauraci$n. bac@up;restauraci$n. >ecuperaci$n >ecuperaci$n de desastres. Besti$n de usuarios.


o







o





     















Enfo-ues es%e&fi&os 9 res%onsa*ilidades= res%onsa*ilidades= 4as pruebas de aceptaci$n son a menudo responsabilidad de los clientes o usuarios de un sistema% a pesar de que también pueden participar otras partes interesadas. o

!2

2.7 Ti%os de %rue*a (62) Pruebas de caa nera

Prue"as tanto funcionales como no funcionales, sin referencia a la estructura interna del componente o sistema.

Cobertura de c$dio

5(todo de an$lisis que determina qu( partes del softare *an sido ejecutadas 0cu"iertas1 por el juego de prue"as y qu( partes no *an sido ejecutadas, ejemplo co"ertura de sentencia, co"ertura de decisión o co"ertura de condición.

Pruebas funcionales Pruebas interoperabilidad

Prue"as "asadas en el an$lisis de las especificaciones funcionales de un componente o de un sistema

de

Proceso de prue"as con el o"jeto de determinar la interopera"ilidad de un producto softare. 6(ase tam"i(n prue"as de funcionalidad.

Pruebas de cara

Pruebas mantenibilidad

-ipo de prue"a relacionado con medida del comportamiento de un componente o sistema con una carga creciente, por ejemplo el n+mero de usuarios concurrentes y/o n+mero de transacciones para determinar qu( carga puede ser soportada por el componente o sistema. 6(ase tam"i(n prue"as de estr(s.

de

Proceso de prue"as para determinar el grado de manteni"ilidad de un producto softare. 5anteni"ilidad' Facilidad con la que un producto softare puede ser modificado para corregir defectos, cumplir con nuevos requisitos, *acer m$s sencillo el mantenimiento futuro o ser adaptado a un entorno modificado.

Pruebas de rendimiento Pruebas de eficiencia

Proceso de prue"as para determinar el rendimiento de un producto softare. 6(ase tam"i(n prue"as de eficiencia

Proceso de prue"a para determinar la eficiencia de un producto de softare. %ficiencia' !apacidad del producto softare para proporcionar un rendimiento apropiado, relativo a la cantidad de recursos usados "ajo condiciones esta"lecidas.

Pruebas de portabilidad

Proceso de prue"as para determinar la porta"ilidad de un producto softare. Porta"ilidad' Facilidad con la que un producto softare puede ser transferido de un entorno *ardare o softare a otro.

Pruebas de fiabilidad

Proceso de prue"as para determinar la fia"ilidad de un producto softare.

#iabilidad= :a"ilidad de un producto softare para llevar a ca"o aquellas funciones requeridas en condiciones esta"lecidas para un per#odo de tiempo espec#fico, o para un n+mero espec#fico de operaciones.

Pruebas de seuridad

Prue"as para determinar la seguridad 0efectos adversos1 de un producto softare. Seguridad'  &tri"utos de productos softare que se refieren a su capacidad para prevenir accesos no autorizados, sean accidentales o deli"erados, a programas y datos.

!1

Pruebas de estrés Pruebas de usabilidad

Prue"as orientadas a evaluar un componente o sistema en o m$s all$ de los l#mites especificados en los requisitos.

Prue"as para determinar en qu( medida el producto softare es comprensi"le, f$cil de aprender, f$cil de operar y atractivo a los usuarios "ajo condiciones especificadas.

Esabilidad= !apacidad del softare para ser comprendido, aprendido, utilizado y atractivo al usuario cuando es utilizado "ajo condiciones especificadas.

Pruebas de caa blanca ; estructurales ; basadas en la estructura

!!

Prue"as "asadas en un an$lisis de la estructura i nterna del componente o sistema.

Ante&edentes En tipo de prueba se centra en un obeti3o de prueba= •

Ena funci$n a realiar por el software.

•

Ena caracter6stica de calidad no funcional (fiabilidad% usabilidad% ....

•

4a estructura o arquitectura del software o sistema.

•

Confirmar que se an solucionado los defectos (pruebas de confirmaci$n.

•

4ocaliar cambios no intencionados (pruebas de reresi$n.

2.7.! Prue*as de fun&iones (Prue*as fun&ionales) (62) #unciones T 4o que ace el sistema. Pruebas funcionales= •

•

•

•

•

•

*e basan en funciones o prestaciones & en su interoperabilidad con sistemas espec6ficos. 4as funciones (de un sistema% subsistema o componente se describen en productos de trabao= ◦

)specificaci$n de requisitos.

◦

Casos de uso.

◦

)specificaci$n funcional.

◦

A no estar documentadas (experiencia.

Pueden lle3arse a cabo en todos los ni3eles de prueba (por eemplo% pruebas de componente basadas en una especificaci$n de componente. <écnicas basadas en la especificaci$n= obtener condiciones de prueba & casos de prueba a partir de la funcionalidad de un software o sistema. 4as pruebas funcionales tienen en cuenta el comportamiento externo del software (pruebas de caa nera. )emplos= ◦

◦

Pruebas de seuridad de un cortafueos (funciones asociadas a la detecci$n de amenaas procedentes de personas aenas & malintencionadas. Pruebas de interoperabilidad (e3alan la capacidad del producto de software de interactuar con uno o más componentes o sistemas especificados.

2.7.2 Prue*as de &ara&tersti&as no fun&ionales del soft/are (Prue*as no fun&ionales) (62) Pruebas no funcionales T C$mo funciona el sistema (medida de caracter6sticas de los sistemas & software que pueden cuantificarse sen una escala 3ariableR por eemplo=
!"

0nclu&en (entre otras= ◦

Pruebas de rendimiento.

◦

Pruebas de cara.

◦

Pruebas de estrés.

•

•

•

◦

Pruebas de usabilidad.

◦

Pruebas de mantenibilidad.

◦

Pruebas de fiabilidad.

◦

Pruebas de portabilidad.

Pueden eecutarse a todos los ni3eles de prueba. Pueden acer referencia a un modelo de calidad (por eemplo% calidad de producto sen 0*A -1! ; 0*A !5222.
2.7.7 Prue*as de estru&turaKar-uite&tura de soft/are (Prue*as estru&turales) (62) Pruebas estructurales (caa blanca pueden realiarse en todos los ni3eles de prueba. •

•

Permiten medir la exausti3idad de las pruebas mediante una e3aluaci$n de la cobertura de un tipo de estructura. ◦

◦

◦

•

Cobertura= medida en que un ueo de pruebas a probado una estructura% expresada como porcentae de los elementos cubiertos. *i la cobertura no es del 122U podrán dise/arse más pruebas para probar los elementos que faltan para aumentar la cobertura. )n todos los ni3eles de prueba (especialmente en pruebas de componente e interaci$n de componentes= Da& erramientas para medir la cobertura de c$dio (como sentencias o decisiones.

Pueden basarse en la arquitectura del sistema (por eemplo% una erarqu6a de llamadas.
2.7." Prue*as aso&iadas a &a*ios= e%eti&i'n de %rue*as 9 %rue*as de re+resi'n (62) •

Pruebas de confirmaci$n= Ena 3e detectado & correido un defecto% el software debe 3ol3er a probarse para confirmar que el defecto oriinal a sido correido con éxito. ◦

•

Pruebas de reresi$n= prueba reiterada de un prorama &a probado% después de aber sido modificado (el software o su entorno% con 3istas a localiar defectos suridos o no descubiertos como resultado del cambio. ◦

◦

◦

•

)stos defectos pueden estar en el software obeto de las pruebas% o en cualquier otro componente de software asociado o no asociado al cambio. )l alcance de las pruebas de reresi$n depende del rieso de encontrar defectos en el software que antes funcionaba. Pueden realiarse en todos los ni3eles de prueba (inclu&endo pruebas funcionales% no funcionales & estructurales.

Pruebas de confirmaci$n;reresi$n= deben ser repetibles. ◦

!'

4a depuraci$n es una acti3idad de desarrollo% no una acti3idad de pruebas.

*obre todo las de reresi$n= se eecutan mucas 3eces & en eneral suelen e3olucionar lentamente. *on candidatas a automatiarse.

2." Prue*as de anteniiento (62) nálisis de impacto

Pruebas de mantenimiento

•

•

)ntre las modificaciones se inclu&en= ◦

7odificaciones de meora planificadas.

◦

7odificaciones correcti3as & de emerencia.

◦

7odificaciones de entorno. ▪

ctualiaciones pre3istas de sistema operati3o o base de datos.

▪

ctualiaciones pre3istas de software comercial de distribuci$n masi3a.

•

•

•

•

4as pruebas de mantenimiento inclu&en= ◦

Probar lo que se a modificado.

◦

Probar otras partes del sistema (pruebas de reresi$n.

)l alcance de las pruebas 3ariará en funci$n de= ◦

)l rieso de la modificaci$n.

◦

)l tama/o del sistema existente.

◦

4as dimensiones de la modificaci$n.

Gependiendo de las modificaciones las pruebas podrán realiarse en= ◦


◦


nálisis de impacto=

◦

Geterminaci$n de c$mo el sistema existente podrá 3erse afectado por las modificaciones. *ir3e para a&udar a decidir cuántas pruebas de reresi$n son necesarias.

*ituaciones problemáticas para eecutar pruebas de mantenimiento= ◦

!5

4as pruebas de miraci$n (pruebas de con3ersi$n también son necesarias cuando se pre3é mirar datos de otra aplicaci$n al sistema obeto del mantenimiento.

4as pruebas de mantenimiento para la retirada de un sistema pueden incluir pruebas de miraci$n de datos o arci3o si se requieren laros periodos de retenci$n de datos.

◦

•

Parces para correir 3ulnerabilidades recientemente descubiertas en el sistema operati3o.

4as pruebas de mantenimiento en los casos de miraci$n deben incluir pruebas operati3as tanto del nue3o entorno como del software modificado. ◦

•

Prue"as de los cam"ios en un sistema en operación o el impacto de un entorno modificado para un sistema en operación.

*e realian en un sistema en operaci$n & se acti3an a partir de modificaciones% casos de miraci$n o la retirada del software o sistema.

▪

•

6aloración del cam"io en las capas de documentación de desarrollo, documentación de prue"as y componentes, con el o"jeto de implementar un cam"io dado en requisitos especificados.

:o se disponen de especificaciones o están desactualiadas.

◦

!

:o a& probadores con conocimiento de dominio disponibles.

7. T3&ni&as est,ti&as (62) 7.! Las t3&ni&as est,ti&as 9 el %ro&eso de %rue*as (62) Pruebas dinámicas Pruebas estáticas

Prue"as que implican la ejecución del softare de un componente o sistema.

Prue"as de un componente o sistema a nivel de especificación o implementación sin ejecutar el softare, por ejemplo revisiones o an$lisis est$tico de código.

Ante&edentes Pruebas dinámicas= exien la eecuci$n del software. Pruebas estáticas= no eecutan el c$dio. *e basan en el examen manual (re3isiones & el análisis automatiado (análisis estático del c$dio o de cualquier otra documentaci$n del pro&ecto. >e3isiones= •

7anuales o utiliando erramientas de soporte.

•

Principal acti3idad manual= examinar un producto de trabao & acer comentarios.

•

•

Cualquier producto de trabao puede ser obeto de una re3isi$n= especificaciones de requisitos% especificaciones de dise/o% el c$dio% los planes de prueba% las especificaciones de pruebas% los casos de pruebas% los uiones de prueba% las u6as de usuario o las páinas Jeb. Ieneficios de las re3isiones= ◦

Getecci$n & correcci$n temprana de defectos (por eemplo% en la re3isi$n de requisitos.

◦

Gesarrollo de meoras de producti3idad.

◦

>educci$n de los tiempos de desarrollo.

◦

orro de tiempo & dinero in3ertido en pruebas.

◦

N

4as re3isiones% el análisis estático & las pruebas dinámicas tienen el mismo obeti3o= identificar defectos. •

•

*on procesos complementarios= las distintas técnicas pueden encontrar distintos tipos de defectos de manera eficiente & efecti3a. 4as pruebas dinámicas detectan los fallos% mientras que las estáticas detectan sus causas (los defectos.

Gefectos t6picos que resultan fáciles de localiar en re3isiones (& en esto son más eficaces;eficientes que las pruebas dinámicas=

!+

•

Ges3iaciones de los estándares.

•

Gefectos de requisito.

•

Gefectos de dise/o.

•

7antenibilidad insuficiente.

•

)specificaciones de interfa incorrectas.

7.2 Pro&eso de revisi'n (62) Criterios de entrada

>e3isi$n formal >e3isi$n informal 0nspecci$n

7étrica

!onjunto de condiciones gen(ricas y espec#ficas para permitir que un proceso prosiga con una tarea definida, por ejemplo la fase de prue"as. %l o"jetivo de los criterios de entrada es evitar que una tarea comience, lo cual conllevar#a un mayor esfuerzo que el necesario para eliminar los criterios de entrada fallidos.

)evisión caracterizada por procedimientos y requisitos documentados, por ejemplo la inspección.

)evisión que no est$ "asada en un procedimiento formal 0documentado1.

-ipo de revisión entre pares que se "asa en el examen visual de documentos para detectar defectos, por ejemplo violaciones de est$ndares de desarrollo y no conformidades a la documentación de nivel superior. %s la t(cnica de revisión m$s formal y, por lo tanto, si empre "asada en un procedimiento documentado. 6(ase tam"i(n revisión entre pares.

%scala de medida y el m(todo utilizado para la medición.

7oderador >e3isi$n entre pares (peer re3iew

>e3isor

#der y principal persona responsa"le de una inspección u otro proceso de revisión.

)evisión de un producto de tra"ajo softare por parte de compañeros de tra"ajo del desarrollador del producto con el o"jeto de identificar defectos y mejoras. %jemplos de este tipo de revisión son la inspección, revisión t(cnica y revisión guiada.

Persona involucrada en la revisión, responsa"le de la identificación y descripción de anomal#as en el producto o proyecto "ajo revisión. os revisores pueden ser seleccionados para representar diferentes puntos de vista y roles dentro del proceso de revisión.

)scriba

Persona que registra en un acta cada defecto mencionado y cualquier sugerencia para la mejora de un proceso durante una reunión de revisión. %l escri"a tiene que asegurarse que el acta sea legi"le y comprensi"le.

>e3isi$n técnica

 &ctividad de discusión de grupo de pares que se centra en alcanzar consenso respecto del enfoque t(cnico a adoptar. 6(ase tam"i(n revisión entre pares.

>e3isi$n uiada

Presentación paso a paso de un documento por parte del autor con el fin de recoger información y esta"lecer un entendimiento com+n de su contenido. 6(ase tam"i(n revisión entre pares.

Ante&edentes
•

0nformales (los re3isores carecen de instrucciones escritas. *istemáticas (inclu&en la participaci$n del equipo% se documentan los resultados & a& procedimientos documentados para realiarlas.

Brado de formalidad depende de= madure del proceso de desarrollo% requisitos leales;normati3os% necesidad de rastro de auditor6a. Posibles obeti3os=

!,

•

)ncontrar defectos.

•

#ormar probadores o nue3os desarrolladores.

•

Gebatir & decidir por consenso.

7.2.! A&tividades de una revisi'n foral (6!) !. Planificar= ◦

Gefinir los criterios de re3isi$n.

◦

*eleccionar al personal.

◦

sinar funciones.

◦

Gefinir los criterios de entrada & salida (en re3isiones formales.

◦

*eleccionar qué partes de los documentos deben re3isarse.

2. 0nicio= ◦

>epartir los documentos.

◦

)xplicar los obeti3os% procesos & documentos a los participantes.

7. Comprobar los criterios de entrada (en re3isiones formales. ". Preparaci$n indi3idual. ◦

Prepararse para la reuni$n de re3isi$n repasando los documentos.

◦

Prestar especial atenci$n a posibles defectos% preuntas & comentarios.

:. )xamen;e3aluaci$n;reistro de los resultados (reuni$n de re3isi$n= ◦

◦

◦

Gebatir o reistrar% mediante resultados documentados o actas (en re3isiones formales. Prestar especial atenci$n a los defectos% acer recomendaciones sobre c$mo manear los defectos% tomar decisiones al respecto. Gurante reuniones f6sicas o de seuimiento de los rupos.

?. Correir los defectos detectados (normalmente a caro del autor. ◦

>eistrar el estado actualiado de los defectos (en re3isiones formales.

@. Dacer un seuimiento. ◦

Comprobar que los defectos an sido tratados.

◦

>ecopilar métricas.

. Comprobar los criterios de salida (en re3isiones formales. 7.2.2 Fun&iones 9 res%onsa*ilidades (6!) Fun&iones de una revisi'n foral= !. Mefe= ◦

Gecide sobre la eecuci$n de las re3isiones.

◦

sina el tiempo en los calendarios del pro&ecto.

◦

Getermina si se an lorado los obeti3os de la re3isi$n.

2. oderador=

!-

◦

◦

4idera la re3isi$n del documento o serie de documentos (inclu&endo planificaci$n de la re3isi$n% celebraci$n de la reuni$n & seuimiento después de la reuni$n. 7edia entre los distintos puntos de 3ista.

7. Autor= ◦

)scritor o persona con máxima responsabilidad de los documentos a re3isar.

". evisores (evaluadoresKins%e&tores)= ◦

◦

Personas con experiencia espec6fica en el ámbito técnico o comercial. (Ena 3e preparados para ello 0dentifican & describen las conclusiones (por eemplo% los defectos sobre el producto obeto de la re3isi$n.

:. Es&ri*a (o re+istrador)= ◦

Gocumenta todos los problemas% asuntos% temas abiertos que se an identificado durante la reuni$n.

Vtil para meora de efecti3idad;eficiencia re3isiones= Etiliar listas de comprobaci$n basada en distintas perspecti3as (usuario% mantenedor% probador% operaciones o que inclu&a los problemas t6picos (por eemplo% en la definici$n de requisitos. 7.2.7 Ti%os de revisiones (62) (En nico producto de software o producto de trabao asociado puede ser obeto de 3arias re3isiones. (4as re3isiones uiadas% las re3isiones técnicas & las inspecciones pueden lle3arse a cabo dentro de un mismo rupo de pares% es decir% entre coleas de un mismo ni3el oraniati3o. )ste tipo de re3isiones recibe el nombre de Lre3isi$n entre paresM.  continuaci$n se listan las principales caracter6sticas de cada tipo de re3isi$n= evisi'n inforal •

•

usencia de un proceso formal. Puede adoptar la forma de proramaci$n por pares o una re3isi$n por parte de un l6der técnico de los dise/os & el c$dio.

•

4os resultados pueden estar o no documentados.

•

*u utilidad 3ar6a en funci$n de los re3isores.

•

Abeti3o principal= Abtener beneficios de forma barata.

evisi'n +uiada Presentación paso a paso de un documento por parte del autor con el fin de rec oger información y esta"lecer un entendimiento com+n de su contenido. 6(ase tam"i(n revisión entre pares.

•

Puede 3ariar desde bastante informal asta mu& formal.

•

euni'n liderada %or el autor.

•

Puede adoptar la forma de escenarios% simulacros o participaci$n de rupos de pares.

•

*esiones abiertas= ◦

◦

"2

Preparaci$n;Capacitaci$n opcional de re3isores pre3ia a la reuni$n. Preparaci$n opcional de un informe de re3isi$n en el que se inclu&a la lista de conclusiones.

•

)scriba opcional (distinto del autor.

•

Abeti3o principal= prender% encontrar defectos.

evisi'n t3&ni&a  &ctividad de discusión de grupo de pares que se centra en alcanzar consenso respecto del enfoque t(cnico a adoptar. 6(ase tam"i(n revisión entre pares.

•

•

Puede 3ariar desde bastante informal asta mu& formal. Proceso documentado & definido para la detecci$n de defectos que inclu&e la participaci$n de pares & expertos técnicos (opcionalmente también la direcci$n.

•

Idealente diri+ida %or un oderador forado (distinto del autor).

•

Preparaci$n pre3ia a la reuni$n por parte de los re3isores.

•

Eso opcional de lista de comprobaci$n.

•

)laboraci$n de un informe de re3isi$n en el que se inclu&e=

•

◦

4ista de conclusiones.

◦

8eredicto de si el producto de software cumple los requisitos.

◦

>ecomendaciones.

Abeti3os principales= debatir% tomar decisiones% e3aluar alternati3as% encontrar defectos% resol3er problemas técnicos% comprobar la conformidad con las especificaciones;planes;normati3as;estándares.

Ins%e&&i'n -ipo de revisión entre pares que se "asa en el examen visual de documentos para detectar defectos, por ejemplo violaciones de est$ndares de desarrollo y no conformidades a la documentación de nivel superior. %s la t(cnica de revisión m$s formal y, por lo tanto, siempre "asada en un procedimiento documentado. 6(ase tam"i(n revisión entre pares.

•

Pro&eso foral. #unciones definidas.

•

Giriida por un moderador formado (distinto del autor.

•

Beneralmente celebrada como un examen entre pares.

•

0nclu&e una recopilaci$n de métricas.

•

*e basa en normas & listas de comprobaci$n.

•

Criterios de entrada & salida especificados para la aceptaci$n del producto de software.

•

Preparaci$n pre3ia a la reuni$n.

•

0nforme de inspecci$n en el que se inclu&e una lista de las conclusiones

•

Proceso de seuimiento formal (con proceso de meora de componentes opcional.

•

4ector opcional.

•

Abeti3o principal= 0dentificar defectos.

7.2." Fa&tores de 35ito de las revisiones (62)
•

*e cuenta con la participaci$n de las personas adecuadas. ◦

•

"1

4os probadores constitu&en re3isores 3aliosos que contribu&en a la re3isi$n & aprenden sobre el producto% lo que les permitirá preparar pruebas en una fase más temprana.

4os defectos detectados son bien3enidos & se expresan de manera obeti3a.

•

•

•

•

•

•

•

*e afrontan los problemas de personal & los aspectos psicol$icos (por eemplo% aciendo que sea una experiencia positi3a para el autor. 4a re3isi$n se lle3a a cabo en una atm$sfera de confiana (el resultado no se utiliará para e3aluar a los participantes. *e aplican las técnicas de re3isi$n adecuadas (para los obeti3os% tipo;ni3el de productos de trabao & los re3isores. *e utilian listas de comprobaci$n o funciones si procede para aumentar la efecti3idad del proceso de identificaci$n de defectos. *e ofrece formaci$n sobre técnicas de re3isi$n% especialmente por lo que respecta a las técnicas más formales como la inspecci$n. )xiste respaldo (asinaci$n de recursos;tiempo en el cronorama dedicado desde Girecci$n. *e ace incapié en el aprendiae & en la meora del proceso.

Nota so*re IEEE !2  Est,ndar -ue se a%li&a a las revisiones *ecciones= !. Gescripci$n eneral. 2. >eferencias. 7. Gefiniciones. 4.

Revisiones de gestión (no entra en el nivel básico de ISTQB).

:. evisiones t3&ni&as. ?. Ins%e&&iones. @. evisiones +uiadas. 8.

 Auditorías (no entra en el nivel básico de ISTQB).

7.7 An,lisis est,ti&o &on >erraientas (62) Compilador Compleidad

Compleidad ciclomática

:erramienta softare que traduce programas expresados en un lenguaje de alto nivel a su lenguaje m$quina equivalente.

rado en el cual un componente o sistema tiene un diseño y/o estructura interna que es dif#cil de comprender, mantener y verificar. 6(ase tam"i(n complejidad ciclom$tica.

0Seg+n 5c!a"e1 "#mero de caminos independientes en un programa  0; n+mero de prue"as "$sicas requeridas para cu"rir el grafo, en el cas o de prue"as de unidad para una función1. Se define la complejidad ciclom$tica como' % 4 < = >P, donde –

% ;n+mero de aristas/enlaces en un grafo 0secuencias de cero o m$s sentencias sin ramas1.

–

< ;n+mero de nodos en un grafo 0puntos de entrada, puntos de salida y decisiones1.

–

P ;n+mero de partes desconectadas del grafo 0por ejemplo un grafo invocado y una su"rutina1 ?
Por tanto, $ % & ' "  )  <ernativa' $ % *  + 0siendo ) el n+mero de regiones cerradas en el grafo1. 3tra alternativa' 0Partiendo de @1 =@ por cada if, for, *ile, do *ile, "loque case de sitc* 0else de los if no cuenta, "loque default de sitc* no cuenta1.

"!

!ada función en un programa, incluyendo la función principal, comienza con un contador de complejidad de @. !ontamos la complejidad función por función. !ada vez que *ay una rama o "ucle en una función, el contador de c omplejidad aumenta en uno. !$lculo de los caminos "$sicos/independientes ; se comienza con u n camino cualquiera a trav(s del diagrama. uego adicionando otro camino que cu"re el m#nimo n+mero de aristas no cu"iertas previamente, repitiendo este proceso *asta que todas las aristas *ayan sido cu"iertas por lo menos una vez. as prue"as "$sicas son las entradas y l os resultados esperados asociados con cada camino "$sico. 7sualmente las prue"as "$sicas coincidir$n con las prue"as necesarias para alcanzar co"ertura de rama 0decisión1. !o"ertura de rama 0decisión1 corresponde a la co"ertura de particiones de equivalencia.

#luo de control

Secuencia de eventos 0caminos1 en la ejecución a trav (s de un componente o sistema. r$fico de flujo de control' )epresentación a"stracta de todas las posi"les secuencias de eventos 0caminos1 en la ejecución a trav(s de un componente o sistema.

#luo de datos

)epresentación a"stracta de la secuencia y posi"les cam"ios de estado de los o"jetos de datos, donde el estado de un o"jeto puede ser cualquiera de los siguientes' creación, uso o destrucción.

nálisis estático

•

•

Abeti3o del análisis estático= Getectar defectos en el c$dio fuente del software & en los modelos de software. *e realia sin eecutar el software obeto de la re3isi$n (al contrario que en las pruebas dinámicas. ◦

4as erramientas de análisis estático analian el c$dio del prorama (p.e. el fluo de control & fluo de datos & las salidas eneradas (p.e. D<74 o F74.

•

(l iual que en las re3isiones )ncuentra defectos en luar de fallos.

•

)l 3alor del análisis estático es= ◦

4a detecci$n temprana de defectos antes de la eecuci$n de las pruebas. ▪

◦

◦

•

""

 &n$lisis de los artefactos softare, por ejemplo requisitos o código, llevado a ca"o sin la ejecución de estos artefactos softare.

Pre3enci$n de defectos% si se aprende la lecci$n en la fase de desarrollo.

d3ertencia temprana sobre aspectos sospecosos del c$dio o del dise/o mediante cálculo de métricas (p.e compleidad ciclomática. 0dentificaci$n de defectos que no se encuentran fácilmente mediante pruebas dinámicas.

◦

Getectar dependencias e inconsistencias en modelos de software (p.e. )nlaces.

◦

7antenibilidad meorada del c$dio & del dise/o.

Gefectos abitualmente detectados por las erramientas de análisis estático= ◦

>eferenciar una 3ariable con un 3alor indefinido.

◦

0nterfaces inconsistentes entre m$dulos.

◦

8ariables que no se utilian o que se declaran de forma incorrecta.

◦

C$dio inaccesible (muerto.

•

◦

usencia de l$ica o l$ica err$nea (posibles bucles infinitos.

◦

Construcciones demasiado complicadas.

◦

0nfracciones de los estándares de proramaci$n.

◦

8ulnerabilidades de seuridad.

◦

0nfracciones de sintaxis del c$dio & modelos de software.

4as erramientas de análisis estático eneralmente las utilian= ◦

◦

•

"'

4os desarrolladores antes & durante las pruebas de componente e interaci$n% o durante la comprobaci$n del c$dio. 4os dise/adores durante la modelaci$n del software.

4as erramientas de análisis estático pueden producir un ran nmero de mensaes de ad3ertencia que deben ser estionados para permitir el uso efecti3o de la erramienta.

". T3&ni&as de diseo de %rue*as (6") ".! El %ro&eso de desarrollo de %rue*as (7) Caso de prueba

)specificaci$n de casos de prueba Abeti3o de prueba Abeto de prueba )lemento de prueba Condici$n de prueba

()specificaci$n de Gise/o de pruebas Calendario de eecuci$n de pruebas ()specificaci$n de procedimiento de pruebas Bui$n(script de prueba
!onjunto de valores de entrada, precondiciones de ejecución, resultados esperados y postcondiciones de ejecución, desarrollado con un o"jetivo en particular o condición de prue"a, tales como pro"ar un determinado camino de ejecución o para verificar el cumplimiento de un requisito determinado.

ocumento que especifica un conjunto de casos de prue"a para un elemento de prue"a.

)azón o propósito para el diseño y la ejecución de una prue"a.

!omponente o sistema a ser pro"ado. 6 (ase tam"i(n elemento de prue"a.

%lemento individual a ser pro"ado.
%lemento o evento de un componente o sistema que de"er#a ser verificado por uno o m$s casos de prue"a, por ejemplo una función, transacción, caracter#stica, atri"uto de calidad o elemento estructural.

ocumento que especifica las condiciones de prue"a 0elementos de co"ertura1 para el elemento de prue"a, el enfoque de prue"as de forma detallada e identifica los casos de prue"a de alto nivel asociados.

Planificación para la ejecución de procedimientos de prue"a. os procedimientos de prue"a est$n incluidos en el calendario de ejecución de prue"as en su contexto y en el orden en el cual de"en ser ejecutados.

ocumento que especifica la secuencia de acciones para la ejecución de una prue"a. -am"i(n conocido como script de prue"a o script de prue"a manual.

!om+nmente usado para referirse a una especificación de procedimiento de prue"a, especialmente una automatizada.

!apacidad de identificar elementos relacionados en la documentación y el softare, tales como requisitos con las prue"as asociadas. 6(ase tam"i(n traza"ilidad *orizontal y traza"ilidad vertical. -raza"ilidad *orizontal' -razas de requisitos para un nivel de prue"as a trav(s de las capas de la documentación de prue"as 0por ejemplo, plan de prue"as, especificación de diseño de prue"a, especificación de caso de prue"a y especificación de procedimiento de prue"a o script de prue"as1. -raza"ilidad vertical' -razado de requisitos a trav(s de las capas de la documentación de desarrollo *asta los componentes.

"5

•

Puede 3ariar= desde mu& informal (con poca o ninuna documentaci$n a mu& formal (que se trata en este cap6tulo. ◦

•

:i3el de formalidad depende de= madure de pruebas & proceso de desarrollo% limitaciones de tiempo% requisitos de seuridad;normati3as% personas implicadas.

nálisis de pruebas= ◦

◦

◦

*e analia la documentaci$n básica de las pruebas para determinar las condiciones de prueba. Condici$n de prueba= )lemento o e3ento que deber6a ser 3erificado por uno o más casos de prueba (p.e. Ena funci$n% transacci$n% atributo de calidad o elemento estructural.
▪

◦

•

Permite obtener un análisis de impacto efecti3o cuando los requisitos cambian. Permite determinar la cobertura de requisitos para una serie de pruebas.

)l análisis de pruebas permite seleccionar las técnicas de dise/o de pruebas a utiliar en funci$n (entre otros factores de los riesos identificados.

Gise/o de pruebas= ◦

*e crean los casos de prueba & los datos de prueba.

◦

Caso de prueba. ◦

◦

Abeto= Cubrir uno o 3arios obeti3os de prueba o poscondiciones de prueba. Consta de= ▪

8alores de entrada.

▪

Precondiciones de eecuci$n.

▪

▪

◦

▪

Contenido de las especificaciones de dise/o de pruebas (inclu&endo condiciones de prueba. )specificaciones de los casos de prueba.

)ecuci$n de la prueba= ◦

◦

◦

*e desarrollan% implementan% priorian & oranian los casos de prueba para especificar el procedimiento de prueba. Procedimiento de prueba= )specifica la secuencia de acciones necesarias para eecutar una prueba (si se utilia una erramienta de eecuci$n de pruebas la secuencia de acciones se especifica en un ui$n de prueba T procedimiento de prueba automatiado. 4os distintos procedimientos de prueba (inclu&endo automatiados conforman un calendario de eecuci$n de pruebas que establece el orden en el que deben eecutarse los distintos procedimientos de prueba. ▪

"

Poscondiciones de eecuci$n.

4a L:orma para la documentaci$n de pruebas de softwareM (0))) ,!- describe= ▪

•

>esultados esperados (3alores de salida% modificaciones a los datos% .... Para no interpretar como correcto un resultado plausible pero err$neo.

)ste calendario de eecuci$n de pruebas tendrá en cuenta factores como= pruebas de reresi$n% prioriaci$n & dependencias técnicas & l$icas.

IEEE 2$ # Nora %ara la do&uenta&i'n de %rue*a de soft/are *ecciones plantilla de es%e&ifi&a&i'n de diseo de %rue*as= •

Identifi&ador de la especificaci$n del dise/o de pruebas.

•

Cara&tersti&as -ue de*en ser %ro*adas (mediante este ueo de pruebas.

•

efinaientos del 3todo (técnicas espec6ficas% erramientas% etc..

•

•

Identifi&a&i'n de las %rue*as (traabilidad de los casos de prueba en el ueo de pruebas. Criterios de %asoKfalla de las &ara&tersti&as (p.e% oráculo de pruebas% base de pruebas% sistemas eredados% etc..

*ecciones plantilla de es%e&ifi&a&i'n de &aso de %rue*a= •

Identifi&ador de la especificaci$n del caso de prueba.

•

0tesKEleentos de %rue*as (lo que tiene que ser entreado & probado.

•

Es%e&ifi&a&iones de las entradas (entradas del usuario% arci3os% etc..

•

•

•

•

Es%e&ifi&a&iones de las salidas (resultados esperados% inclu&endo pantallas % arci3os% tiempo% etc.. Ne&esidades del entorno (ardware% software% personas% accesorios% N. e-uisitos es%e&iales de %ro&ediiento (inter3enci$n del operador% permisos% N. 1e%enden&ias entre &asos (si es necesario para establecer condiciones pre3ias.

*ecciones plantilla de es%e&ifi&a&i'n de %ro&ediiento de %rue*a= •

Identifi&ador de la especificaci$n del procedimiento de prueba.

•

Pro%'sito.

•

e-uisitos es%e&iales (abilidades% permisos% entorno% etc..

•

Pasos del %ro&ediiento.

".2 Cate+oras de t3&ni&as de diseo de %rue*as (62) <écnica de dise/o de pruebas <écnica de dise/o de pruebas de caa blanca <écnica de dise/o de pruebas de caa nera <écnica de dise/o de pruebas basadas en la experiencia

Procedimiento utilizado para o"tener y/o seleccionar casos de prue"a.

Procedimiento para o"tener y/o seleccionar casos de prue"a "asados en un an$lisis de la estructura interna del componente o sistema.

Procedimiento para o"tener y/o seleccionar casos de prue"a "asados en el an$lisis de la especificación, tanto funcional como no funcional de un componente o sistema sin referencia a su estructura interna.

Procedimiento para derivar y/o seleccionar casos de prue"a "asados en l a experiencia, conocimiento e intuición del pro"ador.

;*
"+

Clasificaci$n (tradicional= •

<écnicas de pruebas de caa nera (basadas en la especificaci$n= ◦

◦

•

0nclu&e= Pruebas funcionales & no funcionales.

<écnicas de pruebas de caa blanca (basadas en la estructura o estructurales= ◦

•

Iasadas en un análisis de la documentaci$n básica de la prueba (no utilian ninuna informaci$n sobre la estructura interna del componente o sistema a probar.

*e basan en el análisis de la estructura del componente o sistema.

<écnicas de pruebas basadas en la experiencia. ◦

4as pruebas de caa nera;blanca también pueden basarse en la experiencia de los desarrolladores% probadores & usuarios para determinar el obeto de las pruebas.

lunas técnicas pertenecen claramente a una nica cateor6a% otras tienen elementos de 3arias cateor6as. Cara&tersti&as &ounes de las t3&ni&as de diseo de %rue*as de &a
•

)l problema a solucionar% el software o sus componentes se especifican a partir de modelos% tanto formales como informales. 4os casos de prueba pueden obtenerse sistemáticamente a partir de estos modelos.

Cara&tersti&as &ounes de las t3&ni&as de diseo de %rue*as de &a
•

0nformaci$n sobre c$mo debe utiliarse el software construido para obtener los casos de prueba (por eemplo% c$dio e informaci$n de dise/o detallada. Puede medirse el alcance de la cobertura del software para los casos de prueba existentes% & puede obtenerse otros casos de prueba de manera sistemática para aumentar la cobertura.

Cara&tersti&as &ounes de las t3&ni&as de diseo de %rue*as *asadas en la e5%erien&ia= •

•

•

*e emplea el conocimiento & la experiencia de las personas para obtener los casos de prueba. )l conocimiento de los probadores% desarrolladores% usuarios & demás partes interesadas sobre el software% su uso & su entorno constitu&e una fuente de informaci$n. )l conocimiento sobre los defectos probables & su distribuci$n constitu&e otra fuente de informaci$n.

".7 T3&ni&as *asadas en la es%e&ifi&a&i'n o t3&ni&as de &a
•

•

",

4os 3alores de entrada del software o del sistema se di3iden en rupos que se espera demuestren un comportamiento similar% de manera que puedan ser procesados de la misma forma. 4as particiones de equi3alencia (o clases son aplicables a datos 3álidos e in3álidos.

•

•

•

4as particiones también pueden aplicarse a los 3alores de salida% 3alores internos% 3alores relati3os al tiempo (por eemplo% antes o después de un e3ento o a los parámetros de interfa (por eemplo% prueba de interaci$n entre componentes. 4a partici$n de equi3alencia es aplicable a todos los ni3eles de pruebas. 4a partici$n de equi3alencia puede utiliarse para lorar obeti3os de cobertura de entrada & salida.

7anera de proceder= !. 0dentificar entradas% salidas% comportamientos% entornos% confiuraciones... a probar. 2. *eparar los 3alores posibles de cada uno de ellos en clases de equi3alencia (que mostrarán un comportamiento similar. 7. Creaci$n de casos de prueba de opciones L3álidasM= •

•

*eleccionar una combinaci$n de clases de equi3alencia 3álidas (seleccionando un 3alor de cada una & definir el resultado esperado en esa situaci$n. >epetir el proceso asta que a&a seleccionado al menos un 3alor representati3o para cada partici$n de equi3alencia 3álida.

". Creaci$n de casos de prueba de opciones Lin3álidasM= •

•

*eleccionar un 3alor de una partici$n in3álida de equi3alencia. Para el resto de las particiones de equi3alencia seleccione un 3alor 3álido. Gefina el resultado esperado en esa situaci$n. >epetir el proceso asta que a&a seleccionado todas las particiones in3álidas.

".7.2 An,lisis de valores lite (67) -(cnica de diseño de prue"as de caja negra en la cual los casos de prue"a son diseñados "as$ndose en los valores l#mite. 6(ase tam"i(n valor l#mite. 6alor l#mite' 6alor de entrada o de salida que se encuentra en la frontera de una partición de equivalencia o a la m#nima distancia incremental a cualquier lado de la frontera, por ejemplo el valor m#nimo o m$ximo de un rango.

•

•

•

•

•

•

•

"-

)l comportamiento en el l6mite de cada partici$n de equi3alencia tiene más posibilidades de ser incorrecto que el comportamiento dentro de la partici$n (los l6mites constitu&en un área en el que las pruebas tenderán a incluir defectos. 4os 3alores máximos & m6nimos de una partici$n son sus 3alores l6mite. )l 3alor l6mite de una partici$n 3álida constitu&e un 3alor l6mite 3álido% mientras que los l6mites de una partici$n no 3álida constitu&en 3alores l6mite no 3álidos. 4as pruebas pueden dise/arse para cubrir 3alores l6mite tanto 3álidos como no 3álidos. Al disear &asos de %rue*a8 se sele&&iona una %rue*a %or &ada valor lite. )l análisis de 3alores l6mite puede aplicarse a todos los ni3eles de prueba. )s relati3amente fácil de aplicar & su capacidad para detectar defectos es alta. 4as especificaciones detalladas son tiles a la ora de establecer los l6mites interesantes. )sta técnica a menudo se considera como una extensi$n de la partici$n de equi3alencia u otras técnicas de dise/o de pruebas de caa nera. Puede utiliarse en clases de equi3alencia para los 3alores que los usuarios introducen en pantalla &% por eemplo% en ranos de tiempo (tales como tiempo aotado o requisitos de 3elocidad de transacciones o ranos de tabla (por eemplo% el tama/o de la tabla es !5W!5.

•

•

*$lo podemos utiliar el análisis de 3alores l6mite cuando los elementos de la partici$n de equi3alencia son ordenados.
".7.7 Prue*as de ta*la de de&isi'n (67) -(cnica de diseño de casos de prue"a de caja negra en la que los casos de prue"a se diseñan para ejecutar las com"inaciones de entradas y/o est#mulos 0causas1 representadas en una ta"la de decisión. 6(ase tam"i(n ta"la de decisión. -a"la de decisión' -a"la que muestra las com"inaciones de entradas y/o est#mulos 0causas1 con sus s alidas y/o acciones asociadas 0efectos1, que puede ser utilizada para diseñar casos de prue"a.

•

4as tablas de decisi$n= reflean los requisitos del sistema que contienen condiciones l$icas. ◦

◦

◦

◦

◦

◦

*e analia la especificaci$n & se identifican las condiciones & acciones del sistema. Por lo eneral% las condiciones & acciones de entrada se sentencian de manera que deben ser 3erdaderas o falsas (booleano. 4a tabla de decisi$n inclu&e las condiciones de acti3aci$n % a menudo combinaciones de 3erdadero & falso para todas las condiciones de entrada% & las acciones resultantes para cada combinaci$n de condiciones. Cada columna de la tabla corresponde a una rela comercial que define una combinaci$n nica de condiciones & que resulta en la eecuci$n de aquellas acciones asociadas a dica rela. Est,ndar de &o*ertura= 1is%oner al enos de una %rue*a %or &oluna en la ta*la% lo que eneralmente implica cubrir todas las combinaciones de condiciones de acti3aci$n. 7ediante esta técnica se prueba la l$ica de neocio (sus relas. 4as 3alidaciones de entrada se deben aber probado antes.

".7." Prue*as de transi&i'n de estado (67) -(cnica de diseño de prue"as de caja negra en la cual los casos de prue"a son diseñados para ejecutar transiciones de estado v$lidas e inv$lidas. 6(ase tam"i(n prue"as de conmutador de multiplicidad <. Prue"as de conmutador de multiplicidad <' Forma de prue"as de transición de estado en la cual los c asos de prue"a est$n diseñados para ejecutar todas las secuencias v$lidas de <=@ transiciones.

•

Giarama de transici$n de estado= 7uestra las respuestas diferentes de un sistema en funci$n de sus condiciones actuales o su istorial pre3io (su estado. ◦

◦

◦

'2

)l software se 3e en términos de sus estados% transiciones entre estados% entradas o e3entos que acti3an los cambios de estado (transiciones & acciones que pueden deri3arse de dicas transiciones. 4os estados del sistema u obeto de la prueba son independientes% identificables & finitos en nmero. *obre el diarama de transici$n de estados=

1. Primero identificar los estados del sistema (estado T situaci$n que persiste asta que aln e3ento ocurra para causar una transici$n de estado. !. 0dentifica el estado inicial & final. ". >ela eneral= 4os casos de prueba deber6an comenar con el sistema en el estado inicial & deber6an terminar en el estado final. '. )n cada estado un e3ento puede ocurrir que forará una transici$n de estado (excepci$n= en el estado final esto no ocurre. (4os e3entos son frecuentemente entrada de aln tipo de sistema o aplicaci$n. 5. 7ientras la transici$n de estado ocurre el sistema podr6a tomar aluna acci$n (las acciones son usualmente salidas de aln tipo de sistema o aplicaci$n. . )n alunos casos% dos o más condiciones son aplicadas al e3ento% el cuál influ&e sobre cuál transici$n ocurre% & por tanto cuál acci$n es tomada. +. Gespués de que la transici$n de estado a ocurrido% el sistema está en un nue3o estado o se a mantenido en el actual. ◦

◦

•

Puedes dise/arse pruebas para cubrir una secuencia t6pica de estados% cubrir todos los estados% eercitar todas las transiciones% eercitar secuencias espec6ficas de transiciones o probar transiciones in3álidas. Criterio nio de &o*ertura dia+raa de transi&i'n de estados= Jisitar &ada estado 9 atravesar &ada transi&i'n.

Una ta*la de transi&iones de estado muestra la relaci$n entre los estados & las entradas% & e3entualmente puede poner de manifiesto posibles transiciones no 3álidas. ◦

C$mo construirla= 1. Daa una lista de todos los estados en el diarama. !. Daa una lista de todos los pares e3ento;condici$n en el diarama. ". Crear una tabla con cada combinaci$n posible del estado con el par e3ento;condici$n. '. Para cada combinaci$n de estado9e3ento;condici$n% si el diarama especifica la acci$n que debe ser tomada & el nue3o estado al que se debe inresar% pona aquella informaci$n en la fila correspondiente en la tabla. *i no% escriba LindefinidoM en aquellos dos campos en esa fila.

◦

•

Criterio de &o*ertura nio= Cada fila de*era tener una %rue*a aso&iada (sie%re -ue sea %osi*le).

<écnica adecuada para= industria del software interado (automatiaci$n técnica en eneral% modelar un obeto de neocio% probar los fluos pantalla9diáloo (aplicaciones Jeb.

".7.: Prue*as de &aso de uso (62) -(cnica de diseño de prue"a de caja negra en la que los casos de prue"a est$n diseñados para ejecutar escenarios de usuario.

•

•

•

•

'1

Pruebas deri3adas de casos de uso. En caso de uso describe las interacciones entre los actores% inclu&endo usuarios & el sistema% para producir un resultado de 3alor para un usuario de sistema o para el cliente. 4os casos de uso pueden describirse tanto a ni3el abstracto (caso de uso comercial% ni3el de proceso empresarial como a ni3el de sistema (caso de uso de sistema a ni3el de funcionalidad del mismo . Cada caso de uso tiene precondiciones que deben cumplirse para que el caso de uso funcione correctamente.

•

•

•

Cada caso de uso termina con poscondiciones% que son los resultados obser3ables & el estado final del sistema una 3e finaliado el caso de uso. Beneralmente% un caso de uso tiene un escenario principal (o más probable & caminos alternati3os. 4os casos de uso describen los Lfluos de procesoM mediante un sistema basado en su uso probable real. ◦

◦

◦

◦

4os casos de prueba deri3ados de los casos de uso resultan mu& tiles a la ora de descubrir defectos en los fluos de proceso durante el uso real del sistema. 4os casos de uso son de ran utilidad para dise/ar las pruebas de aceptaci$n con la participaci$n del cliente;usuario. simismo% a&udan a descubrir e3entuales defectos de interaci$n % pro3ocados por la interacci$n & la interferencia de distintos componentes% que las pruebas de componente a ni3el indi3idual no pueden detectar. )l dise/o de los casos de prueba a partir de casos de uso pueden combinarse con otras técnicas de pruebas basadas en la especificaci$n.

"." T3&ni&as *asadas en la estru&tura o t3&ni&as de &a
Cobertura de sentencia Cobertura de rama

5(todo de an$lisis que determina qu( partes del softare *an sido ejecutadas 0cu"iertas1 por el juego de prue"as y qu( partes no *an sido ejecutadas, ejemplo co"ertura de sentencia, co"ertura de decisión o co"ertura de condición.

Porcentaje de sentencias ejecuta"les que *an sido practicadas por un juego de prue"as.

Porcentaje de ramas que *an sido practicadas por un juego de prue"as. @AAB de co"ertura de rama implica @AAB de co"ertura de decisión y @AAB de co"ertura de sentencia.

)ama' Cloque "$sico que puede ser seleccionado para su ejecución en "ase a una estructura propia de un programa en la cual est$n disponi"les uno de dos o m$s caminos alternativos, por ejemplo case, jump, go to, ift*en4else.

Cobertura de decisi$n

Porcentaje de resultados de decisión que *an sido practicados por un j uego de prue"as. %l @AAB de co"ertura de decisión implica tanto un @AAB de co"ertura de rama como un @AAB de co"ertura de sentencia. . ecisión' Punto de un programa en el cual el flujo de control tiene dos o m$s rutas alternativas. 7n nodo con dos o m$s enlaces para separar ramas.

Cobertura de condici$n

Pruebas basadas en la estructura (Pruebas de caa blanca

'!

Porcentaje de los posi"les resultados de una condición que *an si do practicados por un juego de prue"as. 7na co"ertura de condición del @AAB requiere que cada condición simple de toda sentencia de decisión *aya sido pro"ada como 6erdadera y Falsa.

Prue"as "asadas en un an$lisis de la estructura interna del componente o sistema.

Ante&edentes 4as pruebas basadas en la estructura o de caa blanca se basan es una estructura identificada del software o del sistema. Por eemplo= •

•

•

:i3el de componente= la estructura de un componente de software (sentencias% decisiones% ramas% caminos distintos% N. :i3el de interaci$n= la estructura puede ser un árbol de llamadas (un diarama en el que los m$dulos llaman a otros m$dulos. :i3el de sistema= 4a estructura puede ser una estructura de mens% procesos de neocio o una estructura de páina Jeb.

)n este apartado se tratan tres técnicas de dise/o de pruebas estructurales relacionadas con el c$dio para la cobertura de c$dio en base a sentencias% ramas & decisiones. Para las pruebas de decisiones% puede utiliarse un diarama de fluo para 3isualiar las alternati3as de cada decisi$n. Para dise/ar pruebas estructurales;de caa blanca= !. naliar los fluos de control en el c$dio. 2. Etiliar ese análisis para medir la cobertura de las pruebas existentes. 7. dicionar las pruebas adicionales para alcanar un ni3el deseado de cobertura. ".".! Prue*as de senten&ias 9 &o*ertura (6") Pruebas de sentencias= -(cnica de diseño de prue"as de caja "lanca en la cual los casos de prue"a se diseñan para ejecutar sentencias. Cobertura de sentencia= Porcentaje de sentencias ejecuta"les que *an sido practicadas por un juego de prue"as.

)n las pruebas de componente% la cobertura de sentencia es la e3aluaci$n del porcentae de sentencias eecutables que an sido practicadas por un ueo de caso de prueba. 4a técnica de pruebas de sentencia obtiene casos de prueba para eecutar sentencias espec6ficas% normalmente con 3istas a aumentar la cobertura de sentencias. 4a cobertura de sentencia 3iene determinada por el nmero de sentencias eecutables cubiertas (dise/adas o eecutadas por casos de prueba di3idido entre el nmero de todas las sentencias eecutables en el c$dio obeto de la prueba. ".".2 Prue*as de de&isi'n 9 &o*ertura (6") Pruebas de decisiones= -(cnica de diseño de casos de prue"a de caja "lanca en l a cual los casos de prue"a se diseñan para practicar resultados de decisiones. !o"ertura de decisión' Porcentaje de resultados de decisión que *an sido practicados por un juego de prue"as. %l @AAB de co"ertura de decisión implica tanto un @AAB de co"ertura de rama como un @AAB de co"ertura de sentencia.

4a cobertura de decisi$n% asociada a las pruebas de rama% es la e3aluaci$n del porcentae de los resultados de decisi$n (por eemplo% las opciones 3erdadero & falso de una sentencia 0# que an sido practicados por un ueo de casos de prueba. 4a técnica de prueba de decisi$n obtiene los casos de prueba para eecutar resultados de decisiones espec6ficos. 4as ramas forman puntos de decisi$n en el c$dio. 4a cobertura de decisi$n 3iene determinada por el nmero total de resultados de decisi$n cubiertos (dise/ados o eecutados por casos de prueba di3idido entre el nmero total de posibles resultados de decisi$n en el c$dio obeto de la prueba. 4as pruebas de decisi$n constitu&en una forma de pruebas de fluo de control &a que siuen un fluo espec6fico de control a tra3és de los puntos de decisi$n.

'"

4a cobertura de decisi$n es más fuerte que la cobertura de sentencia. En 122U de cobertura de decisi$n arantia un 122U de cobertura de sentencia% pero no al contrario (&a que a& 0#Ss que no tienen )4*)% o *J0
Cobertura de condici$n mltiple (o de multicondici$n Cobertura condici$n decisi$n modificada

de &

Porcentaje de com"inaciones de todos los resultados de condiciones simples dentro de una sentencia, que *an sido practicadas por un juego de prue"as. %l @AAB de co"ertura de condición m+ltiple implica el @AAB de co"ertura de condición.

6ariante leve de la co"ertura de condición m+ltiple.
)xisten ni3eles más fuertes de cobertura estructural además de la cobertura de decisi$n% como por eemplo la cobertura de condici$n & la cobertura de condici$n mltiple. )l concepto de cobertura también puede aplicarse a otros ni3eles de prueba. Por eemplo= •

)n el ni3el de interaci$n= el porcentae de m$dulos% componentes o clases practicados por un ueo de casos de prueba podr6a expresarse como cobertura de m$dulo% componente o clase.

)l uso de erramientas constitu&e un soporte til para las pruebas estructurales del c$dio.

".: T3&ni&as *asadas en la e5%erien&ia Pruebas exploratorias

-(cnica informal de diseño de prue"as donde quien prue"a controla activamente el diseño de las prue"as a medida que las prue"as son realizadas y utiliza la información o"tenida durante las prue"as para diseñar unas nuevas y mejores.

taque (falta 4as pruebas basadas en la experiencia son aquellas en las que las pruebas se deri3an de la abilidad e intuici$n del probador & de su experiencia con aplicaciones & tecnolo6as similares. *i se utilian para aumentar las técnicas sistemáticas% estas técnicas pueden ser tiles a la ora de identificar pruebas especiales que no pueden capturarse fácilmente mediante técnicas formales% especialmente si se aplican después de adoptar enfoques más formales. :o obstante% esta técnica puede tener distintos rados de efecti3idad% en funci$n de la experiencia del probador. Predicci$n de error= •

<écnica basada en la experiencia mu& usada.

•

4os probadores anticipan los defectos en base a su experiencia.

•

En enfoque estructurado de la técnica de predicci$n de error consiste en enumerar una lista de posibles defectos & dise/ar pruebas para atacar dicos defectos. ▪

''

)ste enfoque sistemático se denomina ata-ue de faltas.

▪

)sta lista de defectos & fallos puede elaborarse en base a la experiencia% a los datos disponibles sobre defectos & fallos & a partir del conocimiento comn sobre por qué falla el software.

Pruebas exploratorias= <écnica informal de dise/o de pruebas donde quien prueba controla acti3amente el dise/o de las pruebas a medida que las pruebas son realiadas & utilia la informaci$n obtenida durante las pruebas para dise/ar unas nue3as & meores. •

•

•

4as pruebas exploratorias coinciden con las fases de dise/o de pruebas% eecuci$n de pruebas% reistro de pruebas & aprendiae% en base a un contrato (plan de pruebas que contempla los obeti3os de las pruebas% & se lle3an a cabo dentro de los periodos de tiempo establecidos. *e trata de un enfoque especialmente til en los casos en los que las especificaciones son escasas o inadecuadas & existe una importante presi$n temporal% o para aumentar o complementar otras pruebas más formales. simismo% puede ser3ir como comprobaci$n del proceso de pruebas% para a&udar a arantiar que los defectos más ra3es an sido efecti3amente detectados.

".? Sele&&i'n de t3&ni&a de %rue*a (62) :inn término espec6fico. 4a selecci$n de la técnica de pruebas a utiliar depende de una serie de factores entre los que se inclu&en= •

)l tipo de sistema.

•

4os estándares normati3os.

•

4os requisitos contractuales o de cliente.

•

)l ni3el;tipo de rieso.

•

)l obeti3o de prueba.

•

4a documentaci$n disponible.

•

)l conocimiento de los probadores.

•

)l tiempo & presupuesto.

•

)l ciclo de 3ida de desarrollo.

•

4os modelos de caso de uso.

•

4a experiencia pre3ia en los tipos de defectos detectados.

lunas técnicas resultan más aplicables a ciertas situaciones & ni3eles de prueba% mientras que otras son aplicables a todos los ni3eles de pruebas. Para crear casos de prueba% los probadores eneralmente aplican una combinaci$n de técnicas de pruebas% entre las que se inclu&en técnicas uiadas por procesos% relas & datos% con 3istas a arantiar la correcta cobertura del obeto que se está probando.

'5

: Gesti'n de %rue*as (67) :.! ;r+ania&i'n de %rue*as (62) Probador 46der de pruebas Qefe de pruebas

Profesional experto que esta involucrado en las prue"as de un componente o sistema.

6(ase jefe de prue"as.

Persona responsa"le de la gestión de proyecto de las actividades y recursos de prue"as, y de la evaluación de un o"jeto de prue"a. 2ndividuo que dirige, controla, administra, planifica y regula la evaluación de un o"jeto de prue"a.

:.!.! ;r+ania&i'n de %rue*as e inde%enden&ia (62) 4a efecti3idad de la identificaci$n de defectos del proceso de pruebas & re3isi$n puede meorarse si se utilian probadores independientes. lternati3as para obtener independencia en las pruebas= •

•

•

•

•

•

usencia de probadores independientes= los desarrolladores son lo que prueban su propio c$dio. Probadores independientes dentro de los equipos de desarrollo. )quipos de prueba independientes o rupos dentro de la oraniaci$n (que reporten a la direcci$n de pro&ectos o direcci$n eecuti3a. Probadores independientes procedentes de la oraniaci$n comercial o de la comunidad de usuarios. )specialistas en pruebas independientes para tipos de pruebas espec6ficas (probadores de usabilidad% probadores de seuridad% probadores de certificaci$n 9que certifican un producto de software en base a los estándares & la normati3a. 4os probadores independientes subcontratados o externos a la oraniaci$n.

Para pro&ectos randes% compleos o cr6ticos para la seuridad% normalmente lo meor es contar con 3arios ni3eles de pruebas & poner aluno o todos los ni3eles a caro de probadores independientes. )l personal de desarrollo puede participar en las pruebas% especialmente en los ni3eles más baos% pero su falta de obeti3idad a menudo limita su efecti3idad. 4os probadores independientes pueden tener potestad para exiir & definir procesos & relas de pruebas. •

:o obstante% los probadores s$lo deberán asumir dica funci$n en relaci$n con los procesos pre3ia orden de la Girecci$n en ese sentido.

8entaas de la independencia de las pruebas= •

•

4os probadores independientes 3en más & diferentes defectos & son obeti3os. En probador independiente puede comprobar los supuestos planteados durante las fases de especificaci$n e implementaci$n del sistema.

0ncon3enientes de la independencia de las pruebas= •

'

islamiento del equipo de desarrollo (si se trata como totalmente independiente.

•

•

•

4os desarrolladores pueden llear a perder el sentido de responsabilidad frente a la calidad. 4os probadores pueden 3erse como cuellos de botella o ser culpados de retrasos en el lanamiento. 4as tareas de prueba pueden realiarlas personas con una funci$n de pruebas espec6fica% o por otra persona con otro caro como efe de pro&ecto% efe de calidad% desarrollador% experto de neocio & dominio% operaciones de infraestructura o <0.

:.!.2 Tareas del Lder de Prue*as 9 del Pro*ador (6!) )ste prorama de estudio cubre dos caros de prueba= el l6der de pruebas & el probador. *us acti3idades & tareas dependen del pro&ecto% contexto del producto% oraniaci$n% N 46der de prueba T Qefe de pruebas T Coordinador de pruebas )l caro de l6der de pruebas puede desempe/arse por un efe de pro&ecto% un efe de desarrollo% un efe de aseuramiento de la calidad o el efe de un rupo de pruebas. )n pro&ectos randes puede aber dos caros= l6der de pruebas & efe de pruebas. :ormalmente% el l6der de pruebas es el que planifica% monitoria & controla las acti3idades & tareas de prueba. 4as tareas t6picas del l6der de pruebas inclu&en% entre otras= •

•

•

•

•

•

•

•

•

•

•

•

Coordinar la estrateia de pruebas & planificar con los efes de pro&ecto & demás responsables. >edactar o re3isar una estrateia de pruebas para el pro&ecto% & una pol6tica de pruebas para la oraniaci$n. Contribuir a la perspecti3a de pruebas de otras acti3idades de pro&ecto% tales como la planificaci$n de la interaci$n. Planificar las pruebas  teniendo en cuenta el contexto & entendiendo los obeti3os & riesos de las pruebas  inclu&endo seleccionar los enfoques de prueba% calcular el tiempo% el esfuero & el coste de las pruebas% contratar recursos% definir ni3eles de prueba% ciclos & planificar la esti$n de incidencias. 0niciar la especificaci$n% preparaci$n% implementaci$n & eecuci$n de pruebas% acer un seuimiento de los resultados de pruebas & comprobar los criterios de salida. daptar la planificaci$n en base a los resultados & proreso de las pruebas (a 3eces documentados en informes de estado & adoptar todas las acciones necesarias para compensar los problemas. )stablecer una esti$n de la confiuraci$n adecuada de los productos de soporte de pruebas a efectos de su traabilidad. 0ntroducir métricas adecuadas para medir el proreso de las pruebas & e3aluar la calidad de las pruebas & del producto. Gecidir qué debe automatiarse% asta qué punto & c$mo. *eleccionar las erramientas de soporte de las pruebas & oraniar cursos de formaci$n sobre el uso de dicas erramientas para los probadores. Gecidir sobre la implementaci$n del entorno de pruebas. >edactar informes resmenes de pruebas en base a la informaci$n recopilada durante las pruebas.

4as tareas t6picas del probador inclu&en% entre otras= •

•

•

•

'+

>e3isar & contribuir a los planes de pruebas. naliar% re3isar & e3aluar los requisitos de usuario% las especificaciones & los modelos para su testeabilidad. Crear especificaciones de prueba. Confiurar el entorno de pruebas (a menudo en coordinaci$n con administraci$n del sistema & esti$n de redes.

•

•

•

•

Preparar & obtener datos de prueba. 0mplementar pruebas en todos los ni3eles de prueba% eecutar & reistrar las pruebas% e3aluar los resultados & documentar las des3iaciones de los resultados esperados. Etiliar erramientas de administraci$n o esti$n & erramientas de seuimiento de prueba sen proceda. utomatiar pruebas (puede contar con el soporte de un desarrollador o un experto en automatiaci$n de pruebas.

•

7edir el rendimiento de los componentes & sistemas (si procede.

•

>e3isar las pruebas desarrolladas por terceros.

4as personas dedicadas al análisis de pruebas% al dise/o de pruebas% a tipos de pruebas espec6ficas o a la automatiaci$n de pruebas pueden ser especialistas en estas tareas. )n funci$n del ni3el de prueba & de los riesos asociados al producto & al pro&ecto % a& distintas personas que pueden asumir el papel de probador manteniendo cierto rado de independencia. )n eneral% los probadores a ni3el de componente e interaci$n son los desarrolladores% los probadores a ni3el de pruebas de aceptaci$n son los expertos de neocio & usuarios% & los probadores de pruebas de aceptaci$n operati3as son los operadores.

:.2 Planifi&a&i'n 9 estia&i'n de %rue*as (7) )nfoque (método de pruebas )strateia de pruebas

Pruebas exploratorias

2mplementación de la estrategia de prue"as definida para un proyecto espec#fico.

escripción de alto nivel de los niv eles de prue"a a ser llevados a ca"o y l as prue"as dentro de estos niveles para una organización o programa 0en uno o m$s proyectos1.

-(cnica informal de diseño de prue"as donde quien prue"a controla activamente el diseño de las prue"as a medida que las prue"as son realizadas y utiliza la información o"tenida durante las prue"as para diseñar unas nuevas y mejores.

:.2.! Planifi&a&i'n de %rue*as (2) 4a planificaci$n podrá documentarse en un plan de pruebas maestro & en planes de prueba separados para ni3eles de prueba. )l dise/o de un documento para la planificaci$n de pruebas se aborda en la L:orma para la documentaci$n de prueba de softwareM 0))) ,!-. Se&&iones del %lan de %rue*as IEEE 2$= !. 0dentificador del plan de pruebas. 2. 0ntroducci$n. 7. Xtems (elementos de prueba. ". Caracter6sticas a probar ; que no deben ser probadas. :. 7étodo;)nfoque de prueba (implementaci$n de la estrateia de prueba para el pro&ecto. ?. Criterios paso;falla del 6tem. @. Criterios de entrada% salida% suspensi$n% reanudaci$n. . )ntreables de las pruebas.

',

$. esponsabilidades. !7. Gotaci$n de personal & necesidades de capacitaci$n. !". >iesos (de calidad de producto & de pro&ecto. !:. probaciones.

4a planificaci$n se 3e afectada por= •

4a pol6tica de pruebas de la oraniaci$n.

•

)l alcance de las pruebas.

•

4os obeti3os.

•

4os riesos.

•

4as limitaciones del pro&ecto (coste% tiempo% alcance

•

4a criticidad (del sistema

•

4a testeabilidad

•

4a disponibilidad de recursos

 medida que la planificaci$n del pro&ecto & de las pruebas 3an a3anando abrá más informaci$n disponible & el plan podrá incluir más detalles. 4a planificaci$n de pruebas es una acti3idad continua que se lle3a a cabo en todos los procesos del ciclo de 3ida & acti3idades. •

)l feedbac@ de las acti3idades de pruebas sir3e para reconocer los riesos cambiantes con 3istas a austar la planificaci$n.

:.2.2 A&tividades de %lanifi&a&i'n de %rue*as (67) 4as acti3idades de planificaci$n para un sistema completo o para parte de un sistema pueden incluir= •

•

•

•

Gefinir el enfoque lobal de las pruebas% incluida la definici$n de los ni3eles de pruebas & los criterios de entrada & salida. 0nterar & coordinar las acti3idades de pruebas en las acti3idades de ciclo de 3ida del software (adquisici$n% suministro% desarrollo% operaci$n & mantenimiento. doptar decisiones sobre qué probar% qué caros lle3arán a cabo las acti3idades de pruebas% c$mo deber6an realiarse las acti3idades de pruebas & c$mo se e3aluarán los resultados de las pruebas.

•

Proramar las acti3idades de análisis & dise/o de las pruebas.

•

Proramar la implementaci$n% eecuci$n & e3aluaci$n de las pruebas.

•

sinar recursos para las distintas acti3idades definidas.

•

•

•

'-

Geterminar el alcance & los riesos e identificar los obeti3os de las pruebas.

Gefinir la cantidad% el ni3el de detalle% la estructura & las plantillas para la documentaci$n de las pruebas. *eleccionar métricas para el seuimiento & el control de la preparaci$n & eecuci$n de las pruebas% la resoluci$n de defectos & los temas de riesos. )stablecer el ni3el de detalle de los procedimientos de prueba para facilitar informaci$n suficiente para dar soporte a la preparaci$n & eecuci$n reproducible de pruebas.

:.2.7 Criterios de entrada (62) 4os criterios de entrada establecen cuándo iniciar las pruebas (por eemplo% al inicio de un ni3el de prueba o cuando una serie de pruebas esté lista para su eecuci$n. )n eneral% los criterios de entrada pueden cubrir lo siuiente= •

Gisponibilidad & disposici$n del entorno de pruebas.

•

Gisposici$n de las erramientas de prueba en el entorno de pruebas.

•

Gisponibilidad de c$dio testeable.

•

Gisponibilidad de datos de prueba.

:.2." Criterios de salida (62) 4os criterios de salida establecen cuándo detener las prueba (por eemplo% al final de un ni3el de prueba o cuando una serie de pruebas a&a lorado un obeti3o espec6fico. )n eneral% los criterios de salida pueden cubrir lo siuiente= •

7edidas de exausti3idad% tales como la cobertura de c$dio% la funcionalidad o el rieso.

•

)stimaciones de densidad de defectos o medidas de fiabilidad.

•

Coste.

•

•

>iesos residuales% tales como defectos no correidos o ausencia de Cobertura de pruebas en determinadas áreas. Calendarios% como los basados en el plao de comercialiaci$n.

:.2.: Estia&i'n de %rue*as (62) Gos enfoques distintos para estimar el esfuero de pruebas son= •

•

)l enfoque basado en métricas= estimar el esfuero de pruebas en base a métricas de pro&ectos anteriores o similares o en base a 3alores t6picos. )l enfoque basado en expertos= estimar las tareas en base a las estimaciones ecas por el propietario de las tareas o por los expertos.

Ena 3e estimado el esfuero de la prueba% pueden identificarse los recursos & elaborarse un calendario. )l esfuero de prueba puede depender de una serie de factores% entre los que se inclu&en= •

4as caracter6sticas del producto. ◦

•

•

52

4a calidad de la especificaci$n & demás informaci$n utiliada para modelos de prueba (es decir% la base de la prueba.

◦

)l tama/o del producto.

◦

4a compleidad del dominio del problema.

◦

4os requisitos de fiabilidad & seuridad.

◦

4os requisitos de documentaci$n.

4as caracter6sticas del proceso de desarrollo. ◦

4a estabilidad de la oraniaci$n.

◦

4as erramientas utiliadas.

◦

)l proceso de pruebas.

◦

4as abilidades de las personas implicadas.

◦

4a presi$n temporal.

)l resultado de las pruebas. ◦

)l nmero de defectos.

◦

4a cantidad de cambios necesarios.

:.2.? Estrate+ia de %rue*as8 enfo-ue de %rue*as (62) )nfoque de pruebas T plicaci$n de la estrateia de pruebas para un pro&ecto espec6fico. )l enfoque de pruebas se define & redefine en los planes & dise/os de prueba. Beneralmente inclu&e las decisiones tomadas en base a= •

)l obeti3o del pro&ecto de pruebas.

•

4a e3aluaci$n de los riesos del pro&ecto de pruebas.

Constitu&e el punto de inicio para= •

Planificar el proceso de pruebas.

•

*eleccionar las técnicas de dise/o de pruebas.

•

*eleccionar los tipos de pruebas a aplicar.

•

Gefinir los criterios de entrada & salida.

)l enfoque seleccionado dependerá del contexto & puede tener en cuenta= •

4os riesos.

•

4os peliros & la seuridad.

•

4os recursos disponibles & abilidades.

•

4a tecnolo6a.

•

4a naturalea del sistema (p.e. Personaliado 3s CA<*.

•

4os obeti3os de prueba.

•

4a normati3a.

Entre los enfo-ues t%i&os se in&lu9en= !. Enfo-ues analti&os% &oo las %rue*as *asadas en ries+os  en las que las pruebas se concentran en las áreas de ma&or rieso. 2. Enfo-ues *asados en odelos8 &oo las %rue*as esto&,sti&as  que utilian informaci$n estad6stica sobre frecuencias de fallos (tales como los modelos de fiabilidad de crecimiento o uso (tales como perfiles operati3os. 7. Enfo-ues et'di&os8 &oo los *asados en fallos  (inclu&endo la predicci$n de errores & los ataques de faltas% los *asados en la e5%erien&ia8 los *asados en listas de &o%ro*a&i'n 9 los *asados en &ara&tersti&as de &alidad. ". Enfo-ues de %ro&eso  o enfo-ues aeursti&os% &oo las %rue*as e5%loratorias en las que las pruebas son más reacti3as a e3entos en luar de estar planificadas con antelaci$n% & en las que las tareas de eecuci$n & e3aluaci$n son simultáneas. ?. Enfo-ues &onsultivos% como aquellos en los que la Cobertura de pruebas se establece principalmente en base a las recomendaciones & orientaciones de los expertos de tecnolo6a &;o neocio más allá del equipo de pruebas. @. Enfo-ues anti#re+resi'n% como los que inclu&en la reutiliaci$n del material de pruebas existente% la automatiaci$n extensi3a de pruebas de reresi$n funcionales &  ueos de prueba estándar. Pueden combinarse 3arios enfoques & adoptar% por eemplo% un enfoque dinámico basado en el rieso.

51

:.7 Se+uiiento 9 &ontrol del %ro+reso de las %rue*as (62) Gensidad de defectos

#recuencia de fallos

Control de pruebas

7onitoriaci$n de pruebas

*euimiento de pruebas 0nforme resumen de pruebas

<+mero de defectos identificados en un componente o sistema dividido por el tamaño del mismo 0expresado en t(rminos de medidas est$ndar, por ejemplo l#neas de código, n+mero de clases o puntos de función1.

!ociente del n+mero de fallos de una categor#a dada por unidad de medida especifica, por ejemplo fallos por unidad de tiempo, fallos por unidad de transacciones, fallos por n+mero de ejecuciones de programa.

-area de la gestión de prue"as que se encarga de desarrollar y aplicar un conjunto de acciones correctivas para poner el proyecto de prue"as en l a dirección correcta cuando el seguimiento 0monitorización1 muestra una desviación con respecto a lo que se *a"#a planificado. 6(ase tam"i(n gestión de prue"as.

-area de gestión de prue"as que se ocupa de las actividades relacionadas con la compro"ación periódica del estado de un proyecto de prue"as. Se preparan informes que comparan el estado real con lo que fue planificado.

(Véase control y monitorización de pruebas) ocumento que resume las actividades y resultados de las prue"as. -am"i(n contiene una evaluación de los correspondientes elementos de prue"a respecto de los criterios de salida.

:.7.! Se+uiiento del %ro+reso de las %rue*as (6!) )l obeti3o del seuimiento de las pruebas es facilitar feedbac@ & 3isibilidad sobre las acti3idades de pruebas. 4a informaci$n a controlar puede recopilarse de forma manual o automática & puede utiliarse para medir los criterios de salida% tales como la cobertura. 4as métricas también pueden utiliarse para e3aluar el proreso contra el prorama & el presupuesto pre3istos. )ntre las métricas de prueba más comunes se inclu&en= •

•

•

•

Porcentae de trabao realiado en la preparaci$n del entorno de pruebas. C$mputo & porcentaes de eecuci$n de los casos de prueba (por eemplo% nmero de casos de prueba eecutados;no eecutados% & casos de prueba superados;fallidos. 0nformaci$n sobre defectos (por eemplo% densidad de los defectos% defectos detectados & correidos% frecuencia de fallos & resultados de la repetici$n de pruebas.

•

Cobertura de pruebas de los requisitos% riesos o c$dio.

•

Confiana subeti3a de los probadores en el producto.

•

#ecas de itos de las pruebas.

•

5!

Porcentae de trabao realiado en la preparaci$n de los casos de prueba (o porcentae de casos de prueba planificados preparados.

Coste de las pruebas% inclu&endo el coste comparado con el beneficio de detectar el siuiente defecto o de eecutar la siuiente prueba.

:.7.2 Infores de %rue*as (62) 4os informes de pruebas tienen por obeto describir los resultados de un ni3el dado o fase de pruebas% teniendo en cuenta= •

•

Yué a pasado durante un periodo de prueba (e3entos cla3e% o la medici$n del cumplimiento de los criterios de salida para una reuni$n propuesta acerca de la salida de las pruebas. nálisis de informaci$n & métricas para respaldar las recomendaciones & decisiones sobre acciones futuras% tales como una e3aluaci$n de los defectos restantes% el beneficio econ$mico de las pruebas continuadas% los riesos pendientes & el ni3el subeti3o de confiana en el software probado.

)l dise/o de un informe resumen de pruebas se aborda en la L:orma para la documentaci$n de pruebas de softwareM 0))) ,!-. Se&&iones infore de resuen de %rue*as se+On IEEE 2$ !. Identifi&ador del infore. 2. esuen (lo -ue fue %ro*ado8 ...). 7. JarianasK1esvia&iones (del %lan8 de los &asos...). ". Evalua&i'n &o%rensiva. :. esuen de resultados (3tri&as finales8 &'%utos8...). ?. Evalua&i'n (de &ada te de %rue*a &on rela&i'n a los &riterios de %asoKfalla). @. esuen de las a&tividades (utilia&i'n de los re&ursos8 efi&ien&ia8 ...). . A%ro*a&i'n. 4as métricas deben recopilarse durante & al final de cada ni3el de prueba con 3istas a e3aluar= •

4a idoneidad de los obeti3os de la prueba para dico ni3el de prueba.

•

4a idoneidad de los enfoques de prueba adoptados.

•

4a efecti3idad de las pruebas por lo que respecta a los obeti3os.

e+istro de %rue*as= >eistro cronol$ico de los detalles rele3antes respecto a la eecuci$n de pruebas. Se&&iones re+istro de %rue*as se+On IEEE 2$ !. Identifi&ador del re+istro de %rue*as. 2. La des&ri%&i'n de las %rue*as (6tems sometidos a prueba 3ersionados% entornos de prueba utiliados% N. 7. 1atos de a&tividades 9 eventos  (descritos prueba tras prueba & e3ento tras e3ento. :.7.7 Control de %rue*as (62) )l control de pruebas describe cualquier acci$n orientati3a o correcti3a adoptada como resultado de la informaci$n & las métricas recopiladas e incluidas en un informe. 4as acciones pueden referirse a cualquier acti3idad de prueba & pueden afectar a cualquier acti3idad o tarea del ciclo de 3ida del software. lunos eemplos de acciones de control de pruebas inclu&en= •

•

5"

establecer la prioridad de las pruebas si sucede un rieso identificado (por eemplo% demora en la entrea del software.

•

•

Cambiar el calendario de pruebas por moti3os de disponibilidad o no disponibilidad de un entorno de pruebas. )stablecer un criterio de entrada que requiera la repetici$n de las pruebas de las correcciones (pruebas de confirmaci$n por parte de un desarrollador antes de aceptarlas en una construcci$n.

:." Gesti'n de la &onfi+ura&i'n (62) Besti$n de la confiuraci$n

Control de 3ersi$n ; Control de la confiuraci$n

isciplina que aplica dirección y supervisión t(cnica y administrativa a' identificar  y documentar las caracter#sticas funcionales y f#sic as de un elemento de la configuración, controlar cam"ios de esas caracter#sticas, registrar e informar so"re el estado de la implementación y proceso de cam"io, y v erificar la conformidad con los requisitos especificados.

%lemento de la gestión de la configuración consistente en la evaluación, coordinación, apro"ación o desapro"ación e implementación de los cam"ios en los elementos de la configuración tras el esta"lecimiento formal de l a identificación de la configuración.

)l obeti3o de la esti$n de la confiuraci$n es establecer & mantener la interidad de los productos (componentes% datos & documentaci$n del software o sistema a tra3és del ciclo de 3ida del pro&ecto o del producto. )n el caso de las pruebas% la esti$n de la confiuraci$n puede implicar arantiar lo siuiente= •

•


Para el probador% la esti$n de la confiuraci$n le a&uda a identificar (& reproducir de manera un63oca el elemento probado% los documentos de prueba% las pruebas & los arneses de pruebas. Gurante la planificaci$n de las pruebas% deben seleccionarse% documentarse e implementarse los procedimientos de esti$n de la confiuraci$n & las erramientas de infraestructura. Infore de transisi'n de los tes de %rue*as (&oOnente llaado notas de versiones)= describe los 6tems que deben ser entreados para las pruebas. Se&&iones del infore de transisi'n de los tes de %rue*as se+On IEEE 2$ = !. Identifi&ador del infore. 2. Los tes transitidos (inclu&endo nombres de los 6tems & nmeros de re3isi$n. 7. El lu+ar (u*i&a&i'n) del obeto o 6tem de pruebas. ". El estado del o*
5'

:.: ies+os 9 %rue*as >ieso

Factor que puede resultar en futuras consecuencias negativas, expresada normalmente como impacto y pro"a"ilidad.

>ieso de producto

)iesgo directamente relacionado con el o"jeto de prue"a.

>ieso de pro&ecto

Pruebas riesos

basadas

)iesgo relativo a la gestión y control de un proyecto 0 de prue"as1, por ejemplo, falta de personal, plazos estrictos, requisitos cam"iantes, etc..

en

%nfoque de prue"as para reducir el nivel de riesgos de producto e informar a los afectados de su estado, comenzando desde las fases iniciales de un proyecto. 2mplica la identificación de riesgos de producto y su uso para dirigir el proceso de prue"as.

Ante&edentes >ieso T Aportunidad de un e3ento% peliro% amenaa o situaci$n que sucede & tiene como resultados consecuencias no deseadas o un problema potencial. :i3el de rieso T Probabilidad (de que ocurra un e3ento ad3erso x 0mpacto (da/o resultante de dico e3ento :.:.! ies+os de %ro9e&to (62) 4os riesos de pro&ecto son los riesos relati3os a la capacidad del pro&ecto de lorar sus obeti3os. )emplos de riesos de pro&ecto= •

#actores de oraniaci$n= ◦

ptitudes% formaci$n & falta de personal.

◦

spectos pol6ticos% tales como= ▪

▪

◦

•

◦

◦

◦

◦

ctitud indebida o falsas expectati3as ante las pruebas (por eemplo% no 3alorar el 3alor de detectar defectos durante las pruebas. Problemas para definir los requisitos adecuados. 4a medida en que no pueden cumplirse los requisitos dadas las limitaciones existentes. )l entorno de pruebas no está listo a tiempo. Gemora en la con3ersi$n de datos% planificaci$n & desarrollo de miraci$n & con3ersi$n de datos de prueba;erramientas de miraci$n. Iaa calidad del dise/o% c$dio% datos de confiuraci$n% datos de prueba & pruebas.

spectos de pro3eedores= ◦

55

0ncapacidad del equipo de acer un seuimiento de la informaci$n encontrada durante las pruebas & re3isiones (por eemplo% no se meora el desarrollo & las prácticas de pruebas.

spectos técnicos= ◦

•

Problemas con la forma en la que los probadores comunican sus necesidades & resultados de las pruebas.

#allos de terceros.

◦

spectos contractuales.

 la ora de analiar% estionar & mitiar estos riesos% el efe de pruebas debe seuir principios de esti$n de pro&ectos bien establecidos. •

4a L:orma de Gocumentaci$n de pruebas de softwareM 0))) ,!- esboa los planes de prueba & exie que se indiquen los riesos & continencias.

:.:.2 ies+os de %rodu&to (62) 4as posibles área de fallo (e3entos futuros ad3ersos o peliros en el software o sistema se conocen como riesos de producto% &a que suponen un rieso para la calidad del producto. )emplos de riesos de producto= •

•

•

•

•

)l software entreado es procli3e a los fallos. 4a posibilidad de que el software;ardware pueda da/ar a un indi3iduo o a una empresa. 7alas caracter6sticas del software (por eemplo% carencias en la funcionalidad% fiabilidad% usabilidad o rendimiento. 7ala interidad & calidad de los datos (por eemplo% problemas de miraci$n de datos% problemas de con3ersi$n de datos% problemas de transporte de datos% 3iolaci$n de estándares de datos. )l software no realia las funciones pre3istas.

Etilidad de los riesos de producto= *ir3en para decidir por d$nde empear las pruebas & d$nde probar más. •

 su 3e% las pruebas sir3en para reducir el rieso de que suceda un efecto ad3erso (probabilidad% o para reducir el impacto del mismo.

4os riesos de producto constitu&en un tipo especial de rieso para el éxito de un pro&ecto. )l eco de realiar pruebas a modo de acti3idad de control del rieso proporciona feedbac@ sobre el rieso residual midiendo la efecti3idad de la eliminaci$n de los defectos cr6ticos & los planes de continencia. )l enfoque basado en el rieso en las pruebas ofrece oportunidades proacti3as de reducir los ni3eles de rieso de producto% empeando en las etapas iniciales de un pro&ecto. •

•

)ste enfoque implica la identificaci$n de riesos de producto & su uso en la planificaci$n de las pruebas & especificaci$n de control% preparaci$n & eecuci$n de las pruebas. )n un enfoque basado en el rieso% los riesos identificados pueden utiliarse para= ◦

)stablecer las técnicas de pruebas a emplear.

◦

)stablecer el alcance de las pruebas a eecutar.

◦

◦

•

Prioriar las pruebas en un intento por identificar los defectos cr6ticos lo antes posible. )stablecer si podr6a utiliarse aluna acti3idad no de prueba para reducir el rieso (por eemplo% impartir formaci$n a dise/adores sin experiencia.

4as pruebas basadas en riesos se basan en el conocimiento colecti3o & en la comprensi$n de las partes interesadas del pro&ecto para establecer los riesos & los ni3eles de pruebas necesarios para abordar dicos riesos.

Con 3istas a arantiar que la posibilidad de fallo de un producto es m6nima% las acti3idades de esti$n del rieso establecen un enfoque disciplinado para= •

)3aluar (& re9e3aluar de manera reular qué puede fallar (riesos.

•

)stablecer qué riesos son importante tratar.

•

0mplementar acciones para abordar dicos riesos.

demás% las pruebas pueden contribuir a identificar nue3os riesos% pueden a&udar a establecer qué riesos deben reducirse & pueden reducir la incertidumbre sobre los riesos.

5

:.? Gesti'n de in&iden&ias (67) 0ncidencia >eistro de ; >eistrar incidencias Besti$n de incidencias 0nforme de incidencias

!ualquier ocurrencia de un suceso que requiere investigación.

 &cción de consignar los detalles de cualquier incidencia ocurrida, por ejemplo durante las prue"as.

Proceso de reconocimiento, investigación, toma de medidas y eliminación de incidencias. !omprende registrar incidencias, clasificarlas e identificar el impacto.

ocumento que informa de la ocurrencia de cualquier suceso, por ejemplo durante las prue"as, que requiere investigación.

Gado que uno de los obeti3os de las pruebas es la detecci$n de defectos% las discrepancias entre los resultados reales & los resultados esperados deben reistrarse como incidencias.
simismo% pueden surir por problemas en el c$dio o en el sistema de funcionamiento% o en cualquier tipo de documentaci$n (requisitos% documentos de desarrollo% documentos de prueba e informaci$n de usuario 9como u6as de a&uda o instalaci$n9.

Abeti3os de los informes de incidencias= •

•

•

#acilitar feedbac@ sobre el problema a los desarrolladores & demás partes implicadas permitiendo su identificaci$n% aislamiento & correcci$n. Proporcionar a los l6deres de prueba un medio de seuimiento de la calidad del sistema probado & del proreso de las pruebas. portar ideas para la meora del proceso de pruebas.

)l informe de incidencias puede incluir los siuientes detalles= a Fe&>a de e5%edi&i'n  (creador;informante.

(creaci$n%

or+ania&i'n

eisora

9

autor

b esultados es%erados 9 resultados reales. c Identifi&a&i'n del eleento de %rue*a (elemento de confiuraci$n 9 entorno. d Pro&eso del &i&lo de vida del soft/are o del sistema en el que se a obser3ado la incidencia. e 1es&ri%&i'n de la in&iden&ia para permitir su reproducci$n & resoluci$n% inclu&endo reistros% 3olcados de bases de datos o pantallaos. f Al&an&e o +rado de i%a&to en los intereses de las partes interesadas.  Gravedad del i%a&to en el sistema.  Ur+en&iaK%rioridad de su correcci$n. i

Estado de la in&iden&ia (por eemplo% abierta% diferida% duplicada% esperando correcci$n% correida  esperando la repetici$n de las pruebas% cerrada.

  Con&lusiones8 re&oenda&iones 9 autoria&iones.

5+

@ As%e&tos +lo*ales% como otras áreas que pueden 3erse afectadas por un cambio deri3ado de la incidencia. l

Ristorial del &a*io% como la secuencia de acciones adoptadas por los miembros del equipo de pro&ecto por lo que respecta a la incidencia para aislarla% repararla & confirmarla como correida.

m eferen&ias% inclu&endo la identidad de la especificaci$n de caso de prueba que puso de manifiesto el problema. 4a estructura de los informes de incidencias se aborda en la L:orma para la documentaci$n de pruebas de softwareM 0))) ,!-. Se&&iones de un infore de in&iden&ias se+On IEEE 2$= !. 0dentificador del informe. 2. >esumen (describe especialmente el impacto acerca de los interesados de neocio. 7. Gescripci$n de la incidencia.

5,

◦

)ntradas (posibles anomal6as obser3adas en las mismas.

◦

>esultados esperados 3s >esultados reales.

◦

#eca;Dora cuando se obser3aron las anomal6as.

◦

)ntorno de pruebas en el cuál las anomal6as fueron obser3adas.

◦

0dentificador del caso de prueba o procedimiento que detect$ la anomal6a.

◦

4a reproducibilidad del fallo.

◦

)l informador de la incidencia.

◦

N

? Rerraientas de so%orte de %rue*as (62) #alta comparar términos del tema  con losario !211.

?.! Ti%os de >erraientas de %rue*as (62) Aráculo de prueba

Fuente para determinar resultados esperados para compararlos con los resultados reales del softare en prue"as. 7n or$culo puede ser un sistema existente 0para una evaluación comparativa1, un manual de usuario o el conocimiento especializado de un individuo, pero no de"er#a ser el código.

Derramienta de esti$n de la confiuraci$n Derramienta de cobertura Derramienta de depuraci$n Derramienta dinámico

de

análisis

Derramienta de esti$n de incidencias Derramienta de pruebas de cara Derramienta de modelado Derramienta monitoriaci$n

de

Derramienta de pruebas de rendimiento )fecto sonda

%fecto producido por el instrumento de medida so"re el sistema o componente que est$ siendo medido, por ejemplo mediante una *erramienta de prue"as de rendimiento o un monitor. Por ejemplo el rendimiento puede ser ligeramente peor  cuando las *erramientas de prue"a de rendimiento est$n siendo usadas.

Derramienta de esti$n de requisitos Derramienta de re3isi$n Derramienta de seuridad Derramienta estático

de

análisis

Derramienta de pruebas de estrés Comparador de pruebas

:erramienta de prue"as para realizar comparaciones autom$ticas de prue"as entre los resultados o"tenidos y los resultados esperados. !omparación de prue"as' Proceso de identificación de las diferencias entre los resultados reales producidos por el componente o sistema en prue"as y los resultados esperados para la prue"a. a comparación de prue"as puede ser llevada a ca"o durante la ejecución de la prue"a 0comparación din$mica1 o con posterioridad a la ejecución de la prue"a.

Derramienta de preparaci$n de datos de

5-

prueba Derramienta de dise/o de pruebas rnés de prueba Derramienta de eecuci$n de pruebas Derramienta de esti$n de pruebas Derramienta de marco de trabao de pruebas unitarias ?.!.! Si+nifi&ado 9 o*erraientas de so%orte de %rue*as (62) 4as erramientas de pruebas pueden utiliarse en una o más acti3idades de soporte de pruebas. )emplos de erramientas de pruebas= •

•

4as erramientas que se utilian directamente en las pruebas= ◦

Derramientas de eecuci$n de pruebas.

◦

Derramientas de eneraci$n de datos de prueba.

◦

Derramientas de comparaci$n de resultados.

◦

...

4as erramientas que a&udan a estionar el proceso de pruebas= ◦

•

◦

Derramientas para elaborar informes & monitoriar la eecuci$n de pruebas.

◦

N

4as erramientas usadas para el reconocimiento o exploraci$n= ◦

•

Derramientas de esti$n de pruebas% resultados de pruebas% datos% requisitos% incidencias% defectos% N

Derramientas que monitorian la acti3idad de ficeros de una aplicaci$n.

Cualquier erramienta que contribu&e al proceso de pruebas (desde las más sofisticadas a una simple oa de cálculo.

4as erramientas de soporte de pruebas pueden tener uno o más de los siuientes obeti3os en funci$n del contexto= 1 7eorar la eficiencia de las tareas de pruebas automatiando tareas repetiti3as o dando soporte a las acti3idades de pruebas manuales (como la planificaci$n% el dise/o% la elaboraci$n de informes & la monitoriaci$n de pruebas. ! utomatiar aquellas acti3idades que requieren mucos recursos si se acen de manera manual (como por eemplo% las pruebas estáticas. " utomatiar aquellas acti3idades que no pueden eecutarse de forma manual (por eemplo% pruebas de rendimiento. ' umentar la fiabilidad de las pruebas (por eemplo% automatiando las comparaciones de randes ficeros de datos & simulando comportamientos. )l término Lmarcos de trabao de pruebasM (test framewor@ se utilia a menudo en el sector & puede tener% como m6nimo% cualquiera de los tres siuientes sinificados (aunque en el caso del presente prorama de estudio solo se contemplan los dos primeros= •

•

2

4ibrer6as de pruebas reutiliables & ampliables que pueden utiliarse para crear erramientas de pruebas (también conocido como arnés de pruebas. En tipo de dise/o de automatiaci$n de pruebas (por eemplo% uiada por datos o uiadas por palabras cla3e.

•

Proceso eneral de eecuci$n de las pruebas.

?.!.2 Clasifi&a&i'n de >erraientas de %rue*a (62) )n este prorama de estudio las erramientas se clasifican en funci$n de las acti3idades de pruebas a las que dan soporte. lunas erramientas dan soporte a una acti3idad de manera clara% mientras que otras pueden dar soporte a más de una acti3idad% pero se clasifican dentro de la acti3idad a la que están más estrecamente 3inculadas. lunos tipos de erramientas de prueba puede ser intrusi3os% es decir% pueden afectar al resultado real de la prueba. •

•

Por eemplo% los tiempo reales pueden diferir debido a las instrucciones adicionales que la erramienta eecuta% o incluso puede obtenerse una medida distinta de cobertura de c$dio. 4a consecuencia del uso de erramientas intrusi3as se denomina Lefecto sondaM.

lunas erramientas ofrecen un soporte más adecuado para los desarrolladores (como por eemplo% las erramientas que se utilian durante las pruebas de componente & de interaci$n de componentes. )stas erramientas aparecen marcadas con el s6mbolo L(GM  en la lista a continuaci$n. ?.!.7 Rerraientas de so%orte %ara la +esti'n de %rue*as (6!) 4as erramientas de esti$n son aplicables a todas las acti3idades de pruebas durante todo el ciclo de 3ida del software. •

Rerraientas de +esti'n de %rue*as. ◦

◦

◦

•

•

&udan a localiar los obetos de prueba conforme a las especificaciones de requisitos & pueden tener una capacidad de control de 3ersi$n independiente o una interfa conforme a una externa.

◦

lmacenan sentencias de requisitos.

◦

lmacenan los atributos de los requisitos (incluida la prioridad.

◦

Proporcionan identificadores nicos.

◦

#acilitan la localiaci$n de los requisitos para pruebas indi3iduales.

◦

&udan a identificar la ausencia o la inconsistencia de requisitos.

Rerraientas de +esti'n de in&iden&ias (Rerraientas de se+uiiento de defe&tos). lmacenan & estionan informes de incidencias% es decir% defectos% fallos% cambio de peticiones o problemas & anomal6as percibidas.

◦

&udan a estionar el ciclo de 3ida de las incidencias.

◦

Apcionalmente% Proporcionan soporte al análisis estad6stico.

Rerraientas de +esti'n de la &onfi+ura&i'n. ◦

◦

1

Gan soporte al análisis cuantitati3o & a la elaboraci$n de informes sobre los obetos de prueba.

Rerraientas de +esti'n de re-uisitos.

◦

•

Afrecen interfaces para eecutar pruebas% localiar defectos & estionar requisitos.

*on necesarias para el almacenamiento & la esti$n de 3ersiones de productos de soporte de prueba (testware & software asociado. )specialmente a la ora de confiurar más de un entorno de ardware;software en términos de 3ersiones del sistema operati3o% compiladores% na3eadores% etc.

?.!." Rerraientas de so%orte %ara las %rue*as est,ti&as (6!) 4as erramientas de prueba estática proporcionan una manera efecti3a de localiar más defectos en una etapa más temprana del proceso de desarrollo. •

Rerraientas de revisi'n. ◦

◦

◦

•

*e utilian para almacenar & comunicar comentarios de re3isi$n% informes sobre defectos & esfueros. Pueden ser3ir de a&uda para las re3isiones en l6nea de equipos randes o eoráficamente dispersos.

Rerraientas de an,lisis est,ti&o (1). ◦

◦

•

Vtiles en los procesos de re3isi$n% listas de comprobaci$n & directrices de re3isi$n.

&udan a los desarrolladores & probadores a localiar defectos antes de realiar pruebas dinámicas proporcionándoles soporte para aplicar las normas de codificaci$n (inclu&endo codificaci$n LseuraM% el análisis de las estructuras & las dependencias. Pueden ser tiles para planificar o analiar los riesos facilitando métricas para el c$dio (por eemplo% compleidad ciclomática.

Rerraientas de odelado (1). ◦

◦

*e utilian para 3alidar modelos de software (tales como modelos de datos f6sicos 9P&sical Gata 7odel ; PG79 de una base de datos relacional enumerando inconsistencias & localiando defectos.  menudo sir3en para enerar alunos casos de prueba basados en un modelo.

?.!.: Rerraientas de so%orte %ara la es%e&ifi&a&i'n de %rue*a (6!) Rerraientas de diseo de %rue*as. •

◦

•

*ir3en para enerar entradas de prueba o pruebas eecutables &;o oráculos de prueba a partir de requisitos% interfaces ráficas de usuario% modelos de dise/o (estado% dato u obeto o c$dio.

Rerraientas de %re%ara&i'n de datos de %rue*a. ◦

7anean bases de datos% arci3os o transmisiones de datos para confiurar los datos de prueba que se utilian durante la eecuci$n de pruebas con 3istas a arantiar la seuridad a tra3és del anonimato de los datos.

?.!.? Rerraientas de so%orte %ara la e
◦

◦

Beneralmente ofrecen un reistro de prueba para cada eecuci$n de una prueba.

◦

Pueden ser3ir para reistrar pruebas.

◦

•

#acilitan el proceso de pruebas en componentes o partes de un sistema simulando el entorno en el que se eecutará dico obeto de prueba% a tra3és de la creaci$n de obetos de imitaci$n 9moc@ obects9 como LstubsM o controladores.

Co%aradores de %rue*as. ◦

!

:ormalmente soportan lenuae de creaci$n de scripts o una confiuraci$n basada en BE0 para la parametriaci$n de datos & demás personaliaci$n durante las pruebas.

Arn3s de %rue*asKRerraientas de ar&o de tra*a
•

Permiten eecutar pruebas de manera automática% o semiautomática% utiliando entradas almacenadas & resultados esperados% a tra3és del uso de un lenuae de creaci$n de scripts.

)stablecen las diferencias entre arci3os% bases de datos o resultados de pruebas.

◦

◦

•

4os comparadores de pruebas pueden especialmente si están automatiados.

utiliar

oráculos

de

pruebas%

Rerraientas de edi&i'n de la &o*ertura (1). ◦

•

4as erramientas de eecuci$n de pruebas normalmente inclu&en comparadores dinámicos% pero la comparaci$n posterior a la eecuci$n a menudo debe acerse con una erramienta de comparaci$n separada.

 tra3és de medios intrusi3os o no intrusi3os% miden el porcentae de tipos espec6ficos de estructuras de c$dio que an sido practicados (por eemplo% sentencias% ramas o decisiones & llamadas a m$dulos o funciones por parte de un conunto de pruebas.

Rerraientas de %rue*as de se+uridad. ◦

◦

*ir3en para e3aluar las caracter6sticas de seuridad del software (como la capacidad de proteer la confidencialidad% interidad% autenticaci$n% autoriaci$n% disponibilidad o no repudio de los datos. *e centran principalmente en una tecnolo6a% plataforma & alcance espec6ficos.

?.!.@ Rerraientas de so%orte %ara el rendiiento 9 la onitoria&i'n (6!) Rerraientas de an,lisis din,i&o (1) •

◦

◦

•

:ormalmente se utilian en las pruebas de componente e interaci$n de componentes & en las pruebas de LmiddlewareM.

Rerraientas de %rue*as de rendiientoK%rue*as &ar+aK%rue*as de estr3s. ◦

◦

•

4ocalian defectos que pasan a ser e3identes s$lo una 3e que el software está eecutándose (tales como las dependencias de tiempo o las pérdidas de memoria.

7onitorian & reportan sobre el comportamiento de un sistema en una serie de condiciones de uso simuladas en términos de usuarios simultáneos% modelo de lanamiento (ramp9up% frecuencia & porcentae asociado de transacciones. 4a simulaci$n de cara se lora creando usuarios 3irtuales que lle3an a cabo una serie seleccionada de transacciones% esparcidos en distintas máquinas de prueba conocidos comnmente como eneradores de cara.

Rerraientas de onitoria&i'n. ◦

nalian% comprueban & reportan continuamente el uso de recursos espec6ficos del sistema & lanan a3isos sobre posibles problemas de ser3icio.

?.!. Rerraientas de so%orte %ara ne&esidades de %rue*as es%e&fi&as (6!) Evalua&i'n de la &alidad de los datos. •

◦

◦

•

"

4os datos son la piea cla3e de mucos pro&ectos% como los pro&ectos de con3ersi$n;miraci$n% & las aplicaciones (tales como los data wareouses & sus atributos pueden 3ariar en cuanto a criticidad & 3olumen. )n estos contextos% las erramientas deben emplearse para e3aluar la calidad con 3istas a re3isar & comprobar las relas de con3ersi$n & miraci$n de datos para arantiar que los datos procesados son correctos% completos & se austan a una norma predefinida espec6fica del contexto.

;tras >erraientas8 &oo las utiliadas %ara %rue*as de usa*ilidad8 et&.

?.2

Uso efe&tivo de las %oten&iales 9 ries+os (62)

Pruebas uiadas por datos

Pruebas uiadas por palabra cla3e

4enuae de creaci$n de scripts

>erraientas=

Jenta
-(cnica de creación de scripts que almacena la entrada de la prue"a y los resultados esperados en una ta"la o una *oja de c$lculo, de tal manera que un solo sc ript pueda ejecutar todas las prue"as de la ta"la. as prue"as guiadas por datos a menudo se utilizan para dar soporte en el uso de *erramientas de ejecución de prue"as, tales como *erramientas de captura/reproducción..

-(cnica de creación de scripts que utiliz a arc*ivos de datos para contener no solamente datos de prue"a y resultados esperados, sino tam"i(n pala"ras claves que est$n relacionadas con la aplicación que esta siendo pro"ada. as pala"ras cl aves son interpretadas por scripts especiales de soporte que son i nvocados por el script de control para la prue"a.

enguaje de programación en el cual se escri"en scripts de pr ue"a ejecuta"les para ser utilizados por una *erramienta de ejecución de prue"as 0por ejemplo una *erramienta de captura/reproducción1.

?.2.! Jentaerraientas de so%orte de %rue*as (%ara todas las >erraientas) (62) Jenta
•

•

•

>educci$n del trabao repetiti3o (por eemplo% en la eecuci$n de pruebas de reresi$n% la reintroducci$n de los mismos datos de prueba & la comprobaci$n contra estándares de codificaci$n. 7a&or consistencia & repetibilidad (por eemplo% las pruebas eecutadas por una erramienta en el mismo orden & con la misma frecuencia% & pruebas deri3adas de los requisitos. )3aluaci$n de los obeti3os (por eemplo% medidas estáticas% cobertura. #acilidad de acceso a la informaci$n sobre las pruebas (por eemplo% estad6sticas & ráficos sobre el a3ance de las pruebas% la frecuencia de incidencias & el rendimiento.

ies+os •

•

•

•

•

•

•

'

)xpectati3as poco realistas de la erramienta (inclu&endo funcionalidad & facilidad de uso. *ubestimaci$n de la cantidad de tiempo% coste & esfuero necesario para la introducci$n inicial de una erramienta (inclu&endo formaci$n & experiencia externa. *ubestimaci$n del tiempo & el esfuero necesarios para conseuir 3entaas sinificati3as & constantes de la erramienta (inclu&endo la necesidad de cambios en el proceso de pruebas & la meora continua de la forma en la que se utilia la erramienta. *ubestimaci$n del esfuero necesario para mantener los acti3os de prueba enerados por la erramienta. )xceso de confiana en la erramienta (sustituci$n para dise/o de pruebas o uso de pruebas automatiadas cuando ser6a meor lle3ar a cabo pruebas manuales. :o consideraci$n del control de 3ersi$n de los acti3os de prueba en la erramienta. :o consideraci$n de problemas de relaciones e interoperabilidad entre erramientas cr6ticas% tales como las erramientas de esti$n de requisitos% erramientas de

control de 3ersiones% erramientas de esti$n de incidencias% erramientas de seuimiento de defectos & erramientas procedentes de 3arios fabricantes. •

>ieso de que el fabricante de la erramienta cierre% retire la erramienta o 3enda la erramienta a otro pro3eedor.

•

7ala respuesta del fabricante para soporte% actualiaciones & correcci$n de defectos.

•

>ieso de suspensi$n del pro&ecto de c$dio abierto.

•

0mpre3istos% tales como la incapacidad de soportar una nue3a plataforma.

?.2.2 Considera&iones es%e&iales %ara al+unos ti%os de >erraientas (6!) Rerraientas de e
•

)ste enfoque no es escalable a randes cantidades de uiones de prueba automatiados. En ui$n capturado es una representaci$n lineal que inclu&e datos & acciones espec6ficos como parte de cada ui$n. )ste tipo de ui$n puede resultar inestable si se producen e3entos impre3istos.

Un enfo-ue de %rue*as +uiadas %or datos  separa las entradas de las pruebas (los datos% normalmente en una oa de datos% & se sir3e de un script de prueba más enérico que pueda leer los datos de entrada & eecutar el mismo script de prueba con distintos datos. •

4os probadores que no están familiariados con el lenuae de creaci$n de scripts de este modo pueden crear los datos de prueba para estos scripts predefinidos.

simismo% en las técnicas uiadas por datos se utilian otras técnicas en las que% en luar de colocar en una oa de datos combinaciones de datos codificadas% los datos se eneran utiliando aloritmos en base a parámetros confiurables en el momento de la eecuci$n & facilitados a la aplicaci$n. •

s6% por eemplo% una erramienta puede utiliar un aloritmo que enere una identificaci$n de usuario aleatoria% & a efectos de repetibilidad del modelo% se utilia una semilla para controlar la aleatoriedad.

)n un enfo-ue de %rue*as +uiado %or %ala*ras &lave % la oa de datos contiene las palabras cla3e que describen las acciones a adoptar (también conocidas como palabras de acci$n & datos de prueba. •

4os probadores (a pesar de no estar familiariados con el lenuae de creaci$n de scripts pueden entonces definir pruebas utiliando las palabras cla3e% las cuales pueden austarse a la aplicaci$n en pruebas.

Para todos los enfoques es necesario contar con experiencia técnica en el ámbito del lenuae de creaci$n de scripts (tanto por parte de los probadores como por parte de los especialistas en la automatiaci$n de pruebas. 0ndependientemente de la técnica de LscriptinM utiliada% los resultados esperados para cada prueba deben almacenarse para su posterior comparaci$n. Rerraientas de an,lisis est,ti&o 4as erramientas de análisis estático aplicadas al c$dio fuente pueden aplicar estándares de codificaci$n% pero si se aplican a un c$dio existente% pueden enerar una ran cantidad de mensaes.

5

4os mensaes de ad3ertencia no impiden que el c$dio se traduca en un prorama eecutable% pero idealmente deber6an tratarse de manera que faciliten el mantenimiento del c$dio en el futuro. 4a implementaci$n radual de la erramienta de análisis con filtros iniciales para excluir ciertos mensaes constitu&e un enfoque efecti3o. Rerraientas de +esti'n de %rue*as 4as erramientas de esti$n de pruebas tienen que interactuar con otras erramientas u oas de datos para producir informaci$n til en un formato que se auste a las necesidades de la oraniaci$n.

?.7 Introdu&&i'n de una >erraienta en una or+ania&i'n (6!) :inn término espec6fico. Consideraciones a tener en cuenta a la ora de seleccionar una erramienta para una oraniaci$n= •

•

•

•

•

•

•

nálisis de la madure oraniati3a% fortaleas & debilidades e identificaci$n de las oportunidades para un proceso de pruebas meorado soportado por erramientas. )3aluaci$n frente a requisitos claros & criterios obeti3os. Ena prueba de concepto% utiliando una erramienta de prueba durante la fase de e3aluaci$n para establecer si rinde de manera eficiente con el software obeto de la prueba & dentro de la actual infraestructura o para identificar los cambios necesarios en dica infraestructura para utiliar la erramienta de manera efecti3a. )3aluaci$n del fabricante (inclu&endo formaci$n% soporte & aspectos comerciales o soporte de ser3icio a pro3eedores en caso de erramientas no comerciales. 0dentificaci$n de requisitos internos para impartir LcoacinM & formaci$n sobre el uso de la erramienta. )3aluaci$n de las necesidades de formaci$n abida cuenta de las abilidades de automatiaci$n de pruebas del equipo de pruebas. Cálculo de un ratio coste9beneficio en base a un caso de neocio concreto.

Para introducir la erramienta seleccionada en una oraniaci$n debe lanarse un pro&ecto piloto% cu&os obeti3os son los siuientes= •

•

•

•

prender más detalles sobre la erramienta. )3aluar la forma en la que la erramienta se austa a los procesos & prácticas existentes% & determinar qué debe cambiar. Gecidir las formas estándar en las que se debe utiliar% estionar% almacenar & mantener la erramienta & los acti3os de prueba (por eemplo% decidir sobre la desinaci$n de arci3os & pruebas% la creaci$n de bibliotecas & definir la modularidad de los ueos de pruebas. 8alorar si se lorarán los beneficios a un coste raonable.

4os factores de éxito para el desplieue de la erramienta dentro de una oraniaci$n inclu&en= •



Dacer extensi3a la erramienta al resto de la oraniaci$n de una manera incremental.

•

daptar & meorar los procesos para adaptarlos al uso de la erramienta.

•

0mpartir formaci$n & LcoacinM;tutor6as a los nue3os usuarios.

•

Gefinir las directrices de uso.

•

+

plicar una forma de recopilar informaci$n sobre el uso de la erramienta a partir de su uso real.

•

Dacer un seuimiento del uso & de los beneficios de la erramienta.

•

Proporcionar soporte al equipo de pruebas para una erramienta dada.

•

>ecopilar las lecciones aprendidas de todos los equipos.

ANE; IEEE 2$ N;A PAA LA 1;CUENTACIHN 1E PUEBAS S;FTAE *ecciones plantilla de es%e&ifi&a&i'n de diseo de %rue*as •

Identifi&ador de la especificaci$n del dise/o de pruebas.

•

Cara&tersti&as -ue de*en ser %ro*adas (mediante este ueo de pruebas.

•

•

•

Criterios de %asoKfalla de las &ara&tersti&as (p.e% oráculo de pruebas% base de pruebas% sistemas eredados% etc.. efinaientos del 3todo (técnicas espec6ficas% erramientas% etc.. Identifi&a&i'n de las %rue*as (traabilidad de los casos de prueba en el ueo de pruebas.

*ecciones plantilla de es%e&ifi&a&i'n de &aso de %rue*a •

Identifi&ador de la especificaci$n del caso de prueba.

•

0tesKEleentos de %rue*as (lo que tiene que ser entreado & probado.

•

Es%e&ifi&a&iones de las entradas (entradas del usuario% arci3os% etc..

•

•

•

•

Es%e&ifi&a&iones de las salidas (resultados esperados% inclu&endo pantallas % arci3os% tiempo% etc.. Ne&esidades del entorno (ardware% software% personas% accesorios% N. e-uisitos es%e&iales de %ro&ediiento (inter3enci$n del operador% permisos% N. 1e%enden&ias entre &asos (si es necesario para establecer condiciones pre3ias.

*ecciones plantilla de es%e&ifi&a&i'n de %ro&ediiento de %rue*a •

Identifi&ador de la especificaci$n del procedimiento de prueba.

•

Pro%'sito.

•

e-uisitos es%e&iales (abilidades% permisos% entorno% etc..

•

Pasos del %ro&ediiento.

*ecciones del %lan de %rue*as !. 0dentificador del plan de pruebas. 2. 0ntroducci$n. 7. 0tes (eleentos de %rue*a). ". Cara&tersti&as a %ro*ar K -ue no de*en ser %ro*adas. :. 3todoKEnfo-ue de %rue*a (implementaci$n de la estrateia de prueba para el pro&ecto. ?. Criterios %asoKfalla del te. @. Criterios de entrada8 salida8 sus%ensi'n8 reanuda&i'n. . Entre+a*les de las %rue*as.

,

$. TareasKRitos &lave de las %rue*as. !. Crono+raa. !!. Ne&esidades del entorno. !2. es%onsa*ilidades. !7. 1ota&i'n de %ersonal 9 ne&esidades de &a%a&ita&i'n. !". ies+os (de calidad de %rodu&to 9 de %ro9e&to. !:. probaciones. Se&&iones infore de resuen de %rue*as !. 0dentificador del informe. 2. esuen (lo -ue fue %ro*ado8 ...). 7. JarianasK1esvia&iones (del %lan8 de los &asos...). ". Evalua&i'n &o%rensiva. :. esuen de resultados (3tri&as finales8 &'%utos8...). ?. Evalua&i'n (de &ada te de %rue*a &on rela&i'n a los &riterios de %asoKfalla). @. esuen de las a&tividades (utilia&i'n de los re&ursos8 efi&ien&ia8 ...). . A%ro*a&i'n. *ecciones re+istro de %rue*as !. Identifi&ador del re+istro de %rue*as. 2. La des&ri%&i'n de las %rue*as (6tems sometidos a prueba 3ersionados% entornos de prueba utiliados% N. 7. 1atos de a&tividades 9 eventos  (descritos prueba tras prueba & e3ento tras e3ento. Infore de transisi'n de los tes de %rue*as (&oOnente llaado notas de versiones) describe los 6tems que deben ser entreados para las pruebas. Se&&iones del infore de transisi'n de los tes de %rue*as se+On IEEE 2$ = !. Identifi&ador del infore. 2. Los tes transitidos (inclu&endo nombres de los 6tems & nmeros de re3isi$n. 7. El lu+ar (u*i&a&i'n) del obeto o 6tem de pruebas. ". El estado del o*a de e5%edi&i'n  (creador;informante.

(creaci$n%

or+ania&i'n

b esultados es%erados 9 resultados reales.

-

eisora

9

autor