Mostrando entradas con la etiqueta testeo. Mostrar todas las entradas
Mostrando entradas con la etiqueta testeo. Mostrar todas las entradas

abril 27, 2011

¿Es TDD la hermana pequeña de la validación formal?

Hace un tiempo, al crear el grupo de TDD en castellano, hacía esta pregunta del título. ¿Es TDD la hermana pequeña de la validación formal? Hay un artículo del gran E. W. Dijkstra, "Sobre la crueldad de verdaderamente enseñar ciencias de la computación" que me parece muy revelador tal y como hoy entendemos la ingeniería del software, y cómo se veían las cosas hace tan solo poco más de 20 años.
Básicamente Dijkstra proponía enseñar a los estudiantes de informática, como introducción en el primer curso, la validación formal de los programas sin siquiera tocar un ordenador para programar. Bastante sorprendente.
¿podremos un día verificar formalmente que un programa hace lo que esperamos que haga, y nada más? Lo que pasa, que el principal problema no es verificar, si no CONOCER, aprender, asimilar, conceptualizar lo que tiene que hacer.
Os dejo con este video, del 2001, con una pequeña entrevista a tan interesante personalidad.



Podeis encontrar todos sus manuscritos, algunos de ellos traducidos a castellano en la universidad de Texas.
Computer science is no more about computers
than astronomy is about telescopes
E. W. Dijkstra
Siempre me ha intrigado el verdadero sentido de esa frase...

enero 26, 2011

Testeo defensivo, o que disparen a ese API

A raíz de una entrada de @sergioazo y su correspondiente conversación, he recordado una técnica que leí en algún sitio para minimizar los problemas en el trabajo con librerías externas de terceros en tu proyecto.
Se puede usar para varias cuestiones:
  • Comprender el funcionamiento real de una librería (no el esperado)
  • Defenderte frente a cambios en el comportamiento futuro de la librería
  • Documentar el uso de una librería, su API.
Se puede decir que vamos a generar test unitarios, en los que no podemos escribir el nombre del método de test hasta el final. Si hacemos TDD, el nombre del test deberá indicar que comportamiento queremos asegurar, y después programamos ese test. En este caso, podremos poner un nombre al método realmente coherente al test, cuando ya tenemos los assert ejecutando y comprobados en verde. Quizás coincida con lo esperado, o quizás no. Sugiero que se guarden los dos nombres, para comprender las diferencias encontradas, que probablemente también desconcierten al próximo programador que coja tu código que usa esa librería.

Si tenemos tests de los usos que hace nuestra aplicación de una librería, el cambio de versiones de la misma, puede ser testeado. Basta con ejecutar nuestra suite de integración, para que nos corrobore si la librería sigue funcionando tal y como esperamos.

Veamos un ejemplo. Imaginemos que tenemos un API tal que así:

public String guardaDocumento(String docType, byte[] data);
public byte[] obtenerDocumento(String docCode);

Y no tenemos más información, parece bastante obvio lo que hace, pero queremos asegurarnos, y sobre todo tener cuidados con los cambios con esa librería que se está desarrollando. Podemos hacer un test de la siguiente manera:

public void deberiaDevolverElMismoDocumentoPorCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento(docCode));

}
Pero, este test, tan simple como almacenar un documento y obtenerlo de nuevo, se queda en rojo. ¿por qué? Por que resulta que el código necesita después, no es el mismo código que devuelve
Por lo que finalmente tras unas pruebas (o un telefonazo a alguien harto de tus preguntas) llegamos a la conclusión, que el código que necesita el "obtenerDocumento" es la concatenación del tipo de documento y el código devuelto al guardarlo.
Por tanto, modificamos el test, y después modificamos el nombre del test.

/**
* was:deberiaDevolverElMismoDocumentoPorCodigo
*/
@Test
public void deberiaDevolverElMismoDocumentoPorTipoDocumentalYCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento("tipo1" + docCode));
}
¿conseguimos con esto los objetivos inicialmente planteados?

(nota:basado en hechos reales)

noviembre 17, 2008

Calidad testeada vs calidad creada

