Pruebas de software: guía rápida

¿Qué son las pruebas?

La prueba es el proceso de evaluar un sistema o sus componentes con la intención de encontrar si satisface los requisitos especificados o no. En palabras simples, probar es ejecutar un sistema para identificar cualquier brecha, error o requisitos faltantes en contra de los requisitos reales.

De acuerdo con el estándar ANSI / IEEE 1059, las pruebas se pueden definir como: un proceso de análisis de un elemento de software para detectar las diferencias entre las condiciones existentes y requeridas (es decir, defectos / errores / errores) y para evaluar las características del elemento de software.

¿Quién realiza las pruebas?

Depende del proceso y de las partes interesadas asociadas del proyecto (s). En la industria de TI, las grandes empresas tienen un equipo con responsabilidades para evaluar el software desarrollado en el contexto de los requisitos dados. Además, los desarrolladores también realizan pruebas que se denominanUnit Testing. En la mayoría de los casos, los siguientes profesionales están involucrados en probar un sistema dentro de sus respectivas capacidades:

• Probador de software
• Desarrollador de software
• Jefe / Gerente de Proyecto
• Usuario final

Diferentes empresas tienen diferentes designaciones para las personas que prueban el software en función de su experiencia y conocimiento, como Software Tester, Software Quality Assurance Engineer, QA Analyst, etc.

No es posible probar el software en ningún momento durante su ciclo. Las siguientes dos secciones indican cuándo se deben iniciar las pruebas y cuándo finalizarlas durante el SDLC.

¿Cuándo comenzar a realizar la prueba?

Un inicio temprano de las pruebas reduce el costo y el tiempo para volver a trabajar y producir software libre de errores que se entrega al cliente. Sin embargo, en el ciclo de vida del desarrollo de software (SDLC), las pruebas se pueden iniciar desde la fase de recopilación de requisitos y continuar hasta la implementación del software.

También depende del modelo de desarrollo que se esté utilizando. Por ejemplo, en el modelo Waterfall, las pruebas formales se realizan en la fase de prueba; pero en el modelo incremental, las pruebas se realizan al final de cada incremento / iteración y toda la aplicación se prueba al final.

Las pruebas se realizan de diferentes formas en cada fase de SDLC:

• Durante la fase de recopilación de requisitos, el análisis y la verificación de los requisitos también se consideran pruebas.

• La revisión del diseño en la fase de diseño con la intención de mejorar el diseño también se considera una prueba.

• Las pruebas realizadas por un desarrollador al completar el código también se clasifican como pruebas.

¿Cuándo dejar de realizar la prueba?

Es difícil determinar cuándo detener las pruebas, ya que las pruebas son un proceso interminable y nadie puede afirmar que un software está probado al 100%. Se deben considerar los siguientes aspectos para detener el proceso de prueba:

• Plazos de prueba

• Finalización de la ejecución del caso de prueba

• Finalización de la cobertura funcional y de código hasta cierto punto

• La tasa de errores cae por debajo de un cierto nivel y no se identifican errores de alta prioridad

• Decisión de gestión

Verificación validación

Estos dos términos son muy confusos para la mayoría de las personas, que los usan indistintamente. La siguiente tabla destaca las diferencias entre verificación y validación.

No Señor.	Verificación	Validación
1	La verificación aborda la inquietud: "¿Lo está construyendo correctamente?"	La validación aborda la inquietud: "¿Está construyendo lo correcto?"
2	Asegura que el sistema de software cumpla con todas las funciones.	Asegura que las funcionalidades cumplan con el comportamiento previsto.
3	La verificación tiene lugar primero e incluye la verificación de documentación, código, etc.	La validación se produce después de la verificación e implica principalmente la verificación del producto en general.
4	Realizado por desarrolladores.	Realizado por probadores.
5	Tiene actividades estáticas, ya que incluye la recopilación de revisiones, recorridos e inspecciones para verificar un software.	Tiene actividades dinámicas, ya que incluye ejecutar el software contra los requisitos.
6	Es un proceso objetivo y no debería ser necesaria una decisión subjetiva para verificar un software.	Es un proceso subjetivo e implica decisiones subjetivas sobre qué tan bien funciona un software.

A continuación se muestran algunos de los mitos más comunes sobre las pruebas de software.

Mito 1: Las pruebas son demasiado caras

Reality- Hay un dicho, pague menos por las pruebas durante el desarrollo del software o pague más por el mantenimiento o la corrección más adelante. Las pruebas tempranas ahorran tiempo y costos en muchos aspectos; sin embargo, reducir el costo sin probar puede resultar en un diseño incorrecto de una aplicación de software que inutilice el producto.

Mito 2: Las pruebas requieren mucho tiempo

Reality- Durante las fases de SDLC, las pruebas nunca son un proceso que requiera mucho tiempo. Sin embargo, diagnosticar y corregir los errores identificados durante las pruebas adecuadas es una actividad productiva que requiere mucho tiempo.

Mito 3: solo se prueban productos completamente desarrollados

Reality- Sin duda, las pruebas dependen del código fuente, pero revisar los requisitos y desarrollar casos de prueba es independiente del código desarrollado. Sin embargo, el enfoque iterativo o incremental como modelo de ciclo de vida de desarrollo puede reducir la dependencia de las pruebas en el software completamente desarrollado.

Mito 4: la prueba completa es posible

