Diferentes Tipos de Testing en el Software

Hay varios tipos de técnicas de testing que se puedes utilizar para asegurar que los cambios en el código funcionan como se espera. Sin embargo, no todos los tipos de testing son iguales y exploraremos como difieren unas de otras.

Las pruebas o testing se pueden llevar a cabo de dos maneras:

1. Manual
2. Automatizada

Una prueba manual es hecha por una persona, haciendo clicks en la aplicación o interactuand con el sotware. Esta manera de hacer pruebas es muy costoso ya que requiere que alguien configure un entorno y ejecute las pruebas por sí mismo,y puede ser propenso a errores humanos ya que el evaluador puede cometer errores tipográficos u omitir pasos en el script de testing.

Una prueba automatizada es realiada por una máquina que ejecuta un script de prueba que se escribio de antemano. Estas pruebas pueden variar en complejidad, desde verificar un solo método en una clase hasta asegurarse de que realiza una secuencia de acciones complejas en la interfaz de usuario conduzcan a los mismos resultados. Las ventajas es que es mucho más robusta y confiable que las pruebas manuales, pero la calidad de sus pruebas automatizadas depende de qué tan bien se hayan escrito sus scripts de prueba.

Podemos decir que de manera general existen dos tipos de testing:

1. Funcional. Este tipo de testing asegura que las funcionalidades de una aplicación de software son las especificadas en los requisitos. El diferenciador clave de las pruebas funcionales es que no se basa en el código fuente de la aplicación. Se puede aplicar a la UI, bases de datos, APIs, Aplicaciones Cliente/servidor, así como la seguridad y funcionamiento del programa bajo prueba, verificar si todas las opciones están disponibles o no. Puede realizar pruebas funcionales de forma manual o con la ayuda de un software, es decir, automáticamente.
2. No funcional. Este tipo de testing examina las características no funcionales de una aplicación tanto rendimiento, usabilidad, fiabilidad, entre otras. Puede realizar pruebas en esta sección que tienen una influencia sobre la base de lo que afecta el rendimiento de la aplicación. Hay varias formas de analizar los aspectos no funcionales de las aplicaciones comerciales con pruebas de software.

En esta publicación solo abordaremos el testing funcional, el no funcional lo dejaremos para otro momento.

Tipos de Testing Funcional

Pruebas Funcionales

1. Unit Testing

Tiene muchos pasos como lo muestra el tweet a continuación, es uno de los tipos de testing más importantes.

Twetter.com

Los unit test se realizan a muy bajo nivel, en componentes o funciones del software son evaluadas. Su objetivo es evaluar métodos, funciones de clases, componentes o módulos usados en el software y su finalidad es asegurar que cada elemento del software funcione como pretende que funcione. Este es el tipo de testing más pequeño posible que puede realizarse y generalmente contienen una o pocas entradas y una salida.

Este tipo de testing es realizado directamente por los desarrolladores y no es automatizado (Aunque se puede hacer en un servidor de integración continua).

2. Component Testing

Probar un modulo o un componente de manera independiente para verificar si la salida es como se esperaba, se le denomina Component Testing. De manera general las pruebas de componentes son hechas para verificar la funcionalidad y/o la utilidad de un componente pero no se limita solo a eso. Un componente puede ser cualquier cosa la cual pueda recibir entrada(s) y generar alguna salida. Por ejemplo, el modulo de codigo de una página web, alguna vista o incluso un un sistema dentro de un gran sistema tambien es un componente.

Pensemos en un Login Page, es un componente y podemos probarlo de manera separada con varias pruebas como:

1. Probar la parte de UI con respecto a el UX como es Accesible, fácil de utilizar, últil y agradable.
2. Probar la carga de la página par asegurar el performance o rendimiento.
3. Tratar el SQL injection a travez de la UI para asegurar la seguridad.
4. Probar la funcionalidad de login con credenciales de usuario válidas e inválidas.

3. Smoke Testing

En general, este tipo de testing se refiere a una Prueba Confidencial o Prueba de Verificación porque en este testing, el equipo de pruebas verifica el sistema construido sea estable o haga de manera correcta sin ningun problema “issue” en la contrucción y para procedder a la siguiente fase de pruebas. Es una version simple de una Prueba de regresión, la cual solo se enfoca en las funciones principaes. La principal ventaja de este, es que se ejecuta rapidamente y puede encontrar algun problema critico o importante que podría estar en el sistema. Este sistema se puede hacer manual o automatizado.

Este tipo de pruebas puede ser muy útil justo después de hacer un nuevo Build y te permite decidir si o no cfunciona como se espera que funcione.

El diagrama de flujo siguiente, nos permite ver de manera gráfica como es que se lleva a cabo un Smoke Testing.

Si un una versión contruida, es decir, antes de ser publicada, pasa la prueba de Smoke, entonces se considera una versión estable.

En la versión estable el equipo de QA realiza pruebas funcionales para las características agregadas y luego realiza pruebas de regresión según la situacion. Pero si la versión no es estable. Pro ejemplo, si falla entonces la versión se rechaza y se envia al equipo de desarrollo para solucionar los problemas y crear una nueva versión.

Pongamos un ejemplo más real….

Pensemos que los desarrolladores construyen una applicación de licencia o permisos y la pasan a QA para sus pruebas. El equipo de QA examinó que la version creada requiere entre 80 y 10 casos de prueba para todos los escenarios:

1. Login
2. Mostrar recuento total de hojas y tipos
3. Pruebas del calendarion al seleccionar la fecha .
4. Seleción de Fechas
5. El usuario debería ser capaz de llenar la información requerida. P.ej. La razón de la licencia.
6. Gerente aprueba la licencia.
7. Empleado recibe notificación
8. Logout

Aquí el Testing smoke entra en escena. En luagr de probar todas las funcionalidades, decidieron probar solo las funcionalidades críticas que tenía solo 20 caso de prueba. Estos cubren los siguientes escenarios:

1. Login
2. Selección de fecha
3. Llenado de detaller
4. Petición enviada al gerente después de dar click al botón.

Como se puede observar, se han tomado solo las características principales para las pruebas que eran críticas. Dado que si un empleado no puede seleccionar la fecha, no hay necesidad de realizar más pruebas. Esto ahorra tiempo a los desarrolladores para corregir errores.

4. Integration Testing

En un test de integración, los componentes individuales son integrados y evaluados en conjunto.

Este nivel de testing se realiza para revelar fallas en la integración de las unidades integradas como exponer errores de lógica que pueden estar presentes en el sistema. También se conose como I&T (Integration and Testing). En otras palabras, es conocido como bottom to up testing “prueba de abajo hacia arriba” donde las unidades separadas son combinadas y probadas como una función entera o entidad completa al final.

Por ejemplo, se puede hacer un test en la interación con la base de datos o estar seguro que los microservicios funcionan juntos como se esperaba.

Este tipo de validaciones son más costosas para ejecutarse, dado que requiere de la union de multiples partes de la aplicación y ejecutarse en conjunto.

Para llevar a cabo pruebas de integración como un paso inicial el equipo de QA debe de preparar un plan de testing que incluya casos de rueba y scripts.

Despues de todos los casos de prueba definidos deberán rastrear y volver a probar el defecto encontrado a partir de los resultados de las pruebas.

5. Regression Testing

Est tipo de pruebas es un paso muy importante para un desarrollo de sotware y es muy util y ayuda de manera significativa a los desarrolladores en determinar la estabilidad del producto cuando se necesiten hacer modificaciones. Este se asegura que las actualizaciones del sistema no affecten las funciones actuales del producto. Además permite a los desarroladores a crear pruebas, hasya que la aplicación este libre de errores “bug-free”. Las pruebas de regresion sigue ciegamente algunas técnicas, como volver a probar todo donde hay una nueva prueba de aplicación hasta que esté libre de errores. Para llevar acao las pruebas de regresión, se requiere depurar el código de todos los errores que existan y luego seleccionar los casos y escenarios de prueba adecuados para realizar la prueba.

6. Sanity Testing

Cuando un nueva versión es creada con la menor cantidad de modificaciones, en lugar de realizar una prueba de regresión , se realiza este tipo de testing. Determina que las modificaciones realmente han solucionado los problemas y que las correcciones no han introducido más problemas. Estas pruebas son un subtipo de regression testing y un grupo de caso de prueba son ejecutados los cuales están relacionados a los cambios hechos al producto. Muchos Testest confunden este test con el Smoke testing. pero con la siguiente imagen se puede entender la diferencia:

El ejemplo anterior, del sistema de gestión de licencias.

Supongamos que los desarrladores han lanzado una version 2 con algunas nuevas funcionalidades. Ahora, en primer lugad debemos de realizar una prueba de soke y verificar la funcionalidad en general funciona correctamente.

Aquí asumimos que la versión 2 ha pasado la prueba de smoke. Reportamos que le problema de la “seleción de fecha” de la versión 1 se resolvió en la versión 2. Las pruebas de Sanity solo probaremos la funcionalidad “Selección de fecha” y si afecta a otras funcionalidades.

7. System Testing

Las pruebas del sistema son pruebas realizadas en un sistema completo e integrado para evaluar su cumplimiento con los requisitos especificados.

Después de la finalización de las pruebas de integración, el producto se pasa para las pruebas del sistema. Las pruebas del sistema las llevan a cabo evaluadores independientes que no han desempeñado ningún papel en el desarrollo del programa. Esta prueba se realiza en un entorno que refleja fielmente la producción. La prueba del sistema es muy importante porque verifica que la aplicación cumpla con los requisitos técnicos, funcionales y comerciales establecidos por la parte interesada.

En nuestro ejemplo, podemos realizar pruebas del sistema cuando todos los módulos se desarrollan y pasan la integración con éxito. Por ejemplo, el producto completo puede incluir funciones como solicitud de licencia, informes, detalles de los empleados, seguimiento del rendimiento, etc.

8. User Acceptance Testing

Las pruebas de aceptación del usuario (UAT) es la ultima prueba en el proceso de desarrollo del software. En esta, usuarios reales prueban el sistema para asegurarse que puede manejar las tareas requeridas en escenarios del mundo real.

Generalmente, se realiza en el momento de la entrega del producto a las partes interesadas como punto de control final entre todos los tipos de pruebas funcionales.

Desde el inicio hasta la implementación, el software/aplicación se somete a varios tipos de pruebas por parte del equipo de pruebas y los desarrolladores. El objetivo final de todos los esfuerzos es ofrecer un software/aplicación funcional que cumpla con los requisitos de los usuarios y las expectativas del cliente. Ambos equipos se familiarizaron tanto con la aplicación que podrían convertirse en víctimas de la visión de túnel. Son plenamente conscientes de las soluciones alternativas y pueden omitir ciertos escenarios que pueden ser críticos para los usuarios finales.

That’s all Folks!