INTRODUCCION AL SOFTWARE TESTING

El Software testing o como se conoce en español las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener.

En un principio la mayoría de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad el software testing se ha convertido en una de las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologías.

En la actualidad el software testing se hace más complicado ya que debe hacer frente a una gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc.

Es por esto que el testing debe apoyarse en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de pruebas.

Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de software testing, la administración y seguimiento de errores, la administración de los casos de prueba, automatización de pruebas etc.

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambiente de desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en producción para asegurar su correcto funcionamiento en esa futura etapa, se debe considerar adquirir un equipo de pruebas especializado “software tester” o analista de pruebas, con experiencia, estas personas tienen una formación que les permite detectar una gran cantidad de errores en tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de manera correcta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testers situación que puede traer una serie de problemas debido a la poca experiencia que pueden tener los usuarios en la detección de errores, además se obvian pruebas importantes como las pruebas de Esfuerzo o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las que deberían asegurar que cada módulo del sistema trabaje correctamente de manera independiente, otro error muy conocido en empresas de software es el uso de los mismos desarrolladores como analistas de pruebas, es muy difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, un técnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a la perfección e inconscientemente evitara realizar pruebas más exhaustivas considerando que las mismas podrían ser absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedando descartadas y se van alineando conceptos hacia un software testing profesional.

FUNCTIONAL TESTING - PRUEBAS FUNCIONALES

Se denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales han sido creados, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la última etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción.

A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas.

Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista de pruebas, también es posible automatizar este tipo de pruebas utilizando herramientas como WinRunner o SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo a probar. La automatización de pruebas puede resultar compleja y solo la recomendaría en algunas funcionalidades específicas, por ejemplo en las pantallas que tendrán mayor uso, generalmente pantallas de ingreso de datos. Se debe tener en cuenta que el costo de estas licencias suele ser bastante elevado.

Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario, usar el sistema como él lo usaría sin embargo el analista de pruebas debe ir más allá que cualquier usuario, generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos, enfocados básicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional, el analista de pruebas debería dar fuerza a las pruebas funcionales y más aún a las de robustez, generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bien una misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar se esforzará por que deje de ser pequeña y posiblemente se convertirá en un gran error, cada error encontrado por el analista de pruebas es un éxito, y se debería considerar como tal, en mi experiencia personal he podido ver que proyectos atrasados, o con algunos problemas de tiempo sacrifican horas de pruebas, incluso se siente algún malestar si el tester sigue encontrando errores, si no se corrige esta situación los proyectos en su gran mayoría fracasaran o perderán más tiempo aún.

En la empresa en la he laborado algunos años solo se realizaban pruebas del tipo funcional, ya que al parecer son los que el usuario mejor comprendía y en las que podía apoyar, con el pasar de los años esta situación a cambiado y en la actualidad se utilizan también pruebas unitarias en la mayoría de los aplicativos desarrollados, siendo las pruebas unitarias una primera etapa y las pruebas funcionales la segunda y definitiva en la que se da la conformidad del sistema.

Los sistemas que han pasado por pruebas unitarias tienen un menor tiempo de pruebas funcionales, este comportamiento es obvio, ya que las pruebas unitarias nos permiten encontrar los errores más evidentes y fáciles de corregir, en la etapa de pruebas funcionales el sistema debería estar bastante estable y con muy pocos errores críticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores críticos y/o bloqueantes, se debería devolver el sistema a la etapa de pruebas unitarias ya que resulta muy poco productivo realizar pruebas funcionales con sistemas inestables, el avance es demasiado lento y el analista de pruebas no podrá apoyar mucho en la resolución de los errores ya que en esta etapa solo se centra la atención en las entradas y salidas, y no en la lógica intermedia, (Black Box – Caja Negra).

UNIT TESTING - PRUEBAS UNITARIAS - CAP 1

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también son llamadas pruebas modulares ya que nos permiten determinar si un módulo del programa está listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras está desarrollando el módulo.

El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si los módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de probar y al encontrar algún error será más difícil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de pruebas podrá recomendar que un módulo muy complejo sea separado en 2 o 3 módulos más sencillos.

Fig 1. Pruebas de Caja Blanca - White Box Software Testing

Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar familiarizado en el uso de herramientas de depuración y pruebas, así mismo deben conocer el lenguaje de programación en el que se está desarrollando la aplicación, en la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas para cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboración de casos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas unitarias son: JUnit, La Suite de Mercury, CPPUnit etc.

El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfaces, o flujo de datos entre componentes.

No es un requisito indispensable la culminación de todos los módulos del sistema para iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas metodologías consideran oportuno iniciar la etapa de pruebas unitarias poco después del desarrollo.

En esta imagen se muestra lo que se considera una representación clásica de Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas el cubo representaría un sistema en donde se pueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe ser probado en su totalidad (óvalos), y también sus interfaces o comunicaciones con los demás componentes (flechas), este tipo de pruebas también son llamadas pruebas de caja de cristal ya que este último termino representa mejor el tipo de pruebas.

Lo importante en este tipo de pruebas es que se deben tener claros los siguientes aspectos:

•Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos deben ser preparados con minuciosidad, ya que el resultado de las pruebas dependen de estos.

•Se debe conocer que componentes interactúan en cada caso de prueba.

•Se debe conocer de antemano que resultados debe devolver el componente según los datos de entrada utilizados en la prueba.

•Finalmente se deben comparar los datos obtenidos en la prueba con los datos esperados, si son idénticos podemos decir que el modulo supero la prueba y empezamos con la siguiente.

Luego de tener una buena cantidad de módulos independientes probados y encontrados Conformes, el siguiente paso es integrarlos, las principales formas de integración que existen son:

•Integración Incremental.

•Integración no incremental.

•Integración Incremental

Al realizar una integración incremental debemos combinar o unir el siguiente módulo que se debe probar con el conjunto de módulos ya probados. El número de módulos se incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar de 2 formas.

•Integración Incremental Ascendente y la •Integración Incremental Descendente.

Integración Incremental Ascendente

En este tipo de integración se combinan los módulos de más bajo nivel en grupos que realizan alguna sub función específica.

•A través de un driver (módulo impulsor) se simulan llamadas a los módulos, se introducen los datos de prueba y se recogen los resultados.

•Cada grupo se prueba usando su driver (test integrador), y este luego es sustituido por los módulos de nivel superior en la jerarquía. En el último paso se prueba el programa completo con sus entradas y salidas reales.

En mi experiencia como analista de pruebas, me toco probar un sistema bancario, en esa oportunidad empezamos por los módulos que aplicaban lógica de negocio y hacían cambios en la base de datos, una vez que cada uno de estos módulos funcionaba correctamente, iniciamos las pruebas de los módulos de nivel superior, que básicamente hacían llamadas a estos módulos de más bajo nivel, esta segunda etapa fue mucho más rápida, pues estos últimos tenían muy poca lógica, al reemplazar los drivers que creamos por los módulos de más alto nivel encontrábamos pequeños pero muy críticos errores, por ejemplo componentes que fueron renombrados en el nivel bajo y no fueron actualizados en las llamadas de los niveles superiores.

La siguiente imagen muestra la primera fase de la integración ascendente, en este ejemplo cada módulo debe ser probado por separado, para esto se debe construir un driver o impulsor para probar cada módulo.

Fig. 2 Integración Incremental Ascendente - Fase 1

Tal como se muestra en la figura 3, luego de probar los módulos de más bajo nivel (E, F y G), continuamos con los módulos del siguiente nivel, para esto debemos construir nuevos drivers o impulsores (B y C), que se aplicaran directamente a los módulos superiores (B y C) y estos a su vez se integrarán a los de más bajo nivel (E, F Y G).

Este proceso se repite algunas veces hasta que se culmina por probar el sistema completo, en la figura 4 se muestra un nivel más de integración incremental ascendente.

Fig. 3 Integración Incremental Ascendente - Fase 2

Fig. 4 Integración Incremental Ascendente - Fase 3

Ventajas de la integración incremental ascendente:

•Las entradas para las pruebas son más fáciles de crear ya que los módulos inferiores suelen tener funciones más específicas.

•Es más fácil la observación de los resultados de las pruebas puesto que es en los módulos inferiores donde se elaboran.

•Resuelve primero los errores de los módulos inferiores que son los que acostumbran tener el procesamiento más complejo, para luego nutrir de datos al resto del sistema.

Desventajas de la integración incremental ascendente:

•Se requieren módulos impulsores, que deben escribirse especialmente y que no son necesariamente sencillos de codificar.

•El sistema como entidad no existe hasta que se agrega el último módulo.

Integración incremental Descendente

Inicia del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo a incorporar. La única regla es que el módulo incorporado tenga todos los módulos que lo invocan previamente probados.

En general no hay una secuencia óptima de integración. Debe estudiarse el problema concreto y de acuerdo a este, buscar el orden de integración más decuado para la organización de las pruebas. No obstante, pueden considerarse las siguientes pautas:

•Si hay secciones críticas como ser un módulo complicado, se debe proyectar la secuencia de integración para incorporarlas lo antes posible.

•El orden de integración debe incorporar cuanto antes los módulos de entrada y salida.

Existen principalmente dos métodos para la incorporación de módulos:

1.Primero en profundidad: Primero se mueve verticalmente en la estructura de módulos.

2.Primero en anchura: Primero se mueve horizontalmente en la estructura de módulos.

Etapas de la integración descendente:

•El módulo de mayor nivel hace de impulsor y se escriben módulos ficticios simulando a los subordinados, que serán llamados por el módulo de control superior.

•Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado.

•Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real que reemplazaba, según el orden elegido.

•Escribir los módulos ficticios subordinados que se necesiten para la prueba del nuevo módulo incorporado.