La calidad de un producto software se puede medir, ahora bien, lo dificil es escoger la métrica adecuada. Pero además, también puedes tener la impresión de que se ha hecho con calidad, si se han seguido unos procesos correctos, el equipo ha cuidado sus diseños técnicos, se han seguido patrones de diseño,...
Desde que estuve en la jornada de testeo de software tengo la idea en la cabeza de como comunicar el mundo del testeo y el del desarrollo (eso claro, si cuentas con un equipo propio de QA, que no conozco muchos).
  • Los testeadores no se pueden quedar unicamente en encontrar fallos, además deben dar ideas desde su posición provilegiada de cómo mejorar el desarrollo del software.
  • Así mismo los desarrolladores no deben unicamente desarrollar, deben comprometerse con la realización cada vez más exhaustiva de pruebas y cómo facilitarla.
Podemos tener dos aproximaciones poniendome en el lugar de una empresa que desarrolla muchos proyectos de medio tamaño:
  • Equipo de testeo independiente de los equipos de desarrollo: Esta opción es la que nos contaron la gente de Google en las jornadas de testeo de sw. Podría existir un equipo que valide cada resultado de los sprint, realizando pruebas de caja negra sobre el sistema. Los posibles defectos encontrados, retrasarían la velocidad en el siguiente sprint del equipo de desarrollo.
  • Gente de QA integrada en el equipo: Los testeos más formales se realizarían dentro del sprint mismo de desarrollo, estas personas podrían realizar tanto testeo de caja negra como "blanca".
Pero una de las cuestiones más interesantes, y que en las jornadas de Valencia me parecio un mundo aparte, es la integración entre los dos equipos. Cuando hablamos de "Equipo=software", debemos incluir a todas las personas implicadas. Cada especialista puede aportar una visión muy importante al resto del equipo, que hace mejorar exponencialmente el trabajo en equipo.
Actualmente muchas pruebas se han trasladado a los desarrolladores, no solo por que no existen muchisimas veces equipos de QA, si no por que técnicas como el testeo unitario, se ha trasladado la responsabiliad del equipo de testeo a los desarrolladores.

abril 08, 2008

Testeo, cerdos y gallinas

¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...

abril 06, 2008

Jornadas de testeo de software

El jueves estuve en el primer día de las jornadas sobre testeo de software JTS2008. La verdad que me han sorprendido la cantidad de conceptos que manejan en esta area, y que desconocía.
Hay varias cosas que tengo que analizar mejor. Me llama la atención que casi parece que son diferentes paralelos los procesos para la calidad mediante pruebas que la generada por los desarrolladores. Hablan de los testers por un lado, de sus pruebas, y no lo ligan demasiado a cómo eso afecta a los desarrolladores más que en que tienen que corregir los bugs que encuentran.
Y es curioso, por que yo tengo otro concepto más cíclico. Más que nada por que el concepto de fabricación con calidad, me resulta más atractivo que el de su control. Después de las pruebas, en algún momento se debería analizar lo que está pasando, para ver que se puede mejorar en el desarrollo que minimice en el siguiente ciclo de pruebas el número de errores.
Lo que sí coincido es que hace falta una persona (al menos) dedicada a diseñar/hacer pruebas de los sistemas en el equipo de un proyecto, y que no sea desarrollador.
¿Controlar la calidad, o fabricar con calidad? Yo que veo más cercano el equipo de desarrollo que el de testeo, me inclino a poner primero los medios en este primero para asegurar que hacemos software de calidad: lo que sea, pruebas unitarias, integraciones continuas, reuniones diarias, formación exhaustiva, mejores capturas de requerimientos, entregas iterativas,... y luego, pondría un equipo de test :)
Nos ha contado una persona de Google cómo tienen organizados los tests de sus apliciones: la palabra que más ha mencionado es "divertido". :) Curioso como cuenta que no tienen procesos establecidos, si no que cada uno es responsable de lo que hace y de cómo lo hace. Hay grupos de testeo en la empresa que apoyan a los creadores de productos, especializandose en las pruebas.

Anyway, bastante interesante la jornada, ya os daré más datos... o no,... :P os contaré más de la jornada del viernes, con más empresas contando sus experiencias. Idme contando, ¿teneis departamente de testeo de software?