ASOCIACIÓN DE ESCENARIO DE APLICACIÓN DE FUNDAMENTOS, PRINCIPIOS, TIPOS Y NIVELES DE PRUEBAS

 SOBRE “HISTORIAS DE USUARIO”

Validación principios del Testing

1. Ejecutar pruebas nos desvela la presencia de defectos: En la prueba se valida que la mayoría de los defectos se encuentran en una parte específica del software, de esto la necesidad de priorizar tempranamente y poder enfocar las pruebas en estas zonas sensibles del software.

2. El testing exhaustivo es imposible: En esta parte se validó que por sencillo o pequeño que sea un software, es casi imposible tratar de cubrir todas las posibles combinaciones, teniendo en cuenta también los tipos de software que se pueden aplicar a un software. Siempre es necesario identificar las funcionalidades prioritarias del software y asegurar sus pruebas, esto teniendo en cuenta que hoy en día se aplican metodologías ágiles.

3. La verificación de la calidad de un sistema debe empezarse lo antes posible: Se comprueba y se destaca que las pruebas de software adquieren mayor valor y mayor importancia en la medida en que se apliquen en fases tempranas, incluso desde la fase de requerimientos, debido a que entre mayor sea la madurez del software, mayor será el costo de los defectos.

4. Agrupación de defectos: Estas pruebas fueron enfocadas en las funcionalidades principales de la

aplicación “Lo exquisito del mar”, lo que le permitió a los desarrolladores entregar un producto listo para grandes cargas en las secciones de domicilios, reservas y la visualización del menú del restaurante. Todas estas son las funciones principales, por lo que el énfasis al probarlas es correcto.

5. La paradoja del pesticida: Durante las pruebas se observa buena variedad de enfoques en las funcionalidades evaluadas, por lo que no caemos en la paradoja de este principio en ningún momento.

6. El testing depende del contexto: Los casos que se simulan son adecuados para el contexto de uso de la aplicación “Lo exquisito del mar”. Esta va a tomar muchos domicilios, reservas y selecciones de productos para ambos casos, por lo que el énfasis en la funcionalidad de estos menús es muy acertado.

7. Falacia de ausencia de incidentes: Aunque las pruebas fueron exhaustivas, el software nunca es perfecto y seguramente los clientes tengan críticas constructivas que se puedan aplicar en futuras actualizaciones. Los temas de optimización y velocidad de la aplicación siempre pueden ser mejorados.

Planificación de las pruebas:

- Objetivos

Conocer la metodología que utilizará el equipo de desarrollo es importante para usar las instancias de pruebas adecuadas para los objetivos del proyecto en desarrollo. En proyectos con metodologías ágiles el foco principal estará en desarrollar pruebas que validen las historias de usuario aprobadas para el sprint (período de tiempo establecido durante el cual se debe completar un trabajo específico y prepararlo para su revisión), sin embargo, también hay que tener en cuenta que pueden considerarse otro tipo de pruebas a realizar que aporten valor, como por ejemplo pruebas de rendimiento para validar que la arquitectura del sistema responde correctamente o pruebas de seguridad para validar que no se introducen vulnerabilidades tanto a nivel de la aplicación como en la infraestructura que la soporta.

- Restricciones que se tomaron

Criterios de aceptación o rechazo:

Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja, puede definirse como criterio de aceptación que el 100%

de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos de prueba principales y casos bordes será muy difícil, y podría comprometer los plazos del proyecto (incrementa los riesgos), pero asegura la calidad del producto.

Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba principales (considerados clave) y 20% de casos de prueba no principales (casos borde).

Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de software.

Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo, en el caso de inicio, la condición podría ser la instalación de los componentes de software en el ambiente y que los casos de pruebas de verificación de ambiente sean exitosos.

Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de cuáles criterios de suspensión se presentaron para detener las pruebas. Una vez que estás condiciones ya no existan (sean solventadas) se procede con la reanudación.

Criterios de suspensión:

Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la organización y también de los acuerdos establecidos en cada proyecto individual.

Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos, se puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el personal a otras actividades,

Por otra parte, si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión puede ser poco exigente, por ejemplo, solo ocurriendo si se bloquean por incidencia todos los casos de

prueba.

- Tareas involucradas

Se debe identificar las funcionalidades existentes que están siendo impactadas por el desarrollo de alguna forma, considerando todos los componentes afectados en todas las capas de la arquitectura de software.

Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:

Funcionalidades modificadas de cara al usuario: Por ejemplo, si una funcionalidad está siendo modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en el plan de pruebas de software.

Funcionalidades modificadas en sus componentes internos: Son funcionalidades no modificadas de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin embargo, si se modifican componentes internos que comparten con otras funcionalidades del sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software para determinar a partir de ellas pruebas de regresión a realizar.

