Actualidad y noticias de Testing con un punto de vista de negocio

Supongamos que un cliente te pide que le ayudes con un proyecto de Calidad de Software. No sabe cómo enfocarlo, ha leído en la web muchas cosas, se ha bajado y ha tocado software de soporte y está hecho un lío. Tú lo estudias un poco y le planteas el proyecto: lo primero una fase de conocimiento, de evaluación: entender cómo desarrollan, qué plataforma usan, qué herramientas, cómo implementa Scrum, cómo gestiona los requisitos, las pruebas, etc. Luego se definen procesos, se selecciona la mejor plataforma para tu cliente en función de su situación, se despliega, se hace algún pequeño piloto, se realizan workshops y formaciones y se cierra con alguna bolsa de acompañamiento. ¡Cool!

Pero no todo es tan bonito: el cliente te plantea durante la preventa que la primera fase de consultoría, la de evaluación, tendría que acortarse, que no es necesaria, que realmente no tienen casi nada y sería perder el tiempo, etc… tú accedes a acortar la consultoría cubriendo una serie de supuestos para protegerte, cierras el contrato y empiezas a trabajar. ¡CRASO ERROR!

Sin conocer bien al cliente un proyecto de mejora en SQA & Testing tiene pocas probabilidades de éxito. Una buena evaluación de la organización, bien documentada y compartida por el equipo del cliente y el equipo de consultoría, permite no errar el tiro y realizar una buena definición de la solución a implantar. Atención, en este tipo de proyectos cerrar demasiado el alcance al principio es como pegarse un tiro en el pié. El enfoque correcto es el de un proyecto ágil, analizamos cómo está el cliente, cerramos un esfuerzo y hacemos lo máximo que podemos por ayudarle, entendiendo que el cliente nos reconoce honestos y productivos y que el proyecto puede interrumpirse de mutuo acuerdo en cualquier momento. Es una especie de contrato ágil orientado a proyectos de mejora.

Hace poco un cliente me lo dijo en la reunión de cierre de un proyecto “No te dejes convencer, Carlos, luego es peor para todos”. Mi recomendación a todos es la siguiente: una buena evaluación, rápida (dos semanas máximo), con un documento que se comparte con el cliente en una sesión de trabajo, es imprescindible para que estos proyectos sean un rotundo éxito. Evidentemente también se necesitan consultores y coachers expertos, pero esta es materia para otro post.

Soy un tipo con cierta aversión al riesgo, sobre todo cuando construyo algo. Me gusta diseñar bien y sobre todo me gusta tomarme mi tiempo antes de empezar a realizar la tarea que sea: vísteme despacio que tengo prisa, es para mí una especie de filosofía de vida.

Todavía recuerdo cuando en los primeros 2000 revisaba código (COBOL, siento la falta de glam, pero era COBOL) de personas que llegaban a mí con bugs que no entendían. Me encantaba aplicar una mayéutica muy personal a todo el proceso… el individuo muerto de los nervios porque tenía que entregar y el chalado socrático este (que era yo) haciendo preguntas:

Lee el resto de esta entrada »

geek inside

Pairwise es un método de generación de datos que produce el número mínimo de tuplas que contiene todas las combinaciones de dos campos en una entrada de pruebas (Test Set). Ante una prueba que requiere la generación de datos (casi en todos los casos) podemos elegir distintos métodos para generar los datos de entrada, algunos solo se citan a efectos de demostración:

  • No generar ninguna tupla y por lo tanto no probar la entrada. Este es el caso de 0 esfuerzo en generación de datos. Este escenario no es aceptable desde el punto de vista de Testing.
  • Generar todas las combinaciones posibles. Este caso es potencialmente inmanejable generando lo que se llama una explosión combinatoria.
  • Alguna situación intermedia que minimice el número de casos a probar máximizando su utilidad y eficacia.

Realmente lo que necesitamos es el mínimo eficiente intermedio entre cero esfuerzo y la explosión combinatoria: esta es la misión de Pairwise Testing. Un ejemplo lo clarificará.

Lee el resto de esta entrada »

Entendemos como Testing Reactivo a aquellas pruebas que se realizan una vez que la aplicación ha sido puesta en producción, ejecutándose, por tanto, en entornos productivos y no en entornos pre-productivos. Hay varias preguntas que me he hecho siempre con este tipo de testing: en primer lugar, ¿es esto testing o más bien monitorización? y en segundo lugar, ¿cuándo se justifica su utilización?

Si nada como un pato, camina como un pato y vuela como un pato… será que es testing. Es decir, lo realiza el mismo equipo, aunque en momentos diferentes, probablemente utilizando los mismos casos de prueba, se utilizan las mismas técnicas y las mismas herramientas. Por cierto, al respecto de plataformas reales y que se utilizan para testing reactivo, Jesús Hernández ha publicado recientemente un post de recomendada lectura en el que cita una posible plataforma Open Source. Mi opinión es que sí es testing, pero cambiando el entorno habitual de trabajo, la estrategia de pruebas y, sobre todo, el momento de ejecución, pero la actividad es de la misma naturaleza.

Lee el resto de esta entrada »

Comenzaremos este artículo introduciendo un pensamiento que debiera pertenecer al mundo de lo obvio “las aplicaciones software no son más que la transcripción en lenguaje maquina ejecutable de un conjunto de reglas de negocio “. Gracias al software el diseño de los procesos de negocio se puede realizar de forma centralizada, permitiendo, en cambio, una ejecución de los mismos homogénea, rápida y distribuida en cualquier punto del mundo. El software permite canalizar la ejecución de procesos, ahorrar tiempo en la operación, llegar a nuevos mercados rápidamente y, por supuesto, introducir y diseminar errores en los procesos de negocio a escala global y “con un sólo click”. Es, en definitiva, una espada de doble filo, por un lado es una herramienta necesaria y fundamental para éxito empresarial en la actualidad y por otro una potencial fuente de problemas.

Asumir errores en el proceso de negocio no es aceptable para casi ninguna empresa. No escuchamos a directivos decir sin gran embarazo que “se han contabilizando de forma errónea los gastos de personal” o “hemos retenido un 3% menos a los empleados casados con hijos menores de tres años”. Estos errores de negocio tienen repercusiones económicas, de imagen pública e incluso penales. No obstante cuando se comenta que la aplicación de gestión de nóminas tiene “errores informáticos” tras el último cambio implementado, incluso se llega a asumir como algo habitual y dentro de lo probable. Deberíamos entender que si el software falla, lo que falla es la ejecución del proceso de negocio y por lo tanto lo que se pone en riesgo es la propia organización.

Lee el resto de esta entrada »