Reality- Se convierte en un problema cuando un cliente o evaluador piensa que es posible realizar una prueba completa. Es posible que el equipo haya probado todas las rutas, pero nunca es posible que se realicen pruebas completas. Es posible que haya algunos escenarios que el equipo de prueba o el cliente nunca ejecuten durante el ciclo de vida del desarrollo de software y que se ejecuten una vez que se haya implementado el proyecto.

Mito 5: Un software probado no tiene errores

Reality - Este es un mito muy común en el que creen los clientes, los gerentes de proyecto y el equipo de administración. Nadie puede afirmar con absoluta certeza que una aplicación de software está 100% libre de errores, incluso si un probador con excelentes habilidades de prueba ha probado la aplicación .

Mito 6: Los defectos perdidos se deben a los probadores

Reality- No es un enfoque correcto culpar a los probadores de errores que permanecen en la aplicación incluso después de que se hayan realizado las pruebas. Este mito se relaciona con el tiempo, el costo y los requisitos que cambian las restricciones. Sin embargo, la estrategia de prueba también puede resultar en que el equipo de prueba pase por alto errores.

Mito 7: los probadores son responsables de la calidad del producto

Reality- Es una mala interpretación muy común que solo los probadores o el equipo de prueba deben ser responsables de la calidad del producto. Las responsabilidades de los probadores incluyen la identificación de errores para las partes interesadas y luego es su decisión si corregirán el error o lanzarán el software. Lanzar el software en ese momento ejerce más presión sobre los probadores, ya que serán culpados de cualquier error.

Mito 8: La automatización de pruebas debe usarse siempre que sea posible para reducir el tiempo

Reality- Sí, es cierto que Test Automation reduce el tiempo de prueba, pero no es posible iniciar la automatización de pruebas en ningún momento durante el desarrollo del software. El autómata de prueba debe iniciarse cuando el software se haya probado manualmente y sea estable hasta cierto punto. Además, la automatización de pruebas nunca se puede utilizar si los requisitos siguen cambiando.

Mito 9: Cualquiera puede probar una aplicación de software

Reality- Las personas ajenas a la industria de las TI piensan e incluso creen que cualquiera puede probar un software y probarlo no es un trabajo creativo. Sin embargo, los probadores saben muy bien que esto es un mito. Pensando en escenarios alternativos, intentar bloquear un software con la intención de explorar posibles errores no es posible para la persona que lo desarrolló.

Mito 10: La única tarea de un evaluador es encontrar errores

Reality- Encontrar errores en un software es tarea de los probadores, pero al mismo tiempo, son expertos en el dominio del software en particular. Los desarrolladores solo son responsables del componente o área específica que se les asigna, pero los evaluadores comprenden el funcionamiento general del software, cuáles son las dependencias y los impactos de un módulo en otro módulo.

Pruebas, garantía de calidad y control de calidad

La mayoría de las personas se confunden cuando se trata de precisar las diferencias entre Garantía de calidad, Control de calidad y Pruebas. Aunque están interrelacionadas y, en cierta medida, pueden considerarse como una misma actividad, existen puntos distintivos que las distinguen. La siguiente tabla enumera los puntos que diferencian QA, QC y Testing.

Seguro de calidad	Control de calidad	Pruebas
La garantía de calidad incluye actividades que garantizan la implementación de procesos, procedimientos y estándares en el contexto de la verificación del software desarrollado y los requisitos previstos.	Incluye actividades que aseguran la verificación de un software desarrollado con respecto a los requisitos documentados (o no en algunos casos).	Incluye actividades que garantizan la identificación de errores / errores / defectos en un software.
Se centra en los procesos y procedimientos en lugar de realizar pruebas reales en el sistema.	Se centra en las pruebas reales mediante la ejecución del software con el objetivo de identificar errores / defectos mediante la implementación de procedimientos y procesos.	Se centra en las pruebas reales.
Actividades orientadas a procesos.	Actividades orientadas al producto.	Actividades orientadas al producto.
Actividades preventivas.	Es un proceso correctivo.	Es un proceso preventivo.
Es un subconjunto del ciclo de vida de prueba de software (STLC).	El control de calidad se puede considerar como el subconjunto de garantía de calidad.	Las pruebas son el subconjunto del control de calidad.

Auditoría e Inspección

Audit- Es un proceso sistemático para determinar cómo se lleva a cabo el proceso de prueba real dentro de una organización o un equipo. Generalmente, es un examen independiente de los procesos involucrados durante la prueba de un software. Según IEEE, es una revisión de los procesos documentados que las organizaciones implementan y siguen. Los tipos de auditoría incluyen auditoría de cumplimiento legal, auditoría interna y auditoría de sistemas.

Inspection- Es una técnica formal que involucra revisiones técnicas formales o informales de cualquier artefacto identificando cualquier error o brecha. Según IEEE94, la inspección es una técnica de evaluación formal en la que los requisitos, diseños o códigos de software son examinados en detalle por una persona o un grupo que no sea el autor para detectar fallas, violaciones de los estándares de desarrollo y otros problemas.

Las reuniones formales de inspección pueden incluir los siguientes procesos: planificación, preparación general, reunión de inspección, reelaboración y seguimiento.

Prueba y depuración

Testing- Implica identificar error / error / defecto en un software sin corregirlo. Normalmente, los profesionales con experiencia en garantía de calidad están involucrados en la identificación de errores. La prueba se realiza en la fase de prueba.

Debugging- Implica identificar, aislar y solucionar los problemas / errores. Los desarrolladores que codifican el software realizan la depuración al encontrar un error en el código. La depuración es parte de las pruebas de caja blanca o pruebas unitarias. La depuración se puede realizar en la fase de desarrollo mientras se realizan pruebas unitarias o en fases mientras se corrigen los errores informados.

Muchas organizaciones de todo el mundo desarrollan e implementan diferentes estándares para mejorar las necesidades de calidad de su software. Este capítulo describe brevemente algunos de los estándares más utilizados relacionados con el aseguramiento de la calidad y las pruebas.

ISO / IEC 9126

Esta norma trata los siguientes aspectos para determinar la calidad de una aplicación de software:

• Modelo de calidad
• Métricas externas
• Métricas internas
• Métricas de calidad en uso

Este estándar presenta un conjunto de atributos de calidad para cualquier software como:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

Los atributos de calidad mencionados anteriormente se dividen en subfactores, que puede estudiar cuando estudie el estándar en detalle.

ISO / IEC 9241-11

La Parte 11 de esta norma trata sobre la medida en que un producto puede ser utilizado por usuarios específicos para lograr objetivos específicos con Efectividad, Eficiencia y Satisfacción en un contexto de uso específico.

Este estándar propuso un marco que describe los componentes de usabilidad y la relación entre ellos. En este estándar, la usabilidad se considera en términos de rendimiento y satisfacción del usuario. De acuerdo con ISO 9241-11, la usabilidad depende del contexto de uso y el nivel de usabilidad cambiará a medida que cambie el contexto.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 se conoce comúnmente como el estándar que proporciona las pautas para los requisitos y la evaluación de la calidad del software (SQuaRE). Este estándar ayuda a organizar y mejorar el proceso relacionado con los requisitos de calidad del software y sus evaluaciones. En realidad, ISO-25000 reemplaza las dos antiguas normas ISO, es decir, ISO-9126 e ISO-14598.

SQuaRE se divide en subpartes como:

• ISO 2500n - División de Gestión de la Calidad
• ISO 2501n - División de modelos de calidad
• ISO 2502n - División de medición de la calidad
• ISO 2503n - División de requisitos de calidad
• ISO 2504n - División de evaluación de la calidad

Los principales contenidos de SQuaRE son:

• Términos y definiciones
• Modelos de referencia
• Guía general
• Guías de división individuales
• Estándar relacionado con la ingeniería de requisitos (es decir, proceso de especificación, planificación, medición y evaluación)

ISO / IEC 12119

Este estándar se ocupa de los paquetes de software entregados al cliente. No se enfoca ni se ocupa del proceso de producción de los clientes. Los contenidos principales están relacionados con los siguientes elementos:

• Conjunto de requisitos para paquetes de software.
• Instrucciones para probar un paquete de software entregado con los requisitos especificados.

Diverso

Algunos de los otros estándares relacionados con los procesos de control de calidad y pruebas se mencionan a continuación:

No Señor	Estándar y descripción
1	IEEE 829 Un estándar para el formato de documentos utilizados en diferentes etapas de las pruebas de software.
2	IEEE 1061 Una metodología para establecer requisitos de calidad, identificar, implementar, analizar y validar el proceso y producto de métricas de calidad del software.
3	IEEE 1059 Guía para planes de verificación y validación de software.
4	IEEE 1008 Un estándar para pruebas unitarias.
5	IEEE 1012 Un estándar para la verificación y validación de software.
6	IEEE 1028 Un estándar para inspecciones de software.
7	IEEE 1044 Un estándar para la clasificación de anomalías de software.
8	IEEE 1044-1 Una guía para la clasificación de anomalías de software.
9	IEEE 830 Una guía para desarrollar especificaciones de requisitos del sistema.
10	IEEE 730 Un estándar para los planes de aseguramiento de la calidad del software.
11	IEEE 1061 Un estándar para métricas y metodología de calidad de software.
12	IEEE 12207 Un estándar para los procesos del ciclo de vida del software y los datos del ciclo de vida.
13	BS 7925-1 Un vocabulario de términos utilizados en las pruebas de software.
14	BS 7925-2 Un estándar para la prueba de componentes de software.

Esta sección describe los diferentes tipos de pruebas que se pueden usar para probar un software durante SDLC.

Prueba manual

La prueba manual incluye probar un software manualmente, es decir, sin usar ninguna herramienta automatizada o ningún script. En este tipo, el evaluador asume el rol de usuario final y prueba el software para identificar cualquier comportamiento o error inesperado. Hay diferentes etapas para las pruebas manuales, como pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación del usuario.

Los evaluadores utilizan planes de prueba, casos de prueba o escenarios de prueba para probar un software y garantizar la integridad de las pruebas. Las pruebas manuales también incluyen pruebas exploratorias, ya que los probadores exploran el software para identificar errores en él.

Pruebas de automatización

Las pruebas de automatización, que también se conocen como Automatización de pruebas, son cuando el evaluador escribe scripts y usa otro software para probar el producto. Este proceso implica la automatización de un proceso manual. Las pruebas de automatización se utilizan para volver a ejecutar los escenarios de prueba que se realizaron de forma manual, rápida y repetida.

Además de las pruebas de regresión, las pruebas de automatización también se utilizan para probar la aplicación desde el punto de vista de la carga, el rendimiento y el estrés. Aumenta la cobertura de la prueba, mejora la precisión y ahorra tiempo y dinero en comparación con las pruebas manuales.

