INTRODUCCION AL SOFTWARE TESTING

El Software testing o como se conoce en espaol las pruebas de software se

aplican como una etapa ms 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 mayora 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 ms crticas del ciclo de vida del desarrollo de
software y esto ha causado el origen de diversas metodologas.
En la actualidad el software testing se hace ms complicado ya que debe hacer
frente a una gran cantidad de metodologas de desarrollo, lenguajes de
programacin, sistemas operativos, hardware etc.
Es por esto que el testing debe apoyarse en metodologas generales que
revisan los aspectos ms fundamentales que debe considerar todo proceso de
pruebas.
Debido a esta complejidad actualmente se cuentan con una gran cantidad de
software diseado exclusivamente para la etapa de pruebas, incluyendo la
gestin del proceso de software testing, la administracin y seguimiento de
errores, la administracin de los casos de prueba, automatizacin de pruebas
etc.
Luego de culminadas las etapas de anlisis, diseo 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
produccin, lo ideal es preparar un ambiente de pruebas lo ms parecido a los
ambientes que existen en produccin 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 formacin que les permite detectar una gran
cantidad de errores en tiempos mnimos, as como una metodologa especifica
que les permite hacer el trabajo de manera correcta, algunas empresas ms
informales utilizan a los futuros usuarios del sistema como testers situacin
que puede traer una serie de problemas debido a la poca experiencia que
pueden tener los usuarios en la deteccin de errores, adems se obvian
pruebas importantes como las pruebas de Esfuerzo o Stress testing, tambin
se dejan de lado las pruebas unitarias o pruebas modulares, las que deberan
asegurar que cada mdulo 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 difcil probar
con objetividad un software si nosotros mismos lo hemos desarrollado, un
tcnico o analista programador empezara a probar con la idea preconcebida de

que su hijito trabaja a la perfeccin e inconscientemente evitara realizar

pruebas ms exhaustivas considerando que las mismas podran 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 especficas para los cuales han sido creados, es
comn 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
produccin.
A este tipo de pruebas se les denomina tambin pruebas de comportamiento o
pruebas de caja negra, ya que los testers o analistas de pruebas, no enfocan su
atencin a como se generan las respuestas del sistema, bsicamente el
enfoque de este tipo de prueba se basa en el anlisis 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 mayora de los casos son realizadas
manualmente por el analista de pruebas, tambin 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 automatizacin de pruebas puede resultar compleja y
solo la recomendara en algunas funcionalidades especficas, por ejemplo en
las pantallas que tendrn 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 usara sin embargo el analista de pruebas
debe ir ms 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 bsicamente al negocio, posibles
particularidades que no se hayan contemplado adecuadamente en el diseo
funcional, el analista de pruebas debera dar fuerza a las pruebas funcionales y
ms an a las de robustez, generalmente los usuarios realizan las pruebas con
la idea que todo debera funcionar, a diferencia del analista de pruebas que
tiene ms bien una misin destructiva, su objetivo ser encontrar alguna
posible debilidad y si la llega a ubicar se esforzar por que deje de ser pequea
y posiblemente se convertir en un gran error, cada error encontrado por el
analista de pruebas es un xito, y se debera 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 algn
malestar si el tester sigue encontrando errores, si no se corrige esta situacin
los proyectos en su gran mayora fracasaran o perdern ms tiempo an.

En la empresa en la he laborado algunos aos solo se realizaban pruebas del

tipo funcional, ya que al parecer son los que el usuario mejor comprenda y en
las que poda apoyar, con el pasar de los aos esta situacin a cambiado y en
la actualidad se utilizan tambin pruebas unitarias en la mayora 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 ms evidentes y fciles de
corregir, en la etapa de pruebas funcionales el sistema debera estar bastante
estable y con muy pocos errores crticos. Si un sistema llega a la etapa de
pruebas funcionales con demasiados errores crticos y/o bloqueantes, se
debera 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 resolucin de los errores ya que en esta etapa solo se centra la atencin en
las entradas y salidas, y no en la lgica intermedia, (Black Box Caja Negra).

