You are on page 1of 11

Introducción 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 modulo 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 inconcientemente evitara realizar pruebas mas 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 ultima 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 mas 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. estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras esta desarrollando el módulo. si no se corrige esta situación los proyectos en su gran mayoría fracasaran o perderán más tiempo aún. y se debería considerar como tal. Si un sistema llega a la etapa de pruebas funcionales con demasiados errores críticos y/o bloqueantes. En la empresa en la he laborado algunos años solo se realizaban pruebas del tipo funcional. También es importante separar los módulos de acuerdo a su funcionalidad. 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. se debería devolver el sistema a la etapa de pruebas unitarias ya que resulta muy poco productivo realizar pruebas funcionales con sistemas inestables. Este tipo de pruebas debe ser realizado por personal especializado en Software testing.PRUEBAS UNITARIAS . se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera sencilla y rápida. ya que las pruebas unitarias nos permiten encontrar los errores más evidentes y fáciles de corregir. incluso se siente algún malestar si el tester sigue encontrando errores. y no en la lógica intermedia.CAP 1 Al desarrollar un nuevo software o sistema de información. 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. en la etapa de pruebas funcionales el sistema debería estar bastante estable y con muy pocos errores críticos. la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box). UNIT TESTING . este comportamiento es obvio. cada error encontrado por el analista de pruebas es un éxito. Al hacer esta labor el analista de pruebas podrá recomendar que un modulo muy complejo sea separado en 2 o 3 módulos más sencillos. el cual debe estar familiarizado en el uso de herramientas de depuración y pruebas. o con algunos problemas de tiempo sacrifican horas de pruebas. a diferencia del analista de pruebas que tiene más bien una misión destructiva. posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional. en mi experiencia personal he podido ver que proyectos atrasados. El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar. el analista de pruebas debería dar fuerza a las pruebas funcionales y más aún a las de robustez. estás pruebas también son llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa esta listo y correctamente terminado. ya que al parecer son los que el usuario mejor comprendía y en las que podía apoyar. si los módulos son muy grandes y contienen muchas funcionalidades. Los sistemas que han pasado por pruebas unitarias tienen un menor tiempo de pruebas funcionales. 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. siendo las pruebas unitarias una primera etapa y las pruebas funcionales la segunda y definitiva en la que se da la conformidad del sistema. (Black Box ± Caja Negra). generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar. enfocados básicamente al negocio. así mismo deben conocer el lenguaje de . 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.

y Finalmente se deben comparar los datos obtenidos en la prueba con los datos esperados. La Suite de Mercury. esta segunda etapa fue mucho más rápida. El número de módulos se incrementa progresivamente hasta formar el programa completo. Lo importante en este tipo de pruebas es que se deben tener claros los siguientes aspectos: y Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos deben ser preparados con minuciocidad. el siguiente paso es integrarlos. por ejemplo componentes que fueron renombrados en el nivel bajo y no fueron actualizados en las llamadas de los niveles superiores. iniciamos las pruebas de los módulos de nivel superior. y Integración Incremental Ascendente. cada uno de estos componentes debe ser probado en su totalidad (óvalos). o flujo de datos entre componentes. Integración Incremental Ascendente y 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. si son identicos podemos decir que el modulo supero la prueba y empezamos con la siguiente.programación en el que se esta desarrollando la aplicación. El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfases. que básicamente hacían llamadas a estos módulos de más bajo nivel. y 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. y este luego es sustituido por los módulos de nivel superior en la jerarquía. seguimiento de errores. y A través de un driver (módulo impulsor) se simulan llamadas a los módulos. Esto lo podemos realizar de 2 formas. este tipo de pruebas también son llamadas pruebas de caja de cristal ya que este útlimo termino representa mejor el tipo de pruebas. No es un requisito indispensable la culminación de todos los módulos del sistema para iniciar las pruebas. en este tipo de pruebas el cubo representaría un sistema en donde se pueden observar los diversos componentes que forman parte del mismo. y también sus interfases o comunicaciones con los demás componentes (flechas). en la actualidad algunas metodologías consideran oportuno iniciar la etapa de pruebas unitarias poco después del desarrollo. y Cada grupo se prueba usando su driver (test integrador). . una vez que cada uno de estos módulos funcionaba correctamente. estas herramientas pueden facilitar el desarrollo de pruebas. se introducen los datos de prueba y se recogen los resultados. al reemplazar los drivers que creamos por los módulos de más alto nivel encontrábamos pequeños pero muy críticos errores. CPPUnit etc. En esta imagen se muestra lo que se considera una representación clásica de Software Testing White Box o pruebas de caja blanca. elaboración de casos de pruebas. en esa oportunidad empezamos por los módulos que aplicaban lógica de negocio y hacían cambios en la base de datos. me toco probar un sistema bancario. pues estos últimos tenían muy poca lógica. ya que el resultado de las pruebas dependen de estos. y Se debe conocer de antemano que resultados debe devolver el componente según los datos de entrada utilizados en la prueba. y Se debe conocer que componentes interactuan en cada caso de prueba. y Integración Incremental Descendente. etc. generalmente las pruebas modulares y las pruebas integrales se solapan. Algunas de las herramientas que se utilizan para pruebas unitarias son: JUnit. inclusive se pueden conseguir herramientas para cada tipo de lenguaje. En el último paso se prueba el programa completo con sus entradas y salidas reales. en la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas. En mi experiencia como analista de pruebas. Luego de tener una buena cantidad de módulos independientes probados y encontrados Conformes. las principales formas de integración que existen son: y Integración Incremental.

luego de probar los módulos de más bajo nivel (E. 3 Integración Incremental Ascendente . en este ejemplo cada módulo debe ser probado por separado. en la figura 4 se muestra un nivel más de integracion incremental ascendente. 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.La siguiente imagen muestra la primera fase de la integración ascendente. continuamos con los módulos del siguiente nivel.Fase 1 Tal como se muestra en la figura 3. Fig. F y G). 2 Integración Incremental Ascendente . Fig. Este proceso se repite algunas veces hasta que se culmina por probar el sistema completo. F Y G).Fase 2 . para esto se debe construir un driver o impulsor para probar cada módulo.

y Permite ver la estructura del sistema desde un principio.Fase 3 Ventajas de la integración incremental ascendente: y 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. Desventajas de la integración incremental ascendente: y Se requieren módulos impulsores. sustituir un módulo ficticio subordinado por el real que reemplazaba. para luego nutrir de datos al resto del sistema. pueden considerarse las siguientes pautas: y Si hay secciones críticas como ser un módulo complicado. que deben escribirse especialmente y que no son necesariamente sencillos de codificar. y Escribir los módulos ficticios subordinados que se necesiten para la prueba del nuevo módulo incorporado. La única regla es que el módulo incorporado tenga todos los módulos que lo invocan previamente probados. facilitando la elaboración de demostraciones de su funcionamiento. buscar el orden de integración más decuado para la organización de las pruebas. y Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado. 2. Integración incremental Descendente Inicia del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. Debe estudiarse el problema concreto y de acuerdo a este. No obstante. y Al terminar cada prueba. . y El sistema como entidad no existe hasta que se agrega el último módulo. se debe proyectar la secuencia de integración para incorporarlas lo antes posible. que serán llamados por el módulo de control superior. En general no hay una secuencia óptima de integración. y 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. según el orden elegido. y El orden de integración debe incorporar cuanto antes los módulos de entrada y salida. y Resuelve primero los errores de los módulos inferiores que son los que acostumbran tener el procesamiento más complejo. Primero en anchura: Primero se mueve horizontalmente en la estructura de módulos.Fig. Ventajas de la integración descendente: y Las fallas que pudieran existir en los módulos superiores se detectan en una etapa temprana. 4 Integración Incremental Ascendente . No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo a incorporar. Primero en profundidad: Primero se mueve verticalmente en la estructura de módulos. Etapas de la integración descendente: y El módulo de mayor nivel hace de impulsor y se escriben módulos ficticios simulando a los subordinados. Existen principalmente dos métodos para la incorporación de módulos: 1.

