UNIDAD - 2: PLAN DE PRUEBAS

UNIDAD - 2: PLAN DE PRUEBAS

---

1. REQUERIMIENTOS DE PRUEBAS

---

1.1. INTRODUCCIÓN
Las personas cometemos errores (errare humanum est) en la medida en que trabajamos más tiempo, abordamos tareas complejas, estamos cansados o nos distraigamos. Solemos equivocarnos en ciertas formas características, y según algunos autores, a cierta tasa que es estadísticamente predecible.

En el proceso de elaboración de software, como en cualquier otro proceso humano que requiere atención, precisión, comunicación, comprensión y creación a lo largo del tiempo, inevitablemente se introducen defectos, defectos que quisiéramos detectar y corregir para un producto determinado y prevenir en las futuras aplicaciones del proceso. Además quisiéramos que esta detección y corrección fuera lo menos costoso posible.

"¿Qué tipo de equivocaciones cometemos en el desarrollo de software?"
"¿Cómo se manifiestan en el software? ¿Cómo podemos buscar esos defectos de manera efectiva y eficiente?"

Antes de empezar a buscar respuestas a estas preguntas, debemos aclarar algunos términos que coloquialmente solemos manejar como sinónimos:

• Error (error):
  Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide con la definición de diccionario de error como "una idea falsa o equivocada". Por ende un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las ideas las tienen la gente.
  
  
• Defecto (fault, defect):
  Un error puede conducir a uno o más defectos. Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. De nuevo coincide con la definición de diccionario, "imperfección". Por ejemplo, un defecto es haber utilizado el operador "<" en vez de "<=".
  
  
• Falla (failure):
  En terminología IEEE, una falla es la la discrepancia visible que se produce al ejecutar un programa con un defecto. En general, un proceso (incluido el de ejecución) puede producir fallas, en la medida que no cumple con su cometido. Si queremos ser muy puristas, deberíamos usar el término fracaso.
  

1.2. CONDICIONES PARA QUE SE PRODUZCA UNA FALLA
La meta del proceso de prueba es ejecutar un código con datos de entrada que obligan a los defectos a manifestarse como fallas. Para que se produzca una falla en la ejecución de un código deben cumplirse tres condiciones:

• Alcanzabilidad: Utilizando los datos de prueba del caso, el código debe llegar a ejecutar la línea que contiene el defecto.
  
• Necesidad: La ejecucion de la línea defectuosa debe producir un estado diferente del que produciría la línea correcta.
  
• Propagación: El estado incorrecto debe propagarse de modo que se manifieste en una falla, es decir en una discrepancia entre el resultado esperado y el resultado producido por la ejecución.
  
  Estas tres condiciones plantean requerimientos importantes para la especificación de los casos de prueba.
  

Ejemplo:
Supongamos que una línea de código donde se le asigne una expresión a una variable y, contenga como defecto la operación x*x en vez de x+x. Evidentemente si la línea no se llega a ejecutar, no hay forma que se produzca una falla: no se cumple la condición de alcanzabilidad. Aunque los datos de entrada nos permitiesen ejecutar esta instrucción, si x=2, no se produce una falla, ya que el valor asignado a y es el correcto, a pesar del defecto. Por ende no se produce una falla porque no se cumple la condición de necesidad. Finalmente, aunque escojamos un valor como x=1 que cumpla la condición de necesidad, si el valor incorrecto resultante no se propaga hasta una instrucción que haga visible una discrepancia (por ejemplo imprimiendo y, salvándolo en un archivo que se revisa automáticamente o echando a perder otra asignación cuya variable eventualmente se hace visible), tampoco se produce la falla --en este caso es porque no se cumple la condición de propagación.

1.3. MODELO DE DEFECTOS, PISTAS Y REQUERIMIENTOS DE PRUEBAS
Cualquier proceso de prueba busca construir un conjunto minimal de buenos casos de prueba. Un buen caso de prueba es aquel que tiene una alta probabilidad de producir una falla. Adicionalmente, por definición, un caso de prueba debe especificar, por lo menos, el valor exacto de los datos de entrada y los resultados exactos esperados.

Si conociéramos el tipo de defectos que introducimos en nuestros artefactos, nos resultaría más sencillo construir casos de pruebas que los detectaran.

Toda buena prueba presupone un modelo de defectos. Así por ejemplo, un tipo común de defecto, que debe formar parte de un modelo de defectos, es el uso de un operador relacional por otro, como por ejemplo colocar un "<" en vez de un "<=" o hasta un ">".

Una pista es un posible indicador de cierto tipo de defectos. Así, el hecho que una de las entradas de un código sea un conjunto, es una pista; el hecho que el resultado dependa de que otra de las entradas pertenezca a ese conjunto nos conduce a otra pista: la computación de una pertenencia. En general, el tipo de una entrada es una pista y operaciones conocidas como por ejemplo búsquedas, clasificaciones e intersecciones son pistas, en la medida que despiertan y encaminan nuestras sospechas.

El análisis de las pistas según un modelo de defectos nos puede conducir a unos requerimientos de pruebas.

Un requerimiento de pruebas es una descripción de una combinación de datos de entrada, que por experiencia previa o por intuición consideramos probable que desemboquen en una falla. Así por ejemplo, a partir de las pistas:

Una de las entradas, A, es un conjunto y
El resultado depende de que otra de las entradas, x, pertenezca al conjunto A
y de un modelo de defectos que nos hace desconfiar de situaciones donde se manejan conjuntos vacíos, conjuntos singulares y conjuntos máximos, elaboramos los siguientes requerimientos de pruebas:
A es el conjunto vacío;
A es un conjunto singular y x es ese elemento singular;
A es un conjunto singular y x es un elemento diferente al contenido en A;
A es el conjunto más grande que puede representarse y x pertenece a él.

En resumen, para construir casos de prueba debemos:

Encontrar pistas;
Aplicar un modelo de defectos a las pistas para obtener requerimientos de pruebas;
Concretar y combinar los requerimientos de pruebas para construir un conjunto minimal de casos de prueba. Cada caso de prueba debe satisfacer las condiciones necesarias para producir fallas y completar la especificación de sus datos de entrada con los resultados esperados.

Ejemplo:
Comprobar la validez del carnet del estudiante.

• Debe permitir tambien dejar el carnet en blanco con cualquier cosa como nombre (esto permite jugar con escenarios y que el Coordinador haga pruebas del sistema...).
  
• Idealmente el sistema debe dejar introducir los primeros dos dígitos del carnet, escribir el guión y dejar que el usuario termine de introducir los demás números*. Hay que prestar atención a que capture y valide los carnets "00-" correctamente.
  

*Note que el requerimiento contiene un error y debería especificar que "...el usuario termine de introducir los demás dígitos."

Revisar la verificabilidad del requerimiento
¿El requerimiento está expresado de manera suficientemente precisa como para poder elaborar casos de prueba que permitan indicar si se satisface el requerimiento o no?
En general, el hecho que los requerimientos estén escritos en lenguaje informal siempre es fuente de imprecisiones y ambigüedades; por otro lado, en la práctica es inusual encontrarse con requerimientos escritos en lenguaje formal, por lo que es necesario partir de lo que se tiene, a pesar que sería mucho más fácil elaborar casos de prueba a partir de especificaciones formales que de especificaciones informales como ésta o semiformales como lo constituido por la mayoría de los diagramas UML.

Para comprobar la validez de un carnet de estudiante, tenemos que tener una definición clara de lo que es un carnet válido de estudiante. El requerimiento no proporciona tal definición; se "supone" que tal definición forma parte de los conceptos comunes compartidos por desarrolladores y accionistas.

De resultar cierta tal suposición, el requerimiento es verificable: un carnet es válido o no es válido, y no hay razones para pensar que ese criterio de validez no sea objetivo y computable.


Especificar el criterio de verificación
Un carnet de estudiante introducido al sistema es considerado válido si:

1. Está en blanco.
   
2. Contiene exactamente dos dígitos que lo encabezan y contiene uno o más dígitos que forman su cola.
   

Note que el criterio explicitado no es el único criterio de validación posible y que hay otras interpretaciones posible de lo que es un carnet válido:

1. Un carnet válido está en blanco o es un número natural. Este criterio inadecuado, que por cierto fue utilizada en un sistema de DACE, puede conducir a problemas con el manejo de los carnet de estudiantes que ingresaron a la USB en el año año 2000. De hecho, se presentó un problema cuando en el sistema se implementó que un carnet como 00-32000 se representara internamente como el número 0032000, es decir 32000 (los ceros a la izquierda no son significativos) y al tomar los dos dígitos más significativos del número para determinar la cohorte a que el estudiante pertenece, el sistema fue programado para responder que pertenece a la cohorte de estudiantes que ingresaron en 1932.
   
2. Un carnet válido es una secuencia de dígitos. Por un lado, este criterio inadecuado, permite correcta pero incompletamente definir el carnet en blanco como una secuencia nula de dígitos; por otro lado la secuencia 1 sería (incorrectamente) considerado válido. Note que a partir de esta secuencia es imposible determinar sin ambigüedad, la cohorte del estudiante.
   
3. Un carnet válido está en blanco o es una secuencia de exactamente siete dígitos. Este criterio puede ser considerado adecuado, pero con cierto riesgo que puede argumentarse despreciable. Este criterio reportaría como inválidos carnets que fueron válidos en su momento, como 71-2022. Estimo que el último carnet con 6 dígitos fue otorgado a más tardar en 1978, por lo que las probabilidades de que todavía se encuentre en la USB un estudiante con carnet de 6 dígitos es muy bajo. Por otro lado, hasta hace un año no se sabía si los carnets de la cohorte 2000, vendrían encabezados por 00, 2000, o incluso 000, seguido por cinco dígitos adicionales. Al definirse que la cabeza indicativa del año de ingreso permanece en dos dígitos, el otro problema puede surgir cuando no alcancen cinco dígitos para la cola del carnet.
   
4. Un carnet válido está en blanco o está formado por dos números naturales; el primer número denota el año de ingreso del estudiante a la universidad. Este criterio es adecuado, aunque presenta problemas con implementaciones previas de la USB del concepto de carnet.
   Un carnet válido está en blanco, o está formado por una cabeza de dos dígitos y una cola de cuatro o más dígitos; adicionalmente para cada cabeza hay un conjunto específico de colas válidas. Este criterio es adecuado y de hecho el más completo, pero excesivo en su nivel de detalle. Cada carnet tiene una cola única, ya que el número asociado a esa cola, es mayor que cualquier cola de un estudiante de una cohorte previa y menor a la cohorte posterior. No conozco los números exactos pero, los carnet válidos de la cohorte 96 van en un rango aproximado de 96-28000 a 96-29999.
   Observe cómo en realidad, el requerimiento original deja mucha ambigüedad en lo que constituye el criterio de verificación y cómo la "suposición" de que desarrolladores y accionistas comparten un concepto común de lo que es un carnet de estudiante, peligrosa,.
   

El criterio es criticable en al menos dos aspectos adicionales:

• Supone que hablamos de carnets de estudiantes de la USB, aunque esta precisión no es explícita en el requerimiento;
  
• No precisa qué es un carnet en blanco. ¿Una secuencia vacía de dígitos es un carnet válido? ¿Una secuencia de caracteres blancos es un carnet válido? ¿Una secuencia de caracteres blanco entremezclados con caracteres de tabulación, es un carnet válido?
  

Una observación adicional concierne el uso del guión para separar la cabeza del carnet de su cola. En forma relativamente sutil y fácil de dejar de percibir, note que de los requerimientos se desprende que el usuario no introduce el guión, sino que el sistema automáticamente se las arreglará para intercalar el guión entre la cabeza y la cola del guión.

Hacer visible las propiedades o elementos del software para verificar el cumplimiento del requerimiento:
El sistema pide como entrada el carnet y lo muestra por pantalla, por pantalla, por lo que la visibilidad se satisface.

Hacer controlable los elementos del software necesario para llevar a cabo las pruebas:
Verificar este requerimiento involucra introducir un conjunto de carnet diferentes y verificar que los carnet válidos son aceptados por el sistema, mientras que los invidos son rechazados con un mensaje de error. Actualmente el sistema sólo puede probarse manualmente --¿conviene escribir un manejador que realice las pruebas automáticamente? Para ello, el manejador necesita abrir una sesión, realizar repetidas consultas en cada una de las cuales proporciona un carnet diferente, tomado de un archivo de prueba de carnets y revisar que el carnet válido sea aceptado sin alteración y el carnet inválido sea rechazado con un mensaje de error.

Pistas:

1. Un carnet puede estar en blanco;
   
2. Un carnet es una secuencia de dígitos cuya cabeza está formada por exactamente dos dígitos y cuya cola está formada por uno o más dígitos.
   

Modelo de defectos:
Al manejar secuencias, hay tendencia a equivocarse con:

• La secuencia vacía;
  
• Secuencias singulares;
  
• Secuencias de tamaño mínimo;
  
• Secuencias de tamaño máximo.
  

Si se permiten blancos en una secuencia, hay tendencia a manejar incorrectamente:

• Secuencias puras de blancos;
  
• Secuencias encabezadas por blancos;
  
• Secuencias que terminan en blancos.
  

Si una subsecuencia de dígitos denota un año o una cantidad, pueden cometerse equivocaciones al manejar el año o cantidad cero.

Requerimientos de prueba:
Carnets válidos:

1. Un carnet dejado en blanco (secuencia vacía);
   
2. Un carnet formado por un caracter blanco;
   
3. Un carnet formado por un caracter tabulador;
   
4. Un carnet formado por el número máximo permitido de caracteres blancos;
   
5. Un carnet formado por tres dígitos cuya cabeza sea diferente a 00;
   
6. Un carnet formado por el número máximo de dígitos permitidos de cabeza diferente a 00;
   
7. Un carnet de tres dígitos , cuya cabeza sea 00;
   
