Plan de Pruebas para API

Introducción

Este plan de prueba tiene como objetivo garantizar la calidad, funcionalidad y confiabilidad de la API de Fake rest alojada en: API FAKE. 

La API está diseñada para manejar libros, autores, fotos de portada, usuarios y actividades para un sistema de gestión de libros.

Descripción API

  • Operación de creación (POST):
    1. Prueba la capacidad de la API para crear nuevos autores, libros, usuarios y otros utilizando datos de entrada válidos.
    2. Verifica que se devuelven respuestas de error apropiadas para datos inexistentes o no válidos.
    3. Valida que los datos recién creados se almacenan correctamente en el sistema.
  • Operación de lectura (GET):
    1. Prueba la capacidad de la API para recuperar datos según varios criterios (por ejemplo, ID de usuario, nombre del autor, nombre del libro).
    2. Verifica que la API devuelve los datos correctos en respuesta a las solicitudes de lectura.
    3. Prueba el correcto manejo de datos inexistentes o no válidos.
  • Operación de actualización (PUT):
    1. Prueba la capacidad de la API para actualizar datos existentes con datos nuevos válidos.
    2. Verifica que la API rechaza las solicitudes de actualización no válidas con respuestas de error adecuadas.
    3. Valida que los datos se modifican correctamente en el sistema después de las actualizaciones.
  • Operación de eliminación (DELETE):
    1. Prueba la capacidad de la API para eliminar datos proporcionando criterios válidos (libro o ID de usuario).
    2. Verifica que la API devuelve respuestas adecuadas después de una eliminación exitosa.
    3. Valida que los datos eliminados sean eliminados del sistema.

Alcance

Alcance del plan de prueba para FakeRESTApi:

  • Pruebas funcionales:
    1. Verifica la corrección y funcionalidad de todos los puntos finales de API según la documentación de API.
    2. Prueba varios escenarios para la creación, modificación y eliminación.
    3. Valida los mecanismos de autenticación y autorización de usuarios para endpoints protegidos.
    • Validación de datos:
      1. Asegurar que la API valide correctamente los datos de entrada, rechazando solicitudes no válidas.
      2. Probar los valores de límite de los campos de entrada para comprobar si hay algún comportamiento inesperado.
      3. Validar la exactitud de los datos devueltos en las respuestas.
  • Pruebas de manejo de errores:
    1. Verifica que se devuelvan códigos de error y mensajes apropiados para solicitudes no válidas.
    2. Verifica las respuestas de error para la divulgación de información confidencial.
    3. Valida la capacidad de la API para manejar errores inesperados de forma adecuada.
    • Actuación:
      1. Evaluar el tiempo de respuesta de la API bajo cargas normales y máximas para identificar posibles cuellos de botella.
      2. Medir el rendimiento y la escalabilidad de la API para manejar solicitudes simultáneas.
  • Pruebas de seguridad:

    1. Realizar evaluaciones de seguridad para identificar vulnerabilidades como inyección SQL, XSS, etc.
    2. Validar el cumplimiento de la API con prácticas seguras de transmisión de datos (por ejemplo, HTTPS).
    3. Verifique los controles de acceso adecuados para evitar el acceso no autorizado a recursos confidenciales.
  • Pruebas de integración:
    1. Verifica las interacciones entre diferentes puntos finales y servicios API.
    2. Prueba la coherencia de los datos en todos los puntos finales relacionados.
  • Compatibilidad: Prueba la API en diferentes plataformas, navegadores y dispositivos para garantizar la compatibilidad cruzada.
  • Regresión: Realiza pruebas de regresión después de corregir errores o actualizar para garantizar que la funcionalidad existente permanezca intacta.
  • Concurrencia: Evalua el comportamiento de la API cuando varios usuarios intentan acceder y modificar reservas simultáneamente.
  • Pruebas de usabilidad:
    1. Evalúa la facilidad de uso de la API desde la perspectiva del desarrollador.
    • Actuación: Implementa monitoreo para rastrear el rendimiento de la API en tiempo real.
  • Prueba de carga: Evalúa el comportamiento de la API bajo altas cargas de usuarios simultáneos para garantizar la estabilidad.
  • Prueba de límite de velocidad: Verifica el cumplimiento de la API con las reglas de limitación de velocidad para evitar abusos.
  • Integración de terceros: Valida cualquier integración de terceros para un buen funcionamiento.
  • Revisión de la documentación:
    1. Evaluar la claridad, integridad y precisión de la documentación de la API.
    2. Verificar que la documentación de la API esté sincronizada con el comportamiento real de la API.

Entorno de prueba

  1. Los sistemas operativos y las versiones que se utilizarán para las pruebas, como Windows 10, MacOS o Linux.
  2. Los navegadores y versiones que se utilizarán para las pruebas, como Google Chrome, Mozilla Firefox o Microsoft Edge.
  3. Los tipos de dispositivos de prueba y tamaños de pantalla, como ordenadores de escritorio, portátiles, tablets y teléfonos móviles.
  4. La conectividad de red y el ancho de banda que estarán disponibles para las pruebas, como conexión Wi-Fi, celular o por cable.
  5. Los requisitos de hardware y software para ejecutar los casos de prueba, como el procesador, la memoria o la capacidad de almacenamiento específicos.
  6. Los protocolos de seguridad y métodos de autenticación que se utilizarán para acceder al entorno de prueba, como contraseñas, tokens o certificación.

El permiso de acceso y la función de los miembros del equipo que utilizarán el entorno de prueba, como testers, desarrolladores o partes interesadas.

Datos de prueba

  1. El equipo de pruebas puede crear manualmente datos de prueba (válidos, no válidos) para cubrir escenarios específicos y casos extremos.
  2. Los scripts de automatización se pueden utilizar para generar grandes volúmenes de datos de prueba de forma rápida y eficiente.
  3. La fecha de prueba se puede crear de forma manual o automática según los esquemas de API.
  4. Al probar integraciones de API, las API simuladas pueden proporcionar datos sintéticos para probar varios escenarios.
  5. Para casos de uso específicos, se pueden utilizar proveedores de datos de terceros para obtener datos del mundo real para realizar pruebas.
  6. En algunos casos, los datos depurados del entorno de producción se pueden utilizar para realizar pruebas y replicar escenarios del mundo real.

Estrategia de prueba

Paso 1

  1. El primer paso es crear escenarios de prueba y casos de prueba para las distintas funciones incluidas en el alcance. Mientras desarrollamos casos de prueba, utilizaremos una serie de diseños de prueba.
  2. Técnicas.
    • Partición de clases de equivalencia
    • Análisis de valor límite
    • Tabla de decisiones
    • Pruebas de transición estática
    • Pruebas de casos de uso
  3. También utilizamos nuestra experiencia en la creación de casos de prueba aplicando lo siguiente:
    • Predicción de error
    • Exploratorio
  4. También priorizamos los casos de prueba.

Paso 2

  1. Primero, realizaremos pruebas de humo para ver si funcionan las diferentes y/o principales funcionalidades de la aplicación.
  2. Rechazamos la compilación si la prueba de humo falla y esperaremos una compilación estable antes de realizar pruebas en profundidad de las funcionalidades.
  3. Una vez que recibimos la compilación estable, que pasa las pruebas de humo, realizamos pruebas en profundidad utilizando los casos de prueba creados.
  4. Varios recursos de prueba probarán la misma aplicación en varios entornos simultáneamente.
  5. Luego reportaremos los errores en la herramienta de seguimiento de errores y los enviaremos al desarrollador para que los resuelva.
  6. Como parte de las pruebas, realizaremos los siguientes tipos de pruebas:
    • Pruebas de humo
    • Pruebas de cordura
    • Pruebas de regresión 
    • Pruebas de usabilidad
    • Pruebas de funcionalidad
  7. Repetimos el Ciclo de Prueba hasta asegurar la calidad.

Paso 3

Seguiremos las siguientes prácticas para mejorar nuestras pruebas:

  1. Pruebas basadas en el contexto: Realizaremos pruebas según el contexto de la aplicación.
  2. Prueba de desplazamiento a la izquierda (Shift Left): Comenzaremos a realizar pruebas desde las etapas iniciales del desarrollo , no esperando al final de la entrega.
  3. Prueba exploratoria: Utilizando nuestra experiencia realizaremos Pruebas Exploratorias junto a la ejecución normal de los casos de prueba.
  4. Pruebas de flujo de un extremo a otro (End to End): Probaremos el escenario de un extremo a otro, lo que involucra múltiples funcionalidades para simular los flujos de los usuarios finales.

Procedimiento de notificación de defectos

  1. Criterios para identificar un defecto: desviación de los requisitos, problemas de experiencia del usuario o errores técnicos.
  2. Pasos para informar un defecto: usar una plantilla designada, proporcionar pasos de reproducción detallados y adjuntar capturas de pantalla o registros.
  3. Clasificar y priorizar defectos: asignar niveles de criticidad y prioridad, y asignarlos a los miembros apropiados del equipo para su investigación y resolución.
  4. Herramientas (JIRA/Test Rail) que se utilizarán para rastrear y gestionar defectos.
  5. Funciones y responsabilidades de los miembros del equipo involucrados en el proceso de informe de defectos, como los testers, los desarrolladores y el líder de pruebas.
  6. Canales de comunicación para actualizar a los interesados sobre el avance y estado de los defectos.
  7. Métricas que se utilizarán para medir la eficacia del proceso de informe de defectos: la cantidad de defectos encontrados, el tiempo necesario para resolverlos y el porcentaje de defectos que se solucionaron con éxito.

Calendario de pruebas

Se necesitarán dos sprints (un sprint = 5 días hábiles) para probar la aplicación. A continuación, se muestra el cronograma de pruebas planificado para el proyecto:

Duración del tiempo de la tarea como ejemplo:

  • Creación de plan de prueba
  • Creación de casos de prueba
  • Ejecución de casos de prueba
  • Fecha de presentación del informe resumido

Coberturas de prueba

La cobertura de prueba garantiza que todas las funcionalidades relevantes de la API se prueben adecuadamente. Mide la efectividad y la integridad del esfuerzo de prueba.

Criterios de cobertura para pruebas API:

  • Cobertura funcional:
    1. Este criterio se centra en probar todos los requisitos funcionales de la API, tal y como se especifica en su documentación y diseño.
    2. Cada endpoint y método debe probarse con varias entradas válidas e inválidas para verificar su comportamiento y respuestas.
  • Validación de datos y cobertura: Este criterio se centra en validar la exactitud de los datos devueltos por la API.
  • Coberturas de manejo de errores:
    1. En las pruebas se deben incluir diferentes escenarios de error, como entradas no válidas, errores del servidor y respuestas que limitan la velocidad.
    2. La API debe probarse minuciosamente para garantizar que maneja los errores y proporciona mensajes de error apropiados con códigos de estado adecuados.
  • Coberturas de desempeño: Se deben crear casos de prueba para simular varias cargas de usuarios y medir los tiempos de respuesta de la API y el uso de recursos.
  • Coberturas de regresión: Los casos de prueba seleccionados de varios criterios de cobertura se reutilizan para validar las partes sin cambios de la API.

Riesgo y mitigación

A continuación, se presentan algunos riesgos comunes y estrategias de mitigación para abordarlos:

  1. Documentación API deficiente o desactualizada: Priorizar la obtención de datos actualizados y precisos
  2. Mensajes de error poco claros: Implementar pruebas negativas exhaustivas para validar escenarios de manejo de errores
  3. No disponibilidad de un recurso: Planificación de recursos de respaldo
  4. Las API que dependen de API o servicios externos pueden generar incertidumbres debido a factores más allá de la API que se está probando: Utilice API simuladas o servicios virtualizados para simular el comportamiento de aplicaciones externas - dependencias durante las pruebas.
  5. Los cambios o actualizaciones de la API pueden introducir regresiones que afecten a las funcionalidades existentes o que rompan la compatibilidad con aplicaciones dependientes: Ejecute pruebas de regresión después de cada actualización y lanzamiento de versión para garantizar la compatibilidad con versiones anteriores e identificar problemas de regresión.
  6. Menos tiempo para las pruebas: Incrementar los recursos en función de las necesidades del cliente.
  7. Comunicación insuficiente y colaboración entre testers, desarrolladores y partes interesadas puede resultar en malentendidos, requisitos incumplidos: Fomentar canales de comunicación abiertos y realizar reuniones periódicas entre los equipos de pruebas y desarrollo - Involucrar a las partes interesadas al principio del proceso de prueba para recopilar comentarios y aclarar los requisitos.

Herramientas de prueba

  • Postman: Pruebas API
  • Newman: automatización de API e informes de prueba
  • JMeter: pruebas de carga y rendimiento
  • Suite Burp: pruebas de seguridad
  • JIRA: herramientas de seguimiento de errores 

Funciones y responsabilidades

Tester: Desarrollar un plan de prueba.

  1. Definir el alcance y los objetivos.
  2. Asignar tareas al equipo de pruebas y supervisar el progreso.
  3. Revisar y aprobar casos de prueba y datos de prueba.
  4. Informar el progreso y los resultados de las pruebas a las partes interesadas.

Ingeniero QA: Crear, gestionar y mantener casos de prueba.

  1. Crear, administrar y mantener datos de prueba y asegurarse de que los datos de prueba sean relevantes, precisos y cubran varios escenarios.
  2. Colaborar con los testers de API para comprender los requisitos de datos.
  3. Proporcionar comentarios al líder de control de calidad sobre el progreso y los desafíos de las pruebas.
  4. Desarrollar y mantener scripts de prueba automatizados para pruebas de API.

Ingeniero Jr SQA: Ejecutar casos de prueba y registrar los resultados de las pruebas.

  1. Validar la funcionalidad, el rendimiento y los aspectos de seguridad de la API.
  2. Identificar, informar y rastrear defectos en un sistema de seguimiento de defectos.
  3. Colaborar con los desarrolladores para reproducir y verificar los informes.

Entregables de la prueba

Entregables a cliente:

  • Plan de prueba: Detalles sobre el alcance del proyecto, estrategia de pruebas, pruebas, cronograma y resultados de pruebas.
  • Prueba funcional/Casos: Casos de prueba creados para el alcance definido.
  • Informe de defectos: Descripción detallada de los defectos identificados.
  • Informe resumido del proyecto.



Siguiente Publicación