UNIT TESTING - PRUEBAS UNITARIAS - CAP 1

Al desarrollar un nuevo software o sistema de informacin, la primera etapa de
pruebas a considerar es la etapa de pruebas unitarias o tambin llamada
pruebas de caja blanca (White Box), ests pruebas tambin son llamadas
pruebas modulares ya que nos permiten determinar si un mdulo 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 mdulo.
El principal factor que se debe considerar al inicio de las pruebas es el tamao
del mdulo a probar, se debe considerar si el tamao del mdulo permitir
probar adecuadamente toda su funcionalidad de manera sencilla y rpida.
Tambin es importante separar los mdulos de acuerdo a su funcionalidad, si
los mdulos son muy grandes y contienen muchas funcionalidades, estos se
volvern ms complejos de probar y al encontrar algn error ser ms difcil
ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista
de pruebas podr recomendar que un mdulo muy complejo sea separado en 2
o 3 mdulos ms 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
depuracin y pruebas, as mismo deben conocer el lenguaje de programacin
en el que se est desarrollando la aplicacin, 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, elaboracin 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 culminacin de todos los mdulos del
sistema para iniciar las pruebas, generalmente las pruebas modulares y las
pruebas integrales se solapan; en la actualidad algunas metodologas
consideran oportuno iniciar la etapa de pruebas unitarias poco despus del
desarrollo.
En esta imagen se muestra lo que se considera una representacin clsica de
Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas
el cubo representara 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 tambin sus interfaces o
comunicaciones con los dems componentes (flechas), este tipo de pruebas
tambin 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 interactan en cada caso de prueba.
Se debe conocer de antemano que resultados debe devolver el componente
segn los datos de entrada utilizados en la prueba.
Finalmente se deben comparar los datos obtenidos en la prueba con los datos
esperados, si son idnticos podemos decir que el modulo supero la prueba y
empezamos con la siguiente.
Luego de tener una buena cantidad de mdulos independientes probados y
encontrados Conformes, el siguiente paso es integrarlos, las principales formas
de integracin que existen son:

Integracin Incremental.
Integracin no incremental.
Integracin Incremental
Al realizar una integracin incremental debemos combinar o unir el siguiente
mdulo que se debe probar con el conjunto de mdulos ya probados. El
nmero de mdulos se incrementa progresivamente hasta formar el programa
completo. Esto lo podemos realizar de 2 formas.
Integracin Incremental
Descendente.

Ascendente

la

Integracin

Incremental

Integracin Incremental Ascendente

En este tipo de integracin se combinan los mdulos de ms bajo nivel en
grupos que realizan alguna sub funcin especfica.
A travs de un driver (mdulo impulsor) se simulan llamadas a los mdulos,
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 mdulos de nivel superior en la jerarqua. 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 mdulos que aplicaban lgica
de negocio y hacan cambios en la base de datos, una vez que cada uno de
estos mdulos funcionaba correctamente, iniciamos las pruebas de los mdulos
de nivel superior, que bsicamente hacan llamadas a estos mdulos de ms
bajo nivel, esta segunda etapa fue mucho ms rpida, pues estos ltimos
tenan muy poca lgica, al reemplazar los drivers que creamos por los mdulos
de ms alto nivel encontrbamos pequeos pero muy crticos 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 integracin ascendente, en
este ejemplo cada mdulo debe ser probado por separado, para esto se debe
construir un driver o impulsor para probar cada mdulo.

Fig. 2 Integracin Incremental Ascendente - Fase 1

Tal como se muestra en la figura 3, luego de probar los mdulos de ms bajo

