Prueba, implementaciòn y mantenimiento del sistema
Si le pedimos a diferentes profesionales que indiquen lo que es para ellos hacer pruebas, obtendremos diferentes respuestas como:
Encontrar errores en programas
· Pruebas de Sistemas
· Determinar la aceptabilidad de usuarios
· Adquirir confianza en el funcionamiento del sistema
· Demostrar que no tiene errores
· Evaluar las capacidades de un sistema
· Verificar el funcionamiento de un programa
· Asegurar que el sistema está listo para ser usado
· Mostrar que el sistema funciona correctamente
· Chequear el sistema contra las especificaciones
· Asegurar la satisfacción del cliente
Un programa que se escribía para correr en una computadora tenía que ser probado, y de encontrarse errores, eliminarlos.
Así surge la primera visión:
La prueba vista como una actividad siguiente a la programación, que implicaba no sólo descubrir errores sino también corregirlos y removerlos
Luego de la primera conferencia formal organizada en EEUU, en Junio de 1972, dedicada a las pruebas de sistemas es que surge la segunda visión
La prueba de sistema abarca una serie de actividades asociadas a obtener confianza que un programa o sistema hace lo que se supone que tiene que hacer.
Según Myers (1979), si se planteaban las pruebas con el objetivo de demostrar que el programa o sistema no conténía errores, inconscientemente se iban a elegir datos para probar con baja probabilidad de causar que el sistema falle.
Surge así una tercera visión de las pruebas, donde el objetivo central es “encontrar errores” como parte de un proceso
“El testing es el proceso de ejecutar un programa o sistema con la intención de encontrar errores.” (Myers, 1979, p. 5).
La anterior definición implicaba que sólo se podía probar después que el programa había sido codificado
Entonces aparece una cuarta visión:
El testing como una actividad amplia y continua que acompaña el proceso de desarrollo
“El testing es cualquier actividad orientada a evaluar un atributo o capacidad de un programa o sistema y determinar si alcanza los resultados requeridos
.” (Bill Hetzel, 1988, p. 6)
Si los requerimientos están completos y un producto cumple esos requerimientos, entonces es un producto de calidad
.
Nace la quinta visión
El proceso de verificar que el software se ajusta a los requerimientos y validar que las funciones se implementan correctamente.
Esta última, atiende a tres puntos importantes:
- Uno, que su funcionamiento es correcto, implicando que no hay· errores que impidan operar el sistema.
- Dos, que el sistema cumpla con los requerimientos, es decir, que lo que se haya planteado esté desarrollado
- Y tres, que el hacer pruebas es visto como un proceso (“el· proceso de…”), y no como una actividad al final.
Plantea así tres dimensiones de la calidad de software (que los define como calidad exterior, interior y futura respectivamente)
Funcionalidad definida como la calidad exterior
· ◦ Exactitud ◦ Usabilidad ◦ Confiabilidad
Ingeniería como calidad interior:
(tiene que ver con el proceso de construcción): ◦ Capacidad de pruebas ◦ Eficiencia ◦ Documentación
Adaptabilidad como calidad futura
◦ Flexibilidad ◦ Reusabilidad ◦ Mantenibilidad
Con todo lo expuesto anteriormente, podemos decir que:
·Hacer pruebas no es demostrar que no hay errores.
·Hacer pruebas es detectar los errores y no buscar los motivos, ya que buscar los motivos es hacer debugging
·Hacer pruebas no implica simplemente verificar que las funciones requeridas se implementaron.
·Hacer pruebas es someter un software a ciertas condiciones que puedan demostrar si es o no válido a los requerimientos planteados.
·Considerar las pruebas es agregar valor no sólo al producto, sino que también al proceso de desarrollo
En lo que se refiere a la historia, podemos resumirla a través de las visiones dadas:
Primera visión:
inicialmente, hacer pruebas era hacer debugging.
Segunda visión:
“obtener confianza” que un programa o sistema hace lo que se supone que tiene que hacer
Tercera visión:
“El testing es el proceso de ejecutar un programa o sistema con la intención de encontrar errores.” (Myers, 1979, p. 5).
Cuarta visión:
vincularlo directamente al concepto de calidad, es decir, la prueba vista como cualquier actividad realizada con el objetivo de ayudar en la evaluación o medición de un atributo de software.
Quinta visión:
la prueba vista como el proceso de verificar que el sistema desarrollado se ajusta a los requerimientos y de validar que las funciones se implementan correctamente. Incorpora tres puntos fundamentales: proceso, verificación cumplimiento de requerimientos, y validación de funcionalidad
6.En los 90’ aparecen las herramientas para dar soporte al proceso y ayudar en la ejecución
7. En el 2000 comienza a considerarse como parte del proceso de aseguramiento de calidad de software
El enfoque dinámico apunta a ejecutar una parte o todo el software para determinar si funciona según lo esperado.
El enfoque estático se refiere a la evaluación del software sin ejecutarlo usando mecanismos automatizados (herramientas asistidas)
Dinámica:
implica que para realizar las pruebas hay que ejecutar el programa para los datos de entrada
Comportamiento esperado:
debe ser posible decidir cuando la salida observada de la ejecución del programa es aceptable o no, de otra forma el esfuerzo de la prueba es inútil.
Otras definiciones que podemos tomar de la IEEE2 en su Std. 610 (1990)
que lo define ya como un proceso de operar el sistema o componente, bajo ciertas condiciones específicas, observar su comportamiento, registrar los resultados
Entonces:
Es el proceso de ejercitar el sistema para detectar errores y verificar que satisface las especificaciones de requerimientos funcionales y no funcionales
1.2.1. Error-falla-defecto
El ISTQB (2011)
definíó los conceptos de error–
Falla-
defecto, haciendo una distinción entre cada uno de ellos
Error:
es la acción humana de equivocarse.
Falla:
es la diferencia entre el resultado esperado y el realmente obtenido,
Defecto:
se llama de este modo al desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas, por ejemplo, una sentencia o una definición de datos incorrectas.
1.
¿Es correcto decir que un error lleva a uno o más defecto que están presentes en un componente de software?
2. ¿O que un defecto ocasiona cero, una o más fallas?
1.
Claro que sí. El acto de equivocarse (error) lleva a un desperfecto, que podría ser un error en el código (defecto).
2.Entonces un defecto no siempre causa una falla, el software falla si se ejecuta esa parte del código donde se encuentra el defecto
1.2.2. Caso de prueba
La IEEE en su Std. 829 (2008), define:
Caso de prueba como la documentación que especifica las entradas, los resultados previstos o esperados, y un conjunto de condiciones de ejecución de un elemento de prueba.
Según la IEEE en el Std. 610 (1990)
, la descripción de un caso de prueba incluye, al menos, la siguiente información:
·Precondiciones· Conjunto de valores de entrada· Conjunto de resultados esperados ·Pos-condiciones esperadas· Identificador único· Dependencia de otros casos de prueba· Referencia al requisito que será
El caso de prueba contiene entradas, proceso y salidas
La entrada comprende:
- El conjunto de datos a ingresar para ejecutar el caso de prueba.
- Las pre-condiciones necesarias para poder ejecutar correctamente el caso de prueba. Éstas pueden ser:
De entorno, es decir, en qué sistema operativo
De software, es decir, en qué lugar se debe empezar, qué opción de menú tiene que estar disponible.
El proceso es el conjunto de acciones a realizar para ejecutar el caso de prueba, que partiendo de los datos de entrada
La salida es el conjunto de resultados que deben estar preestablecidas, es decir, ser conocidas y previstas antes de la primera ejecución del caso de prueba
1.2.3. Verificación y Validación
La norma ISO 9000 (2008) define a estos términos en sus puntos 3.8.4 y 3.8.5 de la siguiente manera:
“Verificación
Confirmación mediante la aportación de evidencia objetiva (3.8.1) de que se han cumplido los requisitos (3.1.2) especificados.”
“Validación
Confirmación mediante la aportación de evidencia objetiva (3.8.1) de que se han cumplido los requisitos (3.1.2) para una utilización o aplicación específica prevista.
Considerando estas definiciones se tiene que ambas son una comprobación con respecto a su usabilidad final, con la diferencia que la validación es decir para ver si funciona o no el producto para lo cual se construyó
1. Satisfacen los requerimientos funcionales y otros requerimientos (validación)
2. Cada paso en el proceso de desarrollo de software produce el producto correcto (verificación)
1.2.4. Normas y estándares para pruebas de sistemas: Norma ISO 9126, IEEE, CMM, TMM
Aplicado a la calidad de software, Roger S. Pressman la define como:
“El cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamente documentados y de las carácterísticas implícitas que se esperan de todo software desarrollado profesionalmente
Explicación
Primero habla de requisitos de funcionalidad que es todo aquello que se dice o expresa que se espera del software. Es lo que podemos llamar carácterísticas explícitas. Y al final, habla de las carácterísticas implícitas. En software ocurre muy a menudo que el cliente no solicita algo, pero que lo espera
Según (Pressman, 2006, p. 464)
los factores que afectan la calidad de software se dividen en dos grupos.
Uno, llamados directos, que son los que miden directamente a través, por ejemplo de cantidad de defectos descubiertos sobre casos de pruebas corridos.
Y otro, indirectos, que son los que miden indirectamente como puede ser por ejemplo, la facilidad de uso del producto.
Modelo de McCall
El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los EE.UU en 1977.
El modelo establece una jerarquía de Perspectivas, Factores, Criterios de Calidad y como fin último, las Métricas.
Es muy rico porque logra definir métricas para los factores de calidad, además de dar un significado para cada uno de los factores
Explicamos entonces cómo se estructura:
El modelo de McCall se basa en 11 factores de calidad, organizados en torno a tres perspectivas:
Operación del producto:
Corrección, Confiabilidad, Facilidad de Uso, Integridad, Eficiencia.
Transición del producto:
Portabilidad, Facilidad de Reutilización, Interoperabilidad.
Revisión del producto:
Facilidad de Mantenimiento, Flexibilidad, Facilidad de Prueba.
Las letras R, D e I indican si la lista de comprobación es aplicable a los requisitos (R), el diseño (D) y/o la implementación (I)
La “corrección” depende de la “completitud”, la “trazabilidad”, y la “consistencia”
La medida para la corrección, por ejemplo, se calculará aplicando la fórmula: (x+y+z)/3
Donde x es la medida para la completitud, y la medida para la trazabilidad y z la medida para la consistencia. Para que todas las métricas se puedan combinar sin problemas, lo habitual es que se normalicen sus valores dentro del intervalo [0,1].
Norma ISO 9126
Es un estándar internacional para la evaluación de la calidad de software que si bien se deriva del anterior Modelo de McCall. Ya a partir del 2005 fue reemplazada por la ISO 25000:2005.
La ISO 9126 (2001) propone un modelo de calidad que se divide en tres vistas: interior, exterior y en uso.
o Métricas internas:
aquellas que no dependen de la ejecución del software (estáticas).
o Métricas externas:
Aquellas aplicables al software en ejecución (dinámicas).
o Métricas de uso:
sólo disponibles cuando el producto final es usado en condiciones reales.
Las visiones de calidad permiten definir modelos de calidad (conjunto de carácterísticas), estos modelos permiten definir propiedades del producto y del proceso y en base a estas propiedades definimos métricas; a partir de las éstas se realiza la Gestión de Calidad para asegurarla.
Norma ISO 9000:2005
Se puede decir que son reglas básicas de calidad, independientes del producto o servicio de que se trate. Se definen como un conjunto de buenas prácticas de fabricación de un producto u ofrecimiento de un servicio.
La ISO 9000-3 está dividida en 3 partes:
·Marco de trabajo Actividades en el ciclo de vida· Actividades de apoyo
Específicamente en lo relativo a las pruebas en general, establece los siguientes elementos principales:
a) Las pruebas deben ser realizadas en varios niveles, desde el ítem de software individual hasta el producto completo.
B) En algunas ocasiones la validación, la prueba de campo y la prueba de aceptación pueden ser una sola actividad
c) El documento que describe el plan de pruebas puede ser un documento independiente o estar compuesto de varios documentos.
·Relativo a la planificación de las pruebas
a) Planes para realizar las pruebas de unitarias, integración, sistema y aceptación. B) Definición de casos de pruebas, datos de prueba y resultados esperados.
c) Tipos de pruebas a realizarse, por ejemplo, prueba funcional, prueba de límites, pruebas de rendimiento, prueba de usabilidad.
d) Especificar ambiente de pruebas, herramientas y técnicas de pruebas de software. E) Criterios de completitud en las pruebas.
F) Documentación disponible (requerimientos, diseño, otros)
G) Personal y entrenamiento requerido
·Relativo a la validación del Proveedor
Antes de entregar el producto y la prueba de aceptación del usuario, el proveedor debe validar su operación como un producto completo y si es posible bajo condiciones similares al ambiente que tendrá la aplicación de acuerdo a lo especificado en el contrato.
·Relativo a la aceptación del comprador
Cuando el proveedor está listo para entregar el producto validado, el comprador debe juzgar si el producto es aceptable de acuerdo a los criterios estipulados con el contrato. El método de manejar los problemas detectados durante la prueba de aceptación debe ser acordado entre el comprador y el proveedor y documentado.
·Recursos y personal para verificación
El proveedor deberá identificar internamente los requerimientos, proveer los recursos adecuados y asignar personal entrenado para las actividades de verificación.
Las actividades de verificación deben incluir:
Inspección
o Pruebas
o Monitoreo del diseño, producción, instalación, y procesos de servicio o productos
o Revisiones del diseño o Auditorías del sistema de calidad, procesos y /o productos.
Modelo CMMI8
Tiene su origen en el Departamento de Defensa, USA. Es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software
Se estructura en 5 niveles que explicaremos brevemente:
Inicial (Nivel 1):
Se opera sin procedimientos formales, sin estimaciones ni planes y las herramientas no están bien integradas. No hay buena información acerca de los problemas y asuntos internos y no existe un control de cambio riguroso
Repetible (Nivel 2):
En este estado, superior del anterior, la organización ha logrado un rendimiento estable a través de una administración de compromiso, costos, planificación y control de cambios. Hay Organización, administración de proyectos, administración del proceso de desarrollo y tecnología.
Definido (Nivel 3):
Ya en este nivel hay un proceso estándar definido, se puede decir que hay metodología. Si bien hay escasos datos cuantitativos, se manejan las contingencias y se puede mejorar ordenadamente y facilitar la introducción de tecnología de apoyo.
Administrado cuantitativamente (Nivel 4):
Completo proceso de análisis y medidas, tales como calidad, costo, productividad, entre otros. Existe un preciso conocimiento de los procesos como base para una continua calidad de sus productos y un mejoramiento de la productividad.
Optimizado (Nivel 5):
En este nivel, la completa información acerca del proceso de software es usada para evaluar la efectividad de este proceso y hacer ajustes en forma regular
Si bien el término «pruebas de sistema» no es un término usado en CMMI debido a sus múltiples interpretaciones entre diferentes disciplinas, no implica que no estén contempladas por el modelo
Las pruebas en el modelo CMMI están tratadas principalmente en las áreas de proceso «Verificación» y «Validación». Producto es sistema y prueba valid y verif
IEEE
La IEEE9 es la sociedad técnica profesional más grande del mundo dedicada a la estandarización, entre otras cosas. Su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales.
Se listarán algunos de sus estándares relacionados a las pruebas y que son los más consultados dentro de la comunidad de probadores
IEEE 610 (1990):
estandariza una terminología. Si bien no es una terminología específica de pruebas, ya que es de Ingeniería de Software, incluye todos los términos relacionados a las pruebas
IEEE 829 (2008):
desarrolla una estructura de plan de pruebas maestro acreditada que incluye: descripción de un caso de prueba, contenido de un informe de estado de pruebas, estructura de un informe de incidencias
IEEE 730 (2002):
estructura y da los contenidos de un plan de calidad,
IEEE 1028 (2008):
dedicado exclusivamente a las revisiones, cómo deben hacerse y qué deben incluir.
1.3.Principios de las pruebas y su Psicología
Comenzaremos explicando qué consideramos un principio: es considerado una verdad aceptada
Hetzel (1988) establecíó, por ejemplo, seis principios fundamentales:
·Principio N°1: La prueba completa no es posible
De la siguientes expresiones que frecuentemente escuchamos, como “Pararé de probar cuando esté seguro que funciona”, o “implementaremos el sistema tan pronto como todos los errores sean corregidos”. Podemos ver que asumen que la prueba es una actividad que puede terminar y que siempre se tiene la certeza que todos los defectos son removidos.
No podemos esperar lograr la prueba completa
Los probadores o testers deben seleccionar un pequeño set de pruebas que incluye estas posibilidades. Y ese set debe ser lo suficientemente grande para proporcionar un nivel satisfactorio de confianza, pero no tan grande que resulte impráctico de administrar.
Y si no podemos testear todo, ¿qué podemos hacer?
Gestionar y reducir el riesgo.· Priorizar los casos para enfocar las áreas principales de· riesgo. Distribuir el tiempo de pruebas según el grado de los riesgos· involucrados. Entender el riesgo del negocio.
·Principio N°2: El trabajo de pruebas es creativo y difícil
Lo cual no es así, ya que para probar efectivamente se debe entender el sistema a fondo y los sistemas no son ni simples, ni sencillos de comprender. No se puede comenzar a diseñar y desarrollar una prueba efectiva hasta que no se haya detalladamente entendido lo que se supone que hace el sistema.
Hetzel (1988) establece los siguientes ingredientes esenciales para una buena prueba:
Creatividad e intuición Conocimiento de negocio· Experiencia en pruebas· Metodología de pruebas
Principio N°3: Una importante razón de las pruebas de sistemas· es prevenir que ocurran las deficiencias
está enfocado en una de las últimas visiones que abraza el concepto de pruebas a lo largo del ciclo de vida de desarrollo y no que la prueba es una fase. Hay muchos entregables asociados a cada fase de desarrollo sobre los cuales se pueden hacer pruebas que ayuden a detectar de manera temprana las deficiencias que podrían estar presentes.
Otros autores llaman a este principio como “Pruebas tempranas”.
Principio N°4: La prueba se basa en el riesgo
La cantidad de pruebas que deberíamos hacer depende directamente en el riesgo involucrado. Sistemas con alto riesgo requieren más casos de pruebas y más énfasis en las pruebas i viceversas.
Principio N°5: La prueba debe ser planeada
Si bien todos parecen estar de acuerdo con este principio, no todos están disciplinados en esto de planificar las pruebas. Este principio Pruebas de Sistemas también es corolario del principio n° 1 (que dice, en otras palabras, que no se puede probar todo), es que debe hacerse una selección, y una planificación cuidadosa de las pruebas, y según esa selección que se haga es lo que diferencia entre una buena prueba o una prueba pobre.
La etapa de planificación dentro de un proceso de pruebas, es pensar en un enfoque global, o diseñar las pruebas o y establecer los resultados esperados.
Puede ser formal, si es escrito y está a disposición de manera permanente como un documento del proyecto
. O bien, puede ser informal cuando existe en notas temporales o en la cabeza de alguien sin la intención de ser grabado o revisado
·Principio N°6: La actividad de pruebas requiere independencia
Cuando se requiere una medición objetiva, se requiere una persona objetiva e imparcial
Lo mismo ocurre con las pruebas, por dos motivos:
1. Las personas tienden a pasar por alto sus propios defectos
2. El desarrollador nunca va a analizar su “creación” (el código generado) de forma imparcial ya que tiene con él un apego afectivo
Entonces, las pruebas puede hacerlas:
Quien escribe el código o Otra persona o Una persona de diferente sección o Otra persona de diferente organización
Pueden tomarse como principios o derivados de los dados
Los casos de pruebas deben ser escritos tanto para condiciones de entradas válidas y esperadas
Evite desechar los casos de pruebas a menos que el programa sea ya un verdadero programa.
Nunca planificar el esfuerzo de pruebas suponiendo que no se encontrarán errores.
La probabilidad de existencia de más errores en una sección de un programa es proporcional al número de errores ya encontrados en esa sección.
A continuación listaremos los siete principios dados por el ISTQB (2011)
1.El proceso de pruebas demuestra la presencia de defectos: Dicho de manera contraria, no se tiene que probar para demostrar que funciona y tiene que ver con el último principio de la independencia de las pruebas, ya que eso de demostrar que funciona, es una acción natural del programador
2.No es posible realizar pruebas exhaustivas: idéntico al principio n°1 que dice que “La prueba completa no es posible”
3. Pruebas tempranas: encubierto dentro del principio n° 3
4. Agrupamiento de defectos (“defect clustering”). Sostiene que los defectos aparecen agrupados como hongos o cucarachas, donde se encontró un defecto y se encontrarán más “cerca. La identificación/localización de un defecto puede necesitar ser investigada con un mayor grado de detalle
5. Paradoja del pesticida: Si siempre se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos defectos, es decir que es como que el sistema se hace inmune a los casos de pruebas elegidos. Lo que marca este principio es que repetir pruebas en las mismas condiciones no es efectivo
6.Las pruebas dependen del contexto: simplemente, objetos de prueba diferentes son probados de forma diferente
7.La falacia de la ausencia de errores: similar en su explicación al principio n° 4 de Hetzel, aunque marca claramente que en la mayoría de los casos el proceso de pruebas no detectará todos los defectos del sistema, pero los defectos más importantes deberían ser detectados
1.4.Niveles de pruebas
Hetzel (1988) plantea tres niveles de pruebas elementales
Los programas individuales son probados como componentes individuales y las llama “Pruebas de Unidad”, luego los grupos de programas son probados todos juntos integrando un sistema, a las que llama “Pruebas de Sistema” y, por último, una vez con el sistema completo, se hacen las “Pruebas de Aceptación”.(CLientes o usuarios.
También reconoce otros niveles de pruebas empleados en proyectos más largos y más complejos, como podrían ser las “Pruebas de Integración”.)
1.4.1. Pruebas de Componente
También conocidas como pruebas de unidad, pruebas unitarias o pruebas de módulos.
Consiste en la prueba de los componentes más pequeños apenas son generados.
Este nivel de pruebas tan relacionado al código, tiene como objetivos validar:
Tipos de datos inconsistentes. Valores de inicialización y default incorrectos.· Correspondencia entre parámetros y argumentos en las· llamadas de funciones o módulos. Precisión en las funciones de cálculo.· Comparación entre tipos de datos diferentes.· Terminaciones de loop impropias o no existentes.· Variables de loop modificadas inapropiadamente.· Manejo de errores inadecuado o inentendible
1.4.2. Pruebas de Integración
Si todo funciona bien individualmente, ¿por qué dudan que funcione cuando se une?”.
Justamente ahí es donde está el punto. Es en la uníón de los componentes donde pueden perderse datos o al combinarse las funciones no dar el resultado esperado.
Pueden evaluarse: o Interfaces entre componentes o Interacciones con diferentes partes de un sistema (SO, sistema de archivos, hardware) o Interfaces entre sistemas
No tiene que ser visto como un nivel que se da siempre después del nivel de sistemas ya que: La prueba de integración de componentes se hace una vez que la prueba de componentes se llevó a cabo. O La prueba de integración de sistemas se hace una vez que la prueba de sistemas se llevó a cabo.
Pero, ¿cómo se hace la integración?
Puede ser de dos maneras:
La llamada big bang
Este tipo de integración es la que, una vez probados todos los componentes individuales, se combinan todos de una sola vez y se prueba como un todo.
Al no poder aislar las causas de esos errores, es decir, conocer en la integración de qué partes se originan, es difícil poderlos corregir. Si una vez corregidos aparecen otros, se entra en un proceso que pareciera interminable.
Incremental
Esta modalidad viene a dar solución a lo expuesto anteriormente: “la antítesis del enfoque Big Bang. Se van integrando y probando pequeños incrementos del programa, lo que hace más fácil encontrar la causa de las fallas y así corregir los defectos.
Dentro de esta modalidad de integración existen diferentes estrategias
Integración descendente o top-down:
los módulos se van integrando comenzando por el módulo de control principal al que se le pueden ir incorporando el resto de los módulos de dos maneras diferentes: primero-en-profundidad o primero-en anchura.
Integración ascendente o bottom-up
Se combinan primero los módulos de bajo nivel que juntos realicen alguna sub-función específica. La mayoría de las veces es necesario escribir un controlador que coordine la entrada y salida de los casos de pruebas para probar los grupo
¿Qué es un controlador o también llamado driver?
Si se tienen los módulos Y y Z listos pero el módulo de X no está listo y para probar los módulos Y y Z se necesita que el módulo X devuelva valores, entonces se escribe una pieza de código ficticio de X que devuelve valores para Y y Z. Esta pieza de código ficticio es lo que se llama controlador
Los controladores aportan el entorno al proceso del sistema o subsistema con el objeto de permitir o producir entradas y salidas del (subsistema) sistema o con el objeto de registrar datos.
Al reemplazar los controladores de prueba por componentes reales se pueden generar nuevos defectos tales como:
1.Pérdida de datos, manipulación errónea de datos o entradas erróneas. 2. Los componentes involucrados interpretan los datos de entrada de una manera distinta a los controladores. 3. Los datos son transferidos en un momento incorrecto: muy pronto, muy tarde, a una frecuencia distinta de la requerida.
1.4.3. Pruebas de Sistema
Las pruebas de sistema comienzan cuando una aplicación está funcionando como un todo. Tiene como objetivo determinar si el sistema en su globalidad opera satisfactoriamente (recuperación de fallas, seguridad y protección, stress, performance, otros).
se basan en la perspectiva de caja negra, es decir, sin considerar el cómo está hecho el programa, sino sólo considerar las funcionalidades solicitadas
1.4.4. Pruebas de Aceptación
Cuando las pruebas de sistema han sido completadas, comienzan las pruebas de aceptación. Para llegar a este nivel de pruebas también se ha dado el nivel de integración en cualquier punto anterior del proceso: cuando se han realizados las pruebas de sistemas, se hace la integración; o luego de las pruebas de componentes se hace la integración
Pasando a las pruebas de aceptación, el propósito de estas pruebas es darle al cliente o al usuario final la confianza y la seguridad que el sistema está listo.
Como la representación del usuario final o del cliente es vital en este nivel, se dice que son ellos quienes dirigen las pruebas de este nivel.
Este nivel de pruebas es popularmente conocido como los UAT10, o Prueba de aceptación de usuario
Pero el ISTQB (2011) plantea otros tipos de pruebas de aceptación:
Pruebas de aceptación de contrato:
se refiere a las pruebas que demuestran que los criterios de aceptación definidos en el contrato cliente-proveedor se han alcanzado.
Pruebas de aceptación operacional:
se refiere a lo que implica la operación de un sistema. Por ejemplo, las pruebas de backups y restore, chequeos periódicos de seguridad ante vulnerabilidades
Pruebas beta:
Pruebas realizadas por el usuario en ambientes de producción, de trabajo reales.
Pruebas alfa:
Pruebas realizadas por el usuario en ambientes de laboratorio