Te va a interesar!

6/recent/ticker-posts

Rapid Software Testing: Qué es?


 Ahh... qué sería del mundo de sistemas y testing particularmente sin nuevos frameworks, metodologías y mejores prácticas que vienen siempre a proponer lo que, para ellas, son la mejor manera de hacer nuestro trabajo? 

En este caso, vamos a echar un vistazo a Rapid Software Testing, una práctica no tan difundida, medio abstracta y que la vengo escuchando bastante seguido (quizás por cercanía con los que la promulgan y no necesariamente porque esté siendo muy difundido su uso). 


Qué es Rapid Software Testing? 

Lo primero que tenemos que saber es que NO ES una metodología como podríamos decir, Agile. Es más bien una mentalidad y una serie de habilidades que uno como tester tiene que tener. Se enfoca más en las personas que en los artefactos que generamos a través de nuestro trabajo y tiene un enfoque más que nada orientado al testing exploratorio. 

El "Rapid" de su nombre viene porque apunta a hacer testing más rápido, más barato (mmm...lo barato sale caro decía mi abuela) y con excelentes resultados. 

Pero bueno, el universo es algo siempre balanceado y nada, nada viene gratis, no? Hacer tu trabajo rápido, barato y con excelentes resultados TIENE que tener un costo. Investiguemos cómo propone lograr todo esto y veamos qué encontramos. 

Cómo se hace Rapid Software Testing?

Para esta metodología, testear rápido significa: 
  1. Entender nuestro objetivo y los obstáculos que tenemos para cumplirlos.
  2. Saber cómo reconocer problemas rápido.
  3. Modelar el producto y espacio de testing para saber dónde buscar los problemas.
  4. Elegir, siempre que se pueda, herramientas baratas, livianas y efectivas.
  5. Reducir la dependencia en artefactos caros, que consuman mucho tiempo y dar valor a los que ya se tiene en lo posible.
  6. No hacer nada que signifique una pérdida de tiempo.
También vamos a tener que ser capaces de detectar problemas rápido usando estos parámetros de consistencia:
  1. Familiaridad: El sistema NO es consistente con el patrón de otros problemas familiares.
  2. Explicabilidad: El sistema ES consistente con nuestra capacidad de explicarlo claramente.
  3. Mundo: El sistema es consistente con cosas que vemos en el mundo (???)
  4. Historia: La versión actual del sistema es consistente con versiones pasadas. 
  5. Imagen: El sistema es consistente con la imagen que la empresa quiere proyectar con él. 
  6. Productos similares: El sistema es consistente con otros sistemas comparables. 
  7. Reclamos: El sistema es consistente con lo que personas importantes dicen que debería ser.
  8. Expectativas de los usuarios: El sistema es consistente con lo que un usuario espera de él.
  9. Producto: Cada elemento del sistema es consistente con elementos comparables del mismo sistema.
  10. Razón de ser: El sistema es consistente con su razón de ser, explícita e implícitamente. 
  11. Estándares y legislación: El sistema es consistente con leyes aplicables o cualquier estándar relevante, implícito o explícito. 
Por otro lado se va a enfocar en no generar documentación al divino botón y considerar que, las cosas documentadas, no son necesariamente palabra santa. En este sentido:
  • Un documento con los requerimientos NO SON los requerimientos.
  • Un documento con el test plan NO ES el test plan.
  • Un test script NO ES un test.
  • Hacer, más que planificar, produce resultados.

Mi opinión

En lo personal, tengo varios problemas con todo esto. Primero y principal, me parece un testing exploratorio glorificado que depende demasiado del expertise del tester y demasiado de su conocimiento sobre el sistema. 
Me parece que dice cosas redundantes que todos hacemos y no necesariamente creamos una "ideología" de eso. Los puntos para detectar problemas rápido me parecen horribles en su mayoría. Una versión no siempre va a ser igual a sus previas versiones en caso de rebranding, un tester posiblemente no tenga mucha idea sobre la legislación que impacta al sistema que prueba, muchos de los puntos suenan directamente a venta de humo (como el "mundo"). 

Para mi, un día se juntaron con unas cervezas bien frías y charla va, charla viene, creyeron que habían creado una panacea que se puede ajustar a cualquier equipo de testing y de ahí nació esto. Ojo, hay cosas de valor, pero que deberíamos estar haciendo todos de todas maneras. El resto, me parece un relleno...y no uno del todo bueno. 


Publicar un comentario

0 Comentarios