nivel (E, F y G), continuamos con los mdulos del siguiente nivel, para esto
debemos construir nuevos drivers o impulsores (B y C), que se aplicaran
directamente a los mdulos superiores (B y C) y estos a su vez se integrarn a
los de ms 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 ms de integracin
incremental ascendente.

Fig. 3 Integracin Incremental Ascendente - Fase 2

Fig. 4 Integracin Incremental Ascendente - Fase 3

Ventajas de la integracin incremental ascendente:

Las entradas para las pruebas son ms fciles de crear ya que los mdulos
inferiores suelen tener funciones ms especficas.
Es ms fcil la observacin de los resultados de las pruebas puesto que es en
los mdulos inferiores donde se elaboran.
Resuelve primero los errores de los mdulos inferiores que son los que
acostumbran tener el procesamiento ms complejo, para luego nutrir de datos
al resto del sistema.
Desventajas de la integracin incremental ascendente:
Se requieren mdulos 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 mdulo.

Integracin incremental Descendente

Inicia del mdulo de control principal (de mayor nivel) para luego ir
incorporando los mdulos subordinados progresivamente. No hay un
procedimiento considerado ptimo para seleccionar el siguiente mdulo a
incorporar. La nica regla es que el mdulo incorporado tenga todos los
mdulos que lo invocan previamente probados.
En general no hay una secuencia ptima de integracin. Debe estudiarse el
problema concreto y de acuerdo a este, buscar el orden de integracin ms
decuado para la organizacin de las pruebas. No obstante, pueden
considerarse las siguientes pautas:
Si hay secciones crticas como ser un mdulo complicado, se debe proyectar
la secuencia de integracin para incorporarlas lo antes posible.
El orden de integracin debe incorporar cuanto antes los mdulos de entrada
y salida.

Existen principalmente dos mtodos para la incorporacin de mdulos:

1.Primero en profundidad: Primero se mueve verticalmente en la estructura de
mdulos.
2.Primero en anchura: Primero se mueve horizontalmente en la estructura de
mdulos.

Etapas de la integracin descendente:

El mdulo de mayor nivel hace de impulsor y se escriben mdulos ficticios
simulando a los subordinados, que sern llamados por el mdulo de control
superior.
Probar cada vez que se incorpora un mdulo nuevo al conjunto ya engarzado.
Al terminar cada prueba, sustituir un mdulo ficticio subordinado por el real
que reemplazaba, segn el orden elegido.
Escribir los mdulos ficticios subordinados que se necesiten para la prueba del
nuevo mdulo incorporado.
Ventajas de la integracin descendente:
Las fallas que pudieran existir en los mdulos superiores se detectan en una
etapa temprana.
Permite ver la estructura del sistema desde un principio, facilitando la
elaboracin de demostraciones de su funcionamiento.
Concuerda con la necesidad de definir primero las interfaces de los distintos
subsistemas para despus seguir con las funciones especficas de cada uno por
separado.
Desventajas de la integracin descendente:
Requiere mucho trabajo de desarrollo adicional ya que se deben escribir un
gran nmero de mdulos ficticios subordinados que no siempre son fciles de
realizar. Suelen ser ms complicados de lo que aparentan.
Antes de incorporar los mdulos de entrada y salida resulta difcil introducir
los casos de prueba y obtener los resultados.
Los juegos de datos de prueba pueden resultar difciles o imposibles de
generar puesto que generalmente son los mdulos de nivel inferior los que
proporcionan los detalles.

Induce a diferir la terminacin de la prueba de ciertos mdulos.

