Guía rápida de QA

Bienvenido a nuestra guía introductoria de Control de Calidad (QA) y Testing. En el desarrollo de software, la calidad es un aspecto fundamental que determina el éxito y la satisfacción del usuario final. En este documento, exploraremos los conceptos básicos de QA y Testing, su importancia en el ciclo de vida del desarrollo de software, y las mejores prácticas para garantizar la entrega de productos de alta calidad.

Pruebas

Verificar la funcionalidad o el comportamiento de una aplicación frente a la aplicación de software se conoce como prueba.

La ejecución de un programa con la intención de encontrar defectos se conoce como Prueba.

Principios de prueba

1. Las pruebas muestran la presencia de defectos.
2. Las pruebas exhaustivas son imposibles.
3. Pruebas tempranas.
4. Agrupación de defectos. Es decir, un pequeño número de módulos contiene la mayoría de los defectos detectados.
5. Paradoja del pesticida. Para superar esto, los casos de prueba deben revisarse o revisarse periódicamente. Agregar casos de prueba nuevos o diferentes le ayudará a encontrar una mayor cantidad de defectos.
6. Las pruebas dependen del contexto. La forma de probar una aplicación comercial será diferente de la forma de probar una aplicación comercial lista para usar.
7. La ausencia de errores es una falacia. es decir, encontrar y reparar defectos no ayuda si la construcción del sistema es inutilizable y no satisface las necesidades o requisitos del usuario.

SDLC (Ciclo de vida de desarrollo de software)

Modelo de cascada

Requisitos --> Análisis --> Estudio de Viabilidad --> Diseño --> Codificación --> Pruebas --> Implementación --> Mantenimiento

Requisito

Esto lo realiza el analista de negocios. Tiene que recopilar todos los requisitos relacionados con el proyecto del cliente.

Análisis

Durante el Análisis, si tenemos alguna duda, estamos preparando un documento de Análisis de Impacto o un documento de Análisis de Idoneidad. En este documento dejaremos escritas todas nuestras dudas y los requisitos que necesitan mayor aclaración. BA tiene que aclarar todas nuestras dudas.

Estudio de factibilidad

Esto lo hace un grupo de personas como Arquitectura, Recursos Humanos, Gerente de Finanzas, Gerente de Proyecto.

1. La arquitectura dice sobre las tecnologías que son buenas para el proyecto. RR.HH. dice sobre los recursos disponibles para el proyecto.
2. El Gerente de Finanzas estima el costo del proyecto.
3. El director de proyecto debe conocer los conocimientos básicos de todas estas personas.

Diseño

Es de dos tipos.

1> HLD (Diseño de alto nivel) 2> LLD (Diseño de bajo nivel)

DAN

-> Lo realiza el arquitecto del sistema.

-> Habla brevemente sobre el software.

LLD

-> Lo realiza un desarrollador senior.

-> Da los detalles en términos de diagramas de flujo.

Codificación y pruebas

La codificación la realiza el desarrollador y las pruebas las realizan los evaluadores.

Implementación

Lo hace el desarrollador senior.

Capacita a algunas personas del lado del cliente sobre el proyecto.

Mantenimiento

En esta fase, el director del proyecto crea un equipo llamado CCB (Change Control Board) con algunos representantes. Reciben solicitudes de cambio de S/W del cliente.

1. Desventaja: Aquí los requisitos son fijos. No podemos cambiar los requisitos.
2. Aplicable: Para proyectos a corto plazo podemos implementar el modelo en cascada.

Modelo Espiral

El modelo en espiral funciona de forma iterativa.

Este modelo da más énfasis al análisis de riesgos.

La mayoría de los proyectos grandes y complicados adoptan el modelo en espiral.

Cada iteración comienza con una planificación y finaliza con la evaluación del producto por parte del cliente.

1. Planificación: Recopilación de requisitos, Estimación de costos y Asignación de recursos.
2. Análisis de riesgo: Fortalezas y debilidades del proyecto.
3. Diseño: Desarrollo, Pruebas Internas y Despliegue de Código.
4. Evaluación: Evaluación del cliente del producto para obtener retroalimentación.

Ventajas

1. Permite cambios de requisitos.
2. Adecuado para proyectos grandes y complicados. Permite un mejor análisis de riesgos.
3. Rentable gracias a una buena gestión de riesgos.

Desventajas

1. No apto para proyectos pequeños.
2. El éxito del proyecto depende de la fase de análisis de riesgos. Hay que contratar recursos con más experiencia para el análisis de riesgos.

Modelo V&V (Verificación y Validación)

Supera las desventajas del modelo en cascada. En el modelo en cascada, hemos visto que los evaluadores participan en el proyecto en la última fase del proceso de desarrollo.

En esto, los evaluadores involucran las primeras fases del SDLC. Las pruebas comienzan en las primeras etapas del desarrollo del producto, lo que evita el flujo descendente de defectos, lo que a su vez reduce muchas reelaboraciones.

Ambos equipos (desarrollo y pruebas) trabajan en paralelo. El equipo de pruebas trabaja en diversas actividades, como preparar la estrategia de prueba, el plan de prueba y el caso de prueba, mientras que el equipo de desarrollo trabaja en SRS, diseño y codificación.

Los resultados son paralelos en este modelo.

1. Una vez que el cliente envía BRS/CRS (Especificación de requisitos comerciales), ambos equipos comienzan sus actividades. Los desarrolladores traducen BRS a SRS. El equipo de pruebas participa en la revisión de BRS para encontrar los requisitos faltantes o incorrectos y redacta el plan de prueba de aceptación y los casos de prueba de aceptación.
2. En la siguiente fase, el equipo de desarrollo envía el SRS al equipo de pruebas para su revisión y el equipo de desarrollo comienza a trabajar en HLD del producto. El equipo de pruebas participa en la revisión del SRS y redacta el plan de prueba del sistema y los casos de prueba del sistema.
3. En la siguiente fase, el equipo de desarrollo comienza a trabajar en el LLD del producto. El equipo de pruebas participa en la revisión del HLD y redacta el plan de prueba de integración y los casos de prueba de integración.
4. En la siguiente fase, el equipo de desarrollo comienza con la codificación del producto. El equipo de pruebas participa en la revisión de LLD y redacta planes de pruebas funcionales y casos de pruebas funcionales.
5.  En la siguiente fase, el equipo de desarrollo entrega la compilación al equipo de pruebas una vez finalizadas las pruebas unitarias. Las pruebas llevan a cabo pruebas funcionales, pruebas de integración, pruebas del sistema y pruebas de aceptación en la versión lanzada paso a paso.

Ventajas

 Como los entregables son paralelos, lleva menos tiempo completar el proceso.

Desventajas

 La inversión inicial es mayor porque el equipo de pruebas participa desde la etapa inicial.

Modelo prototipo

Requisitos -> Análisis -> diseño y desarrollo de prototipos -> prueba de prototipos -> Revisión del cliente -> diseño -> codificación -> pruebas -> implementación -> Mantenimiento

Después de recopilar los requisitos del cliente, el equipo de desarrollo diseña y desarrolla un modelo ficticio. El equipo de pruebas prueba el modelo ficticio. Se enviará al cliente para su aprobación. Una vez que el cliente dé la aprobación, podremos comenzar a trabajar en el proyecto original.

Si el cliente es nuevo en el software y el desarrollador es nuevo en el dominio, entonces podemos adoptar este modelo de prototipo.

Metodología ágil Scrum

En scrum, el proyecto se divide en sprint. Cada sprint debe tener un tiempo específico.línea (2 semanas a 1 mes). 

Este cronograma será acordado por el equipo scrum durante la reunión de planificación del sprint. Aquí las historias de usuarios se dividen en diferentes módulos. El resultado final de cada sprint debería ser un producto potencialmente comercializable.

Los tres aspectos más importantes de la metodología ágil scrum son

-> Roles -> Artefactos -> Reuniones

Funciones

