Diferencias entre QA, QC y testing en SDLC
Estos términos están relacionados, pero no son intercambiables, de tal manera que vamos a ver la definición de cada uno de ellos.
La relación entre QA, QC, y Testing es de naturaleza jerárquica donde en lo alto de pirámide estaría QA. Su objetivo es planificar y establecer los procesos de evaluación de calidad. QC o control de calidad especifica la implementación de los procesos de QA. Como parte de QC, el testing es una manera de tener una imagen de la calidad del software para comprobar los resultados de los procesos de control de calidad implementados.
Quality Assurance
QA o quality assurance, son un conjunto de métodos y actividades diseñados para garantizar que el software desarrollado corresponda con todas las especificaciones.
QA busca formas de prevenir posibles errores en el proceso de desarrollo de software y va a estar durante todo el ciclo de vida de este.
Algunas actividades pueden ser: creación de checklist de procesos, estandarización de procesos, documentación de procesos, elección de herramientas.
Quality Control
El control de calidad se centra en la calidad del producto. Su principal objetivo es asegurar la correcta implementación de los procesos establecidos en la etapa de QA. Las actividades de control de calidad son necesarias para encontrar problemas de software.
El control de calidad incluye la revisión del producto de acuerdo con los requisitos definidos. En comparación con el proceso de QA, el control de calidad requiere más tiempo. La eficacia del control de calidad depende únicamente de un equipo de testing.
Algunas actividades pueden ser: entrega y creación de informes de calidad, elección de herramientas y por supuesto el propio testing.
Testing
El testing es un proceso de verificación de diferentes atributos de un sistema y sus posibles usos para asegurarse que el producto funcione como se espera y que no realice ninguna función que no se espere. El testing es una parte del control de calidad y tiene varias técnicas o tipos de pruebas para detectar problemas en el software o aplicativo. Además, el objetivo del testing también es asegurarse de que los errores detectados se solucionen por completo sin efectos colaterales.
QA, QC y testing en SDLC
Planificación y análisis de requerimientos
Un QA puede señalar posibles problemas o carencias de la experiencia del usuario que incluso pueden afectar la decisión del equipo de seguir adelante con una nueva funcionalidad o no. Tener expertos en QA involucrados en la fase de planificación puede ahorrar tiempo y dinero. Incluso si la colaboración del QA en esta fase no genera cambios, tener una vista previa de las nuevas funcionalidades que se van a desarrollar puede ayudar a planificar los casos de prueba.
Diseño
Cuando QA está involucrado en la fase de diseño, puede identificar aspectos del diseño que podrían causar problemas, mientras aún están en progreso. Esto permite que se puedan hacer cambios sobre la marcha.
Implementación
En programación, casi siempre hay más de una forma de implementar una nueva funcionalidad.
Por ejemplo, un desarrollador está pensando en cómo implementar una sección de una página con uso intensivo de datos. Tal vez una forma de hacerlo tardaría más en cargarse, pero se vería mejor una vez que lo hiciera.
Por otro lado, otra forma de implementarlo podría cargar más rápido, pero no incluir tantas opciones. El QA podría evaluar los impactos potenciales en la experiencia del usuario o sugerir el uso de una animación de carga para compensar cualquier retraso.
Testing
El rol del QA en testing puede parecer obvio, pero hace más que solo probar en la fase de testing. Desde escribir casos de prueba hasta reporte de errores, gran parte del tiempo de un QA tester también se dedica a otras actividades. Además de probar minuciosamente la aplicación por supuesto. Estas otras actividades incluyen:
- Análisis y diseño de casos de prueba. Esto implica hacer análisis de la documentación o criterios de aceptación para crear los casos de prueba. Se puede hacer incluso si la funcionalidad no tiene criterios de aceptación claros o documentación. Hay ocasiones en las que hay que investigar tanto lo que se va a probar, como a quién se tiene que preguntar.
- Reportar errores/bugs. Esta no es solo una descripción rápida de un error encontrado. Normalmente, hay pasos para reproducir, capturas de pantalla o gifs para adjuntar o detalles del entorno como la versión.
- Seguimiento de todas las versiones o pases que salen.
Despliegue
Durante un despliegue, el QA está a la espera. Según se termine el despliegue, se realizan pruebas de humo para asegurarse de que la implementación de la nueva versión no haya causado ningún problema.
Mantenimiento
A veces, hay errores que se escapan, incluso con la mejor automatización y/o las pruebas manuales más intensas, no se puede encontrar el 100 % de los errores en el 100 % de los de los casos. El QA probará las correcciones de errores, las actualizaciones de las funcionalidades y las nuevas funcionalidades.
Tipos de pruebas en testing
Funcionales
Las pruebas funcionales son un proceso de control de calidad para asegurar que todo funciona correctamente en base a unos requerimientos funcionales.
Hay muchos tipos, algunos de ellos son:
Pruebas unitarias
Las pruebas unitarias se centran en comprobar el funcionamiento individual de cada unidad de código.
Es una forma efectiva de comprobar el correcto funcionamiento de las unidades individuales más pequeñas de los programas informáticos. Esto sirve para asegurar que cada unidad funcione correcta y eficientemente por separado.
Prueba de humo
Las pruebas de humo se realizan para verificar si las funcionalidades más significativas de la aplicación funcionan o no. Son pruebas sencillas y rápidas que pasan por caminos críticos.
Es una de las pruebas funcionales más importantes y debería ser la primera que se realice en una nueva versión. No se trata de realizar pruebas exhaustivas sino de verificar que la funcionalidad crítica del sistema funcione bien.
Si la prueba es exitosa será entonces una versión estable. El equipo QA realizará pruebas para las nuevas funcionalidades que se hayan incluido. Por otro lado, si esta no es estable y falla, lo normal sería que se devuelva al equipo de desarrollo para solucionar los problemas de la versión y crear una nueva revisión de la misma.
Pruebas de integración
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 simultáneamente y no se centran en otros. Las pruebas de integración permiten que los datos fluyan entre módulos. 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, llamadas a APIs, acceso a bases datos, entre otras.
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 colaterales inesperados en su comportamiento. Estas pruebas de regresión se realizan para asegurar que los cambios 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 versión existente y así garantizar que los errores eliminados continúen así.
Pruebas de aceptación del usuario
Estas pruebas se hacen en la última fase de este proceso de testing. Aquí los usuarios reales del software lo usan 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.
No Funcionales
Las pruebas no funcionales son aquellas que buscan identificar la manera en que un sistema opera, no en la funcionalidad en sí. Este tipo de pruebas pueden ayudarnos a determinar la carga que soporta la versión, si su rendimiento es el correcto o si está estable, si nuestro sistema es un cuello de botella cuando llama a la base de datos o qué rendimiento tiene de cara al usuario final.
Hay muchos tipos también, algunos de ellos son:
Pruebas de carga
Las pruebas de carga consisten en simular una serie de accesos sobre un software y medir el resultado. Estas pruebas se realizan bajo demanda esperada y también en condiciones de sobrecarga.
Estas ayudan a identificar la máxima capacidad operativa de una aplicación, identificando cuellos de botella y las causas de posible degradación del servicio.
Pruebas de seguridad
Relacionadas con el hacking ético, detectar vulnerabilidades y auditoria de buenas prácticas, comprueban los atributos o características de seguridad del sistema, si es un sistema seguro o no, si puede ser vulnerado, si existe control de acceso por medio de cuentas de usuario, si pueden ser vulnerados estos accesos.
Pruebas de rendimiento
Determinan problemas de concurrencia, escalabilidad o carga, entre otras cosas. Se utiliza para ver la velocidad, estabilidad, tiempo de respuesta y el uso de recursos de un sistema de software bajo una carga de trabajo particular.
Pruebas de estrés
Están relacionadas con las pruebas de carga ya que, si se eleva por encima de los parámetros esperados, a estas pruebas se les conoce como pruebas de estrés. Con las pruebas de estrés se pueden identificar los puntos de ruptura, límites para uso seguro de la aplicación, confirmar las especificaciones de diseño, identificar las formas en que el sistema falla, entre otras muchas validaciones.
Pruebas de volumen
Comprueban que el funcionamiento de la aplicación con ciertos volúmenes de datos es adecuado. Estas pruebas no están limitadas a bases de datos, también se pueden usar, por ejemplo, para medir el desempeño de una interfaz en el supuesto de que un archivo supera un tamaño estipulado.
El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad, cuáles son los límites máximos de volúmenes de datos para la operación e identificar las condiciones en las que falla.
Pruebas de usabilidad
Son aquellas que validan cuanto es de fácil usar el software de cara a los usuarios finales. Por ejemplo, comprobar que en un desplegable con muchas opciones exista un buscador.
Conclusiones
Se debería dar más importancia en general a la figura o proceso de QA e intentar integrarlo en todas las fases del ciclo de vida de desarrollo, puede aportar mucho. En Dev&Del estamos muy concienciados en esto y de hecho estamos aplicando ya técnicas y procesos para ello.
¿Te ha parecido interesante lo que te he comentado? Puedes leer más artículos relacionados en: