Automatizacion de pruebas.docx

1. Elaboración y seguimiento de pruebas

Para llevar un adecuado seguimiento de las pruebas, se elaboran artefactos. Las pruebas que se realizan no son al azar, conllevan un orden y un proceso en el marco de un estándar. No obstante, debido al afán de automatizar las pruebas y encontrar la mejor forma de elaborarlas, se hicieron modelos para automatizarlas, lo cual lleva a cabo el personal de pruebas –no por el hecho de que éstas sean automatizadas, deja de intervenir el hombre–.

El desarrollador no pone la atención debida a la realización de pruebas porque, normalmente los clientes no comprenden las pruebas, lo que muchas veces origina la tentación de no escribir código para probar, dejándolo como opcional, puesto que el cliente no paga por el código de prueba, y el hacerlo es un trabajo laborioso, de ahí la necesidad de automatizar las pruebas, así sería fácil mantenerlas y vincularlas al desarrollo de software.

La preparación de pruebas es una actividad creativa, por lo que quien la realiza debe tener una gran capacidad de análisis.

La elaboración de las pruebas, puede ser dirigida cuando no se tiene experiencia por modelos de automatización creados por compañías reconocidas en el ramo de software, o estándares propios de una empresa, institución u organización. Por lo cual, te damos algunos elementos que debes considerar para elaborar las pruebas automatizadas con éxito.

Para llevar a cabo la automatización de pruebas en el proceso de desarrollo del software, las pruebas funcionales deben ser precisadas a partir de la especificación de requerimientos del cliente, deben tener casos de prueba unitarias y de integración cubriendo todo el código del software en desarrollo y llevar a cabo el proceso de pruebas en cada etapa del modelo de desarrollo de software seleccionado de manera continua como práctica de integración.

Los tests unitarios deben incluir las instancias de clases en diferentes escenarios y tener condiciones de pruebas diseñadas y resultados verificados.

Los criterios para un buen diseño facilitan las pruebas de los distintos componentes a partir de su desacoplamiento. Por ello, una buena práctica es:

Realizar el diseño del sistema ocupando una arquitectura en capas, la cual consiste en separar el sistema en cualquier cantidad de éstas (de 2 hasta “n” capas). La más utilizada es la arquitectura de tres capas.

Además de realizar esta separación, el desarrollador debe:

Elaborar una interfaz para el intercambio de información entre capas.

Hacer una inversión en la cadena de dependencia.

Colocar un código cerrado ante cambios.

Segregar las interfaces y las dependencias no cíclicas.

Así mismo, es importante organizar los casos de prueba realizando agrupaciones según métodos de las clases o de acuerdo con las condiciones de ejecución.

Te invitamos a ver, en el siguiente ejemplo, las consideraciones para automatizar las pruebas.

Para automatizar las pruebas se deberá tener en cuenta lo siguiente:

Qué clase de prueba se va a automatizar

Cuáles herramientas se usarán para la automatización

Cómo se administrarán las condiciones de prueba

Cómo asegurar que el sistema será probado eficientemente

Las clases de pruebas a automatizar normalmente son las de funcionalidad –le interesan al cliente–, que posteriormente pasan a ser pruebas de aceptación, teniendo como resultado los requerimientos ejecutables. Otras pruebas corresponden al diseño del sistema –la arquitectura interna a la cual se le tendrían que realizar pruebas en los componentes– y al código, es decir, el desarrollo.

Una herramienta que se utilizará para automatizar los componentes y el código será Junit –la veremos en la Unidad III de Introducción a la Ingeniería de Pruebas–Ésta nos garantiza que nuestras pruebas serán robustas y costeables. Las pruebas se pueden pre-construir, además Junit es simple y barato.

Para administrar las pruebas se debe conducir el seguimiento de la ejecución de los test cases, para lo cual podemos recurrir a alguna de las herramientas comerciales o valernos de una matriz de Excel, donde iremos anotado nuestro “paso” o “fallo” (“sí” o “no”).

Por último, para asegurar que el sistema haya sido probado, debemos identificar los escenarios funcionales. Una vez que identifiquemos los escenarios de prueba tendremos que generar scripts o guiones de prueba que los cubran, y elaborar test cases (abordaremos estos conceptos en la Unidad II).

1.1 Proceso de pruebas automatizadas

El proceso contiene muchas variantes. No hay una uniformidad en cuanto a herramientas o software para automatizar las pruebas, sin embargo hay similitudes en cuanto a actividades que debe tener el proceso de automatización. Recuerda que éste puede orientarte en lo que vas a realizar. No hay un estándar a aplicar, por ello se verán aspectos generales.

La manera en que se desarrolla el software es uno de los elementos que intervienen a la hora de automatizar las pruebas, debido a que se prueba mientras se crea.

En este sentido, la programación es una actividad personalizada, por lo que no hay un proceso estándar a seguir. Algunos programadores comienzan de lo general a lo particular y otros de lo específico a lo general.

El programador puede optar por elaborar los programas por nivel o sobre una línea:

Para elaborar un programa con base en un diseño nos apoyamos en una herramienta CASE, la cual nos ayuda a crear el esqueleto del programa y la interfaz.

El programador sólo puede agregar detalles de la operación de cada componente del programa. Las herramientas para construir prototipos son lenguajes de alto nivel –generadores de interfaz de usuario– que pueden servirnos para diseñar casos de pruebas automatizadas. Hay programadores que se basan en los datos del proceso para comenzar a elaborar el sistema en lugar del diseño, en cuyo caso irá realizando la automatización de pruebas con base en esos datos.

Las herramientas para las pruebas son generadoras de datos de las mismas; son comparadores de archivos.

Ahora veamos los aspectos generales de las herramientas que nos sirven de apoyo para crear la automatización de pruebas.

La clasificación de las herramientas CASE es

Un banco de trabajo para pruebas debe contener diversas herramientas:

Los bancos de trabajo de prueba tienen que adaptarse para satisfacer el plan de prueba (lo veremos en la Unidad II de esta unidad de aprendizaje) de cada sistema.

Es decir, que tenemos herramientas que nos apoyan, al tener varias herramientas conjuntadas se forma el banco de trabajo, y varios bancos de trabajo conforman el entorno.

Te mostramos un esquema que hace referencia a lo que acabas de leer.

En la práctica, no es fácil distinguir la clasificación ya que se venden por separado, pero debemos resaltar que hay una gran cantidad de herramientas para pruebas, las cuales pueden ayudarnos a encontrar errores y defectos exitosa y económicamente.

Dado que el estilo de programar influye en la automatización de las pruebas, también el modelo de desarrollo del software lo hace.

Los sistemas no son simples unidades; normalmente están compuestos por subsistemas constituidos por módulos que contienen procedimientos y funciones.

De esta forma las pruebas automatizadas que se pueden realizar están de acuerdo con cada etapa de desarrollo, esto es, las pruebas se llevan en paralelo con el desarrollo del software.

Los modelos para elaborar el proceso de las pruebas se ven en la unidad de aprendizaje Introducción a la Ingeniería de Pruebas, aquí nos enfocaremos en el proceso de pruebas de cinco etapas.

1.2 Etapas del proceso de pruebas automatizadas

Para que entiendas mejor las etapas de este proceso, a continuación observa el siguiente video clip. Las etapas están jerarquizadas; inician con la prueba de unidades y terminan con la prueba de aceptación (en cada una se realiza la prueba correspondiente).

Proceso de pruebas

Este proceso comprueba los componentes del sistema, la integración del sistema y el sistema en sí. Gracias a éste se descubren errores en la interfaz y, en general, en las etapas iniciales del desarrollo del sistema. Existe una dependencia cíclica de una etapa con otra, dado que las pruebas con los módulos una vez pasados se integran en subsistemas que arrojan defectos o errores en los módulos al interactuar unos con otros, por lo cual hay que repetir las pruebas de módulos y las pruebas de integración con la retroalimentación obtenida.

1.3 Normas para el proceso de pruebas

Para llevar a cabo el proceso de pruebas es necesario tener una serie de lineamientos o normas, mismas que a continuación se mencionan.

Normas para el proceso de pruebas

Debes probar lo antes posible, es decir, probar mientras diseñas y desarrollas.

En las pruebas debes tener puntos de control y de observación.

Escribe primero el test, esto es, diseña y documenta la prueba.

Diseña para que haya testeabilidad, utilizando la arquitectura a capas anteriormente vista.

Utiliza las interfaces públicas siempre que sea posible.

Notifica el intento, para facilitar la lectura y el mantenimiento (puedes realizarlo con un reporte de incidencias).

No cambies el Sistema bajo prueba, así garantizarás que pruebas lo desarrollado y lo que irá al ambiente productivo. Este cambio debe elaborarse de acuerdo con las políticas de la empresa utilizando los canales adecuados para llevarlo a cabo y bajo el estándar o proceso establecido por la misma.

Independiza los casos de pruebas, separándolos para facilitar el aislamiento de los errores.

Es importante que apartes el Sistema bajo prueba en una ubicación específica para no depender del ambiente.

Reduce el solapamiento de pruebas para facilitar el mantenimiento de éstas. Procura diseñar un test que no tenga relación alguna con otro.

Reduce el código que no se ha probado para impedir errores en las pruebas funcionales y en el ambiente productivo; puedes utilizar los resguardos (simulación de la respuesta y entrada de un módulo de algún sistema)

Existen lineamientos originados por los requerimientos del sistema que se pueden emplear al llevar a cabo el proceso de pruebas, como probar el software con valores únicos o usar valores de distintos tamaños en diversas pruebas (cuando se usan límites se debe crear una prueba para acceder al valor inicial, intermedio y ultimo del rango).

Para las interfaces los lineamientos generales son

Diseña pruebas donde los valores de los parámetros a utilizar sean los extremos finales de los rangos. Si los parámetros son apuntadores, prueba con nulos.

Si un componente es llamado por una interfaz de procedimiento, haz la prueba para provocar la caída del componente.

Cuando se pasan cadenas de caracteres, genera pruebas que originen mensajes de manera que se sobrepasen los normales reales. Si hay componentes que compartan memoria, diseña pruebas para activar, en orden variado, estos componentes.

Para las pruebas de las características operacionales del sistema

Diseña pruebas para comprobar las funciones del sistema a las que se acceda por menús y combinaciones de funciones. Cuando el usuario introduce datos, las funciones deben probarse para datos de entrada correctos e incorrectos.

A grandes rasgos, al automatizar las pruebas debemos conocer los lineamientos y las normas, además de no olvidar las consideraciones previamente vista en este tema para que se pueda diseñar un buen caso de pruebas e implementarlas de acuerdo con el proceso guiado por las etapas de pruebas automatizadas.

2. Modelos de automatización

 En el mercado existe una gran variedad de herramientas para automatizar las pruebas, sin embargo lo primero que debes hacer es identificar qué se requiere automatizar y cómo se desea hacerlo; en función de estas consideraciones podrás elegir una herramienta pertinente.

Las características que a continuación proporcionamos son para ayudarte a que elijas una herramienta acorde con las necesidades de aplicación.

Entorno de aplicación de la herramienta hardware y software.

Plataforma donde debe ejecutarse la herramienta.

Soporte comercial.

Coste. Factores políticos (obligatoriedad de comprar a determinados fabricantes, etc.).

Calidad de la herramienta (documentación, complejidad, frecuencia de fallos, riesgo de que la herramienta provoque fallas en otras partes del entorno, etcétera).

