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!

Principios Generales de Testing

On 6 julio, 2010, in Consejos, Definiciones, by twiindan

Actualmente estoy estudiando para realizar la certificación del ISTQB Foundation y en el primer tema existe un apartado donde se indican muy bien los principales principios del testing.

  1. Testing shows presence of defects: El testing puede mostrar que existen defectos, pero no puede provar que no los haya si no que unicamente reduce la probabilidad de que queden defectos sin descubrir.
  2. Exhaustive testing is impossible: Testear todas las combinaciones y posibilidades es imposible, por ello se debe priorizar y realizar análisis de riesgos para enfocar los esfuerzos del equipo de test.
  3. Early testing: Las actividades de test deben lo antes posible en el ciclo de vida de desarrollo de software, enfocandolo en objetivos definidos.
  4. Defect clustering: Un pequeño número de módulos son los que contienen la mayor parte de los defectos descubiertos antes de realizar una release.
  5. Pesticide Paradox: Por mucho que se repitan los mismos tests, no se van a encontrar más errores. Por ese motivo los test cases necesitan ser regularmente revisados y se deben ir añadiendo nuevos para probar las diferentes partes del software.
  6. Testing is context dependent: Los procesos y las metodologías de test aplicadas deben ser diferentes según el contexto.
  7. Absence  of errors fallacy: Encontrar y arreglar defectos no ayuda si el sistema no es usable o no concuerda con las necesidades y expectativas del testing.

Estáis de acuerdo con todos los principios? La verdad que es un buen resumen de las características principales del testing, unos principios que todos deberíamos aplicar siempre que podamos.

Tagged with:  

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.