Dueño del producto: El propietario del producto suele representar al cliente. Actúa como SPOC del lado del cliente. Él es elalguien que prioriza la lista de elementos de la cartera de productos que el equipo scrum debe terminar y publicar.

Maestro de scrum: Scrum master actúa como facilitador del equipo de desarrollo de scrum. Aclara las consultas y organiza al equipo a partir de las distracciones y les enseña cómo usar scrum y se concentra en el ROI.

Equipo de desarrollo de Scrum: Desarrolladores y Testers que desarrollan el producto. El desarrollo de Scrum decide la estimación del esfuerzo para completar un elemento de la cartera de productos.

Equipo Scrum: También incluye Scrum Master. El tamaño del equipo no debe exceder los 12 miembros.

Artefactos

Historias de usuarios: Las historias de usuarios no son como los documentos de requisitos tradicionales. En las historias de usuarios, las partes interesadas mencionan qué funciones necesitan o qué quieren lograr.

Pila de Producto: Product Backlog es un repositorio donde el propietario del producto almacena y mantiene los elementos del backlog del producto. El propietario del producto prioriza la lista de elementos de la cartera de productos como alta o baja.

Trabajo pendiente de sprint: Grupo de historias de uso en las que el equipo de desarrollo de scrum acordó trabajar durante el sprint actual.

Burndown de productos: Un gráfico que muestra cuántos elementos de la cartera de productos están completados o no completados.

Gráfico de quemado de Sprint: Un gráfico que muestra cuántos sprints se implementaron/no se implementaron.

Gráfico de lanzamiento de versiones: Un gráfico que muestra la lista de lanzamientos aún pendientes. Qué equipo scrum ha planeado.

Gráfico de reducción de defectos: Un gráfico que muestra la lista de defectos planteados.y arreglado.

Reuniones

Reunión de planificación de sprint: El primer paso del scrum es la reunión de planificación del sprint a la que asiste todo el equipo.Aquí, el propietario del producto selecciona los elementos del trabajo pendiente del producto del trabajo pendiente del producto.

Las historias de usuario más importantes en la parte superior de la lista y las menos importantes en la parte inferior.El equipo Scrum decide Y proporciona la estimación del esfuerzo.

Reunión Scrum Diaria (Stand-up Diaria): Aquí cada miembro del equipo informa al miembro del equipo de pares sobre lo que hizo ayer, lo que va a hacer hoy y qué obstáculos son inminentes en su progreso. Esta reunión no deberá exceder más de 15 minutos.

Revisión de sprint: En la reunión de revisión del sprint, el equipo de desarrollo de scrum presenta una demostración de un producto potencialmente comercializable. El propietario del producto declara qué elementos están completados y no completados.

El propietario del producto puede agregar elementos adicionales al trabajo pendiente del producto en función de los comentarios de las partes interesadas.

Reunión retrospectiva de Sprint: El equipo Scrum se reúne nuevamente después de la reunión de revisión del sprint y documenta las lecciones aprendidas.

en el sprint anterior, como "Qué salió bien", "Qué se podría mejorar". Ayuda al equipo scrum a evitar errores en los próximos sprints.

Aplicable

Cuando el cliente no tiene claros los requisitos. El cliente espera lanzamientos rápidos.

El cliente no da todos los requisitos a la vez.

 

Tipos de pruebas

Pruebas de caja negra: El diseño de software interno no se considera en este tipo de pruebas. Aquí las pruebas se basan en los requisitos y la funcionalidad.

Pruebas de caja blanca: Esta prueba se basa en el conocimiento de la lógica del código de una aplicación. También conocida como prueba Greybox. Se debe conocer el funcionamiento del software y el código interno para este tipo de pruebas. Aquí los testículos se basan en la cobertura de declaraciones de código, condiciones, rutas y ramas. Esto lo realiza el desarrollador.

Pruebas funcionales: En las pruebas funcionales, solo verificamos que la funcionalidad de la aplicación funcione como se espera según el documento de especificación de requisitos funcionales o no.

Pruebas de componentes: En las pruebas de componentes, todos y cada uno de los componentes se prueban rigurosamente.

Pruebas de integración: Probar el flujo de datos o la interfaz entre dos funciones o módulos se conoce como prueba de integración. Es de tres tipos.

1. Pruebas de integración de arriba hacia abajo
2. Pruebas de integración ascendente
3. Pruebas de integración Big Bang

Pruebas de integración: Un enfoque para las pruebas de integración en el que el componente en la parte superior de la jerarquía se prueba primero y los componentes de nivel inferior se simulan mediante stubs. Ahora los componentes probados se utilizan para probar los componentes de nivel inferior y este proceso se repite hasta que se haya probado el componente del nivel más bajo.

Pruebas de integración ascendente: Un enfoque para las pruebas de integración en el que primero se prueba el componente del nivel más bajo y luego se utiliza para facilitar las pruebas de los componentes de nivel superior. El proceso se repite hasta que se prueba el componente en la parte superior de la jerarquía.

Enfoque del Big Bang: Un enfoque de las pruebas de integración en el que todos los componentes se combinan y prueban de una sola vez se conoce como enfoque Big Bang.

Pruebas del sistema: Las pruebas del sistema se llevan a cabo en un sistema integrado completo para verificar el cumplimiento del sistema con los requisitos especificados. También se denomina prueba de extremo a extremo (E2E). p.ej

1. El usuario A inicia sesión en la aplicación con sus credenciales.
2. El usuario A hace clic en el botón "Redactar correo".
3. El usuario A proporciona una dirección de correo electrónico válida del usuario B en la sección "Para" y proporciona una línea de asunto válida y un cuerpo válido del mensaje.
4. El usuario A hace clic en el botón "Enviar".
5. El usuario A debería poder ver el mensaje de confirmación.
6.  El usuario A cierra la sesión de la aplicación.
7. El usuario B inicia sesión en la aplicación.
8. El usuario B debería poder ver el mensaje enviado por el usuario A en la parte superior de la lista.
9. El usuario B cierra la sesión de la aplicación.
10. Pruebas de aceptación del usuario

La prueba de aceptación: es un nivel de prueba de software en el que se prueba la aceptabilidad de un sistema. El propósito de esta prueba es evaluar el cumplimiento del sistema con los requisitos comerciales y evaluar si es aceptable para la entrega.

Prueba alfa: Alpha Testing es realizado por un equipo de evaluadores altamente capacitados en el entorno/sitio de desarrollo. En Alpha Testing, los desarrolladores están presentes durante las pruebas para poder registrar todos los problemas encontrados durante las pruebas. Cuando el desarrollo del software está a punto de completarse, se realizan las pruebas Alpha.

Pruebas beta: Las pruebas beta las realiza el cliente o los usuarios finales en el entorno/sitio del cliente. En Beta Testing, el cliente registra todos los problemas encontrados durante las pruebas y los vuelve a publicar al desarrollador. Después de pasar la Prueba Alfa y antes de lanzar el software, se debe realizar la Prueba Beta.

Ciclo de vida del defecto

Cuando se genera un defecto en una herramienta de seguimiento de defectos, el estado pasa a ser "Nuevo". Después, el estado debe cambiarse a "Abierto". Una vez que el defecto se asigna al líder de desarrollo, el estado pasa a ser "Asignado". El líder de desarrollo puede rechazar el defecto por tres motivos

1. Si se trata de un defecto por duplicación. Alguien lo ha planteado antes y tú lo estás planteando de nuevo. 
2. Debido a una mala comprensión de los requisitos.
3. Debido a requisitos antiguos de referencia o puede cambiar el estado a "Diferido" si el defecto es menor y puede solucionarse en la próxima versión. 

Si se trata de un defecto genuino, el responsable de desarrollo lo asigna al desarrollador en cuestión. El desarrollador tiene que solucionar el defecto y, una vez solucionado, el estado pasa a ser "Reparado". 

