Plan de pruebas de software

43,254 views
43,467 views

Published on

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
43,254
On SlideShare
0
From Embeds
0
Number of Embeds
1,142
Actions
Shares
0
Downloads
848
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Plan de pruebas de software

  1. 1. PLAN DE PRUEBAS DE SOFTWAREEl Plan de PruebasEl propósito del plan de pruebas es explicitar el alcance, enfoque, recursosrequeridos, calendario, responsables y manejo de riesgos de un proceso depruebas.Note que puede haber un plan global que explicite el énfasis a realizar sobre losdistintos tipos de pruebas (verificación, integración e integración).Un plan de pruebas incluye:1. Identificador del plan.Preferiblemente de alguna forma mnemónica que permita relacionarlo con sualcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1(plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan deverificación del contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la claseDespachador). Como todo artefacto del desarrollo, está sujeto a control deconfiguración, por lo que debe distinguirse adicionalmente la versión y fecha delplan.2. AlcanceIndica el tipo de prueba y las propiedades/elementos del software a ser probado.3. Items a probarIndica la configuración a probar y las condiciones mínimas que debe cumplir paracomenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar unaconfiguración que aún reporta fallas; por otro lado, si esperamos a que todos losmódulos estén perfectos, puede que detectemos fallas graves demasiado tarde.4. EstrategiaDescribe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casosde prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, estasección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de laprecondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible laestrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej.100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia tambiénexplicita el grado de automatización que se exigirá, tanto para la generación decasos de prueba como para su ejecución.5. Categorización de la configuraciónExplicita las condiciones bajo las cuales, el plan debe ser:Suspendido,Repetido;Culminado.En algunas circunstancias (las cuales deben ser explicitadas) el proceso de pruebadebe suspenderse en vista de los defectos o fallas que se han detectado. Al
  2. 2. corregirse los defectos, el proceso de prueba previsto por el plan puede continuar,pero debe explicitarse a partir de qué punto, ya que puede ser necesario repetiralgunas pruebas. Los criterios de culminación pueden ser tan simples como aprobarel número mínimo de casos de prueba diseñados o tan complejo como tomar encuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebasy la tasa de detección de fallas.6. TangiblesExplicita los documentos a entregarse al culminar el proceso previsto por el plan p.ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial delproceso y bitácora de pruebas.7. Procedimientos especialesIdentifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, asícomo cualquier habilidad especial que se requiere.8. RecursosEspecifica las propiedades necesarias y deseables del ambiente de prueba,incluyendo las características del hardware, el software de sistemas (p. ej. elsistema de operación), cualquier otro software necesario para llevar a cabo laspruebas, así como la colocación específica del software a probar (p. ej. qué módulosse colocan en qué máquinas de una red local) y la configuración del software deapoyo.La sección incluye un estimado de los recursos humanos necesarios para elproceso. También se indican cualquier requerimiento especial del proceso:actualización de licencias, espacio de oficina, tiempo en la máquina de producción,seguridad.9. CalendarioEsta sección describe los hitos del proceso de prueba y el grafo de dependencia enel tiempo de las tareas a realizar.10. Manejo de riesgosExplicita los riesgos del plan, las acciones mitigantes y de contigencia.11. ResponsablesEspecifica quién es el responsable de cada una de las tareas previstas en el plan.
  3. 3. INTRODUCCION AL SOFTWARE TESTINGEl Software testing o como se conoce en español las pruebas de software se aplican como una etapa másdel proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con lasespecificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio lamayoría de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en laactualidad el software testing se ha convertido en una de las etapas más críticas del ciclo de vida deldesarrollo 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 grancantidad 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ásfundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente secuentan 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, laadministració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 estaetapa lo recomendable es que el software se mantenga en un ambiente aislado o separado del ambientede desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a losambientes que existen en producción para asegurar su correcto funcionamiento en esa futura etapa, sedebe considerar adquirir un equipo de pruebas especializado “software tester” o analista de pruebas, conexperiencia, estas personas tienen una formación que les permite detectar una gran cantidad de erroresen tiempos mínimos, así como una metodología especifica que les permite hacer el trabajo de maneracorrecta, algunas empresas más informales utilizan a los futuros usuarios del sistema como testerssituación que puede traer una serie de problemas debido a la poca experiencia que pueden tener losusuarios en la detección de errores, además se obvian pruebas importantes como las pruebas deEsfuerzo o “Stress testing”, también se dejan de lado las pruebas unitarias o pruebas modulares, las quedeberían asegurar que cada modulo del sistema trabaje correctamente de manera independiente, otroerror muy conocido en empresas de software es el uso de los mismos desarrolladores como analistas depruebas, es muy difícil probar con objetividad un software si nosotros mismos lo hemos desarrollado, untécnico o analista programador empezara a probar con la idea preconcebida de que su hijito trabaja a laperfección e inconcientemente evitara realizar pruebas mas exhaustivas considerando que las mismaspodrían ser absurdas o innecesarias, lo bueno es que poco a poco estas ideas van quedandodescartadas y se van alineando conceptos hacia un software testing profesional.Ing. Alexander Oré B.FUNCTIONAL TESTING - PRUEBAS FUNCIONALESSe denominan pruebas funcionales o Functional Testing, a las pruebas de software que tienen porobjetivo probar que los sistemas desarrollados, cumplan con las funciones específicas para los cuales hansido creados, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyode algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobreesta 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, yaque los testers o analistas de pruebas, no enfocan su atención a como se generan las respuestas delsistema, básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada yen los de salida, esto generalmente se define en los casos de prueba preparados antes del inicio de laspruebas.
  4. 4. Las pruebas funcionales en la mayoría de los casos son realizadas manualmente por el analista depruebas, también es posible automatizar este tipo de pruebas utilizando herramientas como WinRunner oSilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo aprobar. La automatización de pruebas puede resultar compleja y solo la recomendaría en algunasfuncionalidades específicas, por ejemplo en las pantallas que tendrán mayor uso, generalmente pantallasde 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 sistemacomo é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 eldesarrollo de casos de prueba complejos, enfocados básicamente al negocio, posibles particularidadesque no se hayan contemplado adecuadamente en el diseño funcional, el analista de pruebas debería darfuerza a las pruebas funcionales y más aún a las de robustez, generalmente los usuarios realizan laspruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bienuna misión destructiva, su objetivo será encontrar alguna posible debilidad y si la llega a ubicar seesforzará por que deje de ser pequeña y posiblemente se convertirá en un gran error, cada errorencontrado por el analista de pruebas es un éxito, y se debería considerar como tal, en mi experienciapersonal he podido ver que proyectos atrasados, o con algunos problemas de tiempo sacrifican horas depruebas, incluso se siente algún malestar si el tester sigue encontrando errores, si no se corrige estasituació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 alparecer son los que el usuario mejor comprendía y en las que podía apoyar, con el pasar de los años estasituación a cambiado y en la actualidad se utilizan también pruebas unitarias en la mayoría de losaplicativos desarrollados, siendo las pruebas unitarias una primera etapa y las pruebas funcionales lasegunda 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, estecomportamiento es obvio, ya que las pruebas unitarias nos permiten encontrar los errores más evidentesy fáciles de corregir, en la etapa de pruebas funcionales el sistema debería estar bastante estable y conmuy pocos errores críticos. Si un sistema llega a la etapa de pruebas funcionales con demasiados errorescríticos y/o bloqueantes, se debería devolver el sistema a la etapa de pruebas unitarias ya que resultamuy poco productivo realizar pruebas funcionales con sistemas inestables, el avance es demasiado lentoy el analista de pruebas no podrá apoyar mucho en la resolución de los errores ya que en esta etapa solose centra la atención en las entradas y salidas, y no en la lógica intermedia, (Black Box – Caja Negra).Ing. Alexander Oré B.UNIT TESTING - PRUEBAS UNITARIAS - CAP 1Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es laetapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas tambiénson llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa esta listo ycorrectamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza elprogramador mientras esta 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, sedebe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad demanera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, silos módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos deprobar y al encontrar algún error será más difícil ubicar la funcionalidad defectuosa y corregirla. Al haceresta labor el analista de pruebas podrá recomendar que un modulo muy complejo sea separado en 2 o 3módulos más sencillos.
  5. 5. Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estarfamiliarizado en el uso de herramientas de depuración y pruebas, así mismo deben conocer el lenguajede programación en el que se esta desarrollando la aplicación, en la actualidad existen una gran cantidadde herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientaspara cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboración decasos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebasunitarias son: JUnit, La Suite de Mercury, CPPUnit etc.El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfases,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 algunasmetodologí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 WhiteBox o pruebas de caja blanca, en este tipo de pruebas el cubo representaría un sistema en donde sepueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentesdebe ser probado en su totalidad (óvalos), y también sus interfases o comunicaciones con los demáscomponentes (flechas), este tipo de pruebas también son llamadas pruebas de caja de cristal ya que esteútlimo termino representa mejor el tipo de pruebas.¿COMO REALIZAR PRUEBAS FUNCIONALES?Las pruebas funcionales - Functional Software Testing y las pruebas unitarias Unit Software Testingdeben ser consideradas como temas cien por ciento técnicos, en mi experiencia como analista depruebas o también llamado tester, he llegado a probar una buena cantidad de sistemas en variasempresas, enfocadas principalmente al sector financiero.Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnicadecente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidadel analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes,
  6. 6. una vez aprobados estos documentos podrán servir de base para que el analista de pruebas puedapreparar 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, cadaerror que yo pudiera encontrar significa un éxito para la calidad del sistema. Evidentemente el analista depruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientostécnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos delnegocio, en la actualidad los sistemas más importantes son realizados para dar solución a los problemasde negocios. El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario queutilizará el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento de diversosnegocios 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 negocioes necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estosconocimientos 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 deprueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y elresultado esperado. Próximamente espero publicar un artículo tocando el tema de cómo realizar buenoscasos de prueba.Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara unaprimera 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 esimportante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podríanser prácticamente infinitas, propongo el siguiente ejemplo:Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una grancombinación de variables:Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos conlas siguientes variables:¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A PlazosEsto nos daría al menos 3 variables o casos de prueba.¿La cuanta tendrá saldo? Saldo = 0, Saldo > 0, Saldo < 03 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 No2 variables¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3estados).3 variables¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?Si o No2 variables¿De que tipo será el cargo a la cuenta? 1. Transferencia entre cuenta propia
  7. 7. 2. Transferencia a un tercero 3. Transferencia interbancaria 4. Retiro en efectivo 5. Pago de un cheque5 variables¿En que canal de atención se realizará esta operación? 1. En ventanilla 2. Cajero Automático – ATM 3. POS – Pago de servicio o consumo 4. Home Bankin4 variablesPara este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquieraestamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botonesetc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probardiseñ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 delos errores que he podido encontrar no estaban escritos en mis casos de prueba. Si en mi caso definohacer un cargo de 1000 dólares, luego de eso podría hacer una prueba con un cargo de 1000.01 y otro de9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Esinteresante notar que la gran mayoría de los errores se encuentran en los valores límite. Si una pantallase define para que no soporte un número mayor de 99999999.99 pues entonces probemos con100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado estafuera del rango permitido o algo por el estilo. Es increíble como algunos programadores creen que no sedeben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrarioun buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a unsistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que nohaga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con elsistema, un analista tester jamás debería estar bajo las ordenes de un programador y tampoco esrecomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo apensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en larobustez 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 entiendoporque 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 deun texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan loshuesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en unsistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser unadefinición tan simple muchos la olvidan.Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos ycomplejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calculardiversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificarque valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que sepresenten sean correctos, tanto en las pantallas como en los reportes, jamás he tenido la experiencia deencontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien laprimera vez”. ¡Ese es mi lema!Por último una muy buena recomendación de pruebas es el manejo del valor cero 0 muchas veces por lacomplejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otrovalor y entonces: “Error Exception Faillure #afg99d7 - no valido” o algún otro mensaje horrible.
  8. 8. Espero que con estas pequeñas recomendaciones puedan ser capaces de encontrar una gran cantidadde errores. Próximamente espero mejorar y crear mejores artículos. No olviden que pueden escribirnossobre cualquier consulta o comentario.Ing. Alexander Oré B.

×