Presupuesto, Recursos, Tiempo y Actividades Clave

Pruebas para las Metodologías Ágiles

En contraste al modelo de cascada, _en un modelo ágil se escribe y actualiza un plan de prueba para cada lanzamiento. _

El plan de prueba ágil incluye los tipos de pruebas realizadas en esa iteración. Los planes de prueba típicos en ágil incluyen:

1. El alcance de la prueba
2. Prueba de las nuevas funcionalidades agregadas en la iteración.
3. Las pruebas deben ser basadas en la complejidad de las características.
4. Pruebas de desempeño (carga y rendimiento)
5. Consideraciones de infraestructura
6. Plan de Mitigación de Riesgos.
7. Recursos
8. Entregables e hitos

Análisis: Documentación de las especificaciones de los requerimientos. Se pueden hacer pruebas de las especificaciones, determinar las validaciones y el flujo de las validaciones.

Diseño: Establecer los diseños visuales. Se puede especificar longitudes, si se aceptan números - etc. Mensajes de salida, que sucede si todo está bien, acepta datos null.

Código: Se puede basarse en módulos - funciones - base de datos. Se puede basarse en backend.

Pruebas: Pruebas de Interfaz - Pruebas del canal - Pruebas de dispositivos. Todo esto haría la revisión de los requerimientos, verificación y validación. Con el cliente se hacen las pruebas de aceptación.

Pruebas de Regresión: Las pruebas de regresión se da cuando el software ha tenido modificaciones. Esto es para asegurar que los cambios nuevos, no hayan afectado en los flujos existentes. Y que siga teniendo el correcto funcionamiento.

Pruebas de Aceptación: La prueba de aceptación son definidas por el usuario. El Usuario es el que verifica que el software cumpla con sus expectativas. Las pruebas de aceptación generalmente son funcionales.

Presupuesto
Recursos
Tiempo
Actividades clave
Analisis: observar cada uno de los argumentos que esta agregando el cliente evitar que se vallan detalles que no están escritos no dejarlos al aire o de manera implícita detallar lo mas posible el comportamiento esperado.
Diseño: Visualizar como va a lucir al final el producto para estar de acuerdo y trabajar de la man con el equipo para desarrollar ideas de situaciones en las que puede caer el usuario
Código: Enfocar las pruebas a lo que se esta construyendo, se pueden realizar pruebas en el backend aun cuando no exista un frontend
Pruebas: pruebas de validación donde se evalúa que se cumplan los requerimientos, pruebas de aceptación

de esta manera se reducen substancialmente los errores que pueden llegar al cliente

Apuntes:

Presupuesto, Recursos, Tiempo y Actividades Clave

Si un proyecto no tiene suficiente dinero para tener el equipo necesario de personas y de infraestructura, no habrá quién lo haga. Si no tenemos recursos humanos especializados en ello, tampoco van a poder llevar a cabo el proyecto, al menos no en el tiempo estimado. Una mala planeación de un proyecto puede hacer que los costos se incrementen, que se decida cerrar el proyecto o simplemente se tarden más y el cliente pueda decidir no llevar a cabo el proyecto y buscar alguien más.

Al realizar pruebas desde el inicio te avala el desarrollo del producto final, para no salirse del presupuesto ahorrando tiempo y recursos.

Hacer pruebas parciales de la funcionalidad, lo aplique y me funciono bastante bien. Se tiene un estatus de avance más claro y una mayor certeza de que el software hace lo solicitado.

Un problema que encuentro siempre es realizar una correcta planeacion debido a desorden en el proceso de las pruebas, quisiera saber como considerar o al menos darle entender al departamento de desarrollo estos inconvenientes y evitar los ciclos de retrabajo que son tan costos para la organizacion

La construcción del software tiene los siguientes elementos:

1. Presupuesto
2. Recursos
3. Tiempo

Wow yo pensaba que primero se hacia el FrontEnd y despues el BackEnd…

Es importante

1. Analizar los requerimientos de desarrollo de software
2. Identificar las funcionalidades nuevas a probar
3. Definir la estrategia de pruebas
4. Definir los criterios
5. Establecer metodología y procedimientos de pruebas.

como desarrollador RPA, siempre realizaba las pruebas al final de los proyectos. siempre se alargaban los mantenimientos debido a esto. Veo que en mi empresa anterior flaqueaba mucho en esta parte, pero en mi empleo actual se realizan prueba en cada fase del proceso. ahora me queda claro el por qué hacerlo

Todas las etapas del desarrollo de software pueden tener pruebas:

• Análisis: Preguntar qué debe pasar cuando una historia de usuario se cumple, cuándo no se cumple y qué mensajes deben mostrarse al usuario en ambos casos.
• Diseño: ¿Qué reglas debe cumplir una pantalla? Qué pasa si pongo lo correcto, sino lo hago, que mensajes me debe mandar y cuántos intentos podría tener.
• Código: Pruebas unitarias de los componentes front end y back end. Cuando ambos estén integrados, se pueden realizar pruebas de integración.
• Test: Pruebas de aceptación realizadas por el usuario.

El uso de pruebas en etapas como análisis ya las aplicaba, pero no las había vistos como pruebas hasta hoy.

Hacer un check list con los casos de uso y probarlos en los diferentes dispositivos que se va a usar. También hacer la lista de clases y funciones y probarlas una a una para comprobar que están haciendo lo que dice la documentación. Esto se debe ir haciendo a medida que se van completando los casos de uso y las metas.

Pienso que a la hora de testear, el testing se toma demasiado tiempo en una prueba, cuando el requerimiento se devuelve al desarrollador por un error encontrado y se realiza el ajuste respectivo, la prueba se debe volver a iniciar y esto hace que el desarrollo se demore mas, en mi trabajo sucedia eso y el desarrollador a veces le molestaba que uno no le aceptara el requerimiento.

Tipos de pruebas:
Pruebas de software: Estas pruebas se realizan para evaluar la calidad y
funcionamiento de un software. Incluyen pruebas de unidad, integración, sistema,
rendimiento, usabilidad, seguridad, entre otras.

Pruebas de aceptación: Son pruebas realizadas para verificar si un producto o
sistema cumple con los requisitos y expectativas del cliente. Estas pruebas suelen
ser ejecutadas por los usuarios finales o representantes del cliente.

Pruebas de carga: Se realizan para evaluar el rendimiento y comportamiento de un
sistema bajo condiciones de carga máxima o estrés. Estas pruebas permiten
identificar posibles problemas de rendimiento, como tiempos de respuesta lentos o fallas del sistema.

Pruebas de seguridad: Estas pruebas se centran en identificar vulnerabilidades
y evaluar la resistencia de un sistema frente a ataques cibernéticos.
Se busca asegurar la protección de la información y la integridad del sistema.

Pruebas de usabilidad: Estas pruebas se enfocan en evaluar la facilidad de uso y
la experiencia del usuario en un producto o sistema. Se busca identificar posibles
dificultades o problemas de navegación que puedan afectar la satisfacción del usuario.

Pruebas de regresión: Se realizan para asegurar que las modificaciones o actualizaciones
realizadas en un sistema no introduzcan nuevos errores o problemas, y que las funcionalidades
previamente existentes sigan funcionando correctamente.

Conozco y aplico en mi trabajo algunas de las siguientes:
Pruebas unitarias: las aplico a componentes individuales o específicos.
Pruebas de integración: las hago cuando el componente quedo para probar afecta varias aplicaciones o módulos del estándar del software.
Pruebas de validación: que se cumpla con el requerimiento del cliente.
Pruebas de aceptación: se realizan en ambientes de prueba con datos del cliente antes de la entrega formal al cliente.

Importantisimo que la historia de usuario este bien definida asi el alcance de la prueba no queda a libre interpretacion del developer o del tester. Muchas veces llega al cliente y el comportamiento del flujo no es el pedido exactamente por el mismo.

1. Pruebas de apoyo al equipo (Supporting the team). Se realizan en los cuadrantes Q1 y Q2 del Agile Testing, y se basan en apoyar al equipo de desarrollo en la medida de que este se encuentra elaborando el producto. No suelen buscar algo nuevo, sino más bien validar algo que ya conocen. Se les llaman pruebas de apoyo al equipo ya que en estos cuadrantes las pruebas realizadas son la base de un equipo de desarrollo ágil.

2. Pruebas de críticas al producto (Critique de product). Estas pruebas se realizan en los cuadrantes Q3 y Q4, y se aplican para encontrar errores en el producto. Cuando se indica “críticas al producto”, no tiene necesariamente un sentido negativo, pues éstas pueden ser para resaltar aspectos positivos o incluso sugerir mejoras.

3. Pruebas enfrentadas a la tecnología (Technology view). Son pruebas que se realizan en los cuadrantes Q1 y Q4, y son de mayor naturaleza técnica. Generalmente, los resultados son de mayor interés para el desarrollador, el técnico, el arquitecto, etc. La intención es analizar y someter a pruebas de extremo a características no funcionales como el desempeño, robustez y seguridad.

4. Pruebas enfrentadas al negocio (Business view). Se realizan en los cuadrantes del Agile Testing Q2 y Q3. Acá entran las pruebas que tienen foco en el negocio, podrían pensarse como las pruebas que dan resultados que un Product Owner (o Project Manager) estará interesado en escuchar, que podrá entender. Permiten confirmar que el comportamiento de una determinada funcionalidad es el deseado por el cliente o los expertos de negocio. Hablamos aquí de satisfacer las condiciones de calidad externa solicitadas por el cliente.

Es importante mencionar que esto no es una taxonomía ni una categorización de las tareas del Agile Testing. Asimismo, no es necesario que los cuadrantes se vayan llenando en orden, ya que justamente lo que se busca es una metodología de trabajo ágil en el que todos puedan intervenir.

• Análisis: La documentación del requerimiento.

• Diseño: Definición de la metodología.

• Código: Módulos y Funciones.

• Pruebas: En diferentes dispositivos, la funcionalidad del software.

Durante el proceso de pruebas en cada una de las fases , considero tambien es necesario ejecutar pruebas no funcionales, tales como las pruebas de carga, estres e incluso de seguridad. Con estas se trata de garantziar que los taributos del software cumpla con los atributos establecidos por el cliente .
Dependiendo el tipo de software o aplicacion que se este probando, se deben incluir pruebas en los dispositivos, sistemas operativos o navegadores en que se tenga definido debe funcionar segun el requerimiento e incluso como una forma de establecer un control y una cobertura de uso.
Adicionalmente a las pruebas funcionales manuales es primordial implementar pruebas como por ejemplo a las API o servicios web.

En la fase de pruebas se le hacen pruebas a la manera en como son transmitidos los datos y pruebas en la manera de aceptación del producto por el usuario final. Al final de día lo importante es que como se hicieron pruebas en cada fase, al momento de hacer pruebas de aceptación reducimos la posibilidad de rechazo

Creo que queda implícito el hecho de que en las fases siguientes a la de pruebas ya no se hacen pruebas, porque es puro mantenimiento y lanzamiento del producto

A la hora de la recolección de los datos es muy útil el formato de casos de uso o IEEE 830

El Test Driven Development se hace antes del código.

Los niveles de prueba están hechos para esto ultimo que comentaste, debido a que las pruebas de componentes, estructura y sistema se hacen antes de que el producto llegue al cliente, por lo tanto tienen la funcionalidad de evitar los fallo, lo más que se pueda

.

Por ahora lo que me queda claro es que testing o pruebas en el ciclo de vida es practicamente verificar que se estan haciendo en tiempo y forma los procedimientos. Por ejemplo la toma de entrevista con el cliente para transformar a requerimientos y de ahi a stories, es un trabajo de mucho escribir, pero si hay un personal de pruebas para supervisar que los Stories estan bien redactados y bien analizados, no hay manera de no realizarlo.

Una de las cosas que se proponen es poder hacer pruebas en cada etapa del desarrollo, tanto en diseño , backend o frontend

Blanca, muchas gracias por abrirme el espectro de todos los niveles en los cuales se pueden ir realizando pruebas sin esperar a que el producto este desarrollado, es algo que desconocia.

Es importante tener muy claro los procesos durante cada una de las etapas del desarrollo del software para mitigar los errores a tiempo, para su pronta corrección así evitar contratiempos de costos y recursos, dando un producto de calidad al cliente.

Con respecto a las pruebas que en estos momentos tengo conocimientos, están las pruebas funcionales y no funcionales, pruebas de integración y las pruebas de aceptación de usuarios.

Conozco las pruebas funcionales, de regresión, smoke, pruebas de performance y estress, de caja blanca y caja negra, pruebas de API.

Considero que para que un nuevo desarrollo sea efectivo siempre debe estar de la mano de pruebas tanto a nivel de desarrollo, es decir, pruebas unitarias, como pruebas a nivel funcional por parte de un QA, de manera que certifiquen dicha funcionalidad, de lo contrario, se caería en el error de reprocesos y por ende insatisfacción del cliente

Definitivamente tener un QA en el equipo mejora la calidad del producto y por ende la calidad del desarrollo de software, por que tambien se va adquiriendo experiencia.

Estás clases son excelentes, muchas gracias a la profesora

• Realizar pruebas de validación o confirmación de los requerimientos de comunicación entre módulos y de requerimientos del cliente.

• Pruebas de aceptación: Pruebas de usario final.

• Si quieres asegurar la calidad, es necesario realizar pruebas en cada fase del desarrollo del proyecto para reducir la posibilidad de fallos y acercarse a los requerimientos del cliente.

Actividades Clave de pruebas:

• Codificación
  Durante esta fase se pueden revisar aspectos como las funciones habilitadas de la base de datos.
  y algunas relacionadas con el Back-end.

Probar API, pruebas estáticas al código del desarrollador, y revisar si se están siguiendo buenas prácticas a la hora de escribir código.

Actividades Clave de pruebas:

Análisis de la documentación

• En el análisis es necesario observar a detalle cada uno de los requerimientos que está agregando el cliente y cuestionarlos para entenderlos más allá y despejar dudas posibles.
• Pensar en algunos escenarios posibles como, Que pasa Si, Que pasa si no, Que pasa si si, entre otros.

En fase de diseño

• Verificar lo que se ha planteado con preguntas que agreguen valor, que reduzcan la posibilidad de generar errores, así sean las cosas más obvias y comunes.
• Esta fase se realiza cuando hay un prototipo visual del software.

Notas de la clase:

Elementos base para la construcción del software:

• Presupuesto: Dinero
• Recursos humanos: Personas
• Tiempo: Planeación de las actividades.

Actividades Clave de pruebas:

• Definir las necesidades del cliente
• Análisis de sus requerimientos, visualización, usos.
• Diseño
• Codificación
• Pruebas
• Validación
• Mantenimiento y evolución.

Tener el aporte de un QA desde el diseño o planeación del producto, reduce los errores, permite incluir otros escenarios, reduce costos y aportar ideas de mejora.

• Presupuesto
• Recursos
• Tiempo

• Análisis: Documento con los requerimientos del cliente que muchas veces pueden ser ambiguos
  • Preguntar bien por los requerimientos y sobre lo que quiere el cliente que haga
• Diseño: Establecer criterios visuales de lo que espera ver el cliente
  • Relacionar los acuerdos del análisis con lo que se va a ver en pantalla
• Código: Implica módulos, funciones, estructura de bases de datos
  • Verificar que en las acciones relacionadas con las bases de datos podemos hacer pruebas sin necesidad de que existan módulos construidos ya
• Pruebas: Pruebas directamente en las interfaces de usuario, en la transmisión de datos, en diferentes tipos de dispositivos
  • Pruebas de verificación y validación

Desde el inicio del proyecto es necesario verificar y hacer un analisis a los requerimientos, sin esto es muy dificil que se entienda a profundidad lo que el cliente espera del producto y asi mismo se hace mas dificil entregar un software de calidad que cumpla los estándares del cliente

solamente conosco las pruebas funcionales y no funcionales sobre la parte final es decir las pruebas de aceptacion, me parece muy buebo este curso por que puedo implementar un plan de mejora para las pruebas a futuro e ir reduciendo la cantidad de devoluciones por el cliente

Es importante tener en cuenta los elemento para crear un proyecto de software: Presupuesto, Recursos y tiempo. Todo esto combinado y con un buen equipo de trabajo es provechoso, para entregar un buen trabajo.

Preguntas importantes

1. ¿El ususario puede iniciar sesión?
2. ¿Qué deberia hacer en situaciones que se cumplen?
3. ¿Qué deberia hacer en situaciones que no se cumplen?

Excelente clase

Difiero de Blanca de que no se pueda construir / probar el front end o un middleware sin que esté construido el back end.

Existen herramientas como la Virtualización de APIs que unida a la técnica de proto personas, nos permite construir todos los casos que necesitemos, repetibles, sin dependencia de ambientes e insumos y que permiten que la integración ya con ambientes reales sea mucho más rápida.

la explicación me pareció genial con casos cortos pero reales.

Actualmente en la empresa realizamos las pruebas con base en los criterios de aceptacion por parte del PO, se realizan siempre en compañia con el equipo de desarrollo, ellos se guian por los escenarios planteados por el equipo QA para realizar sus pruebas individuales

Que genial, a partir de una pregunta simple como la del login, saco un montón de preguntas que deberíamos preguntar al cliente y no solo asumir que ya sabemos que debemos hacer

Pienso que en esta parte también es importante tener en cuenta la fase de implantación del software

Estupenda explicación basada desde el análisis de requerimientos, pasando por el modelado de la base y el diseño de las interfaces para el usuario.

Al ejecutar pruebas desde el inicio garantiza tener un panorama mas claro del avance del desarrollo y del equipo

Prueba de casa blanca, negra

Que buena explicación

En metodologías ágiles como Scrum ¿Que tanto se coordinan las pruebas?

Para poder dar review a desarrollo hay que conocer las tecnologías que se están utilizando y eso en un QA no es muy barato, la mayoría de las compañías optan por tener elementos de QA que no cobren tanto y esto afecta significativamente la calidad del producto.

Mockups: Bosetos del diseño.

si muy cierto

Excelente enfoque, muchos piensan que solo se prueba el software, pero también debe probarse la documentación y diseños.

¿Qué debemos probar en cada etapa de desarrollo?

Analisis
Requerimientos y especificaciones. Eliminar cualquier ambigüedad y definir claramente lo que el Cliente se le entregara al cliente al recibir el proyecto

Diseño
Criterios visuales. Simila a Análisis. pero para interfaces gráficas

Código
Probar módulos o funciones. APIs,bases de datos, código.
Se deben realizar pruebas modulares. No debemos esperar hasta tener el producto terminado.

Pruebas
Pruebas de interfaz de usuario y de transmisión de datos.
Pruebas de Aceptación de Usuario Final

En que consisten las pruebas en cada fase del ciclo de desarrollo:

• Análisis -> Pruebas sobre el detalle o especificación de la definición de los requerimientos funcionales.

• Diseño -> Pruebas sobre los criterios visuales o sobre la UI

• Codificación -> Aun cuando toda la aplicación no esta terminada se pueden realizar pruebas sobre módulos, funciones o algún elemento de la arquitectura del software.

• Test -> Pruebas para confirmar los requerimientos.

• UAT -> Donde el cliente valida que se cumplan los requerimientos.

La práctica hace a el maestro. A medida que empiezas como QA es que comienzas a saber por dónde comenzar a testear. A vuelo de pájaro diría que la documentación es donde se puede comenzar a analizar para luego seguir con lo que ya se está ejecutando.

Cuando estamos desarrollando un software, tratamos de que esté listo para una fecha indicada. Pero la realidad es que muchas veces se alarga la espera por cuestiones humanas.

El ciclo de vida del software es:

1. Definición de necesidades
2. Análisis
3. Diseño
4. Codificación
5. Pruebas
6. Validación
7. Mantenimiento y evolución

Cada una de estas etapas puede tener sus pruebas.

Ejemplo: Análisis -> “El usuario puede iniciar sesión”.

• ¿Cuántos usuarios pueden iniciar sesión?
• ¿Qué debería hacer el software tanto si inicia como si no inicia sesión?

Debemos tomar en cuenta estos detalles.

Ejemplo: Diseño -> Crear la pantalla de login/registro, formulario.

• ¿Cuántos caracterés aceptará para el nombre? ¿Cuántos para el apellido?
• ¿Solo aceptará letras o también otros símbolos como “#$%123”? ¿Pueden estar los campos vacíos?
• ¿Qué pasará si los datos son correctos? ¿Qué pasará si son incorrectos?

Ejemplo: Código -> Podemos tener módulos, funciones y bases de datos. Además de tener:

• Front end -> Normalmente tarda más que el backend y no podemos terminarlo de construir sin que el backend esté construido.
• Back end -> Podemos probar apis, bases de datos.

Ejemplo: Pruebas -> Podemos hacer pruebas de cómo se envía la información a la interfaz, de cómo el usuario interactura con el software, de los distintos dispositivos usando el software. Las pruebas están comprobando los requerimientos del cliente.

Las pruebas de validación o de aceptación son en donde el cliente nos dirá que aprueba lo que hemos desarrollado. Una buen práctica es mostrar nuestros avances para tener su feedback. Una mala práctica es esperar hasta el final.