La IEEE Uruguay (Institute of Electrical and Electronics Engineers), sub-sección Litoral invita al Taller de Pruebas de Software que habrá de desarrollarse los días 6 y 7 de Agosto próximos en el salón de actos de la Universidad Católica en Artigas 1251. Este taller lo dictará la A/S Irene Pazos Viana, profesional de amplísima pericia en el campo. Consultora e instructora con experiencia internacional y participación en múltiples proyectos de desarrollo, implementación e investigación. Ha trabajado con empresas de gran porte, implementando procesos y participando como evaluador en certificaciones de madurez y calidad. Actualmente lidera un portafolio de proyectos de tecnología informática, en consultoría de mejora de procesos, metodología para gestión de proyectos y de calidad. Miembro del IEEE por 20 años, actualmente es Coordinadora Académica de la Sección Uruguay, y participa como voluntaria en grupos de trabajo de revisión de estándares para la IEEE Standards Association.

1. Taller de pruebas
de Software
IEEE Uruguay - sub.Sección Litoral
6 y 7 de Agosto
2010
Irene Pazos Viana
Coordinadora Académica IEEE Sección Uruguay
ipazos@ieee.org member
IEEE Standadrs Association
member

2. Pruebas de Software
• viernes 6 de Agosto
18:30hs – 20:30hs
presentación teórica
Calidad, Costo, Verificacion & Validacion, Anomalías, Técnicas,
Casos & Escenarios, Recursos & Roles, Cliclo de Vida.
• sábado 7 de Agosto
09:00hs – 12:00hs
taller práctico
ipazos@ieee.org 23-ago-10 2

3. Pruebas de Software
agenda: viernes
1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente
ipazos@ieee.org 23-ago-10 3

4. fundamentos
“testing”, es una moda, o que??
empecemos por el final …
(porque hay que empezar convencido)
Hola (con quien hablo?),
dígame … por qué vino?
ipazos@ieee.org 23-ago-10 4

5. fundamentos
pongamos un caso de prueba …
pagaría más por un valija que
se ve igual a otra, pero tiene
una etiqueta que dice
“probado con 100 empujones de 500 Newton” ?
ipazos@ieee.org 23-ago-10 5

6. fundamentos
ok …. cuanto más pagaría ?
• lo mismo que un seguro de viaje, por
reposició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ás
perdió la mitad del contenido?
ipazos@ieee.org 23-ago-10 6

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 que
lo que se pierda, si falla la valija)
ipazos@ieee.org 23-ago-10 7

8. fundamentos
en software, cuanto cuesta la etiqueta ?
“probado para 100 empujones de 500 Newton”
~ +30 %
del esfuerzo de desarrollo
ipazos@ieee.org 23-ago-10 8

9. fundamentos
“testing”, es una moda, o que??
“testing” = “seguro” pagado por negocio para
garantizar su producto
• sector de mercado laboral creciente
• agrega valor a producto de negocio
ipazos@ieee.org 23-ago-10 9

10. fundamentos
pruebas agregan valor
+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”
ipazos@ieee.org 23-ago-10 10

11. Pruebas de Software
agenda: viernes
1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente
ipazos@ieee.org 23-ago-10 11

12. valor agregado
mean time
between failure
hay “newtons” o “joules” de software?
vol. datos x unidad
de tiempo en
sistema
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 fallas
detectadas por fase …)
ipazos@ieee.org 23-ago-10 12

13. valor agregado
hay “newtons” o “joules” de software? (NO !!)
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
ipazos@ieee.org 23-ago-10 13

14. valor agregado
como garantizar el valor de la prueba !?
calidad
adherencia (objetiva) a requisitos
formalmente especificados.
estándares !!!
conformidad con requisitos definida
mediante PROCESOS formales que
alcanzan todo el ciclo del producto.
ipazos@ieee.org 23-ago-10 14

15. valor agregado & IEEE
procesos estandarizados
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. (*) .
120 pag.
- 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)
ipazos@ieee.org 23-ago-10 15

