jueves, 20 de diciembre de 2012

Como hacer Testing cuando no tienes Test Cases



¿Alguna vez han entrado en un nuevo proyecto y no tiene documentación, ni siquiera Test Cases? O han encontrado que la documentación es deficiente o no se ha actualizado durante un tiempo ... si su respuesta es sí, quiero presentarles  algunas herramientas que podrían ser útiles para el entendimiento y testeo de una aplicación, y que les pueden llevar a crear los casos de prueba (en caso de que su jefe/cliente desee tener casos de prueba) y su base de conocimientos.

Primer paso: Mapas Mentales
Los Mapas Mentales pueden ser una herramienta poderosa, tanto para una tormenta de ideas como para resumir una charla en una conferencia o un backlog review. Pero también se puede utilizar para crear un plan de pruebas. Pueden utilizar un mapa mental para ayudarlos a decidir sobre cómo podrían asignar sus recursos, cuando se trata de una situación incierta.
Al enfrentarnos con una nueva funcionalidad en la aplicación, se puede ejecutar una sesión de análisis, con el objetivo de identificar lo que hay que analizar. Las sesiones de análisis puede ayudarnos a decidir en donde están los potenciales riesgos, lo que queremos cubrir, o cómo queremos cubrirlo. Estas sesiones se pueden traducir en un mapa mental para tener una perspectiva visual de la situación.
Los mapas mentales son la herramienta perfecta para desarrollar y ejecutar las pruebas, evolucionando sus ideas, mientras realiza el testing. Nuestros resultados se pueden expresar en unos mapas mentales como un punto de inicio para agregar nuevas ideas y cobertura.

Test Planning MindMap
Test Planning Mind Map by http://www.ministryoftesting.com

Hay un montón de herramientas que podrían ser utilizadas para crear mapas mentales, he aquí algunas:

LucidChart: un software on-line de diagramas, tiene múltiples tipos de diagramas, incluyendo mapas mentales.
XMind: la herramienta más utilizada para realizar mapas mentales.
SimpleMind: visualmente, los mapas se ven mucho mejor con esta herramienta, por haber sido creado para iOS, aunque tiene su versión de escritorio, sólo tiene una prueba de 30 días.

Pequeña UI,Gran herramienta
Segundo Paso: Qtrace
Incluso si estás haciendo pruebas exploratorias o Scripting Testing, tienes que escribir un informe de bugs si has encontrado defectos.
Qtrace es una herramienta potente y fácil de usar, que te permite grabar tu sesión de pruebas con varias snapshots y capturar cada paso que haces en esas imágenes, añadir tus propias notas y generar un informe para exportar en varios formatos (Word, PDF, etc ) o que puede ser integrado con múltiples trackers como Quality Center, Jira o Version One.
Estos informes podrían ser utilizados como casos de prueba, ya que tienen pasos para reproducir, el ambiente de testing, especificaciones e imágenes que podrían ayudar a los Testers a seguir el caso de prueba y a los desarrolladores a solucionar el defecto.
Puedes bajarlo aquí.



Tercer Paso: Hexawise
Cuando necesitas comenzar a planificar tu pruebas de cobertura o de regresión, puedes encontrarte con múltiples posibilidades, que generan miles de casos de prueba que puede hacer que sea imposible cubrir todo.
Hexawise es una herramienta web, que maximiza la cobertura de la pruebas con un número mínimo de casos de prueba, ya que te permite crear un plan de pruebas mejor sin omitir cualquier combinación de las funcionalidades y configuraciones.
Sólo tienes que crear tus inputs, y Hexawise va a generar los casos de prueba y analizar su cobertura en pocos segundos.
Fácil de usar, con un poco de práctica, puedes crear fácilmente tus planes de prueba y exportarlo a un archivo de Excel o exportarlo a una herramienta de test management o a herramientas de automatización de pruebas como Quality Center, QTP, selenium, etc
Lo puedes descargar aquí:

Cuarto Paso: Wikis
¿Y dónde podríamos guardar toda esta información para que la puedan usar otros Testers?
Como Leah Stockley dice en su blog:
 "Un método eficaz consiste en capturar la información esencial del proyecto (el conocimiento del dominio, aspectos técnicos, consideraciones de prueba, etc) en un wiki. Parte del tiempo ahorrado por no escribir scripts, puede ser invertido en la actualización de la wiki, la captura de los puntos más importantes en un documento conciso que se puede leer y está disponible para cualquier persona en el proyecto que puedan estar interesados, no sólo el equipo de pruebas.
Cuando un tester nuevo comienza, deben comenzar por leer la wiki ... pero para hacerlo más interactivo, les pedimos que revisen la exactitud y que sean responsables de hacer cambios y mejoras en la base de conocimientos. " (Traducción libre hecha por mí)

En "tiempos ágiles", tener un conjunto de potentes herramientas y personas capaces de adaptarse a cualquier situación, puede hacer la diferencia en el desarrollo de software.