es necesario en primer lugar contar con un ambiente donde probar. la integración consiste en probar cada modulo por separado de manera similar a la integración incremental pero una vez de terminar con los módulos independientes. y La única ventaja es que no se necesita ningún tipo de trabajo adicional: ni planificar el orden de integración. y La cantidad de errores que arroje puede ser atemorizante. esto trae un problema. ya que nuestras pruebas se verían afectadas. las cuales deben trabajar coordinadamente con los testers para que unos pongan la experiencia del sistema y otros la experiencia del negocio. y 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. Suelen ser más complicados de lo que aparentan. que las opciones se presentaran y que la información me sea brindada de manera correcta y precisa. la seguridad que debemos tener para que ninguna persona efectué modificaciones al ambiente respectivo. y esto complica aún mas las pruebas. TESTING A UN SISTEMA DE CALL CENTER El efectuar pruebas a un Call Center me parecía tan práctico como llamar a una central y verificar que la conexión era adecuada. Ahora volviendo al caso del Call Center surge un problema. Para poder efectuar pruebas de cualquier índole. y Antes de incorporar los módulos de entrada y salida resulta difícil introducir los casos de prueba y obtener los resultados. Ahora si no contamos con el ambiente de pruebas debemos usar el ambiente donde efectuamos las modificaciones. para describir esta pequeña experiencia nos situaremos en una empresa cuyo giro es la banca. pero muchas cosas adicionales que hacen que el mundo de las pruebas a un Call Center sean interesantes y a la vez no tan simples como pensaba al inicio. y este es. un grave error de mi parte. la lista de desventajas incluye: y No se tiene noción de la comunicación de los módulos hasta el final. Para la implementación/modificación de un Call Center mayormente se trabaja con una empresa proveedora. si en mi empresa tengo un Call Center grande. y Se corre el riesgo de que a poco tiempo de que se cumpla el plazo de entrega. Integración No Incremental La integración no incremental es bastante sencilla y generalmente se recomienda para proyectos de poca envergadura. Un Call Center dependiendo de la envergadura de la empresa puede ser desde pequeño hasta enorme. y En ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o presentar. ¿necesito otro ambiente de pruebas? ó ¿puedo tomar el mismo ambiente donde efectúo los cambios para efectuar mis pruebas? Lo ideal seria lo siguiente: un ambiente donde efectúo mis cambios. una coordinación adecuada y un control respectivo sería ideal en este punto. un ambiente lo mas parecido (en el mejor de los casos.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. el Call Center es uno de sus canales más importantes y de mas consulta. Por otro lado. pilares básicos para obtener un buen resultado. ya que tras todos estos puntos existen muchas. es decir. y Induce a diferir la terminación de la prueba de ciertos módulos. y tengo un ambiente donde efectúo los cambios. y La tarea de encontrar la causa de los errores resulta mucho más compleja que con los métodos incrementales. por ende. Desventajas de la integración descendente: y 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. haya que volver sobre el diseño y la codificación del sistema. idéntico) a lo real. un ambiente de pruebas y un ambiente real. ni crear módulos impulsores. la cual tiene personas expertas para el proyecto. se continua probándolos todos juntos como un todo. y El hecho de realizar todas las pruebas de una vez hace que las sesiones de prueba sean largas y tediosas. ni crear módulos ficticios subordinados. asimismo la documentación previa debe ser revisada por personas con conocimiento del .

