Una guía completa de pruebas no funcionales para principiantes

complete non functional testing guide

Una guía completa para las pruebas no funcionales: su propósito, tipos, herramienta, casos de prueba con ejemplos

¿Qué son las pruebas no funcionales?

Las pruebas no funcionales se realizan para verificar el requisito no funcional de la aplicación como rendimiento, usabilidad, etc.

Verifica si el comportamiento del sistema es el requerido o no. Cubre todos los aspectos que no están cubiertos en prueba funcional . En nuestras pruebas diarias, se presta mucha atención a las pruebas funcionales y los requisitos funcionales.

Los clientes también están interesados ​​en cumplir con los requisitos funcionales que están directamente relacionados con la funcionalidad de una aplicación. Pero en la fase real, es decir, cuando se realiza una prueba funcional, el software entra en el mercado y es utilizado por los usuarios finales reales, y hay posibilidades de que se enfrente a algunos problemas relacionados con el rendimiento.

Estos problemas no están relacionados con la funcionalidad del sistema, pero pueden afectar la experiencia del usuario de manera negativa. Por lo tanto, es importante que el software o la aplicación se prueben también para los requisitos no funcionales para evitar una experiencia negativa del cliente.

Las pruebas se clasifican ampliamente en dos tipos:

• Pruebas funcionales
• Pruebas no funcionales

Lo que vas a aprender:

• Importancia
• Objetivo
• Ejemplo
• Ventajas
• ¿Cómo capturar los requisitos no funcionales?
  • # 1) Historias técnicas / de usuarios
  • # 2) Criterios de aceptación
  • # 3) en artefactos
• Diferencia en requisitos funcionales y no funcionales
• ¿Se trata de una prueba de caja negra o caja blanca?
• Lista de verificación de casos de prueba no funcionales
  • Lista de verificación para pruebas de rendimiento
  • Lista de verificación para pruebas de seguridad
  • Lista de verificación para pruebas de documentación
• Documento de enfoque
  • Alcance de prueba
  • Métricas de prueba
  • Herramientas de prueba
  • Fechas clave y entregables
• Tipos de pruebas no funcionales
• Herramientas de prueba no funcionales
  • # 1) Casos de prueba de pruebas de usabilidad
  • # 2) Casos de prueba de pruebas de rendimiento
  • # 3) Casos de prueba de pruebas de seguridad
• Conclusión
• Lectura recomendada

Importancia

Esta prueba perdió la debida atención considerando que no está afectando la funcionalidad del sistema.

Los requisitos no funcionales tampoco recibieron la debida atención en los ciclos de prueba anteriores. Sin embargo, esto ha cambiado ahora. Las pruebas no funcionales son ahora más importantes, ya que consideran todos los problemas de seguridad y rendimiento de las aplicaciones en estos días.

Esta prueba tiene un mayor impacto en las aplicaciones cuando se trata del rendimiento de la aplicación con un alto tráfico de usuarios. Esta prueba garantiza que su aplicación sea estable y pueda manejar cargas en condiciones extremas.

Como el propio nombre lo indica, esta prueba se concentra en el aspecto no funcional de la aplicación. Entonces, ¿cuáles son los aspectos no funcionales? ¿O debería decir cuáles son las características que no están relacionadas con la funcionalidad de la aplicación?

Bueno, aquí están las respuestas a esas:

• ¿Cómo funciona la aplicación en circunstancias normales?
• ¿Cómo se comporta la aplicación cuando demasiados usuarios inician sesión al mismo tiempo?
• ¿Puede la aplicación manejar el estrés?
• ¿Qué tan segura es la aplicación?
• ¿Puede la aplicación recuperarse de algún desastre?
• ¿Puede la aplicación comportarse de la misma manera en un entorno o sistema operativo diferente?
• ¿Qué tan fácil es portar la aplicación en un sistema diferente?
• ¿Los documentos o el manual de usuario que se proporcionan con la aplicación son fáciles de entender?

La lista continúa. Pero el punto aquí es que, ¿estas características no contribuyen a la calidad de la aplicación? La respuesta es sí. Estas características son igualmente importantes.

Imagine que una aplicación cumple perfectamente con todos los requisitos del usuario, pero algún usuario no autorizado fácilmente descifra los datos ingresados ​​por el usuario en la aplicación, o la aplicación muere cuando se cargan más de 5BB de cualquier archivo. Entonces, ¿diría que la aplicación es de buena calidad? ¡¡Obviamente no está bien !!

Objetivo

El único propósito de este tipo de prueba es garantizar que los aspectos no funcionales de la aplicación se prueben y que la aplicación funcione bien en el contexto de la misma.

El propósito es cubrir la prueba de todas las características de la aplicación que ayudan a proporcionar una aplicación que cumpla con las expectativas comerciales.

Ejemplo

Este es un tipo de prueba importante.

Las pruebas funcionales prueban la funcionalidad de la aplicación y aseguran que funcione como se espera, pero las pruebas no funcionales aseguran que la aplicación funcione lo suficientemente bien como para cumplir con las expectativas comerciales.

Para comprender su importancia, tomemos un ejemplo simple:

Se desarrolla una aplicación y se prueba completamente su funcionalidad, pero no se realizan pruebas no funcionales en la misma.

Mientras tanto, cuando la aplicación se activa, puede dar lugar a problemas críticos o importantes, como cuando aumenta la carga de la aplicación, se vuelve demasiado lenta y tarda mucho en abrirse.

El tiempo de respuesta puede aumentar o cuando la carga aumenta hasta cierto punto, la aplicación puede bloquearse. Esto muestra lo importante que es probar los aspectos no funcionales de una aplicación.

Ventajas

A continuación se presentan algunas de las ventajas de una prueba no funcional:

• Cubre las pruebas que no se pueden cubrir en las pruebas funcionales.
• Asegura que la aplicación se ejecute de manera eficiente y sea lo suficientemente confiable.
• Garantiza la seguridad de la aplicación.

¿Cómo capturar los requisitos no funcionales?

Mientras realizamos las pruebas, la atención se centra principalmente en las pruebas funcionales que prueban la funcionalidad del producto. Pero las pruebas no funcionales son tan importantes como las pruebas funcionales y sus requisitos deben tenerse en cuenta desde el inicio del producto.

Los requisitos no funcionales se utilizan para realizar pruebas no funcionales. Estos requisitos incluyen la salida de rendimiento que se espera de la aplicación o el software bajo prueba. Esto básicamente incluye el tiempo que tarda el software en operar un sistema en particular.

Los requisitos no funcionales también capturan el comportamiento cuando un gran número de personas utilizan el software al mismo tiempo. La mayoría de las veces se experimenta que los servidores están ocupados o no disponibles debido a una gran carga (es decir, más personas lo están utilizando al mismo tiempo). Reservar billetes de tren online puede ser lo mejor ejemplo de tal situación.

Por lo tanto, documentar adecuadamente el requisito No Funcional y realizar las pruebas correctamente garantizará una alta satisfacción en términos de usabilidad por parte de los clientes potenciales.

Aunque esta prueba no tiene un impacto comercial directo en la funcionalidad del sistema, puede aumentar la experiencia del usuario y la facilidad de uso en mayor medida, lo que a su vez tendrá un mayor impacto en la calidad del software.

Ejemplo:

Considere el mismo ejemplo de página de inicio de sesión de Facebook. En este caso, el alcance de las pruebas no funcionales es anotar el tiempo requerido por el sistema para iniciar sesión en Facebook después de ingresar las credenciales válidas.

Además, se puede probar cuando (digamos 100) los usuarios inician sesión al mismo tiempo, cuánto tiempo se tarda en iniciar sesión como usuario en Facebook.

Esto asegura que el sistema pueda manejar la carga y el tráfico, lo que a su vez tiene una buena experiencia de usuario.

En ágil, el requisito no funcional debe capturarse utilizando entradas.

Un requisito no funcional debe capturarse como:

• Historias técnicas / de usuario
• En criterios de aceptación
• En artefacto

9

# 1) Historias técnicas / de usuarios

Un requisito no funcional se puede capturar usando historias de usuarios o historias técnicas. Capturar requisitos no funcionales como una historia de usuario es lo mismo que capturar cualquier otro requisito. La única diferencia entre el usuario y una historia técnica es que la historia del usuario requiere discusión y tiene visibilidad.

# 2) Criterios de aceptación

Criterios de aceptación es el punto que se define para la aceptación del producto por parte del cliente, es decir, para que el producto sea aceptado en los puntos definidos debe estar en estado de aprobado.

Se debe incluir un requisito no funcional en los criterios de aceptación, pero a veces no es posible probar los requisitos no funcionales con cada historia, es decir, con cada iteración. Por lo tanto, los requisitos deben agregarse o probarse solo con la iteración relevante.