Integracin No Incremental
La integracin no incremental es bastante sencilla y generalmente se
recomienda para proyectos de poca envergadura, la integracin consiste en
probar cada modulo por separado de manera similar a la intregacin
incremental pero una vez de terminar con los mdulos independientes, se
continua probandolos todos juntos como un todo.
La nica ventaja es que no se necesita ningn tipo de trabajo adicional: ni
planificar el orden de integracin, ni crear mdulos impulsores, ni crear
mdulos ficticios subordinados.
Por otro lado, la lista de desventajas incluye:
No se tiene nocin de la comunicacin de los mdulos hasta el final.
En ningn 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 ms compleja que
con los mtodos incrementales.
Se corre el riesgo de que a poco tiempo de que se cumpla el plazo de entrega,
haya que volver sobre el diseo y la codificacin 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
tcnicos, en mi experiencia como analista de pruebas o tambin 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
definicin funcional y tcnica 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 podrn 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 tcnicos son valiosos en esta labor, pero no son suficientes,
necesitamos tambin tener conocimientos del negocio, en la actualidad los
sistemas ms importantes son realizados para dar solucin 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 aplicacin y a cualquier tipo de plataforma: Web,
C/S o Host, siendo esta ltima a m parecer la ms complicada.
Para conocer como funcionara el sistema y tener una visin general de lo que
este hace para el negocio es necesario asimilar la documentacin funcional y
tcnica previamente definida. Luego de asimilar estos conocimientos ser ms
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.
Prximamente espero publicar un artculo tocando el tema de cmo realizar
buenos casos de prueba.
Una vez concluidos los casos de prueba es ms sencillo poder estimar cuanto
tiempo nos tomara una primera barrida de pruebas y con esto tambin
podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirn probar todas las funcionalidades del
sistema, sin embargo es importante tener buen criterio a la hora de
desarrollarlos.
Las combinaciones de casos de prueba podran ser
prcticamente infinitas, propongo el siguiente ejemplo:
Si pensamos hacer casos funcionales para un sistema
encontraremos con una gran combinacin de variables:

bancario

nos

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde
nos encontraramos con las siguientes variables:
En qu tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos dara al menos 3 variables o casos de prueba.
La cuenta tendr saldo? Saldo = 0, Saldo > 0, Saldo < 0
variables

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

Pertenece a una Persona natural PN o Persona Jurdica PJ?
variables
La cuenta es mancomunada? Si o No

2
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
De que tipo ser el cargo a la cuenta?
variables
1.Transferencia entre cuenta propia
2.Transferencia a un tercero
3.Transferencia interbancaria
4.Retiro en efectivo
5.Pago de un cheque

2 variables
5

En que canal de atencin se realizar esta operacin?

variables

1.En ventanilla
2.Cajero Automtico ATM
3.POS Pago de servicio o consumo
4.Home Bankin

Para este ejemplo tan sencillo podramos obtener fcilmente ms de 3000

casos de prueba y ni siquiera estamos enfocados a los casos que presentarn
en cada pantalla. Como mens, listas, grillas, botones etc. Por este motivo
debemos delimitar claramente cual es la funcionalidad que queremos probar
diseando cada caso de manera que abarque la mayor cantidad de esfuerzo
posible al sistema.
Una vez que empezamos a probar nuestros casos siempre deberamos ir un
poco ms 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
dlares, luego de eso podra 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 mayora de los errores
se encuentran en los valores lmite. Si una pantalla se define para que no
soporte un nmero mayor de 99999999.99 pues entonces probemos con
100000000.00 pues el sistema debera mostrarnos un mensaje indicando que
el monto ingresado esta fuera del rango permitido o algo por el estilo. Es
increble 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 jams debera 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 podran ser los campos de ingreso de
datos, an no entiendo porque tantos programadores no colocan valores lmite
mximos permitidos en los campos de texto, sobre todo en los campos de

prrafos o multilneas, 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
definicin tan simple muchos la olvidan.

Las pruebas que requieran clculos de diversos valores deberan tener pocos
casos pero muy extensos y complejos, alguna vez hice pruebas para un
sistema de bolsa de valores en donde se deberan 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, jams he tenido la experiencia de encontrar un
sistema nuevo sin errores en sus clculos complejos El sistema nunca
funciona bien la primera vez. Ese es mi lema!
Por ltimo una muy buena recomendacin 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 algn otro mensaje horrible.
Espero que con estas pequeas recomendaciones puedan ser capaces de
encontrar una gran cantidad de errores. Prximamente espero mejorar y crear
mejores artculos. No olviden que pueden escribirnos sobre cualquier consulta o
comentario.

