Date post: | 28-Jun-2015 |
Category: |
Technology |
Upload: | irene-pazos-viana |
View: | 1,595 times |
Download: | 0 times |
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
[email protected] 23-ago-10 3
Pruebas de Software
agenda: viernes
1. fundamentos2. valor agregado3. procesos4. probando5. la gente
[email protected] 23-ago-10 4
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??
[email protected] 23-ago-10 5
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” ?
[email protected] 23-ago-10 6
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?
[email protected] 23-ago-10 7
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)
[email protected] 23-ago-10 8
fundamentos
en software, cuanto cuesta la etiqueta ?“probado para 100 empujones de 500 Newton”
~ +30 %del esfuerzo de desarrollo
[email protected] 23-ago-10 9
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??
[email protected] 23-ago-10 10
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
[email protected] 23-ago-10 11
Pruebas de Software
agenda: viernes
1. fundamentos2. valor agregado3. procesos4. probando5. la gente
[email protected] 23-ago-10 12
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
[email protected] 23-ago-10 13
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 !!)
[email protected] 23-ago-10 14
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 !!!
[email protected] 23-ago-10 15
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
[email protected] 23-ago-10 16
Pruebas de Software
agenda: viernes
1. fundamentos2. valor agregado3. procesos4. probando5. la gente
[email protected] 23-ago-10 17
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
[email protected] 23-ago-10 18
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)
[email protected] 23-ago-10 19
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
[email protected] 23-ago-10 20
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 -
[email protected] 23-ago-10 21
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
[email protected] 23-ago-10 22
Pruebas de Software
agenda: viernes
1. fundamentos2. valor agregado3. procesos4. probando5. la gente
[email protected] 23-ago-10 23
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
[email protected] 23-ago-10 24
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
[email protected] 23-ago-10 25
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.
[email protected] 23-ago-10 26
probandoIEEE 829 Standard for Software Test Documentation
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.
[email protected] 23-ago-10 27
probandoIEEE 829 Standard for Software Test Documentation
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.
[email protected] 23-ago-10 29
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?
[email protected] 23-ago-10 30
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.
[email protected] 23-ago-10 31
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.
[email protected] 23-ago-10 32
probando: clases & técnicas
la prueba demuestra la presencia de fallas, nunca su
ausencia
Dijkstra
[email protected] 23-ago-10 33
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...
[email protected] 23-ago-10 34
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
[email protected] 23-ago-10 35
probando: clases de pruebas
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, ..
[email protected] 23-ago-10 36
probando: clases de pruebas
prueba de componentes
pruebas de modulos, recorriendo estados, transiciones, decisiones, verificandodatos de entrada y salida, integridad.
[email protected] 23-ago-10 37
probando: clases de pruebas
prueba de integración
correctitud en interfases, entrega de funcionalidad modular, integridad de datos, tiempos de respuesta, volumen, condiciones limite.
[email protected] 23-ago-10 38
probando: clases de pruebas
prueba de sistema
alcance, verificacion y validacion funcional, usabilidad, operabilidad, seguridad, documentación.
[email protected] 23-ago-10 39
probando: clases de pruebas
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)
[email protected] 23-ago-10 40
probando: clases de pruebas
prueba de instalación
gestión de configuración, portabilidad, parametrización, ambientes, licencias de productos, seguridad.
[email protected] 23-ago-10 41
probando: clases de pruebas
prueba de regresión
funcionalidad mantiene sus atributos de calidad, según comportamiento previo.
[email protected] 23-ago-10 42
probando: clases de pruebas
pruebas funcionales
validan comportamiento de atributos de software según especificación de casosde uso (o equivalente)
[email protected] 23-ago-10 43
probando: clases de pruebas
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)
[email protected] 23-ago-10 44
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)
[email protected] 23-ago-10 45
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
[email protected] 23-ago-10 46
probando: técnicas
solo en casos críticos
costoso (imposible), generar universo total de recorridos para dominio completo de datos
prueba exhaustiva
[email protected] 23-ago-10 47
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
[email protected] 23-ago-10 48
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
[email protected] 23-ago-10 49
probando: técnicas
técnica de amplio uso
comportamiento entrada/salida: cómo se implementa es conceptualmente invisible para tester
caja negra
[email protected] 23-ago-10 50
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
[email protected] 23-ago-10 51
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
[email protected] 23-ago-10 52
Pruebas de Software
agenda: viernes
1. fundamentos2. valor agregado3. procesos4. probando5. la gente
[email protected] 23-ago-10 54
la genteatributos personales
• cuestionador• ingenioso• metódico• curioso• sistemático• detallista• habilidades de comunicación• motivado
[email protected] 23-ago-10 55
la genteatributos técnicos
• conocimiento procesos de calidad• técnicas de prueba• experiencia práctica• conocimiento de dominio negocio• conocimiento técnico hard / soft
[email protected] 23-ago-10 56
la genteroles
• responsable de pruebasgerente de proyecto
• diseñador casosespecifica casos según requerimientosdetalla procedimiento y pasos
• implementador (tester)ejecuta especificación
[email protected] 23-ago-10 57
la genteroles
• revisorresponsable por ejecutar revisiones
• coordinador revisionesplanifica, prepara, implementa revisión
• especialista de dominioexperto de negocio
• especialista de herramientassoporte técnico, configuración, ..
[email protected] 23-ago-10 58
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 de pruebasde Software
taller
[email protected] 23-ago-10 60
Pruebas de Software
agenda: sábado
1. repaso?2. ejersicios3. laboratorios en grupos
[email protected] 23-ago-10 62
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
[email protected] 23-ago-10 64
Pruebas de Software
plan de pruebas
1. stakeholders2. equipo de pruebas del proyecto3. responsable de calidad4. negocio (es un activo)
[email protected] 23-ago-10 66
Pruebas de Software
roles
1. responsable de pruebas2. analista de pruebas3. diseñador4. tester5. coordinador de revisiones6. revisor técnico7. especialista herramientas/ambientes
[email protected] 23-ago-10 68
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
[email protected] 23-ago-10 69
Pruebas de Software
ejercicio:
escribir(se) un mini-instructivo de pasos a seguir
(ej. tenemos nuevo ayudante )
[email protected] 23-ago-10 70
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
[email protected] 23-ago-10 71
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.
Taller de pruebasde Software
[email protected] 23-ago-10 73