La prueba de software, es una práctica que se lleva a cabo de manera informal desde que se desarrolla software. A finales de los 60, se reunieron en Garmisch, Alemania, personalidades de la industria y la academia de distintas partes del mundo, para describir la problemática que se planteaba como una “crisis del software”. Fue en esa reunión que se acuñó el término “Ingeniería de Software”.
Distintos enfoques se han planteado desde entonces para abatir problemas relacionados con la calidad del software: enfoques que hacen énfasis en la gente –como el Total Quality Management for Software–, argumentando que son las personas entrenadas y motivadas las que logran productos de calidad; enfoques que se centran en los procesos –como CMMI –, con la conjetura de que con procesos de calidad se generarán productos de calidad; enfoques que se centran en la sistematización rigurosa del proceso de desarrollo de software –como los Métodos Formales–, con la visión de que se puede automatizar (casi todo) el proceso de desarrollo, con ayuda de lenguajes formales, generando bug-free software by construction. La prueba de software es un enfoque alternativo y complementario a éstos.
Los trabajos de G. Myers a finales de los años 70, representan un parteaguas en la disciplina de la prueba de software, en ellos se arranca de la premisa de que prácticamente cualquier programa desarrollado, de manera convencional, tiene anomalías, y se establece como meta de la prueba, la detección de la mayor cantidad de anomalías lo más críticas posible, lo antes posible. Myers fue también de los primeros en enfatizar que la organización que desarrolla el software no debiera ser la misma que lo prueba. Desde entonces, se han desarrollado una buena cantidad de técnicas y herramientas.
En México la prueba de software se enseñaba en muy pocas universidades, y cuando ocurría, eran más bien cursos aislados. Los bancos fueron de los primeros en aplicar esta disciplina para elevar la calidad del software que desarrollaban y utilizaban, pues el tipo de transacciones lo justificaba. Para la inmensa mayoría del resto de la industria nacional del software, esta disciplina pasó prácticamente inadvertida... hasta hace poco.
Presente
La industria del software ha venido fortaleciéndose y creciendo en los últimos años, en muy buena medida por los incentivos del gobierno, pero también por una tendencia hacia la exportación de algunas empresas de software mexicanas.
Una excelente forma de darse cuenta del estatus de esta práctica en nuestro país, es a través de diagnósticos. En el los últimos años, en nuestra empresa (e-Quallity) hemos tenido oportunidad de realizar diagnósticos sobre prueba de software a distintas organizaciones en nuestro país, de distintos tamaños cada una. Para realizar dichos diagnósticos, utilizamos un modelo de calidad que desarrollamos internamente, y que bautizamos como TAM (Test Aptitude Model).
Este modelo define 13 áreas relacionadas con prueba de software. Integra elementos de modelos de calidad de software genéricos como CMMI, y lo complementa con elementos de otros modelos de calidad especializados en pruebas de software, como TPI (Test Process Improvement) y TMM (Test Maturity Model), así como con aportaciones de nuestra experiencia adquirida en proyectos.
La Figura 1 ilustra los porcentajes de cobertura a través de las 13 áreas del modelo, para tres organizaciones que evaluamos recientemente. (Ver figura 1)
Figura 1. Cobertura por área de prueba en distintos diagnósticos
En general, las áreas más fuertes en las organizaciones de prueba resultaron estar relacionadas con la estructura organizacional: el ambiente de trabajo en la organización (Atmósfera), y la posición que ocupa el equipo de prueba en la organización (Estructura Funcional). Consideramos que las áreas de oportunidad más críticas se concentraron en cuestiones metodológicas y de proceso: qué técnicas usar, cuándo y cómo (Metodología y Distribución y Técnicas de Prueba); así como el control, contabilización, y comunicación de los artefactos y resultados de prueba (Defectos, Testware, Métricas y Distribución de Información).
Desde una perspectiva más amplia, una conclusión que hemos obtenido de dichos diagnósticos, así como de la consultoría que realizamos, es que ya existen en el país organizaciones de prueba de muy buen nivel, y que hay un número considerable de organizaciones con nivel bajo, pero que están invirtiendo sistemáticamente para mejorar significativamente.
El crecimiento reciente en el consumo de la prueba de software, puede coincidir con el aumento en la cantidad de empresas que están trabajando hacia modelos como CMMI, pero que se dan cuenta que estos esfuerzos, no les brindan mejoras significativas en el corto plazo en la calidad de sus productos, y por ello, ven en la prueba, una herramienta con la cual pueden abatir riesgos, y reducir tanto costos como time to market en periodos cortos, obteniendo una buena relación costo-beneficio.
Hasta hace algún tiempo, podía observarse que los testers tenían una tendencia a enfatizar el uso de herramientas de automatización, en la labor de la prueba (en buena medida por su desconocimiento de aspectos metodológicos). Hoy, hay cierta conciencia de que si bien en algunos casos la incorporación de una herramienta al proceso de prueba permite hacer el proceso más eficiente, el extrapolar este fenómeno a cualquier herramienta, en cualquier proceso, de cualquier organización, es un error.
Una buena parte de la comunidad de prueba de software en el país, sabe que la adopción de herramientas en una organización de pruebas requiere de un análisis cuidadoso del entorno, y de la situación actual de la organización de prueba en cuestión, desde factores tan elementales como el presupuesto, hasta aspectos tan elaborados como la visión, proyección de la organización de prueba en cuanto a giro, metodologías, y especialización.
Hoy existe también cierta conciencia en las organizaciones de software de que, para obtener el mayor beneficio de esta actividad, es necesario por un lado mantener capacitados a los testers y ofrecerles un plan de carrera adecuado, de manera que permanezcan en la organización; y por otro, situar adecuadamente en el organigrama el departamento de prueba, de manera que tenga autoridad suficiente para que su voz sea escuchada y sus productos utilizados (que no ocurra que el equipo de prueba esté relegado, y que su coordinador reporte a un administrador de proyecto, quien reporta a un gerente de producto, quien reporta a un gerente de tecnología, quien reporta a un director de desarrollo, quien reporta al director general).
Por otro lado, en nuestro país, actualmente son pocas las universidades que abordan la prueba de software, pero es creciente tanto la calidad como la cantidad de los mismos; esto permitirá en el mediano plazo contar con un número significativo de testers junior.
Escenarios futuros
Estos son algunos de los aspectos que percibimos en el futuro próximo en cuanto a la prueba de software:
•Un cambio significativo en términos de calidad y cantidad, comienza a gestarse en las universidades, para poder atender la demanda de testers, que serán requeridos cada vez más.
•La creciente especialización por áreas de aplicación que se observa en el mercado del software, está exigiendo que las organizaciones de prueba también se especialicen de la misma manera.
•Las empresas de prueba de software más maduras, están comenzando a introducir componentes innovadores y, a generar su propia tecnología (no otro robot, ni otra herramienta más de administración de anomalías, sino componentes de mucho mayor valor agregado).
Los sistemas de sistemas, las nuevas arquitecturas y los nuevos paradigmas significarán un gran reto para los testers; la orientación a servicios y la necesidad de probar un sistema que interactuará con otros sobre los cuales no se tiene ningún control, dispararán nuevas y mejores técnicas y modelos para la prueba de software.
Métodos formales
Dentro de las nuevas tendencias en prueba de software, vale la pena explicar más a fondo los métodos formales. En tiempos recientes hemos visto cómo se han venido desarrollando metodologías basadas en lo que llaman métodos formales, para llevar a cabo la verificación de sistemas de hardware y software. Un método formal, es aquel que tiene un fundamento matemático para realizar la especificación y validación de un sistema. La verificación formal, busca probar el funcionamiento del modelo, con el objetivo de garantizar que el modelo no tiene errores o divergencias respecto a la especificación. La justificación de estas técnicas, proviene del hecho de que la prueba puede confirmar la presencia de errores en un sistema, pero no la ausencia de ellos.
Con ese tipo de herramientas, podemos especificar los requisitos de software en un lenguaje formal, y mediante técnicas matemáticas, realizar refinamientos sucesivos, con el objetivo de obtener un diseño que satisface el modelo, y que es, implementable en un lenguaje de programación. Con estos refinamientos, agregamos el detalle suficiente para que la herramienta puede generar el código que implementa el modelo en el lenguaje de programación que elijamos; se dice que el sistema así obtenido es bug-free by construction.
Debido a la complejidad que representa el solo hecho de realizar el modelado y la especificación en algún lenguaje formal y, a la carencia de una oferta atractiva de herramientas comerciales de este tipo, hasta la fecha hemos visto que las técnicas de esta clase, sólo se utilizan para validar sistemas de misión crítica. Una herramienta para el desarrollo basado en métodos formales es B-ToolKit. Que ya ha sido utilizada en algunos sistemas críticos que están operando, como la línea 14 del metro de París.
Consideramos que las dificultades que conlleva el dominio de las herramientas matemáticas necesarias, para utilizar este tipo de metodologías, no permitirá que se utilicen masivamente en el corto plazo y para cualquier aplicación; sin embargo, debido a sus enormes bondades y, a su aplicación en mercados interesantes, seguiremos realizando investigación en esta área.
Referencias
•Luis Vinicio León-Carrillo. “La Prueba de Software”. SG Año 1 números 3-6, y Año 2 números 2-3.
•Luis Vinicio León-Carrillo. The Impact of Software Testing in small Settings. Capítulo del libro “Software Processes in small Enterprises”, por H. Oktaba y M. Piatini; por publicarse.
•G. Myers. The art of software testing. John Wiley & Sons; 1972
•Formal methods. vl.fmnet.info
Acerca de los autores
Luis Vinicio León Carrillo es Director General de e-Quallity, empresa especializada en prueba de software. Es profesor-investigador del Departamento de Electrónica, Sistema e Informática del I.T.E.S.O.; es candidato a doctor por la Technische Universität Clausthal (Alemania) con un tema relacionado con la prueba de software. Es co-fundador del Capítulo Guadalajara de la AMCIS, del cual es actualmente Presidente.
Aarón Moreno Monroy es Director de Operaciones de e-Quallity, empresa especializada en prueba de software. Es profesor de tiempo parcial en el I.T.E.S.O. Es candidato a maestro por el CINVESTAV campus Guadalajara en temas relacionados con verificación formal.
Elena Ruelas Minor es actualmente Administradora de Proyectos de prueba y consultora en e-Quallity. Es ISC por el ITESO. En su trayectoria como tester ha actuado como líder de proyectos de prueba y como tester senior de caja negra. Como consultora, ha aplicando el modelo TAM para diagnosticar áreas de prueba de distintas empresas del país y para diseñar planes de mejora.
- Log in to post comments