16. Pruebas de Software
agenda: viernes
1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente
ipazos@ieee.org 23-ago-10 16

17. procesos …
contexto: de negocio, de desarrollo, de pruebas, …
valor agregado en actividades primarias de cadena de valor
negocio
desarrollo ( proceso muy simplificado )
REQUERIMIENTOS DESARROLLO PRUEBAS ENTREGA &
SERVICIO
pruebas
PLAN & DEV. ACTIVOS
CAPACITACIÓN MGT. ANOMALIAS
EJECUCIÓN TST
MGT. REQ. CLIENTE EVOL. MÉTRICAS
MANTENIM. ACTIVOS
ipazos@ieee.org 23-ago-10 17

18. procesos de pruebas
insumo 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)
ipazos@ieee.org 23-ago-10 18

19. procesos de pruebas
insumo 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
ipazos@ieee.org 23-ago-10 19

20. procesos formales
pruebas agregan valor esta información agrega valor
- refiere a un procedimiento concreto y
un resultado objetivo comprensible -
resultado de proceso formal
“probado para 100 empujones de
500 Newton”
resultado informal
“cayó por la escalera y quedó bien”
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 !! -
ipazos@ieee.org 23-ago-10 20

21. procesos formales
insumo principal es TRABAJO HUMANO
agregar valor con resultados de
pruebas, exige una
ENORME
inversión que negocio hace,
presupuestando RECURSOS que tienen
la responsabilidad de RESPALDAR la
calidad de los productos.
ipazos@ieee.org 23-ago-10 21

22. Pruebas de Software
agenda: viernes
1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente
ipazos@ieee.org 23-ago-10 22

23. probando: ciclo de procesos
PROCESOS: activos críticos de pruebas, para negocio
logística interna
• 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,
operacion
•
captura resultados
• MANTENIMIENTO trazabilidad, customer rqst. upd
baselines, resultados
• MGT. ANOMALÍAS novedades, recurrencia
logística
externa
• EVOL. MÉTRICAS indicadores, mediciones (+10%)
ipazos@ieee.org 23-ago-10 23

24. probando
documentación
resultados independientes de personas
• actividades y procesos conocidos
formalizados, estables …
• entregables por fase identificados
requerimientos de usuario, baselines, resultados, plan de pruebas,
alcance, cobertura, casos, condiciones, ambientes, datos, anomalias …
• trazabilidad en activos
casos vs. requerimientos, resultados vs. casos, anomalias vs.resultados
• indicadores evolución calidad
ipazos@ieee.org 23-ago-10 24

25. probando
IEEE 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.
ipazos@ieee.org 23-ago-10 25

26. probando
IEEE 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.
ipazos@ieee.org 23-ago-10 26

27. probando
IEEE 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.
ipazos@ieee.org 23-ago-10 27

28. probando
IEEE 829 Standard for Software Test Documentation
ipazos@ieee.org 23-ago-10 28

29. probando
definiciones
• 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?
ipazos@ieee.org 23-ago-10 29

30. probando
definiciones - IEEE 610, IEEE 1008, IEEE 1044
anomaly
Any 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 encountered
during execution, may cause a failure of the component or
system.
ipazos@ieee.org 23-ago-10 30

31. probando
definiciones - IEEE 610, IEEE 1008, IEEE 1044
error
A human action that produces an incorrect result.
error seeding
The 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.
failure
Deviation of the component or system from its expected
delivery, service or result.
incident
Any event occurring that requires investigation.
ipazos@ieee.org 23-ago-10 31

32. probando: clases & técnicas
la prueba demuestra la
presencia de fallas, nunca su
ausencia
Dijkstra
ipazos@ieee.org 23-ago-10 32

33. probando: clases & técnicas
fases en ciclo de vida proyecto
• distintas clases de pruebas se
aplican, usando diferentes tecnicas,
según fase de avance del proyecto
prueba prueba prueba
unitaria integración … aceptación
revisión ... dinámicas ... rendimiento t
ipazos@ieee.org 23-ago-10 33

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
ipazos@ieee.org 23-ago-10 34