El desarrollador cambia el estado a "Reprobar", una vez que el defecto está listo para volver a probarse. Si la nueva prueba tiene éxito, el evaluador puede cerrar el defecto o reabrirlo y nuevamente será asignado al líder de desarrollo.

Tipos de pruebas

Se realizan nuevas pruebas para garantizar que un defecto en particular se haya solucionado o no. O

Se vuelven a realizar pruebas para garantizar que los casos de prueba que fallaron en la última ejecución se aprueben después de que se solucionen los defectos de esas fallas.

Pruebas de regresión

La reejecución de los mismos casos de prueba en diferentes versiones para garantizar que cualquier modificación, adición o eliminación de código no afecte las áreas o características no modificadas se conoce como prueba de regresión.

Se realizan pruebas de regresión para garantizar que las funciones existentes o no modificadas no se vean afectadas debido a las correcciones de errores.

Prueba de humo

Las pruebas de humo no son más que validar que las funciones principales y críticas de la aplicación funcionan como se esperaba o no. También se denomina BVT (/prueba de verificación de compilación). El objetivo es rechazar una aplicación muy defectuosa para que el equipo de control de calidad no pierda tiempo instalando y probando la aplicación con errores.

Sanity Testing

Sanity Testing es un tipo de prueba de software que se realiza después de recibir una compilación con cambios menores en el código o la funcionalidad para garantizar que los errores se hayan corregido y que no se introduzcan más problemas debido a estos cambios. El objetivo es determinar que la funcionalidad propuesta funciona más o menos como se esperaba. Si falla la cordura, la compilación se rechaza para ahorrar tiempo y costos involucrados en pruebas más rigurosas.

El objetivo no es verificar a fondo la nueva funcionalidad, sino determinar que el desarrollador ha aplicado cierta racionalidad (cordura) al producir el S/W.

Pruebas no funcionales

Las pruebas no funcionales son un tipo de prueba para comprobar los aspectos no funcionales (rendimiento, usabilidad, confiabilidad, escalabilidad, portabilidad, etc.) de una aplicación de software. Está diseñado para probar la preparación de un sistema según los parámetros no funcionales que nunca se abordan en las pruebas funcionales.

Pruebas de rendimiento

Verificar la estabilidad y el tiempo de respuesta de una aplicación aplicando carga se conoce como prueba de rendimiento.

Prueba de carga

Verificar la estabilidad y el tiempo de respuesta de una aplicación aplicando una carga menor o igual al número deseado de cargas.

Pruebas de estrés

Verificar la estabilidad y el tiempo de respuesta de una aplicación aplicando una carga mayor que la cantidad deseada de cargas se conoce como prueba de estrés.

Prueba de volumen

Verificar la estabilidad y el tiempo de respuesta de una aplicación con una gran cantidad de datos se conoce como prueba de volumen.

Pruebas de accesibilidad

Probar una aplicación desde el punto de vista de una persona con discapacidad física, es decir, si una persona con discapacidad física podrá acceder a la aplicación de software o no, se conoce como prueba de accesibilidad.

Pruebas de seguridad

Probar qué tan bien protege un sistema contra daños o accesos internos o externos no autorizados se conoce como prueba de seguridad.

Pruebas de localización (L10N)

Las pruebas de localización consisten en realizar los cambios necesarios en el software de una región en particular para adaptarse a los requisitos naturales, culturales o lingüísticos de esa región.

Pruebas de Internacionalización (I18N)

Las pruebas de internacionalización consisten en crear múltiples versiones de un software para satisfacer los requisitos naturales, culturales y lingüísticos de diferentes regiones del mundo.

Pruebas de usabilidad

Probar la facilidad de uso de una aplicación se conoce como prueba de usabilidad.

Nomenclatura de defectos

Defecto

El defecto no es más que una desviación de un resultado real respecto de un resultado esperado. O

La variación entre el resultado esperado y el resultado real se conoce como Defecto.

Bug

Error es un nombre informal de un defecto.

Error

No podemos compilar o ejecutar un programa debido a un error de codificación, entonces eso se denomina error.

Falla

Una vez que se implementa el producto y el cliente encuentra algún problema, lo considera un producto defectuoso. Después del lanzamiento, si los usuarios finales encuentran algún problema, se considerará un fracaso.

Gravedad

La gravedad se puede definir como el impacto de un defecto en el negocio del cliente. En palabras simples, cuánto efecto habrá en el sistema debido a un defecto en particular.

Se puede categorizar como:

1. Crítico: Un problema de gravedad crítica es un problema en el que una gran parte de la funcionalidad o un sistema importante está completamente roto y no hay solución alternativa para avanzar más.
2. Importante: Un problema de gravedad importante es un problema en el que una gran parte de la funcionalidad o un sistema importante está completamente roto, pero existe una solución alternativa para avanzar.
3. Menor: Un problema de gravedad menor es un problema que impone cierta pérdida de funcionalidad pero para el cual existe una solución alternativa aceptable y fácilmente reproducible.
4. p.ej. Error de ortografía, familia de fuentes, tamaño de fuente, alineación de fuentes, color de fondo
5. Trivial: Un problema de gravedad trivial es un problema relacionado con la mejora del sistema.

Prioridad

La prioridad no es más que la importancia que se da para solucionar un defecto. Da el orden en el que se debe resolver un defecto. Los desarrolladores deciden qué defecto deben abordar a continuación en función de la prioridad. Se puede clasificar en alto, medio y bajo.

1. Alto: Un problema de alta prioridad es un problema que tiene un gran impacto en el negocio del cliente o un problema que afecta gravemente al sistema y el sistema no se puede utilizar hasta que se solucione el problema.
2. Medio: Los problemas se pueden solucionar y solucionar en la próxima compilación y tienen prioridad media. Estos problemas pueden resolverse con otras actividades de desarrollo.
3. Bajo: Un problema que no tiene impacto en el negocio del cliente tiene baja prioridad.

Estrategia de prueba

La estrategia de prueba identifica el mejor uso posible de los recursos y el tiempo disponibles para lograr la cobertura de prueba requerida o los objetivos de prueba identificados. Decide en qué partes y aspectos del sistema debe recaer el énfasis. La determinación de Test Startegy se basa en una serie de factores. Algunos de ellos se enumeran a continuación.

Verificación

1. El proceso de evaluar un sistema o componente para verificar si el producto de una fase de desarrollo determinada satisface las condiciones impuestas al inicio de esa fase se denomina verificación.
2. La verificación comprueba si estamos construyendo el producto correctamente.
3. Implica actividades como recorridos, inspecciones y revisiones.

Validación

1. La determinación de la exactitud del producto de desarrollo de software con respecto a las necesidades o requisitos del usuario se conoce como validación.
2. La validación comprueba si estamos creando el producto correcto.
3. Implica actividades como pruebas de caja blanca y pruebas de caja negra.

Control de calidad

1. El control de calidad está orientado a procesos.
2. El control de calidad implica
1. Identificar la necesidad del proceso.
2. diseñando el proceso.
3. seguimiento del proceso.
4. mejorando el proceso.
3. El control de calidad se ocupa de la prevención de defectos.

Control de pruebas

1. El control de pruebas está orientado al producto.
2. El control de pruebas implica verificar la funcionalidad de una aplicación con respecto a la especificación de requisitos.
3. El control de pruebas se ocupa de la detección de defectos.

CMM (modelo de madurez de capacidad)

El modelo de madurez de capacidad es un modelo para juzgar la madurez de los procesos de software en una organización e identificar las prácticas clave que se requieren para aumentar la madurez de estos procesos. Tiene cinco niveles

1. Inicial
2. Repetible
3. Definido
4. Gestionado
5. Optimización

Gestión de configuración

La gestión de la configuración cubre los procesos utilizados para controlar, coordinar y rastrear el código, los requisitos, la documentación, los problemas, las solicitudes de cambio, los diseños, las herramientas, los compiladores, las bibliotecas, las rutas, los cambios realizados y quién realizó los cambios.