Desafios del “Testing” en las Organizaciones
El Testing es considerado una de las actividades más importantes y fundamentales en el desarrollo de un proyecto, ya que posibilita procesos, métodos de trabajo y herramientas necesarias para garantizar la calidad de cualquier desarrollo de software.
Con el fin de detectar a tiempo cualquier error y garantizar que el producto cumple con las premisas establecidas, el Testing debe existir en todas las fases de un proyecto; de esta forma podemos prevenir o inclusive corregir posibles desviaciones de software antes de que sea operable.
Para llevar a cabo este proceso de V&V (Verificación y Validación) se toma como referencia los 7 principios propuestos por el estándar internacional ISTQB (International Software Testing Qualifications Board). Sin embargo, la puesta en práctica de estos 7 principios o fundamentos que propone el estándar mencionado generan algunos desafíos en el equipo de Testing de nuestra organización.
¿Qué es el Testing?
La Verificación y Validación de Software, conocida comúnmente como “Testing” es un conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple con las necesidades de los usuarios. Con la verificación se comprueba que el software cumple con los Requisitos Funcionales y No Funcionales de su especificación, respondiendo a la pregunta ¿Estamos construyendo el producto correctamente? ¿El software está acorde a su especificación?, y con la Validación se comprueba que el software cumple con las expectativas que el cliente y/o usuario espera, respondiendo a la pregunta ¿El software cumple con las expectativas del cliente y/o usuario?
Nuestra Trayectoria Profesional
Nuestra Área de Testing está formada por cinco integrantes, y tenemos la responsabilidad de realizar el proceso de Verificación y Validación de todos los Proyectos asociados al desarrollo de Software Operativo de la organización en la que trabajamos.
Existe una gran ambición por parte de la organización de implementar una fase de calidad en todos los proyectos que contienen software operativo, motivo por el cuál se creó un Área de Calidad, en la cual nos desempeñamos. Sin embargo, a la hora de implementar los principios del Testing para el diseño y ejecución de las pruebas nos enfrentamos a distintos desafíos, siendo algunos de ellos de índole profesional y otros de índole organizacional.
Principios del Testing y sus Desafíos
El objetivo de este artículo es presentar los desafíos con los que nos hemos enfrentado y aún nos seguimos enfrentando como equipo de Testing en nuestra trayectoria profesional durante el proceso de V&V tomando como referencia los 7 principios o fundamentos de pruebas propuestos por el estándar internacional ISTQB.
A continuación, mencionaremos y explicaremos cada uno de estos principios y los desafíos que pueden surgir en cada uno de ellos.
PRINCIPIO 1: El Testing Muestra la presencia de defectos, pero no puede asegurar la ausencia de defectos. ¡Este principio es muy cierto! Aún con esta afirmación NO vamos a restarle valor al Testing. Lo importante es realizar las pruebas de manera tal que aporten valor al producto final y nos permita acercarnos a ese software casi perfecto o mejor dicho: de CALIDAD. Nuestro principal objetivo como Testers, es encontrar la mayor cantidad de fallas posibles, con el fin de que puedan ser corregidas y gestionadas antes de que lleguen al usuario final. Por lo tanto, las pruebas reducen la posibilidad de que lleguen al usuario fallas dentro del software, pero no aseguran la ausencia de las mismas.
En nuestra organización este principio, en general, no es conocido, por lo tanto, el Área de Testing corre el riesgo de ser erróneamente responsabilizado en caso de encontrarse algún error en el software, independientemente de su severidad e impacto.
Nuestro principal desafío es que este principio sea conocido y comprendido por todos los miembros de la organización que estén involucrados en los Proyectos asociados al desarrollo de Software Operativo.
PRINCIPIO 2: Las pruebas exhaustivas son imposibles. Probar absolutamente
todas las combinaciones posibles de un sistema no es factible, excepto para casos
muy triviales. De aquí nace parte de una de las máximas premisas de nuestra
profesión: al no poder asumir la verificación de todas las combinaciones a probar,
asumimos un cierto nivel de riesgo, el cual debemos manejar como parte de nuestra
estrategia de pruebas.
El desafío de este principio es establecer de manera correcta las prioridades en cuanto a lo que se probará y lo que no se probará, identificando los fallos que más van a impactar al usuario. Si enfocamos mal el esfuerzo de las pruebas, afectará no solo a la calidad del software, sino también a la conformidad del usuario.
PRINCIPIO 3: Pruebas tempranas. Las actividades de prueba deben comenzar tan pronto como sea posible en el ciclo de vida del software. Cuanto antes se identifiquen los errores, más fáciles y menos costosos serán de reparar. Entonces conociendo este principio, ¿por qué no lo hacemos así siempre?
Hay que tener en cuenta que la forma de trabajo del equipo de Testing viene dada por la forma de trabajo de la empresa en la cual nos encontramos. Cuando el modelo utilizado por el grupo de desarrollo en el ciclo de vida es el modelo cascada, al equipo de Testing se lo involucra una vez finalizado el desarrollo, relevado el requerimiento y con usuarios ansiosos por obtener el producto. Por lo tanto, la decisión de realizar las pruebas de manera temprana, no dependerá en la mayoría de los casos, del equipo de Testing.
En nuestra organización, por cultura organizacional, se nos involucra una vez finalizado el proyecto y antes de la puesta en producción, significando un gran desafío para nosotros poder lograr en un futuro contribuir al cambio de esta cultura organizacional en post de mejorar la forma de trabajo.
PRINCIPIO 4: Agrupación de defectos
Al probar cualquier software, los Testers, nos encontramos con la situación en la que la mayoría de los defectos encontrados están relacionados con alguna funcionalidad específica y el resto de las funcionalidades tendrán un número menor de defectos. Esto puede suceder porque un área del código es particularmente compleja y complicada, por cambios en el software que tienden a causar defectos o bien porque el desarrollador comete siempre los mismos errores.
La agrupación de defectos se basa en ' Principio de Pareto” que también se conoce como la Regla 80-20. Significa que el 80% de los defectos encontrados se deben al 20% de los módulos de la aplicación.
En los proyectos en los que hemos trabajado, observamos que los programadores cometen siempre los mismos errores y, a su vez, éstos se encuentran agrupados según el principio de Pareto.
Nuestro desafío con respecto a este principio es lograr tener un enfoque de pruebas similar para todos los módulos o funcionalidades, pese a que la mayoría de los defectos se encuentren concentrados en el mismo módulo, como así también buscar nuevos errores que puedan llegar a cometer los programadores.
PRINCIPIO 5: La paradoja de los plaguicidas
Si repetimos las mismas pruebas una y otra vez, eventualmente el mismo conjunto de casos de prueba ya no encontrará ningún nuevo error. Para superar esta "paradoja del pesticida", los casos de prueba necesitan ser versionados y revisados periódicamente, y se necesitan nuevas y diferentes pruebas para testear componentes del software o sistemas con el objeto de encontrar potencialmente más defectos.
Al repetir las mismas pruebas, el Testing deja de ser efectivo, por lo que los testers nos encontramos frente al desafío de cambiar nuestro pesticida constantemente, es decir, nuestra forma de testear, de manera de poder encontrar nuevos defectos.
PRINCIPIO 6: Las pruebas dependen del contexto
Las pruebas se realizan de manera diferente en diferentes contextos. Por ejemplo, el software administrativo se prueba de diferente forma al software operativo o científico.
Por otro lado, no es lo mismo diseñar y ejecutar las pruebas en un ambiente de pruebas o realizarlos en el ambiente de desarrollo.
Los diferentes dominios se prueban de manera diferente, por lo que las pruebas se basan exclusivamente en el contexto del dominio o la aplicación.
Si bien nuestra área de Testing cuenta con un procedimiento estándar aplicable a todos los proyectos que contengan Software Operativo en la organización, según el Estándar Internacional ISTQB, nuestro desafío en este principio es elegir para cada proyecto la mejor estrategia, técnica y tipos de prueba, teniendo en cuenta el contexto en el que nos encontremos.
PRINCIPIO 7: Falacia de ausencia de errores
 |