35. probando: clases de pruebas
prueba unitaria
según la fase, las piezas sometidas a
pruebas individuales serán
documentos (alcance/requerimientos,
especificación casos uso,..), piezas de
código (drivers, funciones de cálculo,
seguridad,.. ), prototipos, ..
ipazos@ieee.org 23-ago-10 35

36. probando: clases de pruebas
prueba de componentes
pruebas de modulos, recorriendo estados,
transiciones, decisiones, verificando
datos de entrada y salida, integridad.
ipazos@ieee.org 23-ago-10 36

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.
ipazos@ieee.org 23-ago-10 37

38. probando: clases de pruebas
prueba de sistema
alcance, verificacion y validacion funcional,
usabilidad, operabilidad, seguridad,
documentación.
ipazos@ieee.org 23-ago-10 38

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)
ipazos@ieee.org 23-ago-10 39

40. probando: clases de pruebas
prueba de instalación
gestión de configuración, portabilidad,
parametrización, ambientes, licencias de
productos, seguridad.
ipazos@ieee.org 23-ago-10 40

41. probando: clases de pruebas
prueba de regresión
funcionalidad mantiene sus atributos de
calidad, según comportamiento previo.
ipazos@ieee.org 23-ago-10 41

42. probando: clases de pruebas
pruebas funcionales
validan comportamiento de atributos de
software según especificación de casos
de uso (o equivalente)
ipazos@ieee.org 23-ago-10 42

43. probando: clases de pruebas
pruebas atributos de calidad
pruebas no-funcionales
se realizan para asegurar condiciones de
seguridad (ethical hacking),
confiabilidad, usabilidad, rendimiento,
stress, volumen, configuración,
recuperación (COB)
ipazos@ieee.org 23-ago-10 43

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)
ipazos@ieee.org 23-ago-10 44

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
ipazos@ieee.org 23-ago-10 45

46. probando: técnicas
prueba exhaustiva
solo en casos críticos
costoso (imposible), generar universo total de
recorridos para dominio completo de datos
ipazos@ieee.org 23-ago-10 46

47. probando: técnicas
revisión/inspección
proceso de revisión formal
outline
1. planificación (team, material)
2. presentación de material
3. revisión
4. corrección
5. seguimiento
6. (pgm.nueva revisión)
ipazos@ieee.org 23-ago-10 47

48. probando: técnicas
clases de equivalencia
relación de equivalencia R en un conjunto K
si cumple propiedades reflexiva, simétrica y transitiva
clases de equivalencia de R en K
sub-conjuntos: ki de K, { k x en K / kx R ki }
K- rectas, personas, enteros,
R- paralelismo, parientes, igualdad, menor-que, mayor-que
ipazos@ieee.org 23-ago-10 48

49. probando: técnicas
caja negra
técnica de amplio uso
comportamiento entrada/salida: cómo se
implementa es conceptualmente invisible
para tester
ipazos@ieee.org 23-ago-10 49

50. probando: técnicas
caja blanca
complejidad ciclomática
mé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.
ipazos@ieee.org 23-ago-10 50

51. probando: técnicas
otras herramientas
• diagrama Ishikawa
• camino crítico
• tablas de decisión (Boole)
• smoke test
• defect injection
• automatización (otra historia…!!!
arquitectura datos consumibles, escenarios, ..)
ipazos@ieee.org 23-ago-10 51

52. Pruebas de Software
agenda: viernes
1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente
ipazos@ieee.org 23-ago-10 52

53. la gente
roles & actividades
ipazos@ieee.org 23-ago-10 53

54. la gente
atributos personales
• cuestionador
• ingenioso
• metódico
• curioso
• sistemático
• detallista
• habilidades de comunicación
• motivado
ipazos@ieee.org 23-ago-10 54