¿Qué automatizar?

No es posible automatizar todo en un software. Las áreas en las que un usuario puede realizar transacciones, como el formulario de inicio de sesión o los formularios de registro, cualquier área donde una gran cantidad de usuarios pueda acceder al software simultáneamente debe automatizarse.

Además, todos los elementos de la GUI, las conexiones con las bases de datos, las validaciones de campo, etc. se pueden probar de manera eficiente automatizando el proceso manual.

¿Cuándo automatizar?

La automatización de pruebas se debe utilizar considerando los siguientes aspectos de un software:

• Proyectos grandes y críticos
• Proyectos que requieren probar las mismas áreas con frecuencia
• Los requisitos no cambian con frecuencia
• Acceder a la aplicación para carga y rendimiento con muchos usuarios virtuales
• Software estable con respecto a las pruebas manuales
• Disponibilidad de tiempo

¿Cómo automatizar?

La automatización se realiza mediante el uso de un lenguaje informático de apoyo como las secuencias de comandos VB y una aplicación de software automatizada. Hay muchas herramientas disponibles que se pueden utilizar para escribir scripts de automatización. Antes de mencionar las herramientas, identifiquemos el proceso que se puede utilizar para automatizar el proceso de prueba:

• Identificación de áreas dentro de un software para la automatización
• Selección de la herramienta adecuada para la automatización de pruebas
• Escribir guiones de prueba
• Desarrollo de trajes de prueba
• Ejecución de guiones
• Crear informes de resultados
• Identifique cualquier error potencial o problemas de rendimiento

Herramientas de prueba de software

Las siguientes herramientas se pueden utilizar para pruebas de automatización:

• HP Quick Test Professional
• Selenium
• Probador funcional IBM Rational
• SilkTest
• TestComplete
• Probando en cualquier lugar
• WinRunner
• LoadRunner
• Profesional de prueba de Visual Studio
• WATIR

Existen diferentes métodos que se pueden utilizar para las pruebas de software. Este capítulo describe brevemente los métodos disponibles.

Prueba de caja negra

La técnica de prueba sin tener ningún conocimiento del funcionamiento interior de la aplicación se denomina prueba de caja negra. El evaluador ignora la arquitectura del sistema y no tiene acceso al código fuente. Por lo general, mientras realiza una prueba de caja negra, un probador interactuará con la interfaz de usuario del sistema proporcionando entradas y examinando salidas sin saber cómo y dónde se trabajan las entradas.

La siguiente tabla enumera las ventajas y desventajas de las pruebas de caja negra.

Ventajas	Desventajas
Muy adecuado y eficiente para grandes segmentos de código.	Cobertura limitada, ya que solo se realiza un número seleccionado de escenarios de prueba.
No se requiere acceso con código.	Pruebas ineficientes, debido al hecho de que el evaluador solo tiene conocimientos limitados sobre una aplicación.
Separa claramente la perspectiva del usuario de la perspectiva del desarrollador a través de roles claramente definidos.	Cobertura ciega, ya que el probador no puede apuntar a segmentos de código específicos o áreas propensas a errores.
Un gran número de probadores moderadamente capacitados pueden probar la aplicación sin conocimientos de implementación, lenguaje de programación o sistemas operativos.	Los casos de prueba son difíciles de diseñar.

Prueba de caja blanca

Las pruebas de caja blanca son la investigación detallada de la lógica interna y la estructura del código. La prueba de caja blanca también se llamaglass testing o open-box testing. En orden para realizarwhite-box Al probar una aplicación, un evaluador necesita conocer el funcionamiento interno del código.

El evaluador debe echar un vistazo dentro del código fuente y averiguar qué unidad / parte del código se comporta de manera inapropiada.

La siguiente tabla enumera las ventajas y desventajas de las pruebas de caja blanca.

Ventajas	Desventajas
A medida que el evaluador tiene conocimiento del código fuente, resulta muy fácil averiguar qué tipo de datos pueden ayudar a probar la aplicación de manera eficaz.	Debido al hecho de que se necesita un probador calificado para realizar las pruebas de caja blanca, los costos aumentan.
Ayuda a optimizar el código.	A veces es imposible mirar en cada rincón y esquina para descubrir errores ocultos que pueden crear problemas, ya que muchos caminos no se probarán.
Se pueden eliminar líneas adicionales de código que pueden provocar defectos ocultos.	Es difícil mantener las pruebas de caja blanca, ya que requiere herramientas especializadas como analizadores de código y herramientas de depuración.
Debido al conocimiento del probador sobre el código, se alcanza la máxima cobertura durante la escritura del escenario de prueba.

Prueba de caja gris

La prueba de caja gris es una técnica para probar la aplicación teniendo un conocimiento limitado del funcionamiento interno de una aplicación. En las pruebas de software, la frase cuanto más sepa, mejor tiene mucho peso al probar una aplicación.

Dominar el dominio de un sistema siempre le da al evaluador una ventaja sobre alguien con un conocimiento limitado del dominio. A diferencia de las pruebas de caja negra, donde el evaluador solo prueba la interfaz de usuario de la aplicación; en las pruebas de caja gris, el evaluador tiene acceso a los documentos de diseño y la base de datos. Con este conocimiento, un evaluador puede preparar mejores datos de prueba y escenarios de prueba mientras hace un plan de prueba.