Quienes pueden suministrar la información serán los analistas de negocio o arquitectos de software, familiarizados con el sistema informático implementado en el entorno de producción.

- Calendario de pruebas

Conocer las fechas del proyecto es importante para planificar cuándo podrás realizar los diferentes tipos de pruebas. Por ejemplo, al inicio del proyecto es importante enfocar el esfuerzo de pruebas en los requerimientos, validar que los mismos sean claros, entendibles y que se puedan diseñar pruebas para comprobar su cumplimiento.

En las siguientes fases, el foco deberá ir cambiando hacia las pruebas funcionales y pruebas de UX mientras se comienzan a planificar las pruebas no funcionales, como son las de rendimiento. Para esto es importante coordinar con desarrollo el momento en que los componentes críticos de la arquitectura del sistema estén implementados para medir lo antes posible su respuesta frente a carga.

Análisis de la prueba

Durante las pruebas de “Lo exquisito del mar” se evidencia buen orden de prioridades, sin embargo, ningún sistema está libre de errores y en el caso de esta app podemos ver varios casos de omisión:

- Se le debe dar una introducción en el manejo de la app al usuario después de haber iniciado sesión por primera vez, algo como un tour donde se le indique cómo debe tomar el pedido y cómo visualizar los detalles de este.

- Se requiere un apartado de ayuda/soporte en caso de presentar inconvenientes con el registro o inicio de sesión.

El sistema de pruebas no presenta muchos errores fáciles de notar, por lo que el usuario promedio puede esperar una experiencia óptima. Esto desde que la app esté bien optimizada y no consuma demasiados recursos, está planeada para ser una app de conveniencia, no un juego, por lo que no debe ser muy pesada en los sistemas operativos de los usuarios. De no estar optimizada aparte de perder parte del mercado que no tenga hardware lo suficientemente potente, también generará una experiencia lenta y tediosa para aquellos que soporten la app en sus celulares.

Planteamiento

Como ya se ha mencionado, el proceso que se lleva con esta aplicación es de nivel profesional, es difícil encontrar errores en la planeación de este y los que encontramos son solo inconvenientes que con una actualización se pueden arreglar fácilmente.

En un proceso profesional no hay lugar para contradicciones o problemas de funcionamiento críticos que vuelvan inútil el producto, por lo que, los errores de lógica son poco probables.

Este caso es el de una aplicación de conveniencia por lo que el diseño presentado peca de anticuado y hasta poco ergonómico en ciertos menús. Se ven demasiados elementos grandes que luchan por atención, lo que reduce la estética del app. Otro error de carácter estético es el uso excesivo del color verde, color que al exponer temas de alimentos se sugiere evitar a menos de que se trate de vegetales/ensaladas o alimentos ácidos, esto

porque el color verde se asocia a un sabor ácido como de lima o de limón. (Por ejemplo: se ha comprobado en bebidas de fresa de color verde que más de la tercera parte de las personas encuestadas identifican el sabor de la bebida como de lima o limón).

Volviendo al proceso de pruebas, podemos concluir que fue exitoso en las funcionalidades principales, omite varios detalles de cara a la experiencia de usuario y comete errores en obviar la estética de la aplicación.

DEFINICIONES

PRINCIPIOS DEL TESTING

1. La ejecución de pruebas demuestra la presencia de defectos

El testing nos permite demostrar la existencia de incidentes en un producto, no su ausencia. Tras el reporte de un incidente y su consecuente restauración, es posible reducir la probabilidad de que incidentes aún no descubiertos persistan en el sistema.

2. El testing exhaustivo no es posible

Exceptuando casos puntuales, probar cada combinación posible de datos y acciones en todas las funcionalidades de un software generalmente no es una opción viable, ya sea por cuestiones de tiempo, costos o recursos.

3. Pruebas tempranas

Cuando el proceso de testing comienza en las etapas más tempranas del desarrollo de software, esta alianza resulta extremadamente beneficiosa, pues permite detectar incidentes en los albores del producto. El costo de reparación de estos incidentes sería significativamente más elevado si recién fueran detectados en fases posteriores.

4. Agrupación de defectos

Generalmente, hay ciertos módulos y funcionalidades que son más proclives a presentar incidencias (de mayor prioridad) en comparación al resto de las partes que conforman un producto. Este fundamento está relacionado con la Regla 80/20, que afirma que aproximadamente el conforme 80% de las consecuencias emergen del 20% de las causas.

En términos más precisos, esto podría traducirse de la siguiente manera: no todos los componentes de un software poseen el mismo nivel de relevancia, por lo que el enfoque más propicio en el momento de elaborar nuestra estrategia de pruebas es concentrar nuestros esfuerzos justamente en esas partes más cruciales, para detectar aquellos incidentes que puedan resultar más urgentes de resolver.

5. Paradoja del pesticida

