Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Presupuesto, Recursos, Tiempo y Actividades Clave

8/29
Recursos

Aportes 43

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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.

Pruebas en las diferentes fases del proyecto:

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

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

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.

Para reducir en metodologías ágiles el tiempo de respuesta de corrección entre desarrollo y pruebas. Lo que me ayudó fue que antes de desplegar la solución realizar unas pequeñas pruebas de la funcionalidad afectada en el localhost del desarrollador. Y revisar junto con el su solución, analizar y resolverlo si es que falla. Ya que los desarrolladores no realizan pruebas muy extensas. Esto fue al inicio, luego ya se fueron acostumbrando a realizar un poco más extensas sus pruebas los dev.

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.

La construcción del software tiene los siguientes elementos:

  1. Presupuesto
  2. Recursos
  3. Tiempo

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.

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.

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.

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

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

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

  • 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.

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.