Ventajas	Desventajas
Ofrece beneficios combinados de las pruebas de caja negra y caja blanca siempre que sea posible.	Dado que el acceso al código fuente no está disponible, la capacidad de revisar el código y la cobertura de prueba es limitada.
Los probadores de caja gris no se basan en el código fuente; en su lugar, se basan en la definición de la interfaz y las especificaciones funcionales.	Las pruebas pueden ser redundantes si el diseñador de software ya ha ejecutado un caso de prueba.
Basado en la información limitada disponible, un probador de caja gris puede diseñar escenarios de prueba excelentes, especialmente en torno a protocolos de comunicación y manejo de tipos de datos.	Probar cada flujo de entrada posible no es realista porque tomaría una cantidad de tiempo irrazonable; por lo tanto, muchas rutas de programas no se probarán.
La prueba se realiza desde el punto de vista del usuario y no del diseñador.

Una comparación de métodos de prueba

La siguiente tabla enumera los puntos que diferencian las pruebas de caja negra, las pruebas de caja gris y las pruebas de caja blanca.

Prueba de caja negra	Prueba de caja gris	Prueba de caja blanca
No es necesario conocer el funcionamiento interno de una aplicación.	El probador tiene un conocimiento limitado del funcionamiento interno de la aplicación.	Tester tiene pleno conocimiento del funcionamiento interno de la aplicación.
También conocido como prueba de caja cerrada, prueba basada en datos o prueba funcional.	También conocido como prueba translúcida, ya que el evaluador tiene un conocimiento limitado del interior de la aplicación.	También conocido como prueba de caja transparente, prueba estructural o prueba basada en código.
Realizado por usuarios finales y también por probadores y desarrolladores.	Realizado por usuarios finales y también por probadores y desarrolladores.	Normalmente lo hacen probadores y desarrolladores.
Las pruebas se basan en expectativas externas: se desconoce el comportamiento interno de la aplicación.	Las pruebas se realizan sobre la base de diagramas de flujo de datos y diagramas de bases de datos de alto nivel.	El funcionamiento interno es completamente conocido y el probador puede diseñar los datos de prueba en consecuencia.
Es exhaustivo y el que menos tiempo requiere.	En parte lento y exhaustivo.	El tipo de prueba más exhaustivo y que requiere más tiempo.
No apto para pruebas de algoritmos.	No apto para pruebas de algoritmos.	Adecuado para pruebas de algoritmos.
Esto solo se puede hacer mediante el método de prueba y error.	Los dominios de datos y los límites internos se pueden probar, si se conocen.	Los dominios de datos y los límites internos se pueden probar mejor.

Hay diferentes niveles durante el proceso de prueba. En este capítulo, se proporciona una breve descripción sobre estos niveles.

Los niveles de prueba incluyen diferentes metodologías que se pueden utilizar al realizar pruebas de software. Los principales niveles de prueba de software son:

• Pruebas funcionales

• Pruebas no funcionales

Pruebas funcionales

Este es un tipo de prueba de caja negra que se basa en las especificaciones del software que se va a probar. La aplicación se prueba proporcionando información y luego se examinan los resultados que deben ajustarse a la funcionalidad para la que fue diseñada. Las pruebas funcionales de un software se realizan en un sistema completo e integrado para evaluar el cumplimiento del sistema con sus requisitos especificados.

Hay cinco pasos involucrados al probar la funcionalidad de una aplicación.

Pasos	Descripción
yo	La determinación de la funcionalidad que la aplicación deseada debe realizar.
II	La creación de datos de prueba basados ​​en las especificaciones de la aplicación.
III	La salida basada en los datos de prueba y las especificaciones de la aplicación.
IV	La redacción de escenarios de prueba y la ejecución de casos de prueba.
V	La comparación de los resultados reales y esperados en función de los casos de prueba ejecutados.

Una práctica de prueba eficaz verá los pasos anteriores aplicados a las políticas de prueba de cada organización y, por lo tanto, se asegurará de que la organización mantenga los estándares más estrictos en lo que respecta a la calidad del software.

Examen de la unidad

Los desarrolladores realizan este tipo de prueba antes de que la configuración se entregue al equipo de pruebas para ejecutar formalmente los casos de prueba. Las pruebas unitarias son realizadas por los desarrolladores respectivos en las unidades individuales de áreas asignadas al código fuente. Los desarrolladores utilizan datos de prueba que son diferentes de los datos de prueba del equipo de garantía de calidad.

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas en términos de requisitos y funcionalidad.

Limitaciones de las pruebas unitarias

Las pruebas no pueden detectar todos y cada uno de los errores de una aplicación. Es imposible evaluar cada ruta de ejecución en cada aplicación de software. Lo mismo ocurre con las pruebas unitarias.

Existe un límite en la cantidad de escenarios y datos de prueba que un desarrollador puede usar para verificar un código fuente. Después de haber agotado todas las opciones, no queda más remedio que detener las pruebas unitarias y fusionar el segmento de código con otras unidades.

Pruebas de integración

La prueba de integración se define como la prueba de partes combinadas de una aplicación para determinar si funcionan correctamente. Las pruebas de integración se pueden realizar de dos formas: pruebas de integración ascendente y pruebas de integración descendente.