SOFTWARE TESTING VS. QUALITY ASSURANCE

Con el paso de los aos 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 artculo ha sido escrito precisamente para tratar de aclarar 2 de los
conceptos ms mencionados al referirse a la calidad del software: Pruebas de
Software (Software Testing) y Aseguramiento de la calidad QA (siglas de las
palabras en ingls Quality Assurance).
Para tener una idea clara de las diferencias y relacin 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 70s pero an utilizado, modelo Cascada, se realizan las pruebas una vez
terminada la construccin del sistema, en el Incremental se realizan las
pruebas en cada incremento del sistema, o por ejemplo, en el Evolutivo
mediante la retroalimentacin de los usuarios, en el espiral durante su
verificacin y validacin del desarrollo, o en los enfoques XP (eXtreme
Programming o Programacin Extrema) con repetidas pruebas de cada una de
las mejoras debido a su desarrollo iterativo e incremental. As podramos ir
mencionando otros modelos no tan conocidos pero que seguramente incluyen
Pruebas tambin 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 elaboracin 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 debern definir estndares y establecer procedimientos
contra los cuales se pueda comparar lo alcanzado durante cada una de las
fases. Por ejemplo; si para el Anlisis de Requisitos dentro de un modelo
cascada, se ha definido un tipo determinado de documento a presentar,
entonces para pasar a la fase de Diseo, el documento de Anlisis deber estar
conforme al documento estndar ya que una fase que no se ejecut de forma
correcta podra causar (y muy probablemente lo haga) defectos en las fases
posteriores. La idea es que mientras ms 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 ms sencillo sealar 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 utilizarn Casos de Pruebas para ser ejecutados; en
cambio QA de software utilizar los estndares y procedimientos establecidos
para cada una de las fases del ciclo de vida del software.
Ambas permitirn 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 artculo slo se ha tocado una
pequea parte de l, pero como se mencion inicialmente, QA y Pruebas de
Software son de los conceptos ms utilizados al hablar de Calidad de Software
as que hay que tenerlos siempre claros para saber cundo utilizarlos!

COMO REALIZAR CASOS DE PRUEBA

Cuando mi colega Alexander (creador de este Site) me pidi realizar un artculo
en base a los Casos de Prueba pens que fcil, si crear casos de prueba es
parte de nuestro da a da, la verdad es que lo difcil 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.
Segn WIKIPEDIA: En la Ingeniera del software, los casos de prueba o Test
Case son un conjunto de condiciones o variables bajo las cules el analista
determinar si el requisito de una aplicacin es parcial o completamente
satisfactorio, clarsimo no?, pero para reforzar la idea y ser an ms 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 aplicacin deba cumplir; fcil!!, bueno, lo sera si
tenemos claro los requerimientos, si el analista de sistemas o llamado tambin
analista funcional realiz un buen levantamiento de la informacin y lo que l
indica como verdad es lo que el usuario pidi, pero ese es otro tema que da
para largo y que podramos ver en otro artculo, la idea aqu es que nosotros
como analistas de pruebas debemos tener claro que debe hacer el aplicativo y
cul ser el alcance de las pruebas, una buena documentacin es bsica, como
quien dice papelito manda.
Pensemos que estamos en una empresa que tiene alguna documentacin 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 algn 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 informacin para que absuelva las dudas que podamos tener, amigo
hgalo! vaya que lo esperolisto?, pues sigamos.
Ok, ya sabemos que debe hacer la aplicacin, aplicativo, sistema o como
quiera llamarlo, ahora hagamos una lista de los requerimientos que debemos
verificar, por
ejemplo si quisiramos hacer casos de prueba sobre la
calculadora de windows deberamos primero leer el manual o el help sobre este
aplicativo para saber que funciones realiza.