Modelo de automatización de pruebas

Utilizar herramientas de prueba, puede hacer la prueba más sencilla, efectiva y productiva.

2.1 Modelos tradicionales de automatización

Para automatizar las pruebas debemos diseñarlas, después codificarlas y obtener los resultados que se evaluarán.

El diseño del caso de pruebas se puede establecer con base en los modelos que existen para modelar el sistema (modelos UML).

Uno de los modelos tradicionales de automatización es conocido por la ingeniería de software como el modelo en cascada.

Modelo en cascada

Otro modelo común es el modelo en V: en cada figura se establece la etapa de desarrollo del software y su prueba correspondiente.

En esta figura podemos apreciar que en el diseño se aplican pruebas de validación (cuando codificamos usamos pruebas de unidad, cuando estamos integrando el proyecto utilizamos pruebas de integración. En la siguiente etapa, cuando ya tenemos conformado todo el sistema, aplicamos pruebas de validación y pruebas de sistema).

Modelo en “V”

En el modelo en “V”, tenemos que en la etapa de requerimientos podemos utilizar pruebas de aceptación. Cuando tenemos todos los requerimientos funcionales, podemos aplicar pruebas de sistema. En la etapa de diseño empleamos pruebas de integración y, sobre el código, pruebas de unidad. En este modelo se muestra que antes de ejecutar la prueba es necesario escribirla.

Se sugiere que al menos el 75% de las pruebas sean automatizadas y el resto se elabore manualmente. Lo que se debe automatizar son las pruebas unitarias de sistema y de funcionalidad. No debe automatizarse las tareas únicas de fácil ejecución manual y difícil de automatizar.

Aunque ya tengamos la arquitectura del sistema y el modelo de desarrollo del software, tendremos que crear los casos de prueba para ejecutarlos en las etapas correspondientes. Elaboraremos el diseño del caso de prueba a partir de un diagrama de clases, dado que al tener una clase podemos realizar diferentes pruebas con distintos casos de prueba derivados de una iteración o instancia de la clase, lo cual nos sirve para llevar a cabo las pruebas de unidad, en donde una iteración es un caso de prueba que se puede aplicar.

Para determinar los casos de prueba a aplicar a partir de los diagramas de clases, se propone utilizar lo siguiente:

"AEM (Association-end multiplicity). Dado un conjunto de pruebas T y un modelo SM, T debe causar que se cree cada par de multiplicidades representativo en las asociaciones de SM. Así, si existe una asociación cuya multiplicidad es, en un extremo, p. n, debería instanciarse la asociación con p elementos (valor mínimo), n elementos (valor máximo) y con uno o más valores en el intervalo (p+1, n-1).

GN (Generalization). Dado un conjunto de pruebas T y un modelo SM, T debe conseguir que se cree cada relación de generalización de SM. CA (Class attribute): dado un conjunto de pruebas T, un modelo SM y una clase C, T debe conseguir que se creen conjuntos de valores representativos de los diferentes atributos de la clase C. El conjunto de valores representativos se consigue en tres pasos:

1. Crear valores representativos para cada atributo, para lo cual pueden usarse clases de equivalencia.

2. Calcular el producto cartesiano de estos valores.3. Eliminar los conjuntos de valores inválidos considerando el dominio

del problema; posibles restricciones que anoten el diagrama."

Por ejemplo: Se tiene un inicio de sesión, el cual tiene el siguiente diagrama de clases:

A partir del diagrama de clases podemos elaborar casos de prueba para este inicio de sesión.

Se realizaron los casos de pruebas de los posibles valores que se pueden introducir en cada campo, y de los mensajes que aparecerán según el caso, hasta que se introdujo el valor correcto de acuerdo con la interfaz de usuario creada que se muestra en la imagen de pantalla, esto se puede llevar a cabo realizando precondiciones y obteniendo pos condiciones para un escenario propuesto el cual, de acuerdo con nuestra experiencia, puede ser el más usual.

