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 76

Preguntas 7

Ordenar por:

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

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

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鈥

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

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.

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.

Segun mi experiencia como QA, segun la metodologia que aplique la empresa, uno no siempre esta presente desde los ciclos iniciales del software, como analisis y dise帽o, a veces te entregan los temas con su debida documentacion cuando se esta finalizando el desarrollo, por ende los tipos y estrategias de pruebas que se pueden aplicar cambian, sin contar que los tiempos se reducen. Creo que afecta mucho la metologia y gestion que cada emprese maneje.
  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 鈥渃r铆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.

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

falta tener en cuenta un smoke tes
bueno saber una manera de testear los documentos antes de pasar a producci贸n
Las pruebas en la fases de an谩lisis y dise帽o tienen alg煤n nombre, qu茅 tipo de pruebas son o tienen alguna t茅cnica? O simplemente consiste en cuestionar la documentaci贸n, hacer preguntas y pedir m谩s informaci贸n?

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

me gusta ver m谩s mujeres impartiendo cursos. Me gusta sentirme reflejada en el mundo de TI

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.

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.

.

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.

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

La parte del codigo , no es algo que siempre esta a la vista del tester, se entiende como el equipo de desarrollo nos va haciendo entregas en ambiente de pruebas, considero, si el tester pudiese estar m谩s cerca al codigo podria aportar m谩s valor al proceso.

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.