Aplicativo: Calculadora de Windows

Requerimientos:
1.Sumar dos o ms nmeros
2.Restar dos nmeros
3.Dividir dos nmeros
Etc
A cada punto de la lista debemos darle cuerpo con informacin 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, ms adelante
entenders 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 dndote una idea ms 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 aplicacin debe cumplir si o
si, y luego en base a estos cre casos de prueba incorrectos, es decir, aquellos
en los cules espero forzar a errores a la aplicacin y esperar una respuesta
adecuada pero incorrecta, por ejemplo si la aplicacin 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 aplicacin? Enviarlo y caerse al no encontrar el destino?, o en
otras palabras colgarse!!, sera muy decepcionante que esto suceda, en este
caso lo que deberamos esperar es que al mandar el mensaje de email, nos
aparezca una alerta, mensaje, etc. Cualquier tipo de comunicacin 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 creacin de casos de prueba debemos aplicar la lgica
del usuario tonto, es decir, nos ponemos en la situacin de un usuario que va

a reventar la aplicacin ingresando emails falsos (para el caso de ejemplo), o

datos con formatos incorrectos o no va a seguir las indicaciones de algn flujo
o proceso secuencial, es decir a cada validacin de un proceso en situacin
ideal habra que probar el mismo proceso con situaciones no ideales y que nos
ayuden a encontrar errores. En conclusin no solo debemos verificar que el
aplicativo haga bien las cosas que debe sino tambin que no haga lo que no
debe.
Cuando tengamos nuestros casos de prueba, ahora debemos alimentarlos,
darles vida, existen casos en los cules necesitaremos data, otros quizs 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
diseo 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 ms que
ejecutar los casos de prueba y verificar los resultados, la parte ms pensada
debe ser la creacin del caso de prueba y la bsqueda de data correcta de ser
el caso, luego de ello la ejecucin y verificacin ser un mero trmite, nuestro
mayor logro esta en encontrar errores o defectos y contribuir en primera lnea
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, quizs
algunos errores no sean tcnicos 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 informacin
que debe tener un caso de prueba, esto es relativo y depende mucho de la
informacin 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 informacin que puede ayudarte:
Id de caso de prueba.
Mdulo a probar
Descripcin del caso
Pre-requisitos
Data necesaria (valores a ingresar)
Pasos o secuencia lgica
Resultado esperado (correcto o incorrecto)
Resultado obtenido