8. Un carnet formado por el número máximo de dígitos permitidos y encabezado por 00;
   
9. Un carnet formado por el el número máximo de dígitos y cuyo tercer dígito sea un cero y cuya cabeza sea diferente de 00;
   
10. Un carnet formado por el número máximo de dígitos, cuya cabeza sea diferente de 00 y cuya cola esté formada por ceros.
    

Carnets inválidos:

1. Un carnet formado por un dígito;
   
2. Un carnet que contiene un caracter que no sea ni dígito, ni caracter blanco ni caracter tabulador;
   
3. Un carnet formado por un dígito seguido de caracteres blancos, tal que el número total de caracteres es el máximo permitido;
   
4. Un carnet formado por el número máximo de caracteres, donde el primer caracter es un blanco y el resto son dígitos;
   
5. Un carnet formado por el número máximo de caracteres, donde el último caracter es un blanco y el resto son dígitos;
   
6. Un carnet formado por el número máximo de caracteres, donde el tercer caracter es un blanco y el resto son dígitos.
   

En total son 16 requerimientos, que se traducirán en al menos 16 casos de prueba (ojo, el número de requerimientos puede ser mayor, menor o igual al número de casos de prueba). ¿No es un número excesivo de casos de prueba para este requerimiento? ¿Qué significa "un número máximo de caracteres"?

Fuente: [Tienes que estar registrado y conectado para ver este vínculo]

UNIDAD - 2: PLAN DE PRUEBAS

---

2. PLAN DE PRUEBAS

---

Existen varios estándares para Desarrollo de Software, que proponen distintas herramientas de modelado para la gestión de PLANES DE PRUEBAS. Un plan de prueba es un documento que compila las estrategias que diseñemos, acorde al negocio al software a evaluar, para realizar pruebas en contexto, para aseverar el correcto funcionamiento del mismo.

Uno de los estándares mas reconocidos propone los siguientes enunciados:

2.1. IEEE 829-1983
El estándar IEEE 829-1983 describe los tipos de documentos que pueden producirse durante el proceso de prueba. Puede resultar interesante comparar nuestra propuesta con el estándar. Recuerde que sólo hemos visto los tipos de documentos asociados a la prueba de procedimientos.

2.2. Comparativa entre dos estandares de diseño para Plantes de Pruebas

Delta Pensum	IEEE 829-1983
Plan de pruebas de un requerimiento	Plan de prueba
(opcional) Tabla de decisiones asociada al requerimiento
Análisis de verificabilidad del requerimiento
Criterio de verificación
Requisitos de observabilidad
Requisitos de controlabilidad
Pistas
Catálogo de modelos de defectos
Requerimientos de prueba	Especificación de los requerimientos para el diseño de los casos de prueba
Suite de prueba
Caso de prueba	Caso de prueba
	Descripción del procedimiento de prueba
	Descripción del item a probar (IUT en Binder)
Ambiente de prueba
Bitácora de pruebas	Bitácora de pruebas
	Reporte de incidentes de prueba
Análisis de resultados y acciones recomendadas
Resumen gerencial del proceso	Resumen de pruebas

2.3. El Plan de Pruebas
El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.

Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos 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 su alcance, 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 de verificación del contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicionalmente la versión y fecha del plan.
   
   
2. Alcance: Indica el tipo de prueba y las propiedades/elementos del software a ser probado.
   
   
3. Items a probar: Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.
   
   
4. Estrategia: Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia 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én explicita el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.
   
   
5. Categorización de la configuración:Explicita las condiciones bajo las cuales, el plan debe ser
   a.Suspendido
   b.Repetido
   c.Culminado
   En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al 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 repetir algunas pruebas. Los criterios de culminación pueden ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.
   
   
6. Tangibles: Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.
   
   
7. Procedimientos especiales: Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.
   
   
8. Recursos: Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo.
   La sección incluye un estimado de los recursos humanos necesarios para el proceso. 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. Calendario: Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.
   
   
10. Manejo de riesgos: Explicita los riesgos del plan, las acciones mitigantes y de contigencia.
    
    
11. Responsables: Especifica quién es el responsable de cada una de las tareas previstas en el plan. La dirección del proceso de pruebas es parte de las responsabilidades del Coordinador de Calidad.
    Note que, en el proceso adoptado para Delta Pensum, algunos de los renglones del Plan de Pruebas, pueden detallarse en la descripción de las Suites de Prueba. Recuerde que es importante evitar información redundante.
    

2.4. Referencias
ANSI/IEEE Standard 829-1983 for Software Test Documentation. IEEE Press, 1983. Este estándar se incluye en la colección Software Engineering Standards publicado por IEEE Press.

Fuente: [Tienes que estar registrado y conectado para ver este vínculo]