Ejecutar los mismos tests en una misma parte estable de un sistema repetidas veces es una práctica que tiende a dificultar la detección de nuevos incidentes que aún no han sido descubiertos.

Por esto, para aumentar las posibilidades de detección de incidentes, es imprescindible revisar y actualizar de manera constante nuestra estrategia de pruebas y asegurarnos de explorar las diversas partes que componen el producto con mayor profundidad.

6. El testing depende del contexto

La estrategia y el tipo de pruebas serán seleccionados en función del sistema y a los entornos que se pretenden

verificar. Por ejemplo, un software médico no será probado de la misma forma que un sistema de movilidad vial.

Los procedimientos estructurados, así como los casos diseñados, serán seleccionados teniendo en consideración todos y cada uno de estos factores.

7. Falacia de ausencia de incidentes

Supongamos que todos los incidentes detectados en un sistema dado son corregidos. A continuación, se realiza un nuevo ciclo de pruebas, tras el cual no se detecta la presencia de nuevos incidentes.

La ausencia de nuevos errores detectados no implica necesariamente que el software sea útil, ya que la utilidad del mismo no es indicada por este parámetro, sino por la satisfacción de las expectativas del cliente que el producto pueda brindar.

TIPOS DE PRUEBAS

Pruebas manuales

Son llevadas a cabo por personas, quienes navegan e interactúan con el software (usando herramientas adecuadas para cada caso).

Estas pruebas resultan costosas, ya que se requiere contar con un profesional encargado de esta labor; para configurar un entorno y así mismo ejecutar las pruebas.

Como es de esperarse, estas pruebas están expuestas a errores humanos: por ejemplo, se pueden cometer errores tipográficos u omitir pasos durante la prueba.

Las pruebas automatizadas

Las pruebas automatizadas, por el contrario, son realizadas por máquinas, que ejecutan un "test script" que ya ha sido escrito previamente.

Estos tests (o pruebas) pueden variar mucho en cuanto a complejidad:

● Desde verificar que el método de una clase específica funcione correctamente,

● Hasta asegurar que una secuencia de acciones complejas en la UI se lleven a cabo correctamente y

devuelvan los resultados esperados.

Estas pruebas son más rápidas y confiables que las que se llevan a cabo manualmente – pero la calidad

de estas pruebas automatizadas depende de qué tan bien escritos se encuentren los "tests scripts"

(código que determina qué es lo que se hará en la prueba).

PRUEBAS :

Pruebas unitarias

Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente de la aplicación. Consisten

en probar métodos y funciones individuales de las clases, componentes o módulos que usa tu software.

En general, las pruebas unitarias son bastante baratas de automatizar y se pueden ejecutar rápidamente

mediante un servidor de integración continua.

Pruebas de integración

Las pruebas de integración verifican que los distintos módulos o servicios utilizados por tu aplicación

funcionan bien en conjunto. Por ejemplo, se puede probar la interacción con la base de datos o

asegurarse de que los microservicios funcionan bien en conjunto y según lo esperado. Estos tipos de

pruebas son más costosos de ejecutar, ya que requieren que varias partes de la aplicación estén en

marcha.

Pruebas funcionales

Las pruebas funcionales se centran en los requisitos empresariales de una aplicación. Solo verifican el

resultado de una acción y no comprueban los estados intermedios del sistema al realizar dicha acción.

Pruebas integrales

Las pruebas integrales replican el comportamiento de un usuario con el software en un entorno de

aplicación completo. Además, verifican que diversos flujos de usuario funcionen según lo previsto, y

pueden ser tan sencillos como cargar una página web o iniciar sesión, o mucho más complejos, como la

verificación de notificaciones de correo electrónico, pagos en línea, etc.

Pruebas de aceptación

Las pruebas de aceptación son pruebas formales que verifican si un sistema satisface los requisitos

empresariales. Requieren que se esté ejecutando toda la aplicación durante las pruebas y se centran en

replicar las conductas de los usuarios. Sin embargo, también pueden ir más allá y medir el rendimiento

del sistema y rechazar cambios si no se han cumplido determinados objetivos.

Pruebas de rendimiento

Las pruebas de rendimiento evalúan el rendimiento de un sistema con una carga de trabajo

determinada. Ayudan a medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de respuesta de

una aplicación. Por ejemplo, una prueba de rendimiento puede analizar los tiempos de respuesta al

ejecutar un gran número de solicitudes, o cómo se comporta el sistema con una cantidad significativa

de datos. Puede determinar si una aplicación cumple con los requisitos de rendimiento, localizar cuellos

de botella, medir la estabilidad durante los picos de tráfico y mucho más.

Pruebas de humo

Las pruebas de humo son pruebas básicas que sirven para comprobar el funcionamiento básico de la

aplicación. Están concebidas para ejecutarse rápidamente, y su objetivo es ofrecerte la seguridad de que

