Siempre enarbolando la bandera del Testing

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.

4 comentarios sobre “Siempre enarbolando la bandera del Testing”

  1. Gerson, no comparto en absoluto tu opinión…

    Veo continuamente equipos que fallan en las bases, en lo que comenta Jordi, equipos que desconocen o ignoran los fundamentos de la calidad del software pero que son excelentes en otros aspectos de desarrolla.

    En este sentido el post de Jordi me parece extraordinariamente pedagogico. Un evangelismo que es necesario hacer y que yo también he tratado en mi blog (http://geeks.ms/blogs/rcorral/archive/2006/10/21/Pon-un-tester-en-tus-proyectos.aspx).

    A mi me ha gustado el post.

    Saludos!

  2. Agradezco sinceramente los comentarios de ambos. Ojalá Gerson, pudiese compartir tu opinión, sinceramente aquellos que nos motiva el desarrollo de software nos gustaría estar en la posición de decir que la simple lógica así lo dictamina, ojalá pueda algún día compartir esta opinión contigo. Como suele ocurrir nada es blanco ni negro, sino que hay gamas de grises, que quiero decir, que seguramente tus experiencias son más positivas que las que yo he visto, y no solo a nivel nacional, sino a nivel internacional en proyecto de más de 6 billones de libras, el test, las pruebas son complejas, dificultosas de realizar, de continuar una vez iniciadas, de justificar su valor, ya que las mismas se perciben cuando justamente no se aplican y quizás a base de insistir, de transmitir de la experiencia de cada uno, esta cultura se va impregnando como algo lógico como bien tú comentas y no es ya motivo de debate, puesto que lo hacemos de la misma forma que programamos.
    Recuerdo cuando estudie en la Facultad de Informática de la UPC como el profesor de tecnologías de la programación insistía en aquella época, muchos años atrás con la importancia de establecer per-condiciones, post-condiciones y trazar todas nuestras funciones con estas premisas, aquello lo veía más digno de superar unas pruebas y establecer un marco de dificultad en la carrera que como un hecho realista aplicar, y sin duda cuando salté a la palestra de la realidad todo aquello se difuminó, el otro día escribí un post en mi blog http://jordigosolutionarchitect.spaces.live.com/blog/cns!58DE52AB6FCFEA52!215.entry hablando de algo que muy pronto podría ser una realidad y es el lenguaje Spec#, que quiero transmitir con mi post que la realidad por mucho que nos cueste creer aun dista mucho de lo que la lógica nos dicta y no porque vivamos en España, o no porque sea solo terreno de alguna consultora, creo que es una enfermedad aun que la vivimos en muchos países con grados diferentes de complejidad y que hemos de reconocer que es un campo a evangelizar para reducir los costes, mejorar la calidad, sinceramente no es una batalla que se puede realizar individualmente, sino fuese por las aportaciones de fabricantes de software como Microsoft esta realidad sería una batalla dura en cada proyecto. Desde la consultora donde estoy, permitirme no hacer publicidad, tratamos de aplicar siempre que los condicionantes nos lo permitan las técnicas de test, pero os puedo asegurar no es tarea fácil, hay muchas variables que pueden distorsionar este caminar lógico.
    Por otro lado, comparto y tomo muy buena nota de quizás poner algo más de nivel técnico en mis post, pero antes de no perderme en ellos, quisiera transmitir cual es mi espíritu inicial, al escribir en esta comunidad, y es la de quizás generar debates como el que comentas donde podamos a partir de reflexiones ver cuál es la salud de nuestros ciclos de desarrollo.

  3. Muy buen post Jordi!!

    Creo que Gerson equivoca el enfoque un poco. Me explico: más que afirmar que estas bases nos las dicta la lógica, debería ser al contrario… Partiendo de estas bases, debe ser la lógica la que determine qué pruebas realizar, qué recursos dedicar a ellas y qué frameworks o tecnologías emplear.

    Si ponemos demasiada atención a detalles/herramientas concretas estaremos perdiendo el verdadero significado global, y con ello perderemos nuestro criterio a la hora de considerar unas u otras tecnologías.

    Saludos y bienvenido Jordi.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *