2010 08-06-ieee-salto-soft tst

6 y 7 de Agosto 2010

Irene Pazos VianaCoordinadora Académica IEEE Sección [email protected]

memberIEEE Standadrs Associationmember

IEEE Uruguay - sub.Sección Litoral

Taller de pruebasde Software

[email protected] 23-ago-10 2

Pruebas de Software

• viernes 6 de Agosto18:30hs – 20:30hspresentación teóricaCalidad, Costo, Verificacion & Validacion, Anomalías, Técnicas, Casos & Escenarios, Recursos & Roles, Cliclo de Vida.

• sábado 7 de Agosto09:00hs – 12:00hstaller práctico


Pruebas de Software

agenda: viernes

1. fundamentos2. valor agregado3. procesos4. probando5. la gente


fundamentos

empecemos por el final …(porque hay que empezar convencido)

Hola (con quien hablo?), dígame … por qué vino?

“testing”, es una moda, o que??


fundamentos

pongamos un caso de prueba …

pagaría más por un valija quese ve igual a otra, pero tiene

una etiqueta que dice “probado con 100 empujones de 500 Newton” ?


fundamentos

ok …. cuanto más pagaría ?

• lo mismo que un seguro de viaje, porreposición de una valija dañada?

• lo que de veras le costaría si en el aeropuerto de *@#$! pierde viajes a causa de una valija que ademásperdió la mitad del contenido?


fundamentos

bueno, … todo depende de qué valija y qué situación

• si es la mochila de la escuela, con tres lápices … casi no importa

• si es la valija de transporte de caudales, pagará casi infinito(nunca el costo extra en la valija, será más quelo que se pierda, si falla la valija)


fundamentos

en software, cuanto cuesta la etiqueta ?“probado para 100 empujones de 500 Newton”

~ +30 %del esfuerzo de desarrollo


fundamentos

“testing” = “seguro” pagado por negocio paragarantizar su producto

• sector de mercado laboral creciente

• agrega valor a producto de negocio

“testing”, es una moda, o que??


fundamentos

+costo de 30% … (glup)…ok, qué dice la etiqueta !???

“probado para 100 empujones de 500 Newton”

o dice algo como

“ohh, que software más hermoso, me parece que funciona super bien”

pruebas agregan valor


Pruebas de Software

agenda: viernes



valor agregadohay “newtons” o “joules” de software?

mtbf, throughput, ..

• medida estándar que permite comparar tamaño en software: “puntos funcionales” (www.ifpug.org)

• cuantificación ad-hoc de calidad(ratios: casos vs.alcance, evolución fallasdetectadas por fase …)

vol. datos x unidad de tiempo en

sistema

mean time between failure


valor agregadohay “newtons” o “joules” de software?

automóvil : GARANTÍA: 6 meses o 30.000 km

• velocidad (km/hora)• rendimiento (km/litro)• capacidad (lts)• potencia, autonomía, …

sofware : GARANTÍA: lo que no dice el contrato

• lo que diga el contrato

(NO !!)


valor agregadocomo garantizar el valor de la prueba !?

calidad

adherencia (objetiva) a requisitosformalmente especificados.

conformidad con requisitos definidamediante PROCESOS formales quealcanzan todo el ciclo del producto.

estándares !!!


valor agregado & IEEE

Software Engineering / testing

- IEEE 610 Standard Glossary of Software Engineering Terminology.- IEEE 730 Standard for software quality assurance plans- IEEE 829 Standard for Software Test Documentation. (*) .- IEEE 1008 Standard for Software Unit Testing (*).- IEEE 1012 Standard for Verification and Validation Plans- IEEE 1028 Standard for Software Reviews and Audits.- IEEE 1044 Standard Classification for Software Anomalies.- IEEE 1044-1 Guide to Classification for Software Anomalies.- IEEE 1061 Standard for software quality metrics and methodology.- IEEE 1219 Software Maintenance.- IEEE 12207 Standard for software life cycle processes and life cycle data

Active Working Groups (*)Software and Systems Engineering Standards Committee (S2ESC)

120 pag.

procesos estandarizados


Pruebas de Software

agenda: viernes



procesos …

negocio

