4 Tips para mejorar la calidad del Testing

En Testing no todo es Casos de Pruebas y cobertura en base a los mismos. Existe un sin número de factores que alteran notablemente los resultados y la calidad de las pruebas.

Aquí me atrevo a idear 4 TIPS para tener en mente a la hora de hacer nuestro plan de calidad y Testing:

  1. Reutilización de todos sus datos existentes.
    Es lógico y necesario guardar los datos de prueba en un lugar seguro y a su vez accesible para que se pueden utilizar y re usar por todos los Testers.
    Esto permite ahorrar mucho tiempo y encontrar más errores.
  2. Dejar de hacer copias de la producción.
    Hay quienes dicen que más del 90% de los datos en producción son similares, por lo que trabajar únicamente con ellos creyendo que así tendremos mejor cobertura, es un engaño.
    Es mejor utilizar un 10% de los datos de producción, manteniendo en foco que aquellos datos serán los verdaderamente significativos para las pruebas. El 90 % restante debemos generarlos nosotros para garantizar de esta manera la cobertura y la calidad de las pruebas, ya que así estaremos mucho más seguros de cumplir con más caminos del grafo de pruebas.
  3. Evitar que la mayor parte de nuestra generación de datos de pruebas sea manual.
    Es un trámite muy laborioso que se consume gran parte de nuestro tiempo asignado a pruebas del proyecto. También es muy propenso a errores.
  4. Mantener el foco en la calidad de los datos, asegurando que los mismos es una buena representación de la realidad y que la misma puede ser modificada para configurar varios escenarios posibles.
    Cuanto más alta es la calidad de los datos que utilizamos como juego principal para las pruebas, mayor cantidad de defectos se detectan y se evita que los mismos lleguen a producción.

Quien pueda aportar un poco más, bienvenido sea..

4 thoughts on “4 Tips para mejorar la calidad del Testing

  1. Bien las recomendaciones, pero no esta alineado al tema de la seguridad de la información.
    Según los buenas practicas se recomienda no tener datos de producción en los ambientes de test y desarrollo.
    A lo sumo se migra parte de los datos y se le corre un procesos de enmascaramiento para que los desarrolladores no tengan acceso a la información. Esto también lo empuja el tema legal, en lo respecta a la confidencialidad de los datos.

  2. Seguridad Vs Calidad !!

    Que tema no!

    o también “Cumplir con el cliente” Vs “Seguridad + Calidad”

    Generalmente no están alineados en la practica.

  3. Hola Matías, honestamente no he visto recomendaciones de “buenas prácticas” sobre que datos se deben tener en ambientes de Testing, pero sin dudas no siempre es recomendable tener esos datos, bien sea por cuestiones legales o por que no siempre los datos de producción son los más confiables para pruebas. Eso es lo que intento expresar en el punto 2 de los 4 tips.
    Creo que las técnicas de enmascaramiento, backup, replicación, ocultación o encriptación y niveles de acceso, tienen más que ver con las políticas y cultura de las organizaciones proveedoreas en relación a las exigencias contractuales, que a buenas prácticas defindidas en el mercado.
    Respecto a tu comentario de “Seguridad Vs. Calidad”
    o “Cumplir con el cliente Vs. Seguridad + Calidad”, al menos en la sensación inicial, se tratan de dos temáticas bien diferentes. Por ejemplo, yo no estaría de acuerdo en un planteo que separe a la seguridad informáticas de los aspectos de la calidad de los productos.
    Entiendo que haces referencia a lo que la realidad cotidiana nos presenta en nuestros trabajos, donde lo más normal es no hablar de la seguridad, aún cuando se pueda hablar en demasía de la calidad.
    El segundo punto que planteas quizás tenga que ver con que para sostener los tiempos de los proyectos y cumplir con los compromisos hacia el cliente, entonces los equipos de proyectos hacen recortes en aspectos de seguridad informática, entre otros recortes relativos a la calidad del software.
    Estos aspectos que mencionas son bien tratados en la entrada http://cbasqa.wordpress.com/2008/03/23/politicas-de-seguridad-organizacional-para-el-desarrollo-de-software/

  4. Un tema interesante.

    Nosotros lo que hacemos es emplear datos “dobles”. Me explico, si hay que probar datos con valores clasificados, hacemos un juego de datos que es un doble, es decir, parecido, pero distinto. Así evitamos emplear valores de datos que son clasificados.

    Otro asunto distinto es que la propia entidad del dato o la misma aplicación sean clasificados. Entonces no queda más remedio que trabajar en un entorno de pruebas completo protegido y no reutilizable.

    Un saludo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s