Ventajas de la integración descendente:

•Las fallas que pudieran existir en los módulos superiores se detectan en una etapa temprana.

•Permite ver la estructura del sistema desde un principio, facilitando la elaboración de demostraciones de su funcionamiento.

•Concuerda con la necesidad de definir primero las interfaces de los distintos subsistemas para después seguir con las funciones específicas de cada uno por separado.

Desventajas de la integración descendente:

•Requiere mucho trabajo de desarrollo adicional ya que se deben escribir un gran número de módulos ficticios subordinados que no siempre son fáciles de realizar. Suelen ser más complicados de lo que aparentan.

•Antes de incorporar los módulos de entrada y salida resulta difícil introducir los casos de prueba y obtener los resultados.

•Los juegos de datos de prueba pueden resultar difíciles o imposibles de generar puesto que generalmente son los módulos de nivel inferior los que proporcionan los detalles.

•Induce a diferir la terminación de la prueba de ciertos módulos.

Integración No Incremental

La integración no incremental es bastante sencilla y generalmente se recomienda para proyectos de poca envergadura, la integración consiste en probar cada modulo por separado de manera similar a la intregación incremental pero una vez de terminar con los módulos independientes, se continua probandolos todos juntos como un todo.

La única ventaja es que no se necesita ningún tipo de trabajo adicional: ni planificar el orden de integración, ni crear módulos impulsores, ni crear módulos ficticios subordinados.

Por otro lado, la lista de desventajas incluye:

•No se tiene noción de la comunicación de los módulos hasta el final.

•En ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o presentar.

•El hecho de realizar todas las pruebas de una vez hace que las sesiones de prueba sean largas y tediosas.

•La cantidad de errores que arroje puede ser atemorizante.

•La tarea de encontrar la causa de los errores resulta mucho más compleja que con los métodos incrementales.

•Se corre el riesgo de que a poco tiempo de que se cumpla el plazo de entrega, haya que volver sobre el diseño y la codificación del sistema.

¿COMO REALIZAR PRUEBAS FUNCIONALES?

Las pruebas funcionales - Functional Software Testing y las pruebas unitarias Unit Software Testing deben ser consideradas como temas cien por ciento técnicos, en mi experiencia como analista de pruebas o también llamado tester, he llegado a probar una buena cantidad de sistemas en varias empresas, enfocadas principalmente al sector financiero.

Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada error que yo pudiera encontrar significa un éxito para la calidad del sistema. Evidentemente el analista de pruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientos técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del negocio, en la actualidad los sistemas más importantes son realizados para dar solución a los problemas de negocios. El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento de diversos negocios y le resultará sencillo adaptarse a cualquier tipo de aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta última a mí parecer la más complicada.

Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el resultado esperado. Próximamente espero publicar un artículo tocando el tema de cómo realizar buenos casos de prueba.

Una vez concluidos los casos de prueba es más sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podrían ser prácticamente infinitas, propongo el siguiente ejemplo:

Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables:

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables:

¿En qué tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos

Esto nos daría al menos 3 variables o casos de prueba.

¿La cuenta tendrá saldo? Saldo = 0, Saldo > 0, Saldo < 0 3 variables

¿Es una cuenta en Moneda Nacional MN o Moneda extranjera? 2 variables

¿Pertenece a una Persona natural PN o Persona Jurídica PJ? 2 variables

¿La cuenta es mancomunada? Si o No 2 variables

¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3 estados). 3 variables

¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?

Si o No 2 variables

¿De que tipo será el cargo a la cuenta? 5 variables

1.Transferencia entre cuenta propia

2.Transferencia a un tercero

3.Transferencia interbancaria

4.Retiro en efectivo

5.Pago de un cheque

¿En que canal de atención se realizará esta operación? 4 variables

1.En ventanilla

2.Cajero Automático – ATM

3.POS – Pago de servicio o consumo

4.Home Bankin

Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más allá. Muchos de los errores que he podido encontrar no estaban escritos en mis casos de prueba. Si en mi caso defino hacer un cargo de 1000 dólares, luego de eso podría hacer una prueba con un cargo de 1000.01 y otro de 9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Es interesante notar que la gran mayoría de los errores se encuentran en los valores límite. Si una pantalla se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con 100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. Es increíble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un sistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que no haga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con el sistema, un analista tester jamás debería estar bajo las ordenes de un programador y tampoco es recomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo a pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la robustez de sus sistemas, simplemente en el fondo no quieren maltratarlos, los aman…

Otro nicho en el que se ocultan errores podrían ser los campos de ingreso de datos, aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto, sobre todo en los campos de párrafos o multilíneas, disfruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser una definición tan simple muchos la olvidan.

Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calcular diversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificar qué valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se presenten sean correctos, tanto en las pantallas como en los reportes, jamás he tenido la experiencia de encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la primera vez”. ¡Ese es mi lema!

