Viernes, 4 Abril 2008

Contenidos:

  • El principio de los plátanos para el testeo de software (Lee Copeland)
  • ¿Listos para el testeo? Cómo crear y validar requerimientos de usuario (Petra Heck)
  • Definiendo e implementando un enfoque de testeo en toda la empresa (Graham Thomas)
  • Diez habilidades esenciales para el Testeo de Software Estructurado (Bart Knaack)

El principio de los plátanos para el testeo de software (Lee Copeland)

¿Cuándo parar de testear? Para evitar deficiones vagas, propone algunos criterios:

  • Cuando se alcanzan objetivos de cobertura (según los diferentes niveles de testeo)
  • Cuando el ratio de defectos encontrados baja de un determinado umbral (ya no merece la pena seguir)
  • Según el coste marginal (cuando el coste de encontrar el siguiente error es mayor que la pérdida que provocaría dicho error)
  • Consenso (de todos los factores: técnico, financiero, ventas, …)
  • Cuando el jefe dice "adelante" (la misión de los testeadores no es tomar esa decisión, sino informar)

Charla de Lee Copeland

Al final de la charla, Lee pide la opinión de los asistentes sobre los diferentes criterios.


¿Listos para el testeo? Cómo crear y validar requerimientos de usuario (Petra Heck)

Los requerimientos están directamente relacionados con el testeo de aceptación. Petra establece una serie de directrices para la creación de requerimientos, ilustradas con ejemplos:

  1. Estructurar los requerimientos (mantenerlos coherentes)
  2. Estructurar usando casos de uso
    Permiten establecer una secuencia en los requerimientos; incluyen escenario, pre y post condiciones, variaciones, excepciones, etc.
  3. Crear casos de uso resumen
  4. Especificar funciones después del análisis de usuarios (elegir los usuarios más adecuados)
  5. Documentar las técnicas gráficas (explicar qué significa cada elemento)
    ¿Qué significan las cajas, los círculos, las flechas…?
  6. Relacionar gráficos con el texto
  7. Mantener referencias cruzadas
  8. Mantener un glosario
    Usualmente no se hace, aunque es sencillo y puede resolver muchos malentendidos o ambiguedades.
  9. Crear plantillas
  10. No usar 'N/A - No aplicable' (explicar por qué no es aplicable)
  11. Mantener registro de los puntos abiertos

Ponencia de Petra Heck

En cuanto al testeo o revisión de requerimientos, hay que comprobar que son:

  • consistentes y completos
  • cumplen estándares, directrices, etc.
  • identificables (asignándoles identificadores y siendo "atómicos")
  • no ambiguos (evitando expresiones como "normal", "en principio", "él/ellos")
  • trazables (registrar el origen de cada requerimiento)
  • testeables

Finalmente, explica el tipo de errores e inconsistencias encontrados en los requerimientos de un caso concreto. Como conclusión, los requerimientos deberían testearse pronto, involucrando a los testeadores.

Definiendo e implementando un enfoque de testeo en toda la empresa (Graham Thomas)

El proceso de testeo se puede mejorar hasta cierto punto, a partir del cual sería necesario mejorar otras prácticas fuera del testeo: gestión, desarrollo, etc. Y el cambio tiene que ser aceptado.

Ponencia de Graham Thomas

Diversos síntomas indican que las cosas no van bien en el testeo; entonces se inicia una revisión, para los que da algunos consejos. También presenta dos modelos fluctuantes de cómo reaccionan al cambio las personas; uno de ellos equiparándolo a las cinco etapas del duelo: negación, ira, negociación, depresión, (testeo) y aceptación. El otro está basado en el Hype Cycle de Gartner.

Su modelo de cambio considera seis aspectos, y da consejos para cada uno de ellos:

  • organización
  • personas
  • proceso
  • herramientas
  • métricas
  • calidad

¿Cómo vender el cambio? Sobre todo, comunicando. Para implementar el cambio, hacerlo de modo progresivo y teniendo una visión global de cómo se integra el cambio en el testeo dentro del proceso global de cambio. Por supuesto, habrá resistencia al cambio, y hay que estar preparado para ello.

Finalmente, Graham da algunos consejos globales sobre la gestión del cambio.

Diez habilidades esenciales para el Testeo de Software Estructurado (Bart Knaack)

Después de presentarse a sí mismo y a la empresa Logica, Bart empieza con la motivación del testeo: prevenir defectos, verificar funcionalidad, ahorrar costes. ¿Y por qué estructurado? Porque los sistemas son cada vez más complicados, y no se puede testear todo; el testeo estructurado se integra en el modelo en V de desarrollo. Destaca la necesidad de equiparar riesgos y requerimientos en las primeras etapas de desarrollo.

Charla de Bart Knaack

Las habilidades para el testeo estructurado son:

  1. Preparar condiciones y casos de test.
  2. Planificar el proceso (y monitorizarlo).
  3. Configurar herramientas de soporte.
  4. Usar una gestión de defectos adecuada.
  5. Comunicar resultados.
  6. Involucrar a los afectados.
  7. Priorizar casos de test.
  8. Evaluar el proceso de testeo.
  9. Encajar el proceso de testeo (en el método de desarrollo, en la organización, en los estándares, en el presupuesto, …).
  10. Organizar el entorno de testeo.

Como notas finales, Bart indica que cada una de ellas ayudará a mejorar el proceso de testeo, así que mejor empezar por las más fácilmente alcanzables; la gestión de defectos es importante. Y la gestión de testeo debe incluir también su entorno.

Durante el turno de preguntas, expresa que los testeadores y los ingenieros de requerimientos tienen perspectivas y modos de trabajo similares, aunque no por ello tienen que ser las mismas personas.

Almuerzo

Deje un comentario

*
Teclea la palabra del recuadro, por favor, para comprobar que eres una persona y no un proceso de spam. << Anti-Spam Image



Blog del grupo SQUaC. ¿Conoces nuestros servicios? testeo de software; etc.

SQUaC, una web del ITI