Preguntas Frecuentes

Following son las preguntas más frecuentes de Guru99 Community


¿No puedes ver vídeos?


Todos los vídeos de este sitio están alojados en YouTube e incrustado aquí...
Usted está 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.
NO Es necesario registrarse para ver los vídeos.


no entendí email Para el proyecto


Tenga en cuenta el proyecto emailLos mensajes se envían en un intervalo de 24 hours. Entonces, si se suscribió el jueves a las 10 p.m., recibirá el siguiente correo electrónico.mail a las 10 horas del viernes.

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

Nuestro sistema no tiene una función para reenviar emails. Si aún no rastreas el emails, suscríbete con otra email id 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 hable con el usuario comunity
  • 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 evaluador si encuentra un problema que detiene la presentación unos días antes 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 del control de calidad, los evaluadores deben conocer todas las funcionalidades de la aplicación a probar, esto le permite conocer los diferentes tipos de aplicaciones desarrolladas en diferentes entornos, incluso algunas básicas. concepts en programación. El conocimiento será más amplio cuando hagamos pruebas, pero será limitado cuando hagamos programación. Un desarrollador podría estar desarrollando sólo un pequeño segmento de la aplicación completa y es posible que no esté consciente de la aplicación en su totalidad. En este caso, sentí que el rol de control de calidad (probador) es más interesante.


¿No encontró una respuesta?


Contáctenos