Llevo muchos años dedicados al Delivery y desde los principios, inclusive antes de saltar a la palestra se ha enarbolado la bandera del Test como un factor decisorio. Muchas son las acciones y experimentos que he visto o se han realizado que al final no han tenido éxito, o inclusive he visto en primera persona como el test es la parte del ciclo de vida tedioso, aburrido y que se realizará si se tiene tiempo, y sino pues contemos con la buena suerte de la diosa fortuna, y confiemos en la buena disciplina de los desarrolladores.
La buena noticia, es que hemos evolucionado mucho, tanto en forma de pensar como ejecutar, así como las herramientas que nos permitan asegurar que los resultados que estamos produciendo cumplan lo esperado por nuestros clientes, lo esperado por los requerimientos. Sabemos cuanta variedad de tipos de procesos de pruebas existen… recientemente comentaba mi experiencia en un gran proyecto donde teníamos mas de 20 tipología de entornos enmarcados dentro del ciclo de vida del desarrollo y me decían para que tenías tantos… Adentrémonos dentro de la amalgama de tipología de procesos de test, tenemos por ejemplo: Acceptance testing, Ad hoc testing, Black box testing, Code coverage, Compatibility testing, Conformance testing, Load testing, Localization testing, Mobile Device Testing, Sanity testing, Smoke testing, Stress testing, GUI software testing, Fuzz testing, Unit testing, White box testing, Boundary testing, Integration testing, Installation testing, Exploratory testing, All-pairs testing, Scenario testing, Soak testing, QuickCheck, Software performance testing, Regression testing, System testing, Model-based testing, Static testing, Usability testing, Game testing, Session-based testing, Hallway testing, System integration testing, Boundary Value Analysis, Pseudolocalization, Recovery testing, Software verification, Playtest, Keyword-driven testing, Monkey test, Manual testing, Combinadic, Build Verification Test, realmente es una buena lista, casi podría decir sin equivocarme que en el mundo de la consultoría utilizamos, aquellos que preocupados por la calidad del software, una ínfima parte de la lista. En ocasiones no se comprende ni por el usuario final, ni por los propios consultores, el coste que tiene garantizar lo que estamos desarrollando, se suele escuchar en alguna ocasión, pero si sois profesionales, porque me tiene que costar tanto desarrollar y probarlo…
Sin duda bajo mi concepción, están cambiando mucho las cosas y ello es positivo, se comprende más lo que hacemos en los proyectos, el usuario final no es un ente que desconoce lo que implica el ciclo de vida, se crean nuevos métodos más ágiles de desarrollo, con la única finalidad de acercar lo que entendemos a un producto que no se ciña únicamente por completar con éxito un plan de trabajo, sino a generar un producto que realmente sea desde el primer momento que sale la luz de valor añadido para el cliente. Todos aquellos que vivimos en el mundo del software ya sea trabajando en el o como usuarios, sabemos que los errores no son gratuitos, se requiere tener un equipo bien dimensionado para atender las quejas del usuario, trasladar las quejas a los equipos de mantenimiento, planificar y aplicarlos con cuidad en el código desarrollado, si este código no cumple con los criterios de la orientación a las pruebas, puede ser cada vez más costoso corregir las incidencias.
El proceso de test podríamos estratificarlo en los siguientes niveles:
- Unit test, bajo mi punto de vista sería el test mínimo que cubre la funcionalidad del componente desarrollado o módulo. En una programación orientada a objetos la mínima unidad sería a nivel de clase, donde definiremos los métodos de test para cada método de la clase. Afortunadamente los que trabajamos en el mundo Microsoft contamos con la valiosas aportaciones que nos proporciona el Visual Studio 2008 para añudarnos a cometer este objetivo básico. Deberemos incluir los ciclos de pruebas unitarias dentro de procesos periódicos que alerte al programador de que lo desarrollado no está alterando el comportamiento de otras partes del código. Existen muchas escuelas que nos enseñan cuando debemos generar estas pruebas, unos abogaran por primero establecer la codificación de las pruebas unitarias antes del desarrollo del código, en otros blogs abordaremos con más detalle cada disciplina, aunque existe blogs escrito por vosotros con un nivel de detalle excelente que nos puede ayudar a comprender la mecánica de cómo hacerlo.
- El siguiente nivel que nos viene a todos a la cabeza sin duda son las pruebas integradas, como desarrollamos aplicaciones por fortuna en un solo módulo o clase, aunque de todo he podido ver en mis años dentro del delibery, los componentes que cada desarrollador codifica interactúan unos con otros mediante interfases y las garantías de que esta iteraciones funcionen correctamente son el objetivo de las pruebas integradas, pruebas con componentes comunes, pruebas con elementos de arquitectura, son ejemplos que estarían dentro de las pruebas integradas. Bajo mi punto de vista continuamos aun dentro del ámbito y entorno de la responsabilidad de los desarrolladores y estos deben responsabilizarse de la implementación de estas pruebas.
- El siguiente nivel, que ya tendréis en mente, son las pruebas de sistema, el producto que estamos desarrollando se enmarca dentro de los requerimientos definidos que por un proceso de diseño descendente hemos descompuesto en elementos individuales que hemos ido probando de forma individualiza y sumando elementos y probando sus interfases, toca pues probar que el sistema cubre los requerimientos definidos, muchas veces estas pruebas caen en el contexto del equipo de pruebas de sistema, un equipo con la visión de conjunto de todos el sistema y con los requerimientos como arma arrojadiza contra lo desarrollado, mi visión es que aquí para poder establecer ciclos de desarrollos cortos también deberíamos abordar procesos automatizados de pruebas, será entonces muy importante que modelos de aplicación hayamos seleccionado, modelos que nos permitan orientar nuestro sistema a las pruebas.
- Por último ya tendréis en menta que el siguiente nivel son las pruebas de sistema integradas, en el casi 90% de las aplicaciones que desarrollemos estas deberán de convivir con otras aplicaciones o sistemas, estas pruebas deberán garantizar que lo que desarrollamos se integran perfectamente con otros sistemas que pueden estar desarrollándose en paralelo, con lo que tendremos que lidiar con la dificultad que ello implica, o con sistemas que ya están instalados y que pueden estar sufriendo procesos evolutivos y deberemos gestionar nuestros ciclos de versiones de nuestro producto con los ciclos de versiones de la evolución de otros sistemas. La generación de estas pruebas puede caer fuera del ámbito del desarrollador, ya que es necesario conocer cómo funcionan otros sistemas, pero sin duda bajo mi punto de vista para que estas puedan realizarse con la periodicidad necesaria, deberemos poder automatizar al máximo mediante simuladores, conjunto de datos, etc.
Todos estos niveles junto con todas las pruebas citadas que en sucesivos post podemos debatir si ello es de interés actual, serían imposibles de abordar y esta es mi opinión sin dos condicionantes, herramientas que te ayuden en el proceso de generación de las pruebas, en el proceso de ejecución de las pruebas y en el proceso y esto es muy importante en el proceso de análisis de los resultados e historificación del proceso de mejora que nos permitan tener una visión de la salud de nuestro sistema y su mejora o degradación, para mi es fundamental el esfuerzo realizado por Microsoft con la plataforma de desarrollo Visual Studio Team System y estoy seguro que seguirá aportándonos nuevas capacidades en el futuro con las siguientes versiones del mismo, así como de tener claro la metodología para incorporar de forma adecuada las pruebas en el ciclo de desarrollo de las aplicaciones, sin ello, podemos tener toda la batería de herramientas como un factor interesante a la hora de desarrollar nuestras sesiones de evangelización, nuestras propuestas, pero no en nuestros procesos de delivery.
Corolario final, enarbolemos la bandera de las pruebas como algo realista desde el principio del desarrollo, desde el diseño de la arquitectura de aplicación y tengamos presente todos los aspectos que nuestro sistemas tiene y cuál es su entorno porque podemos generar un producto de calidad que podría ser metástasis cuando lo ponemos en el bosque de sistemas del cliente.
Gracias por leer mi blog que no tiene más finalidad que exponer mi punto de vista sobre como yo percibo la realidad del software enfundado en el mono del entorno de Microsoft.
Grandes consultoras visionaron hace ya unos años la importancia para mejorar su competitividad hacer uso de desarrollos Offshore, desarrollos descentralizados que permitan hacer uso de costes de desarrollo más económicos y a mayor escala que un enfoque estrictamente Onshore. Pero quizás agudizado por estos momentos de crisis que fuerzan a las compañías a ser más eficaces, más eficientes, han impulsado este movimiento a un enfoque con prácticas Agile que podrían a priori pensarse que son más efectiva para enfoques mas pequeños, de corta duración y centralizados. La mayoría de las organizaciones optan por un modelo waterfall tradicional para el enfoque de desarrollos Off-shore. Estas definen tareas dimensionadas en grandes planes de trabajo y con modelos organizativos tradicionales, naturalmente estas aproximaciones chocan directamente con aproximaciones Agile, las cuales definen aproximaciones increméntales de valor añadido. Una aproximación que hemos comentado en alguna ocasión en este blog es hacer uso de modelos híbridos tal como se ilustra en el siguiente gráfico
También recuerdo más recientemente como alguien de relevancia comentaba en una audiencia que exceptuando en raras ocasiones los proyectos SOA había tenido éxito y se conseguían los objetivos que habían impulsado su ejecución. ¿Es SOA por tanto una desilusión?, cabe preguntarse, ¿porque es un fracaso?, quizás la pregunta nos lleve a reflexionar que tal vez hemos menospreciado el factor de otras cuestiones subyacentes que requerían primero una respuesta antes de plantearse un modelo SOA, preguntas quizás de ámbito técnico que se partía de que todo estaría resuelto con simplemente publicitar un conjunto de servicios, preguntas tal vez como cual es el mejor ESB? o preguntarse por WS-* vs REST y otras muchas más que seguro se os estarán ocurriendo, quizás implique que debamos primero rediseñar nuestras aplicaciones para poder dar servicio SOA. SOA debe estar dentro de un proyecto mucho más grande sino seguramente será un fracaso. SOA debe estar dentro de una estrategia a largo plazo y no como un factor complementario y puntual, debe ser un producto de años, bien orquestado y alinear quizás muchas estrategias. Analicemos que factores pueden impulsar una estrategia de esta magnitud, cada uno seguramente tendrá sus propias motivaciones, pero si analizamos algunos escenarios podremos ver que posiblemente tengamos, como muy bien dice Hanu Kommalapati esta tipología: