Preguntas Frecuentes

A continuación se presentan las preguntas más frecuentes de Guru99 comunidad

¿No puedes ver vídeos?

Todos los vídeos de este sitio están alojados en YouTube e incrustado aquí...
Usted probablemente accediendo al sitio web desde una ubicación donde YouTube está prohibido (su empresa, universidad o un país donde YouTube está prohibido)

Intente acceder a los vídeos desde un entorno sin restricciones.
Sí Es necesario registrarse para ver los vídeos.

No recibí correo electrónico para el proyecto.

Tenga en cuenta que los correos electrónicos del proyecto se envían con un intervalo de 24 horas. Por lo tanto, si se suscribió el jueves a las 10 p. m., recibirá el siguiente correo electrónico a las 10 p. m. del viernes.

Por favor revisa tu correo no deseado o spam Mailcaja. Si estás usando gmail, revisa el PromoPestaña de opciones

Nuestro sistema no tiene una función para reenviar correos electrónicos. Si aún así no lo hace, tracPara recibir los correos electrónicos, suscríbase con otra dirección de correo electrónico para obtener el contenido.

Si tengo un error en una aplicación, ¿quién decidirá la gravedad y prioridad del error?

Gravedad de Defecto La determina la persona que identifica el problema (probador), mientras que la prioridad la determina la persona que participa en la solución del problema (Desarrolladores).

Como probador, puede priorizar los defectos que normalmente revisa el líder de pruebas. Los desarrolladores, después del análisis, decidirán si se trata de un defecto de alta o baja prioridad. La mayoría de las veces, lo hace el desarrollador, pero el evaluador también puede participar para explicar su gravedad. Después de la discusión, las pistas llegarán a una conclusión.

La gravedad está básicamente relacionada con la funcionalidad de la aplicación o producto. Si bien la prioridad es qué tan inmediatamente el desarrollador puede corregir ese error o defecto. La prioridad es de naturaleza dinámica y cambiará según el escenario, mientras que la gravedad es de naturaleza estática.

¿Qué hará si no hay especificaciones funcionales o algún documento relacionado con el sistema?

  • Primero intente comprender el dominio con analistas de negocios o PYMES. Realice pruebas exploratorias para comprender el sistema.
  • Si el proyecto no tiene Business Analyst o PYMES, hable con las personas que trabajaron en sistemas similares.
  • Para entender el negocio habla con la comunidad de usuarios.
  • Descubra especificaciones de productos similares en Internet o PMO
  • Busque el mismo tipo de software de aplicación y comprenda las características.
  • Busque algunos escenarios comerciales importantes, documentos alternativos y artículos sobre temas de aplicación.
  • Solicite la explicación sobre todos los módulos a los desarrolladores.
  • Datos históricos del usuario, aplicaciones y características
  • No pruebe la aplicación técnicamente, primero pruebe su aplicación solo desde la perspectiva del usuario.

¿Qué puede hacer un probador si encuentra un fallo en el programa?ping ¿Problema a pocos días del lanzamiento?

  • Confirme y vuelva a confirmar el Defecto nuevamente y documente el error o defecto, el impacto y la posible solución, si puede.
  • Informe esto a su gerente y discútalo con el equipo, ya que el equipo desconoce tal obstáculo una semana antes de su lanzamiento, no es bueno.
  • Una vez que el defecto llegue a su gerente y a las autoridades de pruebas superiores, es posible que deba exponerles su punto de vista, así que sea minucioso con su punto, ya que esto podría tener un impacto en la publicación.
  • Si la discusión te apoya, es tu momento de levantarte y brillar. Si no, tienes una lección aprendida del día para llevar. Seguir aprendiendo.

¿Por qué elige el campo del aseguramiento de la calidad del software?

Para proporcionar proyectos de calidad a los usuarios finales o al cliente, las pruebas son obligatorias, independientemente de la codificación que implique. El control de calidad del software no solo registra los errores, sino que también proporciona soluciones para esos errores.

En el campo de QA, los evaluadores deben conocer todas las funcionalidades de la aplicación que se va a probar, lo que les permite conocer diferentes tipos de aplicaciones desarrolladas en diferentes entornos, incluso algunos conceptos básicos de programación. El conocimiento será más amplio cuando hacemos pruebas, pero será más limitado cuando hacemos programación. Un desarrollador podría ser desarrolladorping Solo una pequeña parte de la aplicación completa y puede que no conozcan la aplicación en su totalidad. En este caso, me pareció que el rol del QA (probador) era más interesante.

¿No encontró una respuesta?

Contáctenos