Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software.
Upcoming SlideShare
Loading in...5
×
 

Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software.

on

  • 379 views

Mucho se ha hablado de cómo y en qué momento se debe probar, pero ¿y después de las pruebas? El verdadero valor de las pruebas está en sus resultados. Cuando los procesos y equipos de prueba solo ...

Mucho se ha hablado de cómo y en qué momento se debe probar, pero ¿y después de las pruebas? El verdadero valor de las pruebas está en sus resultados. Cuando los procesos y equipos de prueba solo tienen la intención de encontrar defectos y no la de prevenirlos, algo se está haciendo de forma incorrecta.

Si un insecto se nos aparece lo aplastamos. Si un biólogo encuentra uno, lo examinará. El tester debe contar con ésta capacidad en el mundo del software y aprender de los defectos.

El objetivo de la sesión es mostrar la importancia que tienen los 'bugs' en el camino a la calidad, y el deber que tienen las áreas involucradas en base al Proceso de Administración de Defectos:

- Principales errores del tester tratando con defectos.
- Principio 4 del testing: Agrupación de defectos.
- Ciclo de vida de un defecto.
- Severidad y Prioridad.
- Mejores prácticas para la asignación y comprobación de resolución (re-test y regresión)
- TMMi y la Prevención de Defectos.

Semblanza del conferencista:
Carlos González cuenta con amplia participación en proyectos de TI cubriendo ciclos de pruebas completos. Actualmente se desempeña como Test Specialist en IBM México donde ha contribuido en la implementación de procesos y metodologías de pruebas

Apasionado por el Testing; creador de la iniciativa Latin America Software Testing (testingla.com) buscando establecer criterios sólidos para el desarrollo y madurez de las pruebas en México y Latinoamérica.

Cuenta con la certificación otorgada por el ISTQB en fundamentos de pruebas.

Statistics

Views

Total Views
379
Views on SlideShare
376
Embed Views
3

Actions

Likes
0
Downloads
16
Comments
0

1 Embed 3

https://twitter.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software. Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software. Presentation Transcript

  • Aprendiendo de nuestros errores. La verdadera importancia de los Defectos de Software. Carlos U. González Tester / ISTQB FL
  • Error: Acción humana que produce resultados incorrectos Defecto: Desperfecto causante del mal desempeño en un sistema Error Defecto Fallo Proyectos caídos desarrollo testing cliente Líderes, PM’s (todos)
  • BUGS. CONOCIENDO AL ENEMIGO ES SOCIABLE NO LE GUSTA SER CONFUNDIDO ADAPTABLE AL MEDIO AMBIENTE LOS RANGOS SON IMPORTANTES PARA EL
  • - Abierto - Rechazado - En Reparación - Cerrado - No Resuelto CICLO DE VIDA DE LOS DEFECTOS El número de estados dependerá de la definición para cada proyecto El número de estados y el proceso deben ser lo más ligero y ágil posible Solo un tester debe cerrar defectos
  • SEVERIDAD 1.- Crítico 2.- Medio 3.- Menor Impacto dentro del sistema o producto que impide el correcto funcionamiento de los flujos tanto principales como alternos
  • PRIORIDAD 1.- Alta 2.- Media 3.- Baja Urgencia de corrección debido al daño ocasionado en la funcionalidad
  • ASIGNACIÓN PARA LA RESOLUCIÓN DE DEFECTOS IEEE 829 Datos de Incidencia (Identificador, versión de aplicación, entorno, Autor, Fecha) Clasificación (severidad, estado, prioridad) Descripción (caso de prueba, resultado del defecto, resultado esperado, informe, captura de pantalla, pasos ejecutados) El Reporte describe al defecto ¿cómo es? ¿Dónde se vio? ¿qué daño causa? ¿en qué momento se dio? NO describe que lo causó
  • PROCESO DE ADMINISTRACIÓN DE DEFECTOS La mayoría de los defectos son causados ​​por fallas en los procesos en lugar de errores humanos.
  • 1.- El objetivo principal es la PREVENCIÓN DE DEFECTOS y no la DETECCIÓN de los mismos. 2.- Encontrar los defectos LO MÁS PRONTO POSIBLE Y MINIMIZAR SUS IMPACTOS 3. Las estrategias, prioridades y soluciones deben enfocarse en la REDUCCIÓN DE RIESGOS del proyecto 4.- A pesar de su clasificación, TODOS los defectos son importantes PRINCIPIOS
  • La mayoría de los errores ocurren en un pequeño número de funciones probadas El 80% de los defectos se generan por el 20% de las módulos, causas, procesos, etc. PRINCIPIO 4 DEL TESTING: Agrupación de defectos y Principio de Pareto
  • PRINCIPIO 4 DEL TESTING: Agrupación de defectos
  • Identificar y analizar las causas comunes de defectos de todo el ciclo de vida y tomar medidas para evitar más defectos por las mismas razones PREVENCIÓN DE DEFECTOS ¿Qué hacer? 0 1 2 3 4 5 6 Defectos Ocurrencia de defectos Fase 1 Regresión Fase 2
  • Selección de defectos a analizar de acuerdo a: - RIESGO - VALOR AGREGADO (costos, importancia, mantenimiento) ¡La selección de análisis de defectos se realiza junto con los interesados en el proyecto! PREVENCIÓN DE DEFECTOS ¿cómo hacerlo?
  • • El daño de un defecto sobre el sistema • La frecuencia de ocurrencia de defectos • El esfuerzo que se necesita para reparar el defecto • Una estimación del esfuerzo que se necesita para evitar que el defecto vuelva a ocurrir • Los costos de reproceso del defecto • La medida en que el defecto tiene un impacto negativo en el rendimiento del proceso PREVENCIÓN DE DEFECTOS ¿qué parámetros usar?
  • 1. Causa raíz de los defectos ¿qué nos llevó a tener estos defectos? (cambios de requerimientos, malinterpretaciones, declaraciones erróneas de variables, condiciones no contempladas) 2. Causas comunes de los defectos ¿en que categoría se dieron los defectos? (procesos, requerimientos, diseño, codificación, comunicación, competencias del personal) PREVENCIÓN DE DEFECTOS ¿cómo analizar?
  • • Contribución a la organización • Impacto y coste • Consecuencias de no atender los defectos • Impacto esperado en la calidad PREVENCIÓN DE DEFECTOS Definir Acciones y Estrategias
  • TESTING Y PREVENCIÓN DE DEFECTOS
  • ¿QUÉ NECESITAMOS?
  • PRINCIPALES ERRORES DEL TESTER TRATANDO CON DEFECTOS 1. No darle seguimiento a los defectos levantados de acuerdo a severidad y prioridad 2. No dar el camino de reproducción del defecto (pérdida de tiempo para desarrollo) 3. Omitir detalles importantes sobre el defecto (¿qué severidad?, ¿en que ambiente fue?)
  • PRINCIPALES ERRORES DEL TESTER TRATANDO CON DEFECTOS 4. Hacerle caso a los desarrolladores! (los defectos solo pueden ser cerrados por testers, con la información y elementos reales) 5. ¡ser solo un tester! (un tester debe dar visión del estado de calidad del proyecto en general)
  • Preguntas @urielgk cu.hs@hotmail.com testingla.com