# 3) en artefactos

Se debe preparar un artefacto separado para los requisitos no funcionales, esto, a su vez, ayudaría a tener una mejor idea de lo que se debe probar y cómo se puede hacer en iteraciones.

Diferencia en requisitos funcionales y no funcionales

Existen varias diferencias entre los requisitos funcionales y no funcionales y algunos de ellos se indican a continuación:

Más lecturas => Diferencias entre pruebas funcionales y no funcionales

¿Se trata de una prueba de caja negra o caja blanca?

La prueba no funcional se incluye en un prueba de caja negra técnica.

Esta técnica no se limita a probar solo las funcionalidades, sino que también se puede utilizar para probar los requisitos no funcionales, así como el rendimiento, la usabilidad, etc.La técnica de prueba de caja negra no requiere ningún conocimiento del sistema interno, es decir, no requiere el conocimiento del código para el probador.

Lista de verificación de casos de prueba no funcionales

Se utiliza una lista de verificación para garantizar que ningún aspecto importante quede sin probar.

Una lista de verificación se usa generalmente cuando no hay tiempo para la documentación y el producto debe ser probado o cuando hay una limitación de tiempo, se puede usar una lista de verificación para asegurar que se hayan cubierto todos los aspectos importantes.

Veamos unejemplode la lista de verificación de pruebas de rendimiento, seguridad y documentación.

Lista de verificación para pruebas de rendimiento

• El tiempo de respuesta de la aplicación debe verificarse, es decir, cuánto tiempo se tarda en cargar la aplicación, cualquier entrada dada a la aplicación proporciona la salida en cuánto tiempo, refrescando el navegador, etc.
• Rendimiento debe verificarse el número de transacciones completadas durante una prueba de carga.
• Ambiente La configuración debe ser la misma que la del entorno en vivo o, de lo contrario, los resultados no serían los mismos.
• Tiempo de procesamiento - Procesar actividades como la importación y exportación de Excel, cualquier cálculo en la aplicación debe ser probado.
• Interoperabilidad debe ser verificado, es decir, un software debe poder interactuar con los otros programas o sistemas.
• ETL Se debe verificar el tiempo, es decir, el tiempo necesario para extraer, transformar y cargar los datos de una base de datos a otra.
• Carga creciente en la aplicación debe ser verificado.

Lista de verificación para pruebas de seguridad

• Autenticación: Solo un usuario auténtico debería poder iniciar sesión.
• Autorizado: El usuario debe poder iniciar sesión en aquellos módulos solo para los que está autorizado o para los que se le ha proporcionado acceso.
• Contraseña: El requisito de contraseña debe verificarse, es decir, la contraseña debe ser según la definición del requisito, es decir, longitud, caracteres especiales, números, etc.
• Se acabó el tiempo: Si la aplicación está inactiva, debería expirar en un tiempo especificado.
• Copias de seguridad: La copia de seguridad de los datos debe realizarse en un momento específico y debe copiarse en una ubicación segura.
• Vínculos internos a la aplicación web no debería ser accesible si se coloca directamente en el navegador.
• Toda la comunicación debe estar encriptada.

Lista de verificación para pruebas de documentación

• Documentación del usuario y del sistema.
• Documentos con fines formativos.

Documento de enfoque

Desarrolle un documento de enfoque específico para la etapa de prueba de rendimiento refinando la estrategia de prueba general. Este enfoque de prueba guía en la planificación y ejecución de todas las tareas de prueba de rendimiento.

convertidor de youtube a mp3 mejor calificado

• Alcance de prueba
• Métricas de prueba
• Herramientas de prueba
• Fechas clave y entregables

Alcance de prueba

Realice pruebas de rendimiento desde diferentes perspectivas, como el rendimiento del usuario, los procesos comerciales, la estabilidad del sistema, el consumo de recursos, etc. Los tipos de pruebas de rendimiento para ejecutar se analizan en la sección anterior del artículo (como prueba de carga, prueba de esfuerzo, etc.)

Métricas de prueba

El enfoque de prueba refina las métricas para medir e informar durante las pruebas, como:

• Tiempo de respuesta (en línea)
• Ventana de lote (lote)
• Rendimiento ( Por ejemplo , el número de transacciones por unidad de tiempo)
• Utilización ( Por ejemplo , el porcentaje de recursos utilizados)

Herramientas de prueba

La mayoría de las pruebas de rendimiento requieren el uso de herramientas adecuadas:

• Herramientas de generación de carga
• Herramientas de monitoreo de desempeño
• Herramientas de análisis de desempeño
• Herramientas de creación de perfiles de aplicaciones
• Herramientas de revestimiento de base.

Fechas clave y entregables

El documento de enfoque de prueba de rendimiento debe describir lo siguiente:

• Fecha y hora de cada prueba de desempeño realizada.
• Tipos de pruebas y combinación de funciones que se incluirán en cada realización de la Prueba de rendimiento.
• Fechas de finalización de la prueba de rendimiento.

Tipos de pruebas no funcionales

La siguiente imagen muestra los tipos de pruebas no funcionales:

Pruebas de rendimiento:

Evalúa el rendimiento general del sistema. .

Los elementos clave son los siguientes:

• Valida que el sistema cumpla con el tiempo de respuesta esperado.
• Evalúa que los elementos significativos de la aplicación cumplen el tiempo de respuesta deseado.
• También se puede realizar como parte de las pruebas de integración y las pruebas del sistema.

Prueba de carga:

Evalúa si el rendimiento del sistema es el esperado en condiciones normales y esperadas.

Los puntos clave son:

• Valida que el sistema funciona según lo esperado cuando usuarios concurrentes acceden a la aplicación y obtienen el tiempo de respuesta esperado.
• Esta prueba se repite con varios usuarios para obtener el tiempo de respuesta y el rendimiento.
• En el momento de la prueba, la base de datos debe ser realista.
• La prueba debe realizarse en un servidor dedicado que estimule el entorno real.

Pruebas de estrés:

Evalúa si el rendimiento del sistema es el esperado cuando tiene pocos recursos.

Los puntos clave son:

• Pruebe con poca memoria o poco espacio en disco en clientes / servidores que revelen los defectos que no se pueden encontrar en condiciones normales.
• Varios usuarios realizan las mismas transacciones con los mismos datos.
• Varios clientes están conectados a los servidores con diferentes cargas de trabajo.
• Reduzca el tiempo de reflexión a 'cero' para estresar a los servidores al máximo.

Piense en el tiempo: Al igual que el intervalo de tiempo entre escribir su usuario y contraseña.

Prueba de volumen:

Evalúa el comportamiento del software cuando se trata de un gran volumen de datos.

Los puntos clave son:

• Cuando el software está sujeto a grandes cantidades de datos, comprueba el límite donde falla el software.
• Se crea el tamaño máximo de la base de datos y varios clientes consultan la base de datos o crean un informe más grande.
• Ejemplo - Si la aplicación está procesando la base de datos para crear un informe, una prueba de volumen sería utilizar un conjunto de resultados grande y verificar si el informe se imprime correctamente.

Pruebas de usabilidad:

Evalúa el sistema para uso humano o comprueba si es apto para su uso.

Los puntos clave son:

• ¿El resultado es correcto y significativo y es el mismo que se esperaba según el negocio?
• ¿Se diagnostican correctamente los errores?
• ¿La GUI es correcta y coherente con el estándar?
• ¿Es la aplicación fácil de usar?

Prueba de interfaz de usuario:

Evalúa la GUI.

Los puntos clave son:

• La GUI debe proporcionar ayuda e información sobre herramientas para facilitar su uso.
• ¿Consistente para su apariencia?
• ¿Los datos se recorren correctamente de una página a otra?
• La GUI no debería molestar al usuario ni resultar difícil de entender.

Prueba de compatibilidad:

Evalúa que la aplicación es compatible con otro hardware / software con configuración mínima y máxima.

Los puntos clave son:

• Pruebe cada hardware con la configuración mínima y máxima.
• Prueba con diferentes navegadores.
  Los casos de prueba son los mismos que se ejecutaron durante las pruebas funcionales.
• En caso de que la cantidad de hardware y software sea demasiada, entonces podemos usar técnicas OATS para llegar a los casos de prueba para tener la máxima cobertura.

Prueba de recuperación:

Evalúa que la aplicación finaliza correctamente en caso de cualquier falla y que los datos se recuperan adecuadamente de cualquier falla de hardware y software.

Las pruebas no se limitan a los siguientes puntos:

• Interrupción de energía, al cliente mientras realiza actividades CURD.
• Punteros y claves de base de datos no válidos.
• El proceso de la base de datos se cancela o se termina prematuramente.
• Los punteros, campos y claves de la base de datos se corrompen manual y directamente dentro de la base de datos.
• Desconecte físicamente la comunicación, apague la energía, apague los enrutadores y los servidores de red.

Prueba de inestabilidad:

Evalúa y confirma si el software se instala y desinstala correctamente.

inicialización de variable estática c ++

Los puntos clave son:

• Valida que los componentes del sistema estén instalados correctamente en el hardware designado.
• Valida que la navegación en la nueva máquina actualice la instalación existente y las versiones anteriores.
• Valida que con espacio en disco insuficiente, no hay comportamiento inaceptable.

Prueba de documentación:

Evalúa los documentos y otros manuales de usuario.

Los puntos clave incluyen:

• Valida que los documentos indicados estén disponibles en el producto.
• Valida todas las guías de usuario, configura las instrucciones, léame archivos, notas de la versión y ayuda en línea.

Prueba de conmutación por error:

Las pruebas de conmutación por error se realizan para verificar que, en caso de falla del sistema, el sistema es lo suficientemente capaz de manejar recursos adicionales como servidores.

Para prevenir tal situación, las pruebas de respaldo juegan un papel importante. Crear un sistema de respaldo es de lo que se trata el proceso. Si la copia de seguridad está disponible, ayuda a recuperar el sistema.

Pruebas de seguridad:

Pruebas de seguridad se hace para garantizar que la aplicación no tenga lagunas que puedan provocar la pérdida de datos o amenazas. Es uno de los aspectos importantes de las pruebas no funcionales y, si no se realiza correctamente, puede provocar amenazas a la seguridad.

Incluye probar la autenticación, autorización, integridad y disponibilidad.

Prueba de escalabilidad:

Las pruebas de escalabilidad se realizan para verificar si la aplicación es lo suficientemente capaz de manejar un mayor tráfico, número de transacciones, volumen de datos, etc. El sistema debería funcionar como se esperaba cuando se realiza el volumen de datos o el cambio en el tamaño de los datos.

Pruebas de conformidad:

Las pruebas de cumplimiento se realizan para verificar si se siguen o no los estándares definidos. Se realizan auditorías para verificar lo mismo.

Para Ejemplo , Las auditorías se realizan para verificar el proceso de creación de casos de prueba / planes de prueba y colocarlos en la ubicación compartida con el nombre estándar que se está realizando o no. En QC, al nombrar los casos de prueba, se sigue o no el nombre del caso de prueba estándar. La documentación está completa y aprobada o no.

Estos son los pocos consejos que se tratan durante la auditoría.

Prueba de resistencia:

Prueba de resistencia se realiza para verificar el comportamiento del sistema cuando una carga aumenta en cierta medida durante un tiempo prolongado.

También se denomina prueba de remojo y prueba de capacidad. Ayuda a verificar si hay pérdidas de memoria en el sistema. Las pruebas de resistencia son un subconjunto de las pruebas de carga.

Prueba de localización:

Prueba de localización se hace para verificar la aplicación en diferentes idiomas, es decir, diferentes configuraciones regionales. La aplicación debe verificarse para una cultura o localidad en particular. El objetivo principal es probar el contenido, la GUI de la aplicación.

Pruebas de internacionalización:

Pruebas de internacionalización también se conoce como prueba i18n.

I18n representa I (dieciocho letras) N. Se hace para verificar si la aplicación funciona como se esperaba en todas las configuraciones de idioma. Verifica que ninguna funcionalidad o aplicación en sí misma no se rompa, es decir, la aplicación debe ser lo suficientemente capaz para manejar todas las configuraciones internacionales.

También verifica que la aplicación se instale sin problemas.

Prueba de confiabilidad:

Las pruebas de confiabilidad se realizan para verificar si la aplicación es confiable y se prueba durante un período de tiempo específico en el entorno definido. Una aplicación debe dar el mismo resultado que se espera cada vez, solo entonces puede considerarse confiable.

Pruebas de portabilidad:

Las pruebas de portabilidad se realizan para verificar si, en caso de que un software / aplicación se instale en un sistema diferente o en una plataforma diferente, debería poder ejecutarse como se esperaba, es decir, ninguna funcionalidad debería verse afectada debido a un cambio en el entorno.

Durante la prueba, también es necesario probar el cambio con la configuración del hardware, como el espacio en el disco duro, el procesador y también con diferentes sistemas operativos para garantizar que el comportamiento correcto de la aplicación y la funcionalidad esperada estén intactos.

Pruebas de referencia:

Las pruebas de referencia también se conocen como pruebas de referencia ya que crea una base para probar cualquier nueva aplicación.

Por ejemplo: En la primera iteración, el tiempo de respuesta de una aplicación fue de 3 segundos. Ahora, esto se ha establecido como un punto de referencia para la próxima iteración y en la próxima iteración, el tiempo de respuesta cambia a 2 segundos. Básicamente es un documento de validación que se utiliza como base para futuras referencias.

Prueba de eficiencia:

Las pruebas de eficiencia se realizan para verificar si la aplicación funciona de manera eficiente y la cantidad de recursos necesarios, herramientas necesarias, complejidad, requisitos del cliente, entorno requerido, tiempo, qué tipo de proyecto es, etc.

Estos son algunos de los indicadores que ayudarían a definir qué tan eficientemente funcionaría una aplicación si todos los parámetros considerados funcionan como se espera.

Prueba de recuperación ante desastres:

Esta prueba se realiza para verificar la tasa de éxito de recuperación de una aplicación o sistema si ocurre alguna falla crítica y si el sistema es capaz de restaurar los datos y la aplicación o si el sistema podría arreglárselas fácilmente para regresar a la forma en que estaba funcionando antes, es decir, desde el frente operativo.

Pruebas de mantenibilidad:

Una vez que la aplicación / Producto se activa, existe la posibilidad de que surja un problema en el entorno en vivo o que el cliente desee una mejora para la aplicación que ya está activa.

En este caso, el equipo de pruebas de mantenimiento está disponible para probar los escenarios mencionados anteriormente. Una vez que la aplicación se pone en funcionamiento, todavía necesita mantenimiento para el que trabaja el equipo de pruebas de mantenimiento.

Herramientas de prueba no funcionales

Hay varias herramientas disponibles en el mercado para las pruebas de rendimiento (carga y estrés).

Algunos de ellos se enumeran a continuación:

• JMeter
• Cargador
• Loadrunner
• Tormenta de carga
• Neoload
• Pronóstico
• Carga completa
• Herramienta de estrés del servidor web
• WebLoad Professional
• Loadtracer
• vPerformer

¿Las pruebas no funcionales se realizan siempre sin documentación ni casos de prueba? ¿Por qué?

“Siempre se nos enseña cómo escribir casos de prueba funcionales. ¿Porqué es eso? ¿Se llevan a cabo las 'pruebas no funcionales' sin documentación (en otras palabras, de forma ad-hoc) o se trata de un proceso separado que es mucho más difícil de entender? ¿Cómo se escriben los casos de prueba para los diferentes tipos de pruebas que ocurren en una aplicación? '

Esta es una de las preguntas más originales, distintivas e innovadoras que me han hecho en los últimos tiempos. Busquemos la respuesta.

¿Cómo es que nunca llegamos a ver y practicar la escritura de casos de prueba no funcionales?

Comencemos con lo que sabemos y, como siempre, un escenario práctico.

Ejemplo: Los siguientes son los pasos que se deben realizar en una aplicación de banca en línea para realizar una transferencia. Usemos eso como nuestra prueba de referencia.

1. Inicie sesión en el sitio.
2. Elija la cuenta bancaria.
3. Elija el beneficiario (este beneficiario podría pertenecer al mismo banco oa uno diferente, esto depende de su elección de datos para ejecutar este paso. En cualquier caso, elija uno. Además, vamos a asumir que el beneficiario ya está agregado). .
4. Ingrese el monto a transferir (valor positivo, dentro del límite, formato correcto, etc.).
5. Haga clic en Transferir y verifique si se recibe la confirmación, el saldo de la cuenta se ha actualizado y todo eso.

Este es el caso de prueba funcional, ¿correcto?

En la misma aplicación, en la misma página de transferencias, digamos que estamos realizando Pruebas de rendimiento, seguridad y usabilidad . Estos son tipos no funcionales, ¿correcto?

¿Cómo escribiríamos los casos de prueba?

# 1) Casos de prueba de pruebas de usabilidad

Las pruebas de usabilidad son un género de pruebas de software que se ocupa de la experiencia del usuario. Estas son algunas de las preguntas que intentamos dar respuesta.

• ¿Qué tan fácil es usar la aplicación?
• ¿Qué tan satisfactoria es la experiencia de usar el sistema?
• Si no es tan familiar de inmediato, ¿qué tan fácil es aprender?