Observaciones o comentarios
Analista de Pruebas (responsable de las pruebas)
Fecha de Ejecucin
Estado (concluido, pendiente, en proces

As por ejemplo usando algunos campos:

Id Caso Modulo a probar Descripcin del

de
caso
prueba

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
- Ingresar datos
OK
graben los datos -Tener Permisos de
de ingreso en la lectura a la BD.
tabla Movimientos.

Pendiente

puedes utilizar los campos y la informacin que mejor se adecue a tus

necesidades, la idea es estar ordenados, organizados y tener una buena
informacin de las pruebas.

PMP Y TESTING - Relaciones Cruzadas?

Es importante tener en cuenta la organizacin a la cual pertenecemos, el nivel
de estandarizacin 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, hacindonos preguntas sencillas,
que nos permitan investigar.
Por tanto, considero que luego del anlisis 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, tambin son denominados QA de aseguramiento de la calidad y
pueden tomar diferentes orgenes:
Ser parte del equipo de desarrollo.
Ser una unidad distinta de la organizacin 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 artculo, nos centraremos en la opcin 2, en la cual
encontramos una unidad interna dedicada a brindar este servicio de QA dentro
de la organizacin a la cual perteneces, que ocurre cuando una organizacin no
es projectizada de manera eficaz. Sencillamente, la metodologa aplicada ser
beneficiada slo por una unidad y estamos convencidos que ello ocurre en las
empresas, al definir la estrategia de utilizar una PMO dentro de su
organizacin, pues se enfoca en logros a nivel estratgico, es decir, las lneas
de QA no reciben el mismo aporte de la metodologa y posiblemente alguna
otra unidad importante para los proyectos tenga el mismo problema.
Hay una metfora muy interesante que lemos en un artculo del PMI Project
Managemente Institute, el cual compartimos; imagnense 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 da a da no nos permiten ver o tener una visin ms amplia.
Por lo tanto, qu deberamos 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-, lderes para difundir la
metodologa.

En conclusin, para el mejor desarrollo de una unidad QA sugerimos lo

siguiente:
En la unidad, debe generar un puesto de trabajo denominado
(Jefe de Proyectos de Aseguramiento de la Calidad)

PM-QA

Los proyectos sern asignados directamente al PM-QA.

El PM-QA adquiere el equipo con la aprobacin de otros jefes.
El PM-QA lleva la direccin de los proyectos asignados con un lder de
proyecto, alinendose con la metodologa del PMO.
Dado que el proyecto es temporal el equipo del PM-QA tambin lo ser, al final
del proyecto los miembros de cada proyecto regresan al mando de sus jefes
iniciales.
Ventajas
Mediante esta asignacin los proyectos sern alineados a una misma
metodologa que usa la oficina PMO.
Formatos, cronogramas, documentacin, seran la misma para todos
los proyectos que sean requeridos a la unidad de QA.
Los recursos podrn adquirir experiencia de diferentes proyectos,
teniendo en cuenta que los proyectos son temporales.
Capacitacin en gestin de proyectos.
Mejor control de los proyectos, dado que los equipos de trabajo se
desarrollan y se crean para un slo 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 lmites de tolerancias entre las personas, quise analizar por
qu estamos fracasando tan enfticamente 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 ms, sin embargo, luego de leer un poco de blogs que frecuento,
encontr una referencia a un artculo muy interesante. El ttulo expresa
simplemente lo siguiente: A mejor Testing, peor calidad de Software?.
Automticamente me llam la atencin esta suerte de contradiccin 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 anlisis de problemas.
Sucede que las metodologas, cualquiera sea, tienen ciertos elementos que si
no sabemos tratar con cuidado, convierten todo un proceso en burdo y
empantanado.

Observ otra pregunta reveladora:

Cmo sabe que su Software no est en un Espiral Muerto?
A este respecto en el artculo se dan ciertas sugerencias como:
Cuenta la cantidad de fallos, errores y defectos
Escucha a los Testers
Observa los tiempos de Integracin
Escucha a los desarrolladores
Presta atencin 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 produccin
Aplica tcnicas de prevencin de fallos
Conoce el esfuerzo de implementacin
Conoce el esfuerzo del Testing
Evala fallos conocidos Los desarrolles pueden continuar con la tasa
de fallos encontrados en su haber?
Los Testers estn encontrando los fallos ms 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?
Evala los Requerimientos Asegrate de que todo el mundo entiende
que estamos construyendo, por que y para que
Convierte los requerimientos implcitos en explcitos
Permite y promueve que los interesados vean el software
peridicamente durante la fase de desarrollo
Escucha cuidadosamente y cuestiona las presunciones

Los defectos ponen a prueba las aplicaciones Define cdigo estndar

Define buenas prcticas de codificacin
Mantenga las revisiones para ver que las codificaciones siguen
los estndares
Toma ventaja de las revisiones de cdigo como una oportunidad
para compartir sugerencias y tcnicas para las pruebas de error
en el entorno de desarrollo
No permita que un problema se transforme en el problema de alguien
ms Mantn una cultura donde la idea viva sea la de la
RESPONSABILIDAD
No dejes de hacer hoy lo que podras delegar en otra persona del
equipo
Si un problema tuyo no se convierte en un problema de alguien
ms, entonces no es un problema
Ten en cuenta que el Software es quien sufrir los resultados
Detecta los fallos en forma temprana Como estn 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 planificacin de los desarrolladores el tiempo
suficiente para realizar algunos tipos de pruebas durante la construccin
de primera mano
Considera en la planificacin de los desarrolladores el tiempo
suficiente y necesario para la correccin de los defectos
detectados durante sus propias pruebas
Presta atencin 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 prevencin 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 ms 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 nmero 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 an a
disconformidad de alguna de las partes, como una Lder 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 organizacin, ms 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 replicarn en los ambientes
productivos y su consiguiente Calidad Percibida.
An 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 an estando ms lejos del
entorno operativo de produccin, son la garanta inicial de que el producto
construido cumplir con los requisitos. Directamente estas garantas iniciales
impactan en los costos de la organizacin.

PAGAR POR DEFECT O ELEVAR LA CONCIENCIA CREATIVA DEL ACTO

VERIFICADOR?
Cmo cres que se debe incentivar a los equipos de calidad? Es posible
incentivar por defecto encontrado o es contraproducente? Imaginemos una
compaa que decide incentivar por objetivos, e incentiva el equipo de
desarrollo por funcionalidad implementada en el menor tiempo. Cmo
incentivamos al Tester? o dicho de otra manera como sabemos quin realiza
mejor labor de verificacin?
Una respuesta de otro amigo:
Pues yo creo que incentivar la localizacin 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 decisin en los casos dudosos (es que no estaba en los requisitos
escritos s, pero es algo obvio y cosas de ese estilo). Ah! Y aado otra
cosa: igual que se incentiva la localizacin de errores en el testeo creo que se
debera desincentivar cuando un Cliente localiza el error una vez lanzada la
versin. Luego se hacen las cuentas de la vieja y se saca balance.
Qu tal un esquema intermedio?
1) Incentivar a los desarrolladores con relacin inversa al nmero de
defectos que les encuentren los Testers.
2)
Incentivar
a
los
Testers
con
relacin
al
nmero
objetos/unidades/loquesea que pasen a produccin validados

