Un poco de humor para alegrar el día 🙂

Tagged with:  

Resumen QA&TEST 2010 (second day)

On 1 noviembre, 2010, in Conferencias, by twiindan

Despues de un muy buen comienzo de las jornadas, llego el segundo día con unos contenidos igual de interesantes que el primer día.

El día empezo con la Keynote de Tammy Noergaard donde explico los principales errores que cometemos dividido en varios niveles, desde errores que se producen por parte de planificación o dirección (como no tener en cuenta los deadlines a la hora de planificar, o escoger el lenguaje de programación correcto a la hora de diseñar y programar la aplicación, o no definir la estrategia de testing desde el primer día). Una keynote muy instructiva donde se nos recordaba errores que siempre cometemos y que conviene siempre tener presentes (creo que me haré una lista y la colgaré en mi sitio para no volverlos a cometer).

Seguidamente se realizaron varias presentaciones dentro de dos tracks (Testing Safety Critical Systems y Requirment Management). Dentro del primero destacar la conferencia sobre análisis estático, y varios problemas o errores que pueden surgir si este no se realiza.  También una gran presentación por parte de Bryan Bakker sobre diseño de tests automáticos emfatizando sobretodo la parte de test de integración, generalmente otro tipo de testing un poco olvidado (por lo menos en mi organización).

Despues de todo esto un descanso bien merecido y una gran comida a base de varios pescados en el restaurante del Palacio de Euskalduna.

Ya con el estomago lleno, volvian las conferencias de nuevo con dos tracks diferentes (People in Software Testing y Testing Techniques & Testing Proccess). Yo me tuve que quedar en la primera de ellas ya que mi conferencia estaba en este track.  Muy destacable el toque de humor de Tony Simms a la hora de narrar los diferentes problemas que podia tener un project manager y que generalmente no tenemos en cuentaa. Seguidamente una descafeinada presentación en la que estaba totalmente de los nervios! Despues de todo este tiempo, fue el momento, 40 intensos minutos donde explique las funciones que se realizan dentro de Diagnostic Grifols, por suerte los nervios se fueron poco a poco y en general la gente por lo menos no se dormia. Una vez ya finalizado, 2 preguntas (una de ellas con un poco de mala leche) y un gran aplauso por la presentación!

Para acabar la jornada se realizó un interesante debate donde hubo varios temas centrales como las metodologias ágiles o las certificaciones, dos temas muy candentes actualmente.

ya acabada la jornada, muchas preguntas sobre varios procesos de mi presentación por parte de varias personas y a descansar al hotel.

Ya por la noche una interesante cena de gala donde los organizadores nos regalarón un buen menu y unas cuantas copichuelas en un bar de copas, lo ideal para soltarse un poco más la lengua y acabar de perfeccionar el ingles! Eso si, no muy tarde a dormir que aun faltaba el tercer día!

Requisitos SMART

On 17 junio, 2010, in Definiciones, requerimientos, by twiindan

Ya comentamos hace unos días que una parte muy importante del desarrollo de un producto de sofware son los requerimientos.

En esta primera fase es donde se define que es lo que el cliente quiere exactamente, y a partir de estos se realizará el análisis, diseño, codificación y pruebas. Por este motivo es tan importante tener unos requisitos muy bien especificados y sin ambiguedades.

Es por ese motivo que se definió la metodología SMART para los requisitos. SMART son las siglas de las características que debe de tener un requerimiento:

  • Specific: Los requerimientos deben de de ser lo más claros posibles, sin ningún tipo de ambigüedad y sin posibilidad de libre interpretación.
  • Measurable: Debe poder ser medido o verificado. Se han de poder definir pruebas para verificarlo.
  • Attainable: El requisito debe ser accesible y realista, debe tener unos objetivos técnicos alcanzables.
  • Realisable: Cada uno de los requerimientos debe ser realizable con los recursos disponibles.
  • Traceable: El requerimiento debe poder trazarse con todo el proceso de desarrollo (análisis, diseño, codificación i pruebas).

Generalmente la mayoría de errores se introducen durante el diseño de los requerimientos, por ese motivo es muy importante crear unos requisitos de calidad.

Tagged with:  

Matriz de Trazabilidad

On 15 junio, 2010, in Definiciones, requerimientos, by twiindan

Durante el ciclo de vida del desarrollo de software de un proyecto existen dos fases muy importates como son la definición de requisitos o especificaciones y el diseño y ejecucción de pruebas.

Cuando el proyecto es muy grande o complejo es difícil poder saber que test ejecutados o diseñados cubren cada una de las especificaciones o requerimientos del proyecto.

Es por este motivo que existe lo que se conoce como la matriz de trazabilidad.

La matriz de trazabilidad es una herramienta que se utiliza para saber que requerimientos quedan cubiertos por una prueba. Veamoslo con un secillo ejemplo.

Imaginemos que tenemos un proyecto con 5 requerimientos (R1-R5) y hemos diseñado tres casos de prueba (T1-T3).

  • El caso de prueba T1 cubre los requerimientos R1 y R4
  • El caso de prueba T2 cubre los requerimientos R3 y R5
  • El caso de prueba T3 cubre el requerimiento R3

En este caso la matriz resultante será:

T1 T2 T3
R1 X
R2
R3 X X
R4 X
R5 X

Viendo la matriz podemos ver claramente dos cosas:

  1. El requerimiento R3 está probado en 2 casos de prueba.
  2. El requerimiento R2 no está cubierto.

Gracias a estos datos podemos ver que partes o módulos del software no están cubiertos y deberían probarse por otras pruebas o identificar los requerimientos más críticos para saber si están suficientemente cubiertos (más de un caso de prueba es diseñado y ejecutado para ese requerimiento).

También podemos identificar los casos de prueba que han fallado y a partir de ahí ver que requerimiento esta en riesgo para poder evaluar la criticidad y el riesgo de este.