las principales funciones de tu sistema funcionan según lo previsto.

ESCENARIO DE SUSTENTACIÓN

Nota: Para nuestro caso de sustentación usaremos una empresa ficticia llamada Namaste Hardware que se dedicará a la producción de software en la forma de videojuegos. Por esto, cualquier parecido con otros productos o empresas es mera coincidencia.

Un nuevo desarrollo llega a los planes de Namaste Software, un juego de mundo abierto en el que nuestro protagonista tiene que explorar, encontrar ciertas ciudades y conquistar los castillos que se encuentran en el centro de estas. Para ello se irá haciendo con una tripulación de compañeros, cada uno con habilidades cruciales para el desarrollo de la historia.

El mundo es el primero en ser desarrollado; todo el entorno, las texturas, localizaciones y, en general, el nivel de inmersión que este mundo le generará al jugador debe ser probado antes de pasar a la siguiente etapa del desarrollo. Para esto se realizará una serie de pruebas tipo Humo.

Reporte #1: En la vista Espectador se revisó todo el mundo, este no presentó mayores problemas de corrupción de texturas ni mala renderización. Pruebas exitosas.

Estas pruebas rápidas le permitirán a la empresa seguir con el desarrollo de cada personaje, desde los protagonistas hasta los extras. Para ello se usa el mismo motor gráfico que para el desarrollo del mundo por lo que las texturas y modelado 3D no suponen ningún problema. Sin embargo, se deben correr pruebas de integración para evaluar la relación entre los personajes y el mundo.

Reporte #2: Las pruebas de integración arrojan que ciertos personajes tienen problemas en el comportamiento que se les programó, este choca con el entorno y deja una experiencia poco satisfactoria.

El desarrollo tuvo que retrasarse unos días mientras se corrigen los errores de interacción de los personajes con el mundo, pero estas pruebas permitieron encontrar errores en las prácticas de los desarrolladores que de no ser corregidas, se comprometería la experiencia de usuario gravemente.

Reporte #3: En el departamento de Testing se desarrolla un test-script para automatizar las pruebas más sencillas como las de humo, funcionales y unitarias.

Luego de la corrección de errores, el desarrollo continúa con la creación de Ítems para el uso del jugador, estos afectan sus estadísticas (la vida, el daño, la velocidad de movimiento, etc.), también se determina cuáles ítems afectan a los demás personajes del juego o solo al jugador.

Reporte #4: Para la prueba de estos ítems se usa el test-script; el tiempo corre y se acerca la salida de la demo para cierta cantidad de jugadores.

Los defectos recolectados hasta ahora han sido agrupados y solucionados en su mayoría. Se esperan buenas reviews de parte de los jugadores.

Aunque el desarrollo está en sus etapas finales, todavía falta una parte crucial, un repaso a la sección del personaje principal, sus interacciones con los demás personajes, movimientos y el modelado 3D de las skins disponibles deben ser pulidos.

Reporte #5: La demo ha salido al mercado y fue probada por 500 jugadores, reportan varios errores de corrupción de diálogos e interacciones erróneas con los personajes en ciertos casos.

Vemos que los jugadores prestan gran atención a sus interacciones con los personajes del juego, por ello se deben pulir y evaluar más a fondo; gracias al feedback de los jugadores, el juego podrá salir al mercado con estos errores corregidos.

Reporte final: El juego ha salido y es un éxito en todas las plataformas disponibles, podremos esperar actualizaciones y demás expansiones para este desarrollo.

Conclusiones

+ Este caso nos demuestra la importancia del testing en el desarrollo de software moderno, nos evita retrasos innecesarios, nos ayuda a entregar productos mejor desarrollados y permite al usuario participar en el perfeccionamiento del producto que va a consumir.

+ A su vez, el testing debe ser ordenado minuciosamente para evitar errores omitidos, ambigüedades y malas prácticas, esto se hace comúnmente a través de los principios del testing que vimos anteriormente en este documento. Estos actúan como una lista de elementos a chequear al momento de planificar nuestras pruebas.

+ En el escenario de Namaste Software vemos que la planeación de pruebas es mediocre porque no se cuenta con contramedidas eficientes para malos resultados en pruebas. Se tiene que retrasar todo el proyecto por más tiempo del aceptable por culpa de esto; lo que lleva los costos de contrato a subir en relación al tiempo perdido.

+ Por otro lado, se puede pensar que, para el desarrollo de un software tan complicado como el de un videojuego, se debe tener buen presupuesto y tolerancia a los retrasos por la gran variedad de equipos de trabajo que se manejan. La toma de atajos por los directivos en este tipo de empresas es lo que suele generar más problemas en el producto que entregan al público, esto al tratar de optimizar erróneamente el trabajo de los equipos que supervisan.