Tipos de pruebas funcionales para el aseguramiento de la calidad

Escrito por Connie Vargas

tipos-de-pruebas-de-software

¿Buscando implementar pruebas funcionales? Te contamos los tipos de pruebas que se realizan bajo esta metodología de pruebas de software y cuándo realizarlas durante este ciclo de desarrollo.

Antes que nada, si poco conoces de estas pruebas, debes saber que las pruebas funcionales son una práctica beneficiosa cuando nos referimos al proceso del desarrollo. De esta manera puedes tener el progreso del proyecto para la administración en las pruebas funcionales aprobadas y reprobadas.  Aquí se facilita la comunicación entre desarrolladores, analistas y evaluadores. Hardik Shah, nos explica cómo funcionan de manera detallada.

Con este tipo de prácticas, verás menos reprocesos y verás un aumento en la velocidad de desarrollo ya que se comunican de manera eficiente los requerimientos.  Aquí nos enfocaremos en el alcance de las diferentes pruebas funcionales y cuando realizarlas, por ejemplo: “la prueba de humo se realiza en cada compilación entregada a QA porque verifica la funcionalidad a un alto nivel, mientras que la prueba de regresión se realiza cuando los errores se corrigen en versiones posteriores”

Tipos de pruebas funcionales

  • Pruebas unitarias
  • Pruebas de componentes
  • Pruebas de humo
  • Pruebas de integración
  • Pruebas de regresión
  • Pruebas de cordura
  • Pruebas de aceptación
Ir arriba

Pruebas unitarias

Las pruebas unitarias son las que aseguran que cada célula del código desarrollado en un componente brinde los resultados adecuados. En estas pruebas los desarrolladores observan la interfaz y la especificación de un componente, proporcionando la documentación del desarrollo del código se prueba exhaustivamente de forma independiente antes de pasar a otra unidad.

Las pruebas unitarias admiten pruebas funcionales al ejercer el código que es más probable que se rompa. Por ello, si usas pruebas funcionales sin pruebas unitarias, puedes experimentar algunas dificultades para diagnosticar pruebas fallidas.

Ir arriba

Prueba de componentes

Las pruebas de componentes se ejecutan de forma independiente para comprobar que el resultado sea el requerido.  Su objetivo es verificar las funcionalidades y/o usabilidades de los componentes, aunque no solo se limite a ello.

Un ejemplo de esta prueba puede ser cualquier elemento que tenga entrada y deba generar alguna salida, como el módulo de código, página web, pantallas e incluso un sistema dentro de un sistema más grande es un componente. Shah nos trae un ejemplo de que componentes probar:

  • Prueba de UI para usabilidad y accesibilidad
  • Prueba de carga para asegurar el rendimiento
  • Inyección de SQL a través de componentes de UI para asegurar la seguridad
  • Prueba de login con credenciales válidas e inválidas
Ir arriba

Prueba de humo

Las pruebas de humo se realizan para verificar si las funcionalidades más significativas de la aplicación funcionan o no, de forma que lo más básico del software se ejecute de forma correcta con pruebas sencillas y rápidas.

Es una de las pruebas funcionales más importantes y debería ser la primera que se realice en una nueva compilación. La prueba de humo se realiza comúnmente y aunque a veces no se tiene claro su concepto, no se trata de realizar pruebas exhaustivas sino verificar que la funcionalidad crítica del sistema funciona bien.

Si la prueba es exitosa será entonces una compilación estable, por lo que el equipo QA realizará pruebas funcionales para las características o funcionalidades recién agregadas; posteriormente las pruebas de regresión según la situación.   Por otro lado, si esta no es estable y falla la compilación será devuelta al equipo de desarrollo para solucionar los problemas de compilación y crear una nueva.

Amplia tu conocimiento con el ejemplo que nos trae Hardik de forma detallada.

Ir arriba

Pruebas de integración

La prueba de integración es un tipo de prueba funcional más común y se realiza de forma automatizada. Se realizan para probar componentes individuales con el objetivo de verificar cómo los módulos que trabajan de forma individual funcionan cuando estén integrados.

El objetivo de realizar estas pruebas es porque comúnmente los desarrolladores se enfocan en construir diferentes módulos del sistema simultáneamente y no se centran en otros. Las pruebas de integración permiten que los datos y comandos operativos fluyan entre módulos, para hacer que todo actúe como partes de un solo sistema en lugar de aplicativos aislados. Usualmente nos ayuda a identificar problemas en las operaciones de la interfaz de usuario, formatos de datos, invocar API, acceso a bases datos, entre otras.

Algunas de las verificaciones que se realizan en las pruebas de integración son:

Prueba de interfaz: comprobación de las transferencias de datos entre dos componentes. Prueba de interfaces como servicios web, API, entre otros. Se realiza para verificar que los componentes estén sincronizados entre sí. Ayudan a determinar que diferentes funciones, como la transferencia de datos entre los diferentes elementos del sistema, se realizan de acuerdo con la forma en que fueron diseñadas.

Ir arriba

Pruebas de regresión

Es normal que los desarrolladores modifiquen y mejoren las funcionalidades de su desarrollo; por ello existe una gran posibilidad de que puedan causar ‘efectos’ inesperados en su comportamiento. Estas pruebas de regresión se realizan para asegurar que los cambios o adiciones no hayan alterado ni eliminado las funcionalidades existentes.

El objetivo de las pruebas de regresión es encontrar errores que puedan haber sido introducidos accidentalmente en la compilación existente y así garantizar que los errores eliminados continúen así.

Ir arriba

Prueba de cordura

Si tienes una compilación con modificaciones menores, en vez de ejecutar las pruebas de regresión, realizamos una prueba de cordura.

Con ella podemos determinar que las modificaciones realmente hayan solucionado los problemas, y que dichas correcciones no hayan generado ningún problema. Usualmente, estas pruebas son subpruebas de la de Regresión que está relacionado con los cambios realizados en el producto. No confundas estas pruebas con las de humo con las de cordura porque:

Las pruebas de humo se inician en la compilación desde el inicio y se inspeccionan las funcionalidades más importantes, mientras que las de cordura analizan profundamente las compilaciones de software.  Es decir, las primeras confirman la estabilidad del producto, mientras que las segundan aseguran la racionalidad del producto.

Ir arriba

Pruebas de aceptación del usuario

Cuando ya hemos seguido e implementado las pruebas que requerimos para nuestro producto, realizar las pruebas de aceptación hacen parte de la última fase de este proceso de testing. Aquí los usuarios reales del software hacen uso de este para verificar que cumpla con las tareas requeridas en un ambiente ‘real’. En ocasiones se realiza cuando se hace la entrega del producto “como punto de control final entre todos los tipos de pruebas funcionales”

Desde el inicio hasta la implementación, el software deberá someterse a varios tipos de pruebas para asegurar la calidad para evitar reprocesos y garantizar las funcionalidades de la aplicación, tanto para el usuario final, como para el cliente.

De esta manera, pudiste identificar las pruebas QA más importantes que puedes implementar para llevar a otro nivel tus desarrollos, productos y/o aplicaciones. Así podrás cumplir con los requerimientos del cliente y entregar soluciones funcionales y de calidad. Conoce más sobre nuestro servicio de Pruebas de Software QA para el aseguramiento de calidad