Es el último principio, pero no el menos importante, por el contrario, lo consideramos el más importante de todos. Como mencionamos al principio del artículo con la verificación apuntamos a que el software cumpla con los requerimientos del sistema y con la validación evaluamos que el sistema cumpla con las necesidades y expectativas del usuario, pero ¿Qué sucede si esos requerimientos fueron mal definidos o interpretados?
La verificación y validación van de la mano, por más que las pruebas hayan sido realizadas con éxito, no nos podemos olvidar nunca del usuario final, y del cumplimiento de sus necesidades, que es, en definitiva, para quien se construyó el software. Esto genera para el equipo de testing un nuevo desafío, que se evidencia en la ejecución de las Pruebas de Aceptación, a través de las cuales el usuario acepta o rechaza el software desarrollado.
Conclusión
El objetivo que tenemos como equipo de trabajo, es realizar el proceso de V&V de manera eficiente, motivo por el cual tomamos como referencia los 7 principios que propone el Estándar Internacional ISTQB. Sin embargo, la puesta en práctica de estos principios genera distintos desafíos laborales.
El mayor inconveniente que se nos presenta a nivel organizacional es que dichos principios no son conocidos ni comprendidos, motivo por el cuál se nos dificulta la aplicación de los principios 1 y 3.
Con respecto al PRINCIPIO 1 “El Testing Muestra la presencia de defectos, pero no puede asegurar la ausencia de defectos”, es frecuente que no sea conocido por todos los miembros del equipo que se encuentran involucrados en los distintos proyectos, asociados al desarrollo de Software Operativo, motivo por el cuál corremos el riesgo de ser erróneamente responsabilizados en caso de encontrarse alguna novedad en el software, luego de la puesta en producción.
Por otro lado, en nuestra trayectoria profesional, por política organizacional, en la mayoría de los casos, el ciclo de vida utilizado por los distintos grupos de desarrollo es el modelo cascada, lo que implica que se involucre al Área de Testing una vez que el desarrollo está terminado, lo que imposibilita el cumplimiento del PRINCIPIO 3 “Pruebas tempranas”.
A pesar de los desafíos que se nos han presentado en los distintos proyectos, consideramos contribuir en gran medida con la entrega de software de calidad, logrando la satisfacción del usuario en todos los casos. Sin embargo, como equipo de testing apuntamos a las nuevas necesidades y tendencias. El valor agregado de esta disciplina se vislumbra desde el inicio de cada proyecto, participando y supervisando todas las etapas de construcción del software. Cada error que se previene en una etapa temprana es menos costoso que aquellos que continúan invisibles hasta la fase productiva. Nuestro reto se enfoca entonces en encontrar las acciones que permitan fortalecer lo anteriormente expuesto a través de un cambio en la cultura organizacional.
Autores:
Ing. Martínez, Soledad
Ing Filoniuk, Valeria
Ing. Chiappori, Gabriel
An. Sist Diz, Ana
An. Sist Alfaya, Diego
Por APIE: Ing. Juan Páez Núñez – Director
Redacción / Edición Boletín APIE Informa: RRPP e Institucionales Monzón Andrea Carolina
Contacto: 03512552171 - www.apie.com.ar // info@apie.com.ar - 
@apie.ingenieros
Jujuy 441 - 5ºP. -Tels: (54) (0351) 4236074 - 4220081/46
CP: 5000 - CORDOBA - ARGENTINA
E-mail: info@apie.com.ar