Quiero agradecer la inspiración de este post a:
Michael Bolton, específicamente a este post, pero pueden leer todo su blog que es más que interesante.
A este post de Mauri Edo, que habla de mapas mentales.
Y a Leah Stockley que hizo un gran post en su blog y ojalá muchas empresas en Latinoamerica pudieran leerla y empezar a cambiar el modelo de testing actual en la región.



jueves, 19 de julio de 2012

Como Testear un Caniche Toy

El otro día me encontré con esta noticia en MDZOnline, en donde a unas personas las estafaron con unas ratas blancas crecidas con anabólicos vendidas como caniches toys...o sea les vendieron rata por perro. Los coreanos se hacen agua la boca (?)
Ahora...digo...de pronto...me parece...si te van a vender un perro...si te van a meter el perro, no podes al menos fijarte si es un perro? y como haces para testear a un perro?
Como sucede con el Testing, a veces uno no puede saber como es exactamente lo que uno debe testear.
Entonces uno debería hacer pruebas utilizando su cerebro.

Apretarle las bolas a ver si dice GUAU!

La primera prueba es comprobar si el perro hace Guau, o sea, aunque sea cachorro los perros dicen GUAU! aunque uno nunca haya tenido perros, y mucho menos un caniche toy, uno sabe por la experiencia, por que le contaron desde el jardín de infantes, por que alguna vez algún perro te ladró, que el sonido que hace un perro es similar a la onomatopeya GUAU.
Hay perros que no ladran mucho, no es el caso que nos compete hoy, pero igual uno debiera ver que al menos hace ese sonido, es un requerimiento que uno espera en un perro. Una rata seguramente no "dice" Guau!
Lo segundo que podemos hacer es ver el contexto. En una feria en donde todo lo que venden es trucho, que te vendan un animal de raza por un valor muy inferior, es como mínimo sospechoso. Es importante ver el contexto en donde uno esta haciendo pruebas. No es lo mismo comprobar que un caniche toy es realmente un perro en una veterinaria que en La Salada.
Lo tercero que podemos hacer antes de comprar un perro, sea la raza que sea y no importa en donde lo compremos o adoptemos, es averiguar como es la raza, su comportamiento, sus necesidades, sus pros y contras,etc. Esto se puede hacer fácilmente buscando en Internet, o preguntando al veterinario mas cercano a nuestro domicilio. Tener información sobre que es lo que vamos a testear es muy importante para entender cómo lo vamos a testear.
Este es mi primer boceto para entender un poco el Exploratory Testing de James Bach y Compañía, en próximos post trataré de adentrarme mas en el tema.
Ya sea comprando un perro o cualquier otra cosa, o probando software, siempre trata que no te vendan Gato por Liebre o, en este caso, Rata por Perro.


jueves, 12 de julio de 2012

El porqué de este Blog

Seguramente no abrí este blog para innovar, es más creo que atraso al menos 5 años. Tampoco lo abrí para compartir mi larga experiencia, todo lo contrario. La idea fundamental es descubrir, o mejor dicho, auto-descubrir, de que se trata mi trabajo. ¿Y cual es mi trabajo? En mi empresa lo llaman QA Engineer, pero no soy Ingeniero. En la gran mayoría de los lugares le llaman (nos llaman) Testers, pero es muy básico... Lo que me importa ahora es descubrir que hay más allá de mi trabajo rutinario e intentar volverlo menos amateur y más profesional. Seguramente usaré este blog para mostrar mis frustraciones profesionales, y tal vez algunas lecciones aprendidas en el camino que le puedan servir a nuevas camadas de incautos. La idea de este blog surgió básicamente de 3 sucesos:

Groso.

  • Una compañera de trabajo me pasó este video de James Bach y me partió un poco la cabeza y me sacó de la modorra mental (?) en la que me estaba auto sometiendo. Hablaré de él y sus ideas en próximos posts, pero entre otras cosas me di cuenta que debía abrir un blog para hablar de estos temas, no importa si nadie me conoce y si nadie sabe si soy bueno o no en esto.



  • Luego apareció esta nota en MDZonline y lo primero que pensé es..."Pero nadie testeó si el perro ladraba!?" y ahí me di cuenta que mi trabajo me está absorbiendo (?) y cambiando lentamente mi forma de pensar. Hablaré de los caniches toy y testing en otro post. 
Esto no es un perro!

Juegazo
  • Por último lo que me decidió un poco más a emprender este blog, es que me aburrí un poco del Civilization IV y tenía ganas de hacer otra cosa, no podría jugar una partida eterna como este tipo que juega hace 10 años (!) al Civ 2. 

Como verán, no tengo grandes razones para hacerlo, pero cualquier excusa es buena para usar el cerebro y tratar de comprender mejor el laburo de uno. Por eso en este blog trataré de volcar lo que encuentre en mi búsqueda hacia el conocimiento, problemas que encuentre para desarrollar mi trabajo y hasta alguna que otra solución...además es mas barato esto que ir al psicólogo (?)