No Señor.	Método de prueba de integración
1	Bottom-up integration Esta prueba comienza con pruebas unitarias, seguidas de pruebas de combinaciones de unidades de nivel progresivamente superior llamadas módulos o compilaciones.
2	Top-down integration En esta prueba, los módulos de nivel más alto se prueban primero y progresivamente, los módulos de nivel inferior se prueban a partir de entonces.

En un entorno de desarrollo de software integral, las pruebas de abajo hacia arriba generalmente se realizan primero, seguidas de las pruebas de arriba hacia abajo. El proceso concluye con múltiples pruebas de la aplicación completa, preferiblemente en escenarios diseñados para imitar situaciones reales.

Prueba del sistema

La prueba del sistema prueba el sistema en su totalidad. Una vez que todos los componentes están integrados, la aplicación en su conjunto se prueba rigurosamente para comprobar que cumple con los estándares de calidad especificados. Este tipo de prueba es realizada por un equipo de pruebas especializado.

La prueba del sistema es importante por las siguientes razones:

• La prueba del sistema es el primer paso en el ciclo de vida del desarrollo de software, donde la aplicación se prueba como un todo.

• La aplicación se prueba minuciosamente para verificar que cumple con las especificaciones técnicas y funcionales.

• La aplicación se prueba en un entorno muy cercano al entorno de producción donde se implementará la aplicación.

• Las pruebas del sistema nos permiten probar, verificar y validar tanto los requisitos comerciales como la arquitectura de la aplicación.

Pruebas de regresión

Siempre que se realiza un cambio en una aplicación de software, es muy posible que otras áreas dentro de la aplicación se hayan visto afectadas por este cambio. La prueba de regresión se realiza para verificar que un error corregido no haya resultado en otra funcionalidad o violación de reglas comerciales. La intención de las pruebas de regresión es garantizar que un cambio, como la corrección de un error, no dé lugar a que se descubra otro error en la aplicación.

La prueba de regresión es importante por las siguientes razones:

• Minimice las brechas en las pruebas cuando se deba probar una aplicación con cambios realizados.

• Probar los nuevos cambios para verificar que los cambios realizados no afectaron a ninguna otra área de la aplicación.

• Mitiga los riesgos cuando se realizan pruebas de regresión en la aplicación.

• La cobertura de la prueba se incrementa sin comprometer los plazos.

• Incrementar la velocidad de comercialización del producto.

Test de aceptación

Este es posiblemente el tipo de prueba más importante, ya que lo lleva a cabo el equipo de control de calidad, que evaluará si la aplicación cumple con las especificaciones previstas y satisface los requisitos del cliente. El equipo de control de calidad tendrá un conjunto de escenarios y casos de prueba escritos previamente que se utilizarán para probar la aplicación.

Se compartirán más ideas sobre la aplicación y se pueden realizar más pruebas para evaluar su precisión y las razones por las que se inició el proyecto. Las pruebas de aceptación no solo están destinadas a señalar errores de ortografía simples, errores cosméticos o lagunas en la interfaz, sino también a señalar cualquier error en la aplicación que resultará en fallas del sistema o errores importantes en la aplicación.

Al realizar pruebas de aceptación en una aplicación, el equipo de pruebas reducirá el rendimiento de la aplicación en producción. También existen requisitos legales y contractuales para la aceptación del sistema.

Prueba alfa

Esta prueba es la primera etapa de la prueba y se realizará entre los equipos (desarrolladores y equipos de control de calidad). Las pruebas unitarias, las pruebas de integración y las pruebas del sistema cuando se combinan juntas se conocen como pruebas alfa. Durante esta fase, se probarán los siguientes aspectos en la aplicación:

• Faltas de ortografía

• Enlaces rotos

• Direcciones nubladas

• La aplicación se probará en máquinas con la especificación más baja para probar los tiempos de carga y cualquier problema de latencia.

Prueba Beta

Esta prueba se realiza después de que la prueba alfa se haya realizado con éxito. En las pruebas beta, una muestra de la audiencia prevista prueba la aplicación. La prueba beta también se conoce comopre-release testing. Las versiones de prueba beta del software se distribuyen idealmente a una amplia audiencia en la Web, en parte para darle al programa una prueba del "mundo real" y en parte para proporcionar una vista previa de la próxima versión. En esta fase, la audiencia probará lo siguiente:

• Los usuarios instalarán, ejecutarán la aplicación y enviarán sus comentarios al equipo del proyecto.

• Errores tipográficos, flujo de aplicaciones confuso e incluso bloqueos.

• Al recibir los comentarios, el equipo del proyecto puede solucionar los problemas antes de lanzar el software a los usuarios reales.

• Cuantos más problemas solucione que resuelvan problemas reales de los usuarios, mayor será la calidad de su aplicación.

• Tener una aplicación de mayor calidad cuando la publiques al público en general aumentará la satisfacción del cliente.

Pruebas no funcionales

Esta sección se basa en probar una aplicación a partir de sus atributos no funcionales. Las pruebas no funcionales implican probar un software a partir de requisitos que son de naturaleza no funcional pero importantes, como el rendimiento, la seguridad, la interfaz de usuario, etc.

Algunos de los tipos de pruebas no funcionales importantes y de uso común se analizan a continuación.

Pruebas de rendimiento

Se utiliza principalmente para identificar cuellos de botella o problemas de rendimiento en lugar de encontrar errores en un software. Hay diferentes causas que contribuyen a reducir el rendimiento de un software:

• Retraso de la red

• Procesamiento del lado del cliente

• Procesamiento de transacciones de base de datos

