+54 911 66509220

Noticias

Noticias
4 Aug 2015

Pensamos en el Qué, Cómo, Cuándo y Porqué Testear

/
Creado por
/
Comentarios0

Complementa este contenido un mapa mental para ayudar a recordar las principales ideas, considerando que los tiempos que haya que manejar y los recursos (por lo general, escasos) con los que contemos, algunos de estos caminos no los podamos seguir y/o completar.

No obstante, lo importante aquí es que tenemos mapeado las distintas condiciones que deberíamos estar considerando a la hora se enfrentar un proyecto.

Testear Requerimientos

Comencemos entonces.

Hay que entender algo y transmitirlo en todo momento a todos los miembros del equipo y a los usuarios: “las cosas pueden fallar”, y sobre esta base debemos manejarnos y ser conscientes de ello.

Cierto es lo escrito por Pilar en su artículo Pensando qué probar, iniciándolo con el siguiente planteo:

  • cuestionar y evaluar el producto
  • focalizarse en los Riesgos, entenderlos y gestionar los cambios

Aquí dejo mi primera ” miga de pan” sólo para recordar y después retomar la idea y explotarla: Cómo hacer para identificar y gestionar a los Riesgos que puedan tener impacto sobre nuestro Testing? Cómo diseñar escenarios de prueba en base a estos riesgos detectados y que sirvan para mejorar el desarrollo y/o calidad del proceso o producto? En fin, sigamos…

Hay algo que es básico, nosotros como Probadores debemos (tenemos la obligación, hasta les diría) tener lo que se denomina “ojo crítico”, y esto significa sencillamente : CUESTIONAR, cosa que no a muchos les agrada y hasta me animaría a decir, que a muchos les molesta porque no lo entienden, y no me refiero a los desarrolladores (únicamente).

Nosotros tenemos que saber : Qué Probar

Aquí dejo mi segunda ” miga de pan” sólo para recordar y después retomar la idea y explotarla: Cómo hacer para saber Qué Probar? Qué técnica se puede usar? Qué metodología aplicar? Con o Sin herramienta para facilitarnos el trabajo?

A partir de saber “Qué Probar”, estaremos reconociendo el o los posibles: Cómo y Cuándo Probar

Aquí dejo mi tercera ” miga de pan” sólo para recordar y después retomar la idea y explotarla:Tenemos el conocimiento y habilidad para construir el Cómo y aplicarlo según el Cuándo? Se complica nuestra existencia si debemos enfrentar algún proceso donde tenemos que automatizar nuestras pruebas?

Indudablemente, el orden y la línea de trabajo que definamos aquí, nos permitirá realizar una actividad que podremos controlar, mantener, seguir y fundamentalmente, mostrarla para evidenciar nuestro progreso.

A continuación, parte del contenido publicado por Pilar, sobre el que me apoyo para ir agregándole ideas que lo complementen.

Lineas de Trabajo (Algunas de las posibles)


Requerimientos que el producto tiene que satisfacer

Si no está escrito, entonces debemos identificar y relevar cuál es el motivo de la prueba y que represente el requerimiento, sin olvidar que debe estar considerándose desde el punto de vista del negocio.


Usos típicos que el producto va a tener

Aquí tendrá mucho que ver el Contexto, Qué parte de una función de negocio estamos viendo, en qué casos se utilizará, por qué tipo de usuario.

Considerar además, las Interfaces posibles, Con otros sistemas, con otras transacciones, con otros aspectos del negocio, dentro o no del sistema que estamos probando.


Atributos de calidad establecidos para el producto

Por ejemplo, considerar preguntar: cuánto se usa, cómo se usa, con qué frecuencia, a qué se le dá más importancia.


Posibles fallas

En base a la experiencia que uno tenga, o que tenga el usuario al cual entrevistemos, podremos conocer características del producto, arquitectura, catálogos de fallas conocidas.

Aquí es importante destacar que este último punto es la base de la técnica del “Risk Based Testing – RBT”.

¿Por dónde comenzar?

Debemos pensar al requerimiento, como un Caso de Uso, por más que no haya sido expresado de esa forma.

