2010 08-06-ieee-salto-soft tst

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

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

Pruebas de Software

agenda: viernes

1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente


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?


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” ?


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?


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)


fundamentos

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

~ +30 %
del esfuerzo de desarrollo


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


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”


Pruebas de Software

agenda: viernes

1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente


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 …)


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


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.


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)


Pruebas de Software

agenda: viernes

1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente


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


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)


procesos de pruebas

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
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 !! -


procesos formales

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.


Pruebas de Software

agenda: viernes

1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente


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%)


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


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.


probando

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.


probando

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.


probando


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?


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.


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.


probando: clases & técnicas

la prueba demuestra la
presencia de fallas, nunca su
ausencia
Dijkstra


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


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án
documentos (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, verificando
datos 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 casos
de uso (o equivalente)



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)


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
prueba exhaustiva

solo en casos críticos

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


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)


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


probando: técnicas
caja negra

técnica de amplio uso

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


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.


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, ..)


Pruebas de Software

agenda: viernes

1. fundamentos
2. valor agregado
3. procesos
4. probando
5. la gente


la gente
roles & actividades


la gente
atributos personales

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


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


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


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, ..


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-


Taller de pruebas
de Software

taller

Pruebas de Software

agenda: sábado

1. repaso?
2. ejersicios
3. 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 experto
3. funcionalidades críticas
4. funcionalidad inestable, novedades
5. 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. stakeholders
2. equipo de pruebas del proyecto
3. responsable de calidad
4. negocio (es un activo)


Pruebas de Software

ejercicio:

que roles distinguimos en prueba ?


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


Pruebas de Software

ejercicio:

lista de activos que necesitaremos ?


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

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ó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

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


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.

2010 08-06-ieee-salto-soft tst

Más contenido relacionado

Similar a 2010 08-06-ieee-salto-soft tst (20)

Más de Irene Pazos Viana (6)

Último (20)

2010 08-06-ieee-salto-soft tst