De acuerdo con lo que se describa en el apartado de la determinación de casos de prueba para clases CA (Class attribute), los escenarios serían

Expresado de otra manera, el diseño de casos de prueba es

La interfaz del usuario para los campos descritos es:

Imagen del inicio de sesión

De esta forma, las actividades que se deben llevar a cabo para realizar las pruebas automatizadas son las siguientes:

Determinar qué vamos a automatizar.

Seleccionar la herramienta para automatizar la prueba.

Diseñar el caso de prueba .

Elaborar el caso de prueba que se diseñó.

Ejecutar el caso de prueba.

Evaluar los resultados.

Para completar las actividades se debe tener en cuenta lo siguiente:

Diseñar la arquitectura del entorno de pruebas considerando la estructura de los directorios, los documentos asociados con los casos de prueba y los resultados de las ejecuciones de prueba.

Generar scripts o guiones de prueba buscando que sea mantenible y flexible.

La mantenibilidad de pruebas. Los casos de prueba no deben ser repetidos ni viejos.

A continuación te proporcionamos algunos modelos comerciales más, los cuales probablemente llegues a encontrar en el campo laboral.

Uno de los modelos  para pruebas automatizadas es el que describimos a continuación (es empleado en una empresa de prestigio):

Este modelo de automatización es para sistemas que utilizan una interfaz gráfica.

Existe un modelo más para automatizar las pruebas. En él hay que definir detalladamente, como primer nivel, el objetivo de la prueba, el grupo de pruebas y la prueba en sí. Después debemos elaborar un mapa de aplicación; finalmente, ejecutar y mantener las pruebas.

Este modelo tiene como base los requerimientos del sistema, a partir de los cuales se realiza el primer nivel.

Como puedes observar, existen varios modelos. Para seleccionar alguno sólo debemos determinar cuál se adecua a las necesidades del proyecto, aunque también dependerá de los recursos disponibles en el momento de llevar a cabo las pruebas.

Para este curso proponemos llevar a cabo la automatización ocupando el modelo de desarrollo en cascada. Por otro lado, proponemos incorporar las actividades para la automatización de pruebas diseñando los casos de prueba con base en los diagramas de UML.

Contar con herramientas que nos permitan elaborar las pruebas automáticas a través de un software presenta ciertas ventajas.

2.2 Ventajas de la automatización de software

Tener automatizadas las tareas, pruebas, software o cualquier otro artefacto, implica optimizar tiempo y esfuerzo. Comprar las herramientas para ello es una inversión. Veamos las ventajas de la automatización.

Las herramientas de prueba son un instrumento importante en su artefacto de almacenamiento de desarrollo. Utilizarlas aumenta la productividad, ya que permite a grupos pequeños realizar las pruebas y hacer mucho más trabajo.

Las pruebas de ejecución automática, una vez construidas, pueden ser ejecutadas continuamente; son repetibles y se obtienen los mismos resultados en múltiples ejecuciones sin intervención manual; también son independientes (es posible ejecutarlas aisladamente). Las pruebas repetitivas generan seguridad.

Las pruebas, cuando han sido automatizadas, son fáciles de construir y ejecutar por los desarrolladores, lo cual permite utilizar el mismo lenguaje de desarrollo.

Es posible verificar los resultados y generar los informes correspondientes a las pruebas realizadas.

Es posible manejar los casos de prueba como si fueran objetos.

Se mejora la calidad pues se reducen los riesgos; se valida el sistema. Por otro lado, los prototipos de interfaz ayudan a entender el comportamiento del ambiente operacional, se eliminan requerimientos ambiguos o contradictorios, se previenen errores y se localizan defectos.

Las pruebas son fáciles de ejecutar, de escribir y mantener. Dado que la edición, la compilación, el linkeo y la ejecución son automáticos, si falla la plataforma da un aviso. Se centran en la prueba y no en el código. Se facilita su lectura por ser simples, se prueba una condición a la vez, se puede separar funcionalidad, código final, y aspectos de prueba.

