Your SlideShare is downloading. ×
  • Like
2010 08-06-ieee-salto-soft tst
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

2010 08-06-ieee-salto-soft tst

  • 1,545 views
Published

La IEEE Uruguay (Institute of Electrical and Electronics Engineers), sub-sección Litoral invita al Taller de Pruebas de Software que …

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.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,545
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
95
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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