• Equilibrio de carga entre servidores

• Representación de datos

Las pruebas de rendimiento se consideran uno de los tipos de pruebas importantes y obligatorias en términos de los siguientes aspectos:

• Velocidad (es decir, tiempo de respuesta, procesamiento de datos y acceso)

• Capacity

• Stability

• Scalability

Las pruebas de rendimiento pueden ser cualitativas o cuantitativas y se pueden dividir en diferentes subtipos, como Load testing y Stress testing.

Prueba de carga

Es un proceso de prueba del comportamiento de un software aplicando la carga máxima en términos de acceso de software y manipulación de grandes datos de entrada. Puede realizarse tanto en condiciones de carga normal como máxima. Este tipo de prueba identifica la capacidad máxima del software y su comportamiento en horas pico.

La mayoría de las veces, las pruebas de carga se realizan con la ayuda de herramientas automatizadas como Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Los usuarios virtuales (VUsers) se definen en la herramienta de prueba automatizada y el script se ejecuta para verificar la prueba de carga del software. El número de usuarios se puede aumentar o disminuir de forma simultánea o incremental según los requisitos.

Pruebas de estrés

Las pruebas de estrés incluyen probar el comportamiento de un software en condiciones anormales. Por ejemplo, puede incluir quitar algunos recursos o aplicar una carga más allá del límite de carga real.

El objetivo de las pruebas de estrés es probar el software aplicando la carga al sistema y asumiendo los recursos utilizados por el software para identificar el punto de ruptura. Esta prueba se puede realizar probando diferentes escenarios como:

• Apagar o reiniciar los puertos de red al azar

• Activar o desactivar la base de datos

• Ejecutando diferentes procesos que consumen recursos como CPU, memoria, servidor, etc.

Pruebas de usabilidad

La prueba de usabilidad es una técnica de caja negra y se utiliza para identificar cualquier error (s) y mejoras en el software al observar a los usuarios a través de su uso y operación.

Según Nielsen, la usabilidad se puede definir en términos de cinco factores, es decir, eficiencia de uso, capacidad de aprendizaje, capacidad de memoria, errores / seguridad y satisfacción. Según él, la usabilidad de un producto será buena y el sistema será utilizable si posee los factores anteriores.

Nigel Bevan y Macleod consideraron que la usabilidad es el requisito de calidad que se puede medir como resultado de las interacciones con un sistema informático. Este requisito puede cumplirse y el usuario final estará satisfecho si los objetivos previstos se logran de manera eficaz con el uso de los recursos adecuados.

Molich en 2000 declaró que un sistema fácil de usar debe cumplir los siguientes cinco objetivos, es decir, fácil de aprender, fácil de recordar, eficiente de usar, satisfactorio de usar y fácil de entender.

Además de las diferentes definiciones de usabilidad, existen algunos estándares y modelos y métodos de calidad que definen la usabilidad en forma de atributos y sub-atributos como ISO-9126, ISO-9241-11, ISO-13407 e IEEE std. 610.12, etc.

UI vs pruebas de usabilidad

La prueba de IU implica probar la interfaz gráfica de usuario del software. Las pruebas de IU aseguran que la GUI funcione de acuerdo con los requisitos y se pruebe en términos de color, alineación, tamaño y otras propiedades.

Por otro lado, las pruebas de usabilidad aseguran una GUI buena y fácil de usar que se puede manejar fácilmente. Las pruebas de IU se pueden considerar como una subparte de las pruebas de usabilidad.

Pruebas de seguridad

Las pruebas de seguridad implican probar un software para identificar fallas y brechas desde el punto de vista de la seguridad y la vulnerabilidad. A continuación se enumeran los aspectos principales que deben garantizar las pruebas de seguridad:

• Confidentiality

• Integrity

• Authentication

• Availability

• Authorization

• Non-repudiation

• El software está protegido contra vulnerabilidades conocidas y desconocidas

• Los datos del software están seguros

• El software cumple con todas las normas de seguridad.

• Comprobación y validación de entrada

• Ataques de inserción SQL

• Defectos de inyección

• Problemas de gestión de sesiones

• Ataques de secuencias de comandos entre sitios

• El búfer desborda vulnerabilidades

• Ataques transversales de directorio

Prueba de portabilidad

Las pruebas de portabilidad incluyen probar un software con el objetivo de garantizar su reutilización y que también se pueda mover desde otro software. Las siguientes son las estrategias que se pueden utilizar para las pruebas de portabilidad:

• Transferir un software instalado de una computadora a otra.

• Construyendo ejecutable (.exe) para ejecutar el software en diferentes plataformas.

Las pruebas de portabilidad se pueden considerar como una de las subpartes de las pruebas del sistema, ya que este tipo de prueba incluye pruebas generales de un software con respecto a su uso en diferentes entornos. El hardware, los sistemas operativos y los navegadores de la computadora son el foco principal de las pruebas de portabilidad. Algunas de las condiciones previas para las pruebas de portabilidad son las siguientes:

• El software debe diseñarse y codificarse teniendo en cuenta los requisitos de portabilidad.

• Se han realizado pruebas unitarias en los componentes asociados.

• Se han realizado pruebas de integración.

• Se ha establecido un entorno de prueba.

La documentación de prueba implica la documentación de los artefactos que deben desarrollarse antes o durante la prueba del software.