Considerar que si estamos participando en un proyecto ágil, lo debemos pensar como una historia de usuario.

Sobre lo que resuelve

  • ¿El caso de uso responde a un requerimiento completo o a parte de él?
  • ¿Cuáles son las demás partes que faltan?
  • ¿Las vemos de alguna forma?
  • ¿Podemos mapear las interacciones? En este caso, se puede aplicar el concepto de mind map con un xmind (p.e.)

Sobre los Actores

  • ¿Quiénes son? (recordemos que no solo estaremos tratando con seres humanos)
  • ¿Cómo accede el actor a esta funcionalidad?
  • ¿De qué depende este acceso?

Sobre las Precondiciones

  • ¿Qué se tiene que cumplir para entrar al curso normal del caso de uso?
  • ¿Qué pasa si no se cumple con alguna precondición?
  • ¿Todas son obligatorias?  y si así no fuera, ¿está claro por qué o cuándo se requiere cada una?

Sobre las Poscondiciones

  • ¿Qué se tiene que cumplir para considerar que el caso de uso finalizó de acuerdo a lo esperado?
  • ¿Qué pasa si esto no ocurre?
  • ¿Cuál debe ser el estado final si se produce algún error?  ¿Está claramente expresado?
  • ¿Qué pasa si no se cumple alguna poscondición?
  • ¿Todas son obligatorias? Si no, ¿está claro cuándo puede faltar cada una?

Sobre el Curso normal

  • ¿es único y bien definido?
  • ¿Hay alternativas al curso normal que no sean por errores o cancelaciones?
  • ¿Qué reglas de negocio aplican? ¿Fórmulas? ¿Decisiones?

Sobre los Cursos alternativos

  • “Positivos”, transacciones exitosas pero que se apartan del curso normal;
  • “Negativos” debido a errores, interrupciones, cancelaciones, timeouts, reglas de negocio que no se cumplen, etc.
  • ¿Podemos identificar qué los hace ser diferentes?

Sobre las Excepciones

  • ¿Hay condiciones que se deban tomar como excepción para ciertos pasos de los cursos antes enunciados?


Sobre el Caso Feliz

  • ¿Cuál es camino principal que sigue el usuario a los efectos de cumplir con la regla de negocio más importante?

Sobre el Camino Crítico

  • ¿Tenemos identificado cuáles son los pasos o el proceso que sí o sí debemos probar para asegurar que el software responderá satisfactoriamente con el requisito principal del negocio?

Pensando en Procesos

Cómo se inicia el proceso

  • qué interfaces de usuario intervienen,
  • reglas que aplican,
  • consistencias puntuales de datos,
  • obligatoriedad,
  • puntos de menú… .

Actividades que se llevan a cabo

  • ¿Qué se hace sobre los datos o con ellos, qué más se consulta o lee o modifica, bajo qué condiciones se hace cada cosa?

Qué tiene que dar como resultados el proceso

  • qué devuelve al usuario y qué puede quedar oculto pero necesitamos validar

Pensando en los Riesgos

  • ¿Se justifica probar?
  • ¿Debemos pasar por esta funcionalidad?

Escenarios que merecerían ser tenidos en cuenta

  • Cursos normales bajo entradas habituales (mínimas obligatorias por ejemplo)
  • Cursos normales bajo entradas no tan habituales (todos los campos no obligatorios)
  • Cursos alternativos, al menos uno de cada uno, importantes según las reglas del negocio
  • Situaciones que puedan no estar contempladas (fallas de HW o SW o aplicación en algún punto relacionado, entradas o resultados muy fuera de rangos, zapato sobre el teclado…)
  • Performance, seguridad, volúmenes, si se considera necesario o surge alguna duda
  • Procesos periódicos
  • Interacciones típicas y/o inesperadas entre procesos que se comunican

Fuente  de inspiración: Pensando qué probar

Leave a Reply

Your email address will not be published. Required fields are marked *

*

* Copy This Password *

* Type Or Paste Password Here *

20,291 Spam Comments Blocked so far by Spam Free Wordpress

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.