55. la gente
atributos técnicos
• conocimiento procesos de calidad
• técnicas de prueba
• experiencia práctica
• conocimiento de dominio negocio
• conocimiento técnico hard / soft
ipazos@ieee.org 23-ago-10 55

56. la gente
roles
• responsable de pruebas
gerente de proyecto
• diseñador casos
especifica casos según requerimientos
detalla procedimiento y pasos
• implementador (tester)
ejecuta especificación
ipazos@ieee.org 23-ago-10 56

57. la gente
roles
• revisor
responsable por ejecutar revisiones
• coordinador revisiones
planifica, prepara, implementa revisión
• especialista de dominio
experto de negocio
• especialista de herramientas
soporte técnico, configuración, ..
ipazos@ieee.org 23-ago-10 57

58. la gente
teamwork
• misma persona, varios roles
• crítico en equipo:
coodinación
comunicación -personal & escrita-
• los resultados, son de procesos que
todos ejecutan –si falla uno, fallan todos-
ipazos@ieee.org 23-ago-10 58

59. Taller de pruebas
de Software
taller

60. Pruebas de Software
agenda: sábado
1. repaso?
2. ejersicios
3. laboratorios en grupos
ipazos@ieee.org 23-ago-10 60

61. Pruebas de Software
ejercicio:
de donde sacar casos de prueba ?
ipazos@ieee.org 23-ago-10 61

62. Pruebas de Software
casos de prueba
1. regresión, errores “conocidos”
2. usuario experto
3. funcionalidades críticas
4. funcionalidad inestable, novedades
5. atributos de calidad (seguridad,uso,..)
6. sistemas similares
ipazos@ieee.org 23-ago-10 62

63. Pruebas de Software
ejercicio:
para quién es el plan de pruebas ?
ipazos@ieee.org 23-ago-10 63

64. Pruebas de Software
plan de pruebas
1. stakeholders
2. equipo de pruebas del proyecto
3. responsable de calidad
4. negocio (es un activo)
ipazos@ieee.org 23-ago-10 64

65. Pruebas de Software
ejercicio:
que roles distinguimos en prueba ?
ipazos@ieee.org 23-ago-10 65

66. Pruebas de Software
roles
1. responsable de pruebas
2. analista de pruebas
3. diseñador
4. tester
5. coordinador de revisiones
6. revisor técnico
7. especialista herramientas/ambientes
ipazos@ieee.org 23-ago-10 66

67. Pruebas de Software
ejercicio:
lista de activos que necesitaremos ?
ipazos@ieee.org 23-ago-10 67

68. Pruebas de Software
lista de activos de pruebas
1. alcance
2. casos de pruebas
3. instructivos operativos (ambiente,
perfiles, …)
4. datos para casos y escenarios
5. registro de resultados ejecución
6. registro de anomalías, métricas
7. formato de informe
ipazos@ieee.org 23-ago-10 68

69. Pruebas de Software
ejercicio:
escribir(se) un mini-instructivo de
pasos a seguir
(ej. tenemos nuevo ayudante )
ipazos@ieee.org 23-ago-10 69

70. Pruebas de Software
instructivo pasos de prueba
1. actualizar alcance - estado de asignación
2. completar caso de prueba según formato
3. preparar ambiente según instructivos
operativos (ambiente, perfiles, …)
4. documentar datos para caso y escenarios
5. ejecutar pruebas para caso
6. registar resultados en formato
7. registrar anomalías y métricas en planilla
8. preparar y enviar informe según formato
ipazos@ieee.org 23-ago-10 70

71. Pruebas de Software
laboratorios
1. tester?? … descripción de puesto
2. a trabajar! … llamado a postulantes
3. quien sirve?? … entrevistas
4. test the tester quiz
ipazos@ieee.org 23-ago-10 71

72. Taller de pruebas
de Software
IEEE Uruguay
Sub. sección Litoral
Viernes 6 de agosto - 18:30 a 20:30
Sábado 7 de agosto - 09:00 a 12:00
Universidad Católica, Artigas 1251 – Salón de actos.

73. ipazos@ieee.org 23-ago-10 73