Por último una muy buena recomendación de pruebas es el manejo del valor cero 0 muchas veces por la complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro valor y entonces: “Error Exception Faillure #afg99d7 - no valido” o algún otro mensaje horrible.

Espero que con estas pequeñas recomendaciones puedan ser capaces de encontrar una gran cantidad de errores. Próximamente espero mejorar y crear mejores artículos. No olviden que pueden escribirnos sobre cualquier consulta o comentario.

SOFTWARE TESTING VS. QUALITY ASSURANCE

Con el paso de los años se han ido inventando nuevas formas de mejorar los sistemas. Estas mejoras son tomadas en cuenta dada la necesidad de obtener productos (software) de mejor calidad.

Este artículo ha sido escrito precisamente para tratar de aclarar 2 de los conceptos más mencionados al referirse a la calidad del software: Pruebas de Software (Software Testing) y Aseguramiento de la calidad QA (siglas de las palabras en inglés Quality Assurance).

Para tener una idea clara de las diferencias y relación entre ambos, es necesario conocer los conceptos.

Las Pruebas de Software son una fase muy importante dentro de casi todos los modelos conocidos de Ciclo de Vida del Software. Por ejemplo; en el venido de los 70’s pero aún utilizado, modelo Cascada, se realizan las pruebas una vez terminada la construcción del sistema, en el Incremental se realizan las pruebas en cada incremento del sistema, o por ejemplo, en el Evolutivo mediante la retroalimentación de los usuarios, en el espiral durante su verificación y validación del desarrollo, o en los enfoques XP (eXtreme Programming o Programación Extrema) con repetidas pruebas de cada una de las mejoras debido a su desarrollo iterativo e incremental. Así podríamos ir mencionando otros modelos no tan conocidos pero que seguramente incluyen Pruebas también para entregar sistemas de Calidad.

Por otro lado, QA se refiere a asegurar (como su nombre lo dice) la calidad en cada una de las fases de la elaboración de un producto final, cualquiera que éste sea. En el caso de QA de software, se referirá entonces, a asegurar la calidad de los resultados de cada una de las fases del ciclo de vida del software y con esto, asegurar la calidad del producto final. Para cumplir con este aseguramiento se deberán definir estándares y establecer procedimientos contra los cuales se pueda comparar lo alcanzado durante cada una de las fases. Por ejemplo; si para el Análisis de Requisitos dentro de un modelo cascada, se ha definido un tipo determinado de documento a presentar, entonces para pasar a la fase de Diseño, el documento de Análisis deberá estar conforme al documento estándar ya que una fase que no se ejecutó de forma correcta podría causar (y muy probablemente lo haga) defectos en las fases posteriores. La idea es que mientras más temprano se detecten las fallas, menor será el costo (monetario, de tiempo, recursos, calidad, etc.) de repararlas y mayor la calidad del producto final.

Una vez con estos conceptos en mente será más sencillo señalar un par de diferencias y relaciones entre ambos:

•Las Pruebas de Software se realizan en una de las fases del ciclo de vida del software; mientras que QA de software se deberá ejecutar en todas las fases (incluida la fase de Pruebas).

•Las Pruebas de Software utilizarán Casos de Pruebas para ser ejecutados; en cambio QA de software utilizará los estándares y procedimientos establecidos para cada una de las fases del ciclo de vida del software.

•Ambas permitirán verificar y afirmar la calidad del producto final, el software.

•Ambas definen un conjunto de actividades a realizarse dentro del ciclo de vida del software para mejorar y asegurar la calidad del mismo.

Este tema es sumamente amplio y en este artículo sólo se ha tocado una pequeña parte de él, pero como se mencionó inicialmente, QA y Pruebas de Software son de los conceptos más utilizados al hablar de Calidad de Software así que hay que tenerlos siempre claros para saber cuándo utilizarlos!

COMO REALIZAR CASOS DE PRUEBA

Cuando mi colega Alexander (creador de este Site) me pidió realizar un artículo en base a los Casos de Prueba pensé “que fácil, si crear casos de prueba es parte de nuestro día a día”, la verdad es que lo difícil es plasmar en forma clara, concisa, entendible y sobretodo útil este conocimiento, he tratado de darles una idea global del tema, orientado a pruebas funcionales pero los conceptos expuestos son aplicables a todo tipo de prueba, espero les sea útil.

Según WIKIPEDIA: “En la Ingeniería del software, los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio”, clarísimo ¿no?, pero para reforzar la idea y ser aún más claros, podemos decir que los casos de prueba nos ayudan a validar que el aplicativo desarrollado realice las funciones para las que ha sido creado en base a los requerimientos del usuario solicitante.

Esto nos indica que por lo menos deberá existir un caso de prueba por cada requerimiento que la aplicación deba cumplir; ¡¡fácil!!, bueno, lo sería si tenemos claro los requerimientos, si el analista de sistemas o llamado también analista funcional realizó un buen levantamiento de la información y lo que él indica como verdad es lo que el usuario pidió, pero ese es otro tema que da para largo y que podríamos ver en otro artículo, la idea aquí es que nosotros como analistas de pruebas debemos tener claro que debe hacer el aplicativo y cuál será el alcance de las pruebas, una buena documentación es básica, como quien dice papelito manda.