que los tiempos de respuesta sean correctos. cual es el tiempo de atención de cada uno de ellos. 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. etc. 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. Aplicativo de Reportes. cada error que yo pudiera encontrar significa un éxito para la calidad del sistema. etc. enfocadas principalmente al sector financiero. así tenemos: 1. la falla de algunos de ellos impacta en todo lo demás. asesores conectados. testers. muy útil para que los supervisores puedan tomar decisiones para mejorar los tiempos de respuesta y reducir las esperas. Debemos revisar que las llamadas siempre lleguen a las personas indicadas y que el tiempo de respuesta sea el adecuado. proveedores (desarrolladores). mails y llamadas. Pantallas de Control.Functional Software Testing y las pruebas unitarias Unit Software Testing deben ser consideradas como temas cien por ciento técnicos. 2. quien recibió mas llamadas. Como pueden ver este mundo es complejo y se necesitan revisar varios temas. 4. llegan a un sistema donde el operador responde automáticamente las llamadas. una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas. deben ser primordiales. Aplicativo automatizado para responder las consultas. Las estrategias de ruteo. asesores. los conocimientos técnicos son valiosos en esta labor.negocio. C/S o Host. y acá empiezan los controles de tiempos. importancia del cliente. etc. 5. en mi experiencia como analista de pruebas o también llamado tester. cuando las llamadas son ruteadas por las estrategias. para revisar que se reflejen adecuadamente en el sistema. que las llamadas sean ruteadas correctamente. el cronograma de pruebas y los casos de prueba. Evidentemente el analista de pruebas o tester debe ser un profesional en Ing. Las reuniones periódicas entre usuarios. Aplicativo de Monitoreo en línea. siendo esta última a mí parecer la más complicada. que todas las opciones estén activas. Información obtenida en línea del aplicativo de monitoreo. se tienen todos los reportes respectivos obtenidos en base a la información proveniente del aplicativo de monitoreo en línea. podemos separar 2 partes para esta validación: La primera parte es revisar todo el proceso automático de respuestas. tiempos de demora. De Sistemas o Ing. que los aplicativos estén sincronizados. ¿COMO REALIZAR PRUEBAS FUNCIONALES? Las pruebas funcionales . necesarias para que la llamada llegue a la persona indicada y esto incluye skills del asesor. estos son una serie de aplicativos que tienen que trabajar coordinadamente. este aplicativo sirve para revisar en línea la cantidad de asesores conectados. en la actualidad los sistemas más importantes son realizados para dar solución a los problemas de negocios. 3. . tipo de consulta. cuantos están ocupados. Debemos tener presente efectuar pruebas de todas las estrategias respectivas. pero no son suficientes. estrategias para ruteo como estrategias de tiempos. El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema. para revisar esto debemos de llevar un control manual de todo lo efectuado en ciertos rangos de horas y fechas. actualizaciones. de Software. ingreso de información. acá debemos revisar la seguridad al ingresar. Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado. en resumen debemos revisar lo siguiente: tiempos de respuesta. Las pruebas al Call Center no eran validar simplemente llamadas telefónicas sino que existía una gran cantidad de aplicativos. 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. el cual es efectuado por un robot. he llegado a probar una buena cantidad de sistemas en varias empresas. etc. etc. el tiempo en este canal de servicio es primordial. en este Call Center se tenían paneles donde se mostraban datos como personas en cola. hora. Aquí debemos tener una demora máxima de 5 segundos para poder tener la certeza de que la información visualizada sea la correcta. necesitamos también tener conocimientos del negocio. que se muestre la información online y que los reportes históricos reflejen fielmente la información. La segunda parte es cuando el cliente quiere comunicarse con un asesor de servicio. para poder estar de acuerdo en lo que se va a hacer. tanto estrategias para colas.

