¿Es posible producir software 100% libre de errores? ¿Por qué?

Afirmar que hay software 100% libre de fallos es totalmente falso

Falta de comunicación entre los equipos de desarrollo y calidad
Complejidad del software
Errores en la programación
Presiones de tiempo
La implantación de nuevas funcionalidades en fases avanzadas del ciclo de vida del producto
Las tools de desarrollo de software
Cambios en los requerimientos
Código pobremente documentado

¿Cuál es el verdadero propósito de las pruebas?

Los casos de prueba son clases o módulos que disponen de métodos para probar los métodos
de una clase o módulo concreta/o. Así, para cada clase que quisiéramos probar definiríamos su
correspondiente clase de caso de prueba.

¿Cuáles son los principales objetivos de las pruebas?

Eliminar el máximo número de errores posible

¿Validar los requisitos es lo mismo que verificar que el software funciona correctamente?

VALIDAR es dar por bueno.

VERIFICAR es comprobar que el software funciona correctamente

¿Qué es la cobertura de unas pruebas? ¿Cobertura de 100% significa que se han privado
todas las posibilidades de ejecución?

Cobertura (http://cobertura.sourceforge.net/) es una herramienta libre (GPL) escrita en Java, que

nos permite comprobar el porcentaje de código al que accedemos desde los test. Es decir,
Cobertura nos permite saber cuánto código estamos realmente probando con nuestros test. No
se puede realizar una cobertura al 100%.

¿Qué es la deuda técnica de pruebas?

La deuda técnica, también conocido como deuda de diseño o deuda de código, es un concepto
de desarrollo de software que hace referencia a los costos de un esfuerzo adicional causado por
la elección de un desarrollo sencillo y apresurado en lugar de usar un mejor enfoque que
tomaría más tiempo.

Eficacia de una prueba para encontrar errores. Eficiencia de una prueba que encuentra errores
con coste mínimo.

¿Qué es una característica desde el punto de vista de las pruebas?

¿Qué es un Subject Under Test SUT?

El Sistema bajo prueba (SUT) desde una perspectiva de Prueba de unidad representa a todos los
actores (es decir, una o más clases) en una prueba que no son simulaciones o resguardos.
¿Qué es un Depended-on Component DOC?

Una clase individual o un componente de grano grande del que depende el sistema sometido a
prueba (SUT). La dependencia suele ser una de delegaciones a través de llamadas a métodos. En
la automatización de pruebas, es principalmente de interés que necesitemos poder examinar y
controlar sus interacciones con el SUT para obtener una cobertura de prueba completa.

¿Qué es un Test Case?

Un caso de prueba o test case es, en ingeniería del software, un conjunto de condiciones o
variables bajo las cuales un analista determinará si una aplicación, un sistema software (software
system), o una característica de éstos es parcial o completamente satisfactoria.

¿Qué es un falso positivo o falsa prueba fallida?

Falso positivo = pasar las pruebas cuando no deberías haberlas pasado

Falsa prueba fallida = error al realizar las pruebas que no debería de haber dado error

Tipos de pruebas según el SUT: Pruebas de Aceptación - Pruebas del Sistema - Pruebas de
Integración - Pruebas de Componente - Pruebas Unitarias

Pruebas de aceptación:

En ingeniería de software y pruebas de software, las pruebas de aceptación (User Acceptance

Testing, UAT) pertenecen a las últimas etapas previas a la liberación en firme de versiones
nuevas a fin de determinar si cumplen con las necesidades y/o requerimientos de las empresas y
sus usuarios.1 Al finalizar las pruebas automatizadas, que garantizan los requisitos tecnológicos
del diseño inicial, se pasa a las pruebas manuales.

Pruebas de sistema:

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y

recuperación.

Pruebas de integración:

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del
desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que prueban es
que todos los elementos unitarios que componen el software, funcionan juntos correctamente
probándolos en grupo. Se centra principalmente en probar la comunicación entre los
componentes y sus comunicaciones ya sea hardware o software.

Pruebas de componente:

La prueba de componente también llamada prueba unitaria es por definición la prueba que se
lleva a cabo luego de haber construido el componente.
Pruebas unitarias:

En programación, una prueba unitaria es una forma de comprobar el correcto funcionamiento

de una unidad de código. Por ejemplo en diseño estructurado o en diseño funcional una
función o un procedimiento, en diseño orientado a objetos una clase. Esto sirve para asegurar
que cada unidad funcione correctamente y eficientemente por separado. Además de verificar
que el código hace lo que tiene que hacer, verificamos que sea correcto el nombre, los nombres
y tipos de los parámetros, el tipo de lo que se devuelve, que si el estado inicial es válido
entonces el estado final es válido

Tipos de pruebas según la característica: Pruebas Funcionales - Pruebas No Funcionales.

Pruebas funcionales:

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las
funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen
mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las
que cuenta el paquete informático. Dicho de otro modo son pruebas específicas, concretas y
exhaustivas para probar y validar que el software

Pruebas no funcionales:

Las pruebas no funcionales se enfocan en validar un sistema o aplicación por medio de sus
requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por medio de
comportamientos específicos.

Tipos de pruebas según el modo de ejecución: Pruebas Manuales - Pruebas automáticas.

Pruebas automáticas:

La automatización de pruebas consiste en la utilización de herramientas de software como Q-

Matic y ThunderTest herramientas propias de Q-Vision, por medio del modelo CAT (Codeless
Automated Testing), permitiendo la generación de scripts sin la necesidad de codificar
optimizando los tiempos de ejecución.

Tipos de pruebas según la táctica: Pruebas estáticas - Pruebas dinámicas de estado o caja
negra - Pruebas dinámicas de comportamiento o caja blanca.

Pruebas de caja negra:

Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo,
charter o sección específica de un software, es decir, es una manera de encontrar casos
específicos en ese modulo que atiendan a su especificación

Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales dedicadas a “mirar” en
el exterior de lo que se prueba. Estas pruebas se denominan de varias formas, pruebas de caja
“opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y
muy variados. En Globe contamos con un grupo experto en la realización de pruebas de caja
negra que solventará tus problemas a nivel de datos externos.
Pruebas de caja blanca:

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas
estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está
fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de
entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse
de que se devuelven los valores de salida adecuados.

Al estar basadas en una implementación concreta, si esta se modifica, por regla general las
pruebas también deberán rediseñarse.