desarrollo ( proceso muy simplificado )

pruebas

CAPACITACIÓNMGT. REQ. CLIENTE

PLAN & DEV. ACTIVOSEJECUCIÓN TST

MANTENIM. ACTIVOS

MGT. ANOMALIASEVOL. MÉTRICAS

contexto: de negocio, de desarrollo, de pruebas, …

REQUERIMIENTOS DESARROLLO PRUEBAS

valor agregado en actividades primarias de cadena de valor

ENTREGA & SERVICIO


procesos de pruebasinsumo principal es TRABAJO HUMANO

usual en pruebas:…hay que entregar, probemos esto y después anotamos…

• pobre documentación de alcance (esto había que probarlo ahora?)

• evolución sin baseline (que había dado ayer?)

• resultados irrepetibles (y cómo hiciste para que saliera ese mensaje??)

• pruebas no transportables entre equipos, proyectos, tiempo.

• CERO REUSO de activos (inventa la pólvora todos los días)


procesos de pruebasinsumo principal es TRABAJO HUMANO

lo necesario en pruebas:• capacitación en procesos propios

(procesos formalizados, resultados consistentes, rotación !?)

• mantenimiento de activos de pruebas (especialmente ↑ vol. casos)

• normalizar gestión alcance, cobertura, metodología,..

resultado sin respaldo formal tiene limitado valor


procesos formales

resultado de proceso formal

“probado para 100 empujones de 500 Newton”

resultado informal

“cayó por la escalera y quedó bien”

pruebas agregan valor

esto parece mas un cuento chino que una garantía- si esta es la información que me puede proveer el fabricante, yo

desconfío del producto !! -

esta información agrega valor- refiere a un procedimiento concreto y un resultado objetivo comprensible -


procesos formales

agregar valor con resultados de pruebas, exige una

ENORMEinversión que negocio hace,

presupuestando RECURSOS que tienenla responsabilidad de RESPALDAR la

calidad de los productos.

insumo principal es TRABAJO HUMANO


Pruebas de Software

agenda: viernes



probando: ciclo de procesos

• CAPACITACIÓN costo aprendizaje, rotación• MGT. REQUERIMIENTOS gestión de alcance (+2% mth)

activos de cliente

• PLAN & DEV. ACTIVOS plan, casos, condiciones, dta, resultados, rpts, evidencias

• EJECUCIÓN ambientes, captura resultados

• MANTENIMIENTO trazabilidad, customer rqst. updbaselines, resultados

• MGT. ANOMALÍAS novedades, recurrencia• EVOL. MÉTRICAS indicadores, mediciones (+10%)

PROCESOS: activos críticos de pruebas, para negocio

logí

stic

ain

tern

aop

erac

ion

logí

stic

aex

tern

a


probandodocumentación

resultados independientes de personas

• actividades y procesos conocidosformalizados, estables …

• entregables por fase identificadosrequerimientos de usuario, baselines, resultados, plan de pruebas, alcance, cobertura, casos, condiciones, ambientes, datos, anomalias …

• trazabilidad en activoscasos vs. requerimientos, resultados vs. casos, anomalias vs.resultados

• indicadores evolución calidad


probandoIEEE 829 Standard for Software Test Documentation

definiciones• pass/fail criteria: Decision rules used to determine whether a software

item or a software feature passes or fails a test.

• software feature: A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).

• software item: Source code, object code, job control code, control data, or a collection of these items.

• test: A set of one or more test cases, or A set of one or more test procedures, or A set of one or more test cases and procedures.

• testing: The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.



definiciones• test case specification: A document specifying inputs, predicted

results, and a set of execution conditions for a test item.

• test design specification: A document specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.

• incident report: A document reporting on any event that occurs during the testing process which requires investigation.

• test item: A software item which is an object of testing.

• test item transmittal report: A document identifying test items. It contains current status and location information.

• test log: A chronological record of relevant details about the execution of tests.



definiciones• test plan: A document describing the scope, approach, resources, and

schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

• test procedure specification: document specifying a sequence of actions for the execution of a test.

• test summary report: A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items.


probandodefiniciones