de

3) E incentivarlos a todos con la velocidad del proceso completo, y con

relacin inversa a los defectos encontrados en produccin.
Me resulta un poco extraa la cuestin 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 especfico 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, tambin sus
controles y gestiones.
Si se considera la existencia de Testers en un equipo de produccin de
software, no debe ser sin la existencia de un responsable QA y la carga de
gestin 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 dems elementos que existen para sumir al equipo de

calidad en un estndar que desde el llano y como punto de partida sea muy
alto.

Podra agregar que es bueno tener mtricas de cantidades de defectos

detectados por Tester pero no podramos 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 servira para que en caso de necesitar dividir
el equipo de Testing, al mejor Tester se le asignara 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 podran desintegrarse por generarse ciertas
incomodidades. No quiero ni hablar de cmo impactara 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 inversin.
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 mximo su conciencia de
responsabilidad.
Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas
inician el Testing. No es mrito del Tester sino de la incompetencia de alguien
en fases anteriores. No sealo a nadie, pero desde el Tester para atrs, hay
muchas responsabilidades intrnsecas.
Es cierto tambin que al principio el Tester se hara de una muy buena suma de
dinero extra por la cantidad de deteccin 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 mtricas, estn all.
Cierta oportunidad siendo Lder de Testing al finalizar uno de los proyectos
postulados para certificacin CMMI-4, mi equipo detect grandes cantidades de
fallos en los productos solo en los primeros ciclos, cuando haba planificados 12
ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los
ciclos subsiguientes, nuestra tasa de deteccin cay significativamente para el
resto de los ciclos (considerar PARETO).
Esto me llevo a analizar la situacin, 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 habamos 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 capacitacin

necesaria y sostener un ambiente colaborativo y ameno, son los mejores
incentivos.