sin embargo es importante tener buen criterio a la hora de desarrollarlos. Transferencia a un tercero 3. Es interesante notar que la gran mayoría de los errores se encuentran en los valores límite.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.00 pues el sistema . 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. Transferencia entre cuenta propia 2. 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. Transferencia interbancaria 4. 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. 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? 1. Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más allá. Saldo > 0. Retiro en efectivo 5. En ventanilla 2. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba. A Plazos Esto nos daría al menos 3 variables o casos de prueba. Home Bankin 4 variables 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. Inactiva. ¿La cuanta tendrá saldo? Saldo = 0. Cajero Automático ± ATM 3. Como menús.99 pues entonces probemos con 100000000. 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. luego de eso podría hacer una prueba con un cargo de 1000. listas. el proceso que debemos seguir en el sistema y el resultado esperado. Cerrada (Suponiendo que solo se manejen 3 estados). Los casos de prueba nos permitirán probar todas las funcionalidades del sistema. En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores. Las combinaciones de casos de prueba podrían ser prácticamente infinitas. Si una pantalla se define para que no soporte un número mayor de 99999999. en donde nos encontraríamos con las siguientes variables: ¿En que tipo de cuenta haremos el cargo? Ahorros. Si en mi caso defino hacer un cargo de 1000 dólares. Pago de un cheque 5 variables ¿En que canal de atención se realizará esta operación? 1. POS ± Pago de servicio o consumo 4. Próximamente espero publicar un artículo tocando el tema de cómo realizar buenos casos de prueba.01 y otro de 9999. los casos de prueba deben definir los datos de entrada a utilizar. botones etc. Corriente. grillas.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Muchos de los errores que he podido encontrar no estaban escritos en mis casos de prueba.

los aman« Otro nicho en el que se ocultan errores podrían ser los campos de ingreso de datos. 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. la verdad es que lo difícil es plasmar en forma clara. como quien dice papelito manda. alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calcular diversos campos calculados. simplemente en el fondo no quieren maltratarlos. cada uno de ellos mostrado en un campo o grilla. ¡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 . 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. se debe probar que el sistema haga lo que debe de hacer y por supuesto que no haga lo que no debe de hacer. ¿Que debemos hacer para desarrollar nuestros casos de prueba? . clarísimo ¿no?. 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. concisa. Es increíble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado. Si realizo esa prueba la primera vez en un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto. 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ó. he tratado de darles una idea global del tema. espero les sea útil.debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. Según WIKIPEDIA: ³En la Ingeniería del software. Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos. si crear casos de prueba es parte de nuestro día a día´. pero para reforzar la idea y ser aún más claros. No olviden que pueden escribirnos sobre cualquier consulta o comentario. 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. ¡¡fácil!!. casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. entendible y sobretodo útil este conocimiento. 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. 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´. Pensemos que estamos en una empresa que tiene alguna documentación de sus desarrollos y nos puede servir como punto de partida. bueno. orientado a pruebas funcionales pero los conceptos expuestos son aplicables a todo tipo de prueba. una buena documentación es básica. disfruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste. Esto nos indica que por lo menos deberá existir un caso de prueba por cada requerimiento que la aplicación deba cumplir. a pesar de ser una definición tan simple muchos la olvidan. tanto en las pantallas como en los reportes. sobre todo en los campos de párrafos o multilíneas. la labor del analista de pruebas es totalmente destructiva para con el sistema. pero ese es otro tema que da para largo y que podríamos ver en otro artículo. lo sería si tenemos claro los requerimientos. aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto. Próximamente espero mejorar y crear mejores artículos. Espero que con estas pequeñas recomendaciones puedan ser capaces de encontrar una gran cantidad de errores.no valido´ o algún otro mensaje horrible. 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. 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´. el caso debe especificar que valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se presenten sean correctos.