Las pruebas, con un mantenimiento mínimo, seguirán siendo útiles ante la evolución del sistema. A través de las instrucciones de JUNIt: Setup + Teardown se robustecen las pruebas.

Se mejora la documentación.

Se mantiene el último release funcionando y actualizado (testeo continuo = UnitTest + Ctrol. Versión).

Se evita elaborar pruebas obsoletas.

Se disminuye el tiempo de salida al mercado. Se puede elaborar más pruebas en menos tiempo y con menos recursos.

Los modelos de automatización tienen herramientas incorporadas para cada actividad que se lleva a cabo para generar las pruebas automatizadas de unidad, sistema e integración que puedes utilizar de acuerdo a los casos de prueba que debas generar, tomando en cuenta que hay características especificas que se deben de incluir para la toma de decisiones a la hora de comprar o desarrollar una plataforma o software de pruebas, sin embargo, no todo está establecido, ni todo se debe de tener por hecho, tampoco podemos decir que un modelo o una herramienta es mejor que otra, todo va de acuerdo con las necesidades que se tengan.

3. Personal de pruebas

En Introducción a la Ingeniería de Pruebas se estableció una propuesta de roles y responsabilidades para el personal que va a realizar las pruebas. Aquí veremos otra propuesta para el personal de pruebas automatizadas y puntualizaremos ciertos aspectos; aunque las responsabilidades son similares, los nombres de los roles cambian.

3.1 Roles, funciones y responsabilidad

La propuesta de roles es menor para el personal involucrado en un desarrollo de software automatizado orientado a objetos, debido a que en su elaboración se tiende a utilizar abstracciones y mecanismos comunes realizados durante el diseño o versiones anteriores. En las pruebas, al incorporar una nueva funcionalidad, se modifica la estructura que se comporta correctamente antes del cambio, lo cual obliga a diseñar un caso de prueba para el cambio y aplicar pruebas de regresión que ocuparán mucho menos recursos que si se aplicara toda una suite de casos de prueba nueva para la estructura modificada.

Para los proyectos orientados a objetos, se tienen los siguientes roles:

Así pues, el equipo de trabajo queda conformado por una tercera parte o la mitad de jefes del subsistema; y la mitad, o más, por el programador de aplicación y el arquitecto del proyecto.

Sugerimos que el arquitecto del proyecto sea elegido del personal interno, pues se involucrará más en el proyecto y podrá aumentar las posibilidades de éxito.

Para proyectos grandes hay distintos roles (ver documento fuente: roles_Booch.doc), sin embargo no todos los proyectos demandan todos esos papeles. En proyectos pequeños muchas responsabilidades deben ser elaboradas por la misma persona.

“Los mejores resultados se dan con menos y mejores personas” Boehm.

Las pruebas son actividades continuas; el personal mínimo para ello es el siguiente:

Es importante subrayar que no se puede eludir la responsabilidad que tiene cada rol, por el hecho de que se apliquen herramientas sofisticadas o recientes en el proyecto.

En muchos proyectos las herramientas se restringen debido a que son costosas, sin embargo las actividades deben ser realizadas por el personal asignado de acuerdo con su puesto y responsabilidad.

La automatización permite que cada rol ofrezca resultados adicionales y personalizados que no son fáciles ni prácticos de producir sin el soporte de las herramientas.

3.2 Ventajas de la organización

Cada uno de los roles para pruebas tiene actividades asignadas dentro de un proyecto. Para desempeñar esas tareas se requieren conocimientos y experiencia.

Correlacionar las actividades con los conocimientos necesarios para efectuarlas permitirá

Nivelar el rol o los roles que cada empleado es capaz de desempeñar en un proyecto.

Establecer el grado de conocimientos que debe obtener para desempeñar nuevos roles.