La documentación para las pruebas de software ayuda a estimar el esfuerzo de prueba requerido, la cobertura de la prueba, el seguimiento / seguimiento de los requisitos, etc. Esta sección describe algunos de los artefactos documentados de uso común relacionados con las pruebas de software, tales como:

• Plan de prueba
• Escenario de prueba
• Caso de prueba
• Matriz de trazabilidad

Plan de prueba

Un plan de prueba describe la estrategia que se utilizará para probar una aplicación, los recursos que se utilizarán, el entorno de prueba en el que se realizarán las pruebas y las limitaciones de las pruebas y el calendario de actividades de prueba. Normalmente, el líder del equipo de control de calidad será responsable de redactar un plan de prueba.

Un plan de prueba incluye lo siguiente:

• Introducción al documento del plan de prueba
• Supuestos al probar la aplicación
• Lista de casos de prueba incluidos en la prueba de la aplicación
• Lista de características a probar
• Qué tipo de enfoque utilizar al probar el software
• Lista de entregables que deben probarse
• Los recursos asignados para probar la aplicación
• Cualquier riesgo involucrado durante el proceso de prueba.
• Un cronograma de tareas e hitos a alcanzar.

Escenario de prueba

Es una declaración de una línea que notifica qué área de la aplicación se probará. Los escenarios de prueba se utilizan para garantizar que todos los flujos de proceso se prueben de un extremo a otro. Un área particular de una aplicación puede tener desde un escenario de prueba hasta unos cientos de escenarios, dependiendo de la magnitud y complejidad de la aplicación.

Los términos 'escenario de prueba' y 'casos de prueba' se usan indistintamente, sin embargo, un escenario de prueba tiene varios pasos, mientras que un caso de prueba tiene un solo paso. Visto desde esta perspectiva, los escenarios de prueba son casos de prueba, pero incluyen varios casos de prueba y la secuencia en la que deben ejecutarse. Aparte de esto, cada prueba depende del resultado de la prueba anterior.

Caso de prueba

Los casos de prueba implican un conjunto de pasos, condiciones y entradas que se pueden usar mientras se realizan tareas de prueba. El objetivo principal de esta actividad es asegurar si un software pasa o falla en términos de su funcionalidad y otros aspectos. Hay muchos tipos de casos de prueba, como casos de prueba funcionales, negativos, de error, lógicos, casos de prueba físicos, casos de prueba de IU, etc.

Además, los casos de prueba se escriben para realizar un seguimiento de la cobertura de prueba de un software. Generalmente, no hay plantillas formales que se puedan utilizar durante la redacción de casos de prueba. Sin embargo, los siguientes componentes siempre están disponibles e incluidos en cada caso de prueba:

• ID de caso de prueba
• Módulo de producto
• Version del producto
• Revisión histórica
• Purpose
• Assumptions
• Pre-conditions
• Steps
• Gastos esperados
• Resultado real
• Post-conditions

Muchos casos de prueba pueden derivarse de un único escenario de prueba. Además, a veces se escriben varios casos de prueba para un solo software que se conocen colectivamente como conjuntos de pruebas.

Matriz de trazabilidad

La Matriz de trazabilidad (también conocida como Matriz de trazabilidad de requisitos - RTM) es una tabla que se utiliza para rastrear los requisitos durante el ciclo de vida del desarrollo de software. Se puede utilizar para el seguimiento hacia adelante (es decir, de los requisitos al diseño o la codificación) o hacia atrás (es decir, de la codificación a los requisitos). Hay muchas plantillas definidas por el usuario para RTM.

Cada requisito en el documento RTM está vinculado con su caso de prueba asociado para que las pruebas se puedan realizar según los requisitos mencionados. Además, Bug ID también se incluye y se vincula con sus requisitos asociados y caso de prueba. Los principales objetivos de esta matriz son:

• Asegúrese de que el software se desarrolle según los requisitos mencionados.
• Ayuda a encontrar la causa raíz de cualquier error.
• Ayuda a rastrear los documentos desarrollados durante las diferentes fases de SDLC.

Estimar los esfuerzos necesarios para las pruebas es una de las tareas principales e importantes de SDLC. La estimación correcta ayuda a probar el software con la máxima cobertura. Esta sección describe algunas de las técnicas que pueden resultar útiles para estimar los esfuerzos necesarios para realizar las pruebas.

Análisis de puntos funcionales

Este método se basa en el análisis de los requisitos funcionales del usuario del software con las siguientes categorías:

• Outputs
• Inquiries
• Inputs
• Archivos internos
• Archivos externos

Análisis de puntos de prueba

Este proceso de estimación se utiliza para el análisis de puntos funcionales para pruebas de aceptación o de caja negra. Los elementos principales de este método son: Tamaño, Productividad, Estrategia, Interfaz, Complejidad y Uniformidad.

Método Mark-II

Es un método de estimación utilizado para analizar y medir la estimación basada en la vista funcional del usuario final. El procedimiento para el método Mark-II es el siguiente:

• Determinar el punto de vista
• Objeto y tipo de recuento
• Definir el límite de la cuenta
• Identificar las transacciones lógicas
• Identificar y categorizar tipos de entidades de datos
• Cuente los tipos de elementos de datos de entrada
• Cuente el tamaño funcional

Diverso

Puede utilizar otras técnicas de estimación populares como:

• Técnica Delphi
• Estimación basada en analogías
• Estimación basada en enumeración de casos de prueba
• Estimación basada en tareas (actividades)
• Método IFPUG