Cualquier tipo de comunicación que nos indique que el formato del email destino es incorrecto. 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. es decir. aplicativo. 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.Primero que nada. nos ponemos en la situación de un usuario que va a reventar la aplicación ingresando emails falsos (para el caso de ejemplo). no podemos aventurarnos a escribir casos de prueba por que sí. pues sigamos. debemos tener claro que hará el aplicativo a validar. otros quizás sean simples en lectura pero impliquen todo el recorrido de un flujo para poder ser completados. Aplicativo: Calculadora de Windows Requerimientos: 1. si ponemos un email destino con un formato correcto y que existe luego mandamos el mensaje esperando que este llegue a destino. nuestro mayor logro esta en encontrar errores o defects y contribuir en primera línea a obtener un producto de calidad. bueno pues. 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. El programador es nuestro amigo. En pocas palabras en la creación de casos de prueba debemos aplicar la lógica del ³usuario tonto´. hasta donde queremos llegar. o en otras palabras colgarse!!. ¡amigo hágalo! vaya que lo espero«¿listo?. ya sabemos que debe hacer la aplicación. las diferentes condiciones en las que el aplicativo deberá trabajar y por cada escenario es posible contar con uno o varios casos de pruebas. luego de tener todo listo no nos queda más que ejecutar los casos de prueba y verificar los resultados. Sumar dos o más números 2. Ok. 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?. etc. entre otras cosas. y luego en base a estos creó casos de prueba incorrectos. ahora hagamos una lista de los requerimientos que debemos verificar. Restar dos números 3. otros pueden ser tan simples como dar un clic o verificar el diseño de una pantalla o reporte. que acciones previas hay que tomar (si esto aplica). que tipo de datos de entrada necesitamos (si esto aplica). en resumen estamos creando nuestros ³escenarios de pruebas´. que resultado estamos esperando. aquellos en los cuáles espero forzar a errores a la aplicación y esperar una respuesta adecuada pero incorrecta. es decir. es decir aquellos requerimientos que la aplicación debe cumplir si o si. esto se puede complicar tanto como queramos por eso es muy importante tener claro el alcance de las pruebas. por ejemplo si la aplicación tiene como un requerimiento enviar un email y para esto tenemos un campo donde ingresar el email destino . o que el mensaje no se pudo entregar porque el destino no existe. 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. bueno pues ese es un caso de prueba incorrecto pero si el resultado es la alerta esperada esta bien. en este caso lo que deberíamos esperar es que al mandar el mensaje de email. 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. somos del mismo equipo. luego de ello la ejecución y verificación será un mero trámite. mensaje. ojo resultado correcto o incorrecto. más adelante entenderás a que me refiero. 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 tal?. si esto sucede es un caso correcto. existen casos en los cuáles necesitaremos data. darles vida. quizás algunos errores no . sin algún fundamento o conocimiento previo del tema. ¡¡documentarnos!!. 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. nos aparezca una alerta. es decir. ahora debemos alimentarlos. 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. ahora bien te cuento que personalmente al crear casos de prueba comienzo por los casos correctos. o datos con formatos incorrectos o no va a seguir las indicaciones de algún flujo o proceso secuencial. Cuando tengamos nuestros casos de prueba. sería muy decepcionante que esto suceda. hay que tener mucho criterio al indicarle los errores encontrados ya que muchos programadores piensan que son infalibles. sistema o como quiera llamarlo.

y Módulo a probar y Descripción del caso y Pre-requisitos y Data necesaria (valores a ingresar) y Pasos o secuencia lógica y Resultado esperado (correcto o incorrecto) y Resultado obtenido y Observaciones o comentarios y Analista de Pruebas (responsable de las pruebas) y Fecha de Ejecución y Estado (concluido.Que exista data OK OK Concluido genere el archivo para el archivo. te hablé de la información que debe tener un caso de prueba. Así amigo. 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. es decir. pendiente. tabla Movimientos. la idea es estar ordenados. para tener un buen registro. plantilla con información que puede ayudarte: y Id de caso de prueba. . para informar sobre las pruebas. en proces Así por ejemplo usando algunos campos: Id Caso Modulo a probar Descripción del Pre requisitos Resultado Resultado Estado de caso esperado obtenido prueba CP001 VENTAS Verificar que se . puedes utilizar los campos y la información que mejor se adecue a tus necesidades.Que exista la ruta correctamente destino CP002 LOGISTICA Verificar que se . organizados y tener una buena información de las pruebas.Ingresar datos OK Pendiente graben los datos -Tener Permisos de de ingreso en la lectura a la BD. no existe una ley que debamos seguir al pie de la letra pero te indico un formato. de ventas . Bueno para terminar y no desplayarme demasiado. depende mucho como hayamos planteado los casos y nuestra estrategia de pruebas.sean técnicos sino funcionales.