En este post, les daré una breve explicación de cada una de las “escuelas” de Software Testing. Con escuela podemos pensar en algo similar a una “Corriente de Pensamiento”, algo así como cuando pensamos en Psicologia Gestalt, analítica, humanista etc.
Existen muchos expertos que no coinciden en la forma de hacer testing, este articulo te ayudara a tener una mejor idea de la razón por la cual nadie se pone de acuerdo. Nuestros proyectos nos son iguales a los de otros, al tener cada quien una forma distinta de trabajar las necesidades para algunos no serán las mismas que para otros.
Analytic school. Definen el software como un artefacto lógico, una rama de las Matemáticas y que las pruebas deben tener una respuesta lógica y una sola respuesta correcta, el Testing se ve de una manera muy técnica. Buscan objetivos medibles, como el porcentaje de cobertura de código de las pruebas, por lo que las pruebas estructurales (Unit Testing) siempre están presentes como parte fundamental del proceso. Las pruebas exploratorias (Exploratory Testing) o basado en experiencia (Error Guessing) son prácticamente nulas.
Las implicaciones de esta escuela es que requieren especificaciones muy precisas y detalladas, prácticamente lo que el tester verifica es si el software trabaja de acuerdo a las especificaciones, cualquier cosa fuera de esto no es Testing.
Esto suele funcionar en entornos científicos, académicos o altamente regulados, como en Telecomunicaciones, sistemas de seguridad crítica etc. Por ejemplo, si el producto debe pasar por la aprobación de la FDA (Food and Drug Administration, USA), aquí podríamos encontrar este tipo de prácticas.
Standard school. También conocida como Factory school, busca industrializar el proceso de testing, todo el proceso debe ser planeado, repetitivo y predecible. Habitualmente se buscan los recursos más económicos para realizar las tareas debido al bajo costo que representan, pero de la misma forma requieren un alto grado de dirección. Testing valida el producto. Uno de sus principales artefactos es la Matriz de Trazabilidad, donde cada requerimiento está vinculado a una prueba y cuando las pruebas finalizan el producto está listo para ser entregado.
Este modelo funciona cuando se subcontrata el desarrollo de software, si las especificaciones están bien detalladas, se puede desarrollar en base a estas y en la fase de testing se define el grado de cumplimiento del contrato.
Las implicaciones de esta escuela es que requieren límites claros en cuanto a cuando iniciar y/o finalizar las pruebas, ya que existe un alto grado de resistencia a las modificaciones en de los planes por parte del equipo de Management. El principal modelo a seguir es el “modelo en V” o la “metodología de cascada” (waterfall), y están en completo acuerdo con certificaciones (ISTQB), estándares (IEEE) o “Mejores prácticas” en general.
Se pueden encontrar este tipo de prácticas principalmente en Empresas de TI, y de Gobierno
Los seguidores de esta escuela suelen negar tajantemente la existencia de las demás, probablemente por ser esta la escuela más extensa, (se puede vivir y morir sin conocer nada mas), y si solo hay una forma correcta de realizar testing, que es la suya, las demás escuelas no tienen razón de ser.
Quality school. Su atención está más en el proceso y el standard más que el testing en si. Aquí, los testers se dedican a evaluar la calidad de los programadores y a proteger a los usuarios de un software infame, los tester pueden “forzar” a que los desarrolladores sigan las reglas del proceso. Una de las figuras que definen esta escuela es que hay una figura en el proceso que autoriza o no al producto a salir a producción (Gatekeeper). Esta figura, tiene el reto de tener la autoridad suficiente para no sacar un producto a producción, ya que si la dirección decide sacar algo a pesar de que el QA Lead (o como se denomine) diga lo contrario, se va a demostrar que el proceso no se está siguiendo y que por lo tanto no es válido.
Quienes practican esta escuela prefieren llamar al proceso “QA” en vez de “Testing”, la administración toma al área de “QA” como un punto de mejora de los proceso. Otra de las implicaciones de esta escuela es que puede llegar a sacar de sus casillas a los desarrolladores, ya que conflictos con el gatekeeper podría implicar tener que apegarse a seguir los procesos y las fechas de entrega sin importar nada (trabajar a deshoras para cumplir metas). Típicamente se pueden identificar este tipo de prácticas con empresas relacionadas a ISO, ASQ y CMMI
Uno de los problemas de esta escuela, es que al final se trata de interacciones humanas, y el puesto de Gatekeeper está sujeto a muchas presiones que no todo el mundo tolera.
Context-driven school. Gira en torno a 7 principios, siendo los principales el 3 “La gente, y la interacción entre ella son la parte más importante del contexto de cualquier proyecto” y el 4, “Los proyectos se desarrollan en formas impredecibles”.
Su máximo exponente es el testing exploratorio, en el que la documentación, la ejecución dinámica de pruebas, la experimentación y el aprendizaje suceden al mismo tiempo. Todo lo que no sea aceptable para el “cliente”, en un defecto,
Algunas implicaciones de esta escuela es que los testers esperan siempre cambios en el proyecto, se trabaja de una manera muy dinámica, y las pruebas deben estar basadas en los resultados de las mismas pruebas. Se indica que las estrategias de pruebas deben ser determinadas con investigación de campo y la investigación de pruebas requiere estudio empírico y psicológico. Se enfoca más en las habilidades que en la práctica.
Este tipo de prácticas pueden ser vistas en pruebas de sistemas comerciales y basados en el mercado.
Uno de los problemas de esta escuela es que no tiene un modelo de formación definido, pero tiene una gran comunidad que apoya el aprendizaje continuo, al fin de cuentas lo que se busca es como colaborar en el proyecto, más que definir un proceso.
Agile school, Con la introducción de las metodologías ágiles, de pronto los equipos de desarrollo típicamente se componen de programadores que emplean Test Driven Development (Desarrollo Basado en Pruebas) como técnica para desarrollar, redactando primero las pruebas de aceptación y después el código que cumple esta funcionalidad, es decir, primero se genera el ejemplo de lo que el código debe hacer, y después el código en sí.
Y si los programadores ya pruebas su propio código, que hace un tester en este proceso? Bueno, pues queda realizar las pruebas de integración, automatizados o no, queda revisar los requerimientos de las User Stories que se definen y queda colaborar en desarrollar el producto con la mayor calidad posible.
Está muy enfocado en la automatización de pruebas y el principal objeto es el Unit Test, utilizado para el Desarrollo Basado en Pruebas, los desarrolladores son quienes proveen los frameworks de automatización. Dada la forma de trabajo el testing exploratorio es lentamente apreciado.
Podemos ver esta escuela principalmente en empresas de consultoría de TI y desarrollo en ASP
El hecho de que existan estas 5 escuelas no implica que seamos parte exclusiva una de ellas, solo son categorías que nos permiten tener un mejor enfoque de los modelos de trabajo que existen y nos permitan tener un mejor entendimiento y debates al respecto