• validación (~ estático)IEEE - the process of evaluating a system or component during or ath the end of development process to determine whether it satisfies specified requirements.Bohem – estamos construyendo el producto correcto?

• verificación (~ dinámico)IEEE - the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of the phase.Bohem – estamos construyendo el producto correctamente?


probandodefiniciones - IEEE 610, IEEE 1008, IEEE 1044

anomalyAny condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation.

defect (fault, problem)A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encounteredduring execution, may cause a failure of the component or system.


probandodefiniciones - IEEE 610, IEEE 1008, IEEE 1044

errorA human action that produces an incorrect result.

error seedingThe process of intentionally adding known defects to those already in the component or system for the purpose of monitoring the rate of detection and removal, and estimating the number of remaining defects.

failureDeviation of the component or system from its expected delivery, service or result.

incidentAny event occurring that requires investigation.


probando: clases & técnicas

la prueba demuestra la presencia de fallas, nunca su

ausencia

Dijkstra


probando: clases & técnicas

• distintas clases de pruebas se aplican, usando diferentes tecnicas, según fase de avance del proyecto

fases en ciclo de vida proyecto

t

pruebaunitaria

pruebaaceptación

pruebaintegración …

revisión ... dinámicas rendimiento...


probando: clases de pruebas

pruebas unitarias, de componentes, de integración, de sistema, de aceptación, de instalación, regresión.

• funcional (casos )• desempeño (no funcionales, calidad)

• seguridad, confiabilidad, usabilidad• rendimiento,stress, volumen• configuración, recuperación



prueba unitaria

según la fase, las piezas sometidas a pruebas individuales serándocumentos (alcance/requerimientos, especificación casos uso,..), piezas de código (drivers, funciones de cálculo, seguridad,.. ), prototipos, ..



prueba de componentes

pruebas de modulos, recorriendo estados, transiciones, decisiones, verificandodatos de entrada y salida, integridad.



prueba de integración

correctitud en interfases, entrega de funcionalidad modular, integridad de datos, tiempos de respuesta, volumen, condiciones limite.



prueba de sistema

alcance, verificacion y validacion funcional, usabilidad, operabilidad, seguridad, documentación.



prueba de aceptación

concordancia de sistema con criterios y condiciones de aceptación.

(si no hay criterios y condiciones, …es todo lo que el cliente quiera y espere)



prueba de instalación

gestión de configuración, portabilidad, parametrización, ambientes, licencias de productos, seguridad.



prueba de regresión

funcionalidad mantiene sus atributos de calidad, según comportamiento previo.



pruebas funcionales

validan comportamiento de atributos de software según especificación de casosde uso (o equivalente)



pruebas atributos de calidadpruebas no-funcionales

se realizan para asegurar condiciones de seguridad (ethical hacking), confiabilidad, usabilidad, rendimiento, stress, volumen, configuración, recuperación (COB)


probando: técnicas

• análisis de código (herram.autom.)• revisión/inspección (presentación)• walktrhough (corrida simulada)

• cobertura, estados (código, decisiones,

transiciones)


probando: técnicas

• prueba exhaustiva (crítico)

• clases de equivalencia• caja negra (limite, clases)

• caja blanca (complejidad ciclomática)

otras herramientas• tablas de decisión, diagrama Ishikawa,

camino crítico, smoke test, defect injection


probando: técnicas

solo en casos críticos

costoso (imposible), generar universo total de recorridos para dominio completo de datos

prueba exhaustiva


probando: técnicas

proceso de revisión formal outline

1. planificación (team, material)2. presentación de material3. revisión4. corrección5. seguimiento6. (pgm.nueva revisión)

revisión/inspección


probando: técnicas

relación de equivalencia R en un conjunto Ksi cumple propiedades reflexiva, simétrica y transitiva

clases de equivalencia de R en Ksub-conjuntos: ki de K, { kx en K / kx R ki }

K - rectas, personas, enteros,

R - paralelismo, parientes, igualdad, menor-que, mayor-que

clases de equivalencia


probando: técnicas

técnica de amplio uso

comportamiento entrada/salida: cómo se implementa es conceptualmente invisible para tester

caja negra


probando: técnicas

complejidad ciclomáticamétrica de software

proporciona medición cuantitativa de la complejidad de un programa. (Es una de las métricas de software de mayor aceptación, por ser concebida en forma independiente del lenguaje).

El resultado obtenido define el número de caminos independientes dentro de un fragmento de código y determina la cota superior del número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

La medida resultante puede ser utilizada en el desarrollo, mantenimiento y reingeniería para estimar el riesgo, costo y estabilidad. Algunos estudios experimentales indican la existencia de distintas relaciones entre la métrica de McCabe y el número de errores existentes en el código fuente, asícomo el tiempo requerido para encontrar y corregir esos errores.

caja blanca


probando: técnicas

• diagrama Ishikawa• camino crítico• tablas de decisión (Boole)• smoke test• defect injection• automatización (otra historia…!!!

arquitectura datos consumibles, escenarios, ..)

otras herramientas


Pruebas de Software

agenda: viernes



la genteroles & actividades


la genteatributos personales

• cuestionador• ingenioso• metódico• curioso• sistemático• detallista• habilidades de comunicación• motivado


la genteatributos técnicos

• conocimiento procesos de calidad• técnicas de prueba• experiencia práctica• conocimiento de dominio negocio• conocimiento técnico hard / soft


la genteroles

• responsable de pruebasgerente de proyecto

• diseñador casosespecifica casos según requerimientosdetalla procedimiento y pasos

• implementador (tester)ejecuta especificación


la genteroles

• revisorresponsable por ejecutar revisiones

• coordinador revisionesplanifica, prepara, implementa revisión

• especialista de dominioexperto de negocio

• especialista de herramientassoporte técnico, configuración, ..


la genteteamwork

• misma persona, varios roles• crítico en equipo:

coodinacióncomunicación -personal & escrita-

• los resultados, son de procesos quetodos ejecutan –si falla uno, fallan todos-


taller


Pruebas de Software

agenda: sábado

1. repaso?2. ejersicios3. laboratorios en grupos


Pruebas de Software

ejercicio:

de donde sacar casos de prueba ?


Pruebas de Software

casos de prueba

1. regresión, errores “conocidos”2. usuario experto3. funcionalidades críticas4. funcionalidad inestable, novedades5. atributos de calidad (seguridad,uso,..)6. sistemas similares


Pruebas de Software

ejercicio:

para quién es el plan de pruebas ?


Pruebas de Software

plan de pruebas

1. stakeholders2. equipo de pruebas del proyecto3. responsable de calidad4. negocio (es un activo)


Pruebas de Software

ejercicio:

que roles distinguimos en prueba ?


Pruebas de Software

roles

1. responsable de pruebas2. analista de pruebas3. diseñador4. tester5. coordinador de revisiones6. revisor técnico7. especialista herramientas/ambientes


Pruebas de Software

ejercicio:

lista de activos que necesitaremos ?


Pruebas de Software

lista de activos de pruebas

1. alcance2. casos de pruebas3. instructivos operativos (ambiente,

perfiles, …) 4. datos para casos y escenarios5. registro de resultados ejecución6. registro de anomalías, métricas7. formato de informe


Pruebas de Software

ejercicio:

escribir(se) un mini-instructivo de pasos a seguir

(ej. tenemos nuevo ayudante )


Pruebas de Software

instructivo pasos de prueba

1. actualizar alcance - estado de asignación2. completar caso de prueba según formato3. preparar ambiente según instructivos

operativos (ambiente, perfiles, …) 4. documentar datos para caso y escenarios5. ejecutar pruebas para caso6. registar resultados en formato7. registrar anomalías y métricas en planilla8. preparar y enviar informe según formato


Pruebas de Software

laboratorios

1. tester?? … descripción de puesto2. a trabajar! … llamado a postulantes3. quien sirve?? … entrevistas4. test the tester quiz

IEEE UruguaySub. sección Litoral

Viernes 6 de agosto - 18:30 a 20:30 Sábado 7 de agosto - 09:00 a 12:00Universidad Católica, Artigas 1251 – Salón de actos.


2010 08-06-ieee-salto-soft tst

Technology

Transcript of 2010 08-06-ieee-salto-soft tst