Crear y planificar las acciones formativas obligatorias para capacitar a los empleados.

Constituir itinerarios de carrera para los empleados.

Una herramienta para automatizar las pruebas es un complemento, no un sustituto del personal, sus roles y responsabilidades.

Determinar la organización que debe tener el personal es una práctica eficiente. Gracias a ello podremos fijar los recursos y reservar el tiempo de la prueba. Ganaremos confianza en el producto, ya que se profundiza el análisis para obtener información que no poseíamos y para seleccionar adecuadamente el trabajo y las herramientas a utilizar.

Conclusión

Podemos concluir que, los elementos básicos para automatizar una prueba son los pilares de un buen desarrollo, a través de bases sólidas como son los modelos, procesos y apoyos que son las herramientas, todos estos elementos tienen peculiaridades que hemos abordado, y hemos determinado para llevar a cabo una buena selección, y concluir con buenos casos de pruebas automatizadas cuyo fin es el detectar el error, la automatización se va dando a través del desarrollo mismo del software en base a los requerimientos, y los procesos establecidos, nosotros debemos de tener un lugar en la elaboración, diseño y ejecución de pruebas, que como se pudo ver esta asignado a cada rol, debemos también tomar conciencia de que la automatización es un gran apoyo para cada actividad que tenemos que llevar a cabo en las pruebas.

Introducción

 Durante el desarrollo de un proyecto se llevan a cabo diversas pruebas en diferentes etapas del proceso. Cuando estas pruebas son automatizadas, además de que intervienen diferentes personas, se involucran uno o varios tipos de software que agilizan la labor del equipo de pruebas.

Para llevar un buen control de las pruebas se debe registrar alguno de los siguientes puntos:

Metodología a aplicar Fases en las que se aplicarán las pruebas Fechas de inicio y fin Quién o quiénes van a realizarlas

Se debe tener un control de lo que se realiza y registrar todo, por ello es necesario contar con los documentos llamados “artefactos” y “entregables”, los cuales contienen información –evidencias– que puede ser útil tanto para el cliente como para los integrantes del equipo. Con tales evidencias todos podrán tener una visión amplia de lo que se va realizando y lo que falta por hacer.

Veamos primero el mapa de conceptos donde localizarás los conceptos clave de esta unidad.

1. Plan de pruebas

 Un plan de pruebas sirve para definir hasta dónde abarcará el proceso de calidad, cuáles son los objetivos a cumplir, las personas y recursos con los que se debe contar, las fechas de entrega y los responsables de cada fase del proceso.

Este documento es muy importante ya que en él se basa todo el equipo de pruebas. Las otras áreas pueden requerir acoplar sus propios planes de trabajo para cumplir las fechas especificadas o permitir un tiempo de trabajo donde ambos equipos coincidan, además, si por alguna razón hay rotación de personal, quedará una evidencia de cómo se estaba trabajando y lo que se tiene planeado realizar en un tiempo determinado.

Durante el desarrollo del proyecto, el plan de pruebas puede sufrir cambios que le permitan adaptarse mejor a la evolución del proyecto. Estos cambios, en caso de que sean aprobados, deben estar claramente especificados en un documento anexo al plan original, así como la causa de los mismos y deberán estar firmados por todos los miembros del equipo, incluidos los líderes de otras áreas ajenas a Pruebas

El plan es la base de todo proceso de pruebas. Todos los miembros del equipo deben conocer su contenido y mantenerlo presente a lo largo del ciclo de vida del proyecto.

A continuación te mostramos la plantilla de un Plan de Pruebas de Sistema que proporciona MOPROSOFT, podrás utilizarla para planear las pruebas de sistema en los proyectos que tengas que realizar. La plantilla consta de cuatro secciones:

También es necesario determinar qué software se debe utilizar para realizar cada prueba e indicar las herramientas a utilizar para cada una de ellas: se deben describir en la sección “descripción de pruebas”. Estas herramientas pueden ser:

El diseño de casos de prueba.

Registro y reporte de defectos (vistos en la unidad de aprendizaje Técnicas de administración de calidad).

Check list.

Gráficas.

Métricas.

Por último, en la sección Requerimientos de ambiente, se describen los recursos que el cliente debe proporcionar para realizar las pruebas, como la implementación del sistema en el lugar donde será utilizado en un futuro

A continuación te presentamos un documento en Word, el cual tendrás que descargar en tu computadora; contiene información respecto a cuál es la forma en que se da seguimiento a las pruebas del sistema. Consúltalo las veces que sea necesario

1.1 Procedimientos de las pruebas de software

Como se explico en la unidad 1, un proceso de pruebas, en general, abarca la aplicación de las mismas durante el desarrollo del sistema. Cada prueba tiene un objetivo determinado –lo ideal es que con todas las pruebas se pueda examinar el sistema completo–. Una buena estrategia consiste en realizarlas de adentro hacia afuera, es decir, comenzar con las partes más pequeñas –nuestras clases con sus respectivos métodos– y terminar con el sistema completo.

Una vez que tengamos nuestro plan de pruebas de sistema y que fijemos las pruebas que deban realizarse, debemos plasmar el procedimiento que debe seguir cada una de éstas. Para realizarlas se deben seguir ciertos pasos generales. Cabe mencionar que para todas se deben elaborar previamente los casos de prueba con el objetivo de definir claramente qué deseamos verificar.

A continuación te presentamos la forma en que se debe realizar cada una de las pruebas con su respectivo procedimiento:

1.2 Guión de pruebas

En un guión de pruebas (también llamado script) enlistamos todos los pasos que se deben seguir para realizar una serie de pruebas (casos de prueba). Los guiones se pueden clasificar en

Identificación de casos de prueba. En este guión se describen brevemente y de manera muy general los casos de prueba identificados.

Casos de prueba de alto nivel. Con este guión se especifica cada uno de los casos de prueba identificados previamente; se describen los actores involucrados dentro de la prueba y las precondiciones que se deben cumplir para que el caso pueda ser ejecutado, como lo veremos en la siguiente imagen

Casos de prueba a detalle. Con este guión especificamos paso por paso lo que se debe hacer para realizar la prueba descrita en la imagen anterior; donde se indican las precondiciones que se deben cumplir y los resultados esperados después de ejecutar la prueba, se especifica también a la persona que desarrolló el caso de prueba, la fecha y el artefacto o requerimiento en el que se basan para definir el caso de prueba.

También podemos encontrar guiones de prueba en los cuales lo único que existe es código. Ese script nos servirá para realizar una prueba de caja blanca (probar código), por ejemplo en el siguiente caso donde el script de prueba que se utilizará para las pruebas es un código que permite controlar valores nulos

Regularmente se plasman los guiones de prueba o script al principio en un archivo de texto plano dentro de una tabla u hoja de Excel, después se cargan en un software determinado (en JUnit, por ejemplo). Dentro del guión de pruebas vienen reconocidos los casos de prueba por medio de un identificador (ID) único para que puedan ser localizados y archivados con mayor facilidad.

Como puedes observar, un guión de pruebas no es más que la lista de los casos de prueba con los cuales vamos a experimentar. Los casos de prueba dependerán del tipo de examen que apliquemos, pues cada prueba tiene un objetivo distinto.

Cabe señalar que el guión de pruebas lo realiza una persona; quien lo lleva a la práctica es otra (se recomienda que no sea la misma), a esta última regularmente se le conoce como ejecutor de pruebas o tester.

Quien diseña el guión de pruebas con los casos de prueba debe ser una persona sumamente experimentada, pues debe analizar detalladamente todo el sistema y pensar en todos los posibles casos de error. Si por algún motivo se soslayara algún caso de prueba es labor del tester realizar la observación pertinente