Pensemos que estamos en una empresa que tiene alguna documentación de sus desarrollos y nos puede servir como punto de partida. ¿Qué debemos hacer para desarrollar nuestros casos de prueba?

Primero que nada, ¡¡documentarnos!!, no podemos aventurarnos a escribir casos de prueba por que sí, sin algún fundamento o conocimiento previo del tema, debemos tener claro que hará el aplicativo a validar, debemos conversar con el equipo de desarrollo y/o analista funcional o con la persona que levantó la información para que absuelva las dudas que podamos tener, ¡amigo hágalo! vaya que lo espero…¿listo?, pues sigamos.

Ok, ya sabemos que debe hacer la aplicación, aplicativo, sistema o como quiera llamarlo, ahora hagamos una lista de los requerimientos que debemos verificar, por ejemplo si quisiéramos hacer casos de prueba sobre la calculadora de windows deberíamos primero leer el manual o el help sobre este aplicativo para saber que funciones realiza.

Aplicativo: Calculadora de Windows

Requerimientos:

1.Sumar dos o más números

2.Restar dos números

3.Dividir dos números

Etc …

A cada punto de la lista debemos darle cuerpo con información como: que queremos verificar en ese punto, que tipo de datos de entrada necesitamos (si esto aplica), que acciones previas hay que tomar (si esto aplica), que resultado estamos esperando, ojo resultado correcto o incorrecto, más adelante entenderás a que me refiero, entre otras cosas, en resumen estamos creando nuestros “escenarios de pruebas”, es decir, las diferentes condiciones en las que el aplicativo deberá trabajar y por cada escenario es posible contar con uno o varios casos de pruebas.

¿Que tal?, espero que bien y que algo de lo que te cuento te pueda estar sirviendo o dándote una idea más clara del asunto, bueno pues, hasta el momento hemos dicho que debemos saber que hace el aplicativo y hemos dado alguna pauta para empezar a crear nuestros casos de prueba, ahora bien te cuento que personalmente al crear casos de prueba comienzo por los casos correctos, es decir aquellos requerimientos que la aplicación debe cumplir si o si, y luego en base a estos creó casos de prueba incorrectos, es decir, aquellos en los cuáles espero forzar a errores a la aplicación y esperar una respuesta adecuada pero incorrecta, por ejemplo si la aplicación tiene como un requerimiento enviar un email y para esto tenemos un campo donde ingresar el email destino , si ponemos un email destino con un formato correcto y que existe luego mandamos el mensaje esperando que este llegue a destino, si esto sucede es un caso correcto, pero que pasa si escribimos el email destino con un formato incorrecto o el email no existe y mandamos el mensaje ¿que debe hacer la aplicación? ¿Enviarlo y caerse al no encontrar el destino?, o en otras palabras colgarse!!, sería muy decepcionante que esto suceda, en este caso lo que deberíamos esperar es que al mandar el mensaje de email, nos aparezca una alerta, mensaje, etc. Cualquier tipo de comunicación que nos indique que el formato del email destino es incorrecto, o que el mensaje no se pudo entregar porque el destino no existe, bueno pues ese es un caso de prueba incorrecto pero si el resultado es la alerta esperada está bien.

En pocas palabras en la creación de casos de prueba debemos aplicar la lógica del “usuario tonto”, es decir, nos ponemos en la situación de un usuario que va a reventar la aplicación ingresando emails falsos (para el caso de ejemplo), o datos con formatos incorrectos o no va a seguir las indicaciones de algún flujo o proceso secuencial, es decir a cada validación de un proceso en situación ideal habría que probar el mismo proceso con situaciones no ideales y que nos ayuden a

encontrar errores. En conclusión no solo debemos verificar que el aplicativo haga bien las cosas que debe sino también que no haga lo que no debe.

Cuando tengamos nuestros casos de prueba, ahora debemos alimentarlos, darles vida, existen casos en los cuáles necesitaremos data, otros quizás sean simples en lectura pero impliquen todo el recorrido de un flujo para poder ser completados, otros pueden ser tan simples como dar un clic o verificar el diseño de una pantalla o reporte, esto se puede complicar tanto como queramos por eso es muy importante tener claro el alcance de las pruebas, hasta donde queremos llegar, luego de tener todo listo no nos queda más que ejecutar los casos de prueba y verificar los resultados, la parte más pensada debe ser la creación del caso de prueba y la búsqueda de data correcta de ser el caso, luego de ello la ejecución y verificación será un mero trámite, nuestro mayor logro esta en encontrar errores o defectos y contribuir en primera línea a obtener un producto de calidad. El programador es nuestro amigo, somos del mismo equipo, hay que tener mucho criterio al indicarle los errores encontrados ya que muchos programadores piensan que son infalibles, quizás algunos errores no sean técnicos sino funcionales, depende mucho como hayamos planteado los casos y nuestra estrategia de pruebas.