Más información al respecto está aquí: Guía de pruebas de usabilidad

¿Cómo determinaría un usuario las respuestas a las preguntas anteriores en el contexto de las pruebas de usabilidad?

El usuario realizaría exactamente los mismos pasos que en el caso de prueba funcional. Estoy en lo cierto?

# 2) Casos de prueba de pruebas de rendimiento

Hay varias variaciones en las pruebas de rendimiento, pero en esencia, se utiliza para obtener estadísticas sobre el sistema, su utilización de recursos, tiempo de respuesta, consumo de red, etc. en varios puntos de carga.

Mira nuestro Tutoriales de pruebas de rendimiento para saber más al respecto.

Ahora, si tuviera que probar el rendimiento de la transacción de las transferencias, tendría 10, 20, 30, 100 ... 1000 ... etc. usuarios que realizan la operación de transferencia de forma simultánea o incremental, según lo que quiero orientar y recopilar datos.

¿Qué pasos realizaría cada usuario para usar la transferencia mientras se realiza la prueba de rendimiento?

Los mismos pasos exactos que la prueba funcional, ¿correcto?

# 3) Casos de prueba de pruebas de seguridad

Security Testing es una rama de QA que ayuda a hacer que los sistemas de software sean a prueba de piratería. Identifica vulnerabilidades (áreas potencialmente problemáticas en el sistema de software), las explota mediante la técnica de penetración o prueba de sombrero blanco y, cuando se encuentran lagunas, se trabaja en ellas.

¿Cuándo quiero verificar si las transferencias son a prueba de piratería y están dirigidas correctamente a los destinatarios previstos y que no hay puntos negros en todo el proceso? Realizaría la transferencia mientras el proceso de monitoreo de fugas de seguridad continúa en paralelo.

Por lo tanto, en efecto, estoy llevando a cabo exactamente los mismos pasos que normalmente haría en el caso de un caso de prueba funcional.

Supongo que tenemos suficiente para establecer que los pasos en todas las situaciones son los mismos. El método y la intención detrás del proceso son lo diferente.

Echemos un vistazo comparativo:

Lo que es interesante notar es que no importa qué tipo de prueba queramos hacer, todos los pasos son los mismos .

La verdadera diferencia es que:

1. ¿Quién realiza estos pasos?
2. ¿Cuál es la intención, o en otras palabras, qué estoy tratando de lograr con esta prueba?
3. Las herramientas y técnicas utilizadas.

Volviendo a nuestra pregunta, ¿por qué nunca aprendemos a escribir casos de prueba no funcionales con todos los pasos detallados que existen para ello?

Eso es porque ,En esencia, los pasos de prueba para una variación de los tipos de prueba en una determinada función son todos iguales, funcionales o no. Es la intención la que marca la diferencia y tal vez el método.

Conclusión

Antes de realizar pruebas no funcionales, es esencial planificar la estrategia de prueba correctamente para garantizar una prueba adecuada. Existen diferentes herramientas que están disponibles en el mercado para realizar este tipo de pruebas como Load Runner, RPT, etc.

Esta prueba juega un papel importante en el éxito de una aplicación y para construir una buena relación con el cliente y, por lo tanto, no debe descuidarse. Esta es una de las partes importantes de las pruebas de software y las pruebas no pueden considerarse completas sin esto.

Podemos incluir detalles de prueba no funcionales en el plan de prueba o podemos crear una estrategia separada para ello. En cualquier caso, el objetivo es tener una cobertura adecuada de los aspectos no funcionales del software.

Esperamos que este proceso de profundizar en este tema haya sido tan divertido para ustedes como se les ha presentado a todos. Nos encantaría escuchar sus comentarios y opiniones sobre este tema.

¿Cómo maneja las pruebas no funcionales en sus equipos? Y como siempre, háganos saber si está de acuerdo o en desacuerdo o si tiene algo que agregar a lo que estamos sucediendo aquí.

Lectura recomendada

• Pruebas funcionales versus pruebas no funcionales
• Pruebas alfa y beta (una guía completa)
• Guía de pruebas de seguridad de aplicaciones web
• Guía completa de pruebas funcionales con sus tipos y ejemplo
• Guía completa de pruebas de verificación de compilación (pruebas de BVT)
• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Guía para principiantes sobre pruebas de penetración de aplicaciones web
• Guía completa de pruebas de carga para principiantes