No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Presupuesto, Recursos, Tiempo y Actividades Clave

8/29
Recursos

Aportes 58

Preguntas 6

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

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 en las diferentes fases del proyecto:

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

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.

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

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

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

  • 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

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.

<h5>Construcci贸n de Software</h5>
  • Presupuesto
  • Recursos
  • Tiempo
<h5>Actividades clave de pruebas</h5>
  • 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 -> 鈥淓l 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.