Bueno para terminar y no desplayarme demasiado, te hablé de la información que debe tener un caso de prueba, esto es relativo y depende mucho de la información que uno necesite para ejecutar el caso de prueba y que quiera hacer con él, para almacenarlo, para tener un buen registro, para informar sobre las pruebas, es decir, no existe una ley que debamos seguir al pie de la letra pero te indico un formato, plantilla con información que puede ayudarte:

•Id de caso de prueba.

•Módulo a probar

•Descripción del caso

•Pre-requisitos

•Data necesaria (valores a ingresar)

•Pasos o secuencia lógica

•Resultado esperado (correcto o incorrecto)

•Resultado obtenido

•Observaciones o comentarios

•Analista de Pruebas (responsable de las pruebas)

•Fecha de Ejecución

•Estado (concluido, pendiente, en proces

Así por ejemplo usando algunos campos:

Id Caso de prueba

Modulo a probar Descripción del caso

Pre requisitos Resultado esperado

Resultado obtenido

Estado

CP001 VENTAS Verificar que se genere el archivo de ventas correctamente

- Que exista data para el archivo.- Que exista la ruta destino

OK OK Concluido

CP002 LOGISTICA Verificar que se graben los datos de ingreso en la tabla Movimientos.

- Ingresar datos-Tener Permisos de lectura a la BD.

OK Pendiente

puedes utilizar los campos y la información que mejor se adecue a tus necesidades, la idea es estar ordenados, organizados y tener una buena información de las pruebas.

PMP Y TESTING - ¿Relaciones Cruzadas?

Es importante tener en cuenta la organización a la cual pertenecemos, el nivel de estandarización de los procesos, el conocimiento de la cultura organizacional, entre otros. No es complicado, basta con un tiempo adicional que le brindemos y comencemos a analizar, haciéndonos preguntas sencillas, que nos permitan investigar.

Por tanto, considero que luego del análisis situacional del entorno en que trabajamos, podremos entender que hay diferentes formas de hacer lo mismo; existen organizaciones en las que la fase de pruebas de un producto, control de calidad, también son denominados QA de aseguramiento de la calidad y pueden tomar diferentes orígenes:

• Ser parte del equipo de desarrollo.

• Ser una unidad distinta de la organización dedicada al servicio.

• Ser una unidad de usuarios finales que requieran el producto. y,

• Una empresa proveedora que brinde dicho servicio.

Pero, para el caso del artículo, nos centraremos en la opción 2, en la cual encontramos una unidad interna dedicada a brindar este servicio de QA dentro de la organización a la cual perteneces, que ocurre cuando una organización no es projectizada de manera eficaz. Sencillamente, la metodología aplicada será beneficiada sólo por una unidad y estamos convencidos que ello ocurre en las empresas, al definir la estrategia de utilizar una PMO dentro de su organización, pues se enfoca en logros a nivel estratégico, es decir, las líneas de QA no reciben el mismo aporte de la metodología y posiblemente alguna otra unidad importante para los proyectos tenga el mismo problema.

Hay una metáfora muy interesante que leímos en un artículo del PMI Project Managemente Institute, el cual compartimos; “imagínense un pez nadando en el mar, usted le pregunta al pez: Puedes decirme qué es el agua? el pez te responde que no…!, tú te quedas intrigado por la respuesta”. El tema es sencillo, muchas veces estamos involucrados o somos parte de un entorno y las presiones del día a día no nos permiten ver o tener una visión más amplia.

Por lo tanto, qué deberíamos tener en cuenta:

• Analizar el entorno y todas las unidades involucradas.

• Trabajar en conjunto con las unidades e integrar sus procesos.

• Desarrollar un grupo de PMP -projects managers-, líderes para difundir la metodología.

En conclusión, para el mejor desarrollo de una unidad QA sugerimos lo siguiente:

• En la unidad, debe generar un puesto de trabajo denominado PM-QA (Jefe de Proyectos de Aseguramiento de la Calidad)

• Los proyectos serán asignados directamente al PM-QA.

• El PM-QA adquiere el equipo con la aprobación de otros jefes.

• El PM-QA lleva la dirección de los proyectos asignados con un líder de proyecto, alineándose con la metodología del PMO.

Dado que el proyecto es temporal el equipo del PM-QA también lo será, al final del proyecto los miembros de cada proyecto regresan al mando de sus jefes iniciales.

Ventajas

• Mediante esta asignación los proyectos serán alineados a una misma metodología que usa la oficina PMO.

• Formatos, cronogramas, documentación, serían la misma para todos los proyectos que sean requeridos a la unidad de QA.

• Los recursos podrán adquirir experiencia de diferentes proyectos, teniendo en cuenta que los proyectos son temporales.

• Capacitación en gestión de proyectos.

• Mejor control de los proyectos, dado que los equipos de trabajo se desarrollan y se crean para un sólo objetivo, el éxito del proyecto.

• Mejor control de los costos para el proyecto.

¿A MEJOR TESTING PEOR CALIDAD DE SOFTWARE?

Luego de altas persistencias de fallos, defectos y errores en los sucesivos ciclos de Testing para distintos proyectos y alguna cantidad de detecciones en los clientes, los reclamos con tonos elevados no se hicieron esperar. Hubo así entre dicho entre los Responsables de Despliegues, ataques entre Testers y Desarrolladores, Administradores de Pruebas y Responsables de Desarrollo y finalmente La Gerencia. Luego de planteos fuera de lugar y experiencias que nos pusieron en límites de tolerancias entre las personas, quise analizar por qué estamos fracasando tan enfáticamente en lo que a calidad de los productos de software se refiere.

Tengo mis anotaciones frescas en mi cuaderno de proyectos y en mi mente mucho más, sin embargo, luego de leer un poco de blogs que frecuento, encontré una referencia a un artículo muy interesante. El título expresa simplemente lo siguiente: “¿A mejor Testing, peor calidad de Software?”. Automáticamente me llamó la atención esta suerte de contradicción y abrí el PDF directamente desde la WEB.

En cuanto inicié la lectura pude ver un diagrama que me refrescó los conceptos que vengo gestando desde mis análisis de problemas.

Sucede que las metodologías, cualquiera sea, tienen ciertos elementos que si no sabemos tratar con cuidado, convierten todo un proceso en burdo y empantanado.

Observé otra pregunta reveladora:

“¿Cómo sabe que su Software no está en un Espiral Muerto?”

A este respecto en el artículo se dan ciertas sugerencias como:

•Cuenta la cantidad de fallos, errores y defectos

•Escucha a los Testers

•Observa los tiempos de Integración

•Escucha a los desarrolladores

•Presta atención a la demanda de recursos

•Recuerda y ten en cuenta ciertos puntos de control ◦Usa una base de conocimiento de los fallos, errores y defectos entregados a producción

◦Aplica técnicas de prevención de fallos

◦Conoce el esfuerzo de implementación

◦Conoce el esfuerzo del Testing

•Evalúa fallos conocidos ◦Los desarrolles pueden continuar con la tasa de fallos encontrados en su haber?

◦Los Testers están encontrando los fallos más importantes?

◦La Gerencia está tomando buenas decisiones al respecto de los fallos que son encontrados?

◦Los fallos son utilizados para mejorar el proceso de desarrollo en general?

•Evalúa los Requerimientos ◦Asegúrate de que todo el mundo entiende que estamos construyendo, por que y para que

◦Convierte los requerimientos implícitos en explícitos

◦Permite y promueve que los interesados vean el software periódicamente durante la fase de desarrollo

◦Escucha cuidadosamente y cuestiona las presunciones

•Los defectos ponen a prueba las aplicaciones ◦Define código estándar

◦Define buenas prácticas de codificación

◦Mantenga las revisiones para ver que las codificaciones siguen los estándares

◦Toma ventaja de las revisiones de código como una oportunidad para compartir sugerencias y técnicas para las pruebas de error en el entorno de desarrollo

•No permita que un problema se transforme en el problema de alguien más ◦Mantén una cultura donde la idea viva sea la de la RESPONSABILIDAD

◦No dejes de hacer hoy lo que podrías delegar en otra persona del equipo

◦Si un problema tuyo no se convierte en un problema de alguien más, entonces no es un problema

◦Ten en cuenta que el Software es quien sufrirá los resultados

•Detecta los fallos en forma temprana ◦Como están definidas las Pruebas de Unidad?

◦Quien es el responsable de las Pruebas de Unidad?

◦Se puede testear algunas partes del sistema en forma aislada?

◦El esfuerzo de las Pruebas Unitarias está mejorando?

◦Cuales herramientas está utilizando para ayudar al proceso de Pruebas Unitarias?

◦El sistema es construido e integrado diariamente?

•Planifica el tiempo para el Desarrollo, Testing y Correcciones de Defectos ◦Incluye en la planificación de los desarrolladores el tiempo suficiente para realizar algunos tipos de pruebas durante la construcción de primera mano

◦Considera en la planificación de los desarrolladores el tiempo suficiente y necesario para la corrección de los defectos detectados durante sus propias pruebas

◦Presta atención a las alarmas de los desarrolladores al respecto de las presiones de tiempo que hacen que se salten etapas

•Invierte en mayor medida en la prevención de los defectos

◦No planifiques obtener mejora de calidad solo promoviendo la mejora del esfuerzo del “Testing Independiente” (grupo separado de los Desarrolladores)

Queda claro el concepto de que la Calidad Percibida es inversamente proporcional a la cantidad de defectos que se dejan pasar a los entornos operativos del cliente. Es decir que a más defectos del lado del cliente, menos calidad percibida y viceversa. De la misma manera a mayor cantidad de defectos detectados en las pruebas de sistemas, el número de defectos posibles a ser pasados al entorno operativo del cliente es menor. Esto quiere decir que hay etapas que deben ser respetadas a raja tabla aún a disconformidad de alguna de las partes, como una Líder de Proyecto, Responsable de Despliegue, Comercial o inclusive La Gerencia.

Una de esas etapas son las Pruebas de Sistemas. Este es el entorno operativo dentro de la organización, más cercano al entorno operativo del cliente y los resultados generados en este ambiente, se deben tomar indefectiblemente como referente directo de los resultados que se replicarán en los ambientes productivos y su consiguiente Calidad Percibida.

Aún cuando se incremente el Esfuerzo Independiente que suponen las pruebas de sistemas, hay otras etapas previas conocidas como el “Esfuerzo del Testing del Desarrollo”, que no deben ser omitidas, pues aún estando más lejos del entorno operativo de producción, son la garantía inicial de que el producto construido cumplirá con los requisitos. Directamente estas garantías iniciales impactan en los costos de la organización.

¿PAGAR POR DEFECT O ELEVAR LA CONCIENCIA CREATIVA DEL ACTO VERIFICADOR?

¿Cómo creés que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente? Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Cómo incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación?

Una respuesta de otro amigo:

Pues yo creo que incentivar la localización de errores está bien. Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (”es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio’” … y cosas de ese estilo). Ah! Y añado otra cosa: igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión. Luego se hacen las cuentas de la vieja y se saca balance.

¿Qué tal un esquema intermedio?

1) Incentivar a los desarrolladores con relación inversa al número de defectos que “les” encuentren los Testers.

2) Incentivar a los Testers con relación al número de objetos/unidades/loquesea que pasen a producción validados

3) E incentivarlos a todos con la “velocidad” del proceso completo, y con relación inversa a los defectos encontrados en producción.

Me resulta un poco extraña la cuestión de tener que incentivar a un Tester o grupos de Testers por tener que hacer su trabajo bien. Igual para los desarrolladores o cualquier otra persona que cumpla un rol específico dentro de la cadena productiva de software.

En primer lugar considero que un plan de verificaciones y/o validaciones no puede quedar librado a la buena de un Tester, sino que debe guiar a cada uno de los involucrados en el proceso hacia los resultados esperados, también sus controles y gestiones.

Si se considera la existencia de Testers en un equipo de producción de software, no debe ser sin la existencia de un responsable QA y la carga de gestión recae sobre los hombros de tal o tales personas. Lo que se puede hacer es “elevar la conciencia creativa del acto verificador” agregando capacitaciones especializadas en herramientas, conceptos avanzados, UML, patrones de calidad y demás elementos que existen para sumir al equipo de calidad en un estándar que desde el llano y como punto de partida sea muy alto.

Podría agregar que es bueno tener métricas de cantidades de defectos detectados por Tester pero no podríamos dejar de mirar que tipo de defectos detecta cada uno de ellos y como es el impacto de cada uno de esos defectos detectados en los proyectos. Esto serviría para que en caso de necesitar dividir el equipo de Testing, al “mejor Tester” se le asignaría una especie de “jefatura” sobre otros que no tienen el mismo rendimiento.

Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos RRHH, es bueno aplicar criterios de competencias operativas. Pero en otros casos no. Equipos enteros podrían desintegrarse por generarse ciertas incomodidades. No quiero ni hablar de cómo impactaría sobre nuestros productos.

Entonces, pagar por defectos detectados vale para equipos de venta. Ya todos los defectos del producto fueron eliminados o se presumen eliminados y el producto de alta calidad. Ahora a generar retorno de la inversión.

Me gusta mucho la idea de incentivar, pero sin generar competencias sino ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su conciencia de responsabilidad.

Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas inician el Testing. No es mérito del Tester sino de la incompetencia de alguien en fases anteriores. No señalo a nadie, pero desde el Tester para atrás, hay muchas responsabilidades intrínsecas.

Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí.

Cierta oportunidad siendo Líder de Testing al finalizar uno de los proyectos postulados para certificación CMMI-4, mi equipo detectó grandes cantidades de fallos en los productos solo en los primeros ciclos, cuando había planificados 12 ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los ciclos subsiguientes, nuestra tasa de detección cayó significativamente para el resto de los ciclos (considerar PARETO).

Esto me llevo a analizar la situación, a modificar definitivamente el modo en que manejamos los ciclos. Finalizado el proyecto que menciono, invité a mi equipo a un almuerzo y por supuesto al equipo de Desarrollo. Allí pude explicar lo que habíamos conseguido trabajando en equipo y como unos sin otros no pueden evidenciar su actividad hecha con responsabilidad.

Creo en definitiva, que brindar las herramientas adecuadas, la capacitación necesaria y sostener un ambiente colaborativo y ameno, son los mejores incentivos.