Más de 40 preguntas y respuestas populares de entrevistas con analistas de control de calidad de pruebas (2021 LIST)

40 popular test qa analyst interview questions

Preguntas y respuestas más frecuentes de la entrevista del analista de control de calidad / pruebas:

Al decidir la carrera en la que quiere estar, el factor decisivo no es solo en la que cree que puede disfrutar trabajando.

Pero estar en esa categoría requiere muchas habilidades, comprender las responsabilidades y los deberes laborales necesarios para la carrera que elija. Lo mismo ocurre al elegir una carrera como analista de control de calidad. No solo requiere que seas un buen evaluador, un aprendiz rápido, un pensador extraordinario, sino que también requiere ser un solucionador de problemas complejos.

Aunque las cualidades mencionadas anteriormente no se logran instantáneamente, obviamente requiere experiencia y días de trabajo duro también.

Este artículo cubrirá todos los aspectos cuyo conocimiento es obligatorio para ser un analista de control de calidad. Las preguntas y respuestas de la entrevista de QA Test Analyst más frecuentes incluidas aquí le darán una idea clara de la preparación de su entrevista.

Preguntas populares de la entrevista del analista de pruebas de control de calidad

P # 1) ¿Cuáles son las responsabilidades de un analista de control de calidad?

Responder: QA Analyst es quien se asegura de que se hayan tomado todas las medidas posibles para probar cada característica de la solución de software tanto funcional como técnicamente.

Las principales responsabilidades de QA Analyst se pueden alistar de la siguiente manera:

• Ejecutar y gestionar todas las actividades para cumplir con los objetivos del plan de pruebas.
• Elija los procesos de alta calidad para desarrollar el producto.
• Debe poder analizar los requisitos y documentar los procedimientos.
• Documente y vuelva a verificar todos los defectos. Establezca la prioridad y la gravedad de los defectos.
• Deberían poder crear, documentar y mantener casos de prueba.
• Análisis de resultados de pruebas.

P # 2) ¿Qué entiende por un plan de prueba?

Responder: Cuando tienes una idea clara de qué, cuándo, cómo y quién, las cosas se vuelven más fáciles. Lo mismo ocurre con las pruebas de software, donde el plan de prueba es un documento que consta del alcance, el enfoque, los recursos y el esquema del proyecto de prueba, así como las actividades para rastrear el progreso del proyecto.

El plan de prueba es un registro de procesos que incluyen:

• Tareas de prueba
• Entorno de prueba
• Técnicas de diseño
• Criterios de entrada y salida
• Cualquier riesgo, etc.

P # 3) Incluya la prioridad de las tareas de prueba definidas por el equipo de control de calidad en el desarrollo de productos.

Responder: La prioridad de las tareas de prueba se define de la siguiente manera:

• Se prepara un plan de prueba que consta del esquema y el alcance del proyecto de prueba.
• Los casos de prueba se preparan para cubrir todas las funcionalidades principales y secundarias con los datos necesarios para las pruebas.
• Ejecución de los casos de prueba según las funcionalidades implementadas con las próximas compilaciones del proyecto de prueba en el ciclo de prueba.
• Informe de defectos con re-verificación, así como seguimiento de su progreso.
• Preparación del resumen del informe de ejecución de la prueba.

P # 4) Incluya algunos de los desafíos clave que se enfrentan al realizar pruebas de software.

Responder: Como decimos que nunca se puede lograr una prueba completa, hay varios desafíos involucrados en ello. Ya sea pequeño o complicado, existen algunos desafíos que enfrenta al realizar las pruebas de software de cualquier proyecto.

A continuación se enumeran algunos desafíos clave:

• Falta de evaluador capacitado que generalmente se enfrenta al problema del conocimiento del tema, así como a la falta de un buen conocimiento del negocio del cliente.
• El tiempo también se considera un factor, ya que generalmente los evaluadores se enfocan principalmente en la cobertura de tareas en lugar de la cobertura de pruebas con pruebas de calidad cuando hay una gran lista de tareas por completar.
• Decidir qué caso de prueba se debe ejecutar primero y con prioridad. Esto generalmente se logra mediante la experiencia del trabajo.
• Una comprensión adecuada de los requisitos que pueden llevar a que todos sus esfuerzos de prueba lleguen a cero, si el requisito no se entiende bien.
• Falta de disponibilidad de las mejores herramientas necesarias para completar las pruebas con menos tiempo y más eficacia.
• Manejar la relación entre probadores y desarrolladores con buena comunicación y habilidades de análisis.

P # 5) Definir pruebas de casos de uso.

Responder: Las pruebas de casos de uso se pueden definir como la técnica de prueba funcional de caja negra que captura la serie de interacciones que se han producido entre 'actores' y 'sistema'. Aquí, los 'actores' están representados por los usuarios y sus interacciones.

Las características de las pruebas de casos de uso se enumeran a continuación:

• Se organizan los requisitos funcionales del proyecto.
• Registra la ruta o los escenarios de principio a fin.
• Puede cubrir defectos de integración, es decir, los defectos que se produjeron como resultado de la interacción entre diferentes componentes.
• Describe los flujos principales así como el flujo excepcional de los eventos.
• Todas las condiciones previas necesarias para que el caso de uso funcione se deben especificar antes.

P # 6) Definir la estrategia de prueba.

Responder: Un conjunto de pautas o enfoques de prueba que generalmente lleva a cabo el gerente de proyecto para determinar el diseño de prueba y el enfoque de prueba general se define como Estrategia de prueba. Se encuentra como una pequeña sección del plan de prueba y es utilizado por varios proyectos.

Se siguen diferentes enfoques de prueba basados ​​en factores como la naturaleza y el dominio del producto, el riesgo de falla del producto, la experiencia en el trabajo con las herramientas propuestas, etc.

Estos enfoques se clasifican además de la siguiente manera:

• Enfoque proactivo , donde el enfoque de diseños de prueba comienza antes de que se cree la compilación. Por lo tanto, ayuda a encontrar y corregir los errores antes de la compilación.
• Enfoque reactivo , donde el enfoque de prueba se inicia después de completar el diseño y la codificación de la prueba.

P # 7) Explique la diferencia entre control de calidad y garantía de calidad.

Responder: 'Control de calidad' y 'Seguro de calidad' son los dos términos principales que se utilizan en relación con cualquier proyecto o producto de prueba. Por lo general, los probadores, que son nuevos en este campo, no comprenden la diferencia real entre los dos.

Comprendamos la diferencia con la ayuda de la siguiente tabla.

P # 8) Según usted, ¿cuándo es el buen momento para iniciar el control de calidad en un proyecto?

Responder: Según el ciclo de vida del desarrollo de software (SDLC), la fase de prueba se ejecuta después de la finalización de la fase de 'Implementación y codificación'. Pero en el escenario actual, para lograr los mejores resultados, es necesario iniciar el control de calidad del proyecto o producto al inicio del proyecto.

Seguir este enfoque conducirá a las principales ventajas que se detallan a continuación:

• Planificación temprana del proceso para cumplir con las expectativas de calidad del cliente.
• Buena y sana comunicación entre los equipos.
• Da una gran cantidad de tiempo que se requiere para configurar el entorno de prueba.
• Permite la revisión y aprobación anticipadas de planes de prueba.

P # 9) Diferenciar los procesos de Verificación y Validación.

Responder: Los procesos de verificación y validación suelen estar determinados por dos preguntas famosas, es decir, ' ¿Estamos construyendo el sistema correctamente? ' y '¿Estamos construyendo el sistema correcto?' .

Veamos la otra diferencia entre estos dos procesos en la siguiente tabla:

P # 10) Explique los beneficios de las pruebas destructivas.

Responder: La prueba destructiva se define como la forma de prueba que lleva a cabo el equipo de prueba para determinar el punto de falla del producto bajo diferentes cargas, es decir, para evaluar el desempeño estructural de la aplicación para determinar su resistencia, tenacidad, dureza o, por ejemplo, robustez.

A continuación se enumeran los beneficios de las pruebas destructivas:

• Se determina la debilidad del diseño de la aplicación.
• Determine la vida útil de la aplicación.
• Ayuda a reducir costos y fallas.

P # 11) ¿En qué se diferencia la repetición de la prueba de la prueba de regresión?

Responder: Hay varias diferencias entre las pruebas de regresión y repetición.

Esto se puede entender fácilmente en la siguiente tabla:

P # 12) ¿Qué sabe sobre las pruebas basadas en datos?

Responder: Es muy claro para cada evaluador de automatización que los scripts de prueba de automatización cubren solo el área de la aplicación que se va a probar con una secuencia registrada de acciones del usuario. Normalmente, estas acciones no producen ningún error ya que solo se toman los datos de entrada en las condiciones que hemos introducido durante la grabación.

Las pruebas basadas en datos entran en escena aquí, donde queremos que la aplicación funcione como se espera para cualquier tipo de valores de entrada. Para este propósito, los datos necesarios para las pruebas basadas en datos no están codificados, pero los scripts de prueba toman sus datos de fuentes de datos como archivos CSV, fuentes ODBC, etc.

En resumen, las pruebas basadas en datos realizan las siguientes acciones en el ciclo:

creando un árbol de búsqueda binario en java

• Toma datos de prueba de entrada del almacenamiento.
• Datos ingresados ​​en la aplicación para realizar acciones.
• Verifique los resultados reales con los esperados.
• Repita nuevamente los mismos pasos con nuevos datos de prueba de entrada.

P # 13) ¿Qué es la Matriz de Trazabilidad? ¿Es necesario para todos los proyectos?

Responder: La matriz de trazabilidad en cualquier proyecto es el medio para rastrear el progreso del proyecto en cuanto a la implementación de nuevas funcionalidades, mejora de funcionalidades existentes, etc. A través de una matriz de trazabilidad, siempre puede estar atento al progreso del proyecto con todos los aspectos mantenidos según la fecha.

La matriz de trazabilidad de requisitos consta de los parámetros que se mencionan a continuación, que en realidad corresponden al documento de especificación de requisitos.

Los parámetros de la matriz de trazabilidad de requisitos incluyen:

• Cada sección del documento de requisitos es un punto que debe cubrirse en RTM (Matriz de trazabilidad de requisitos).
• El título de cada punto es el título de cada sección en la especificación de requisitos.
• En correspondencia con cada punto, se mencionan los identificadores de casos de prueba que están escritos para esa sección en particular.
• BUG / New Feature ID también se menciona en cada sección.
• El punto más importante es que también se mantiene el seguimiento de la función en la que se ha implementado la construcción del proyecto y su función.
• Otro parámetro incluye si la sección está completamente probada o aún está en estado de prueba.

P # 14) Describa los beneficios de las pruebas ágiles.

Responder: Al ser un evaluador, el enfoque se convierte en entregar el producto de calidad en menos tiempo al comprender los requisitos del usuario final y, lo que es más importante, sin defectos por parte del usuario final. Aquí, entran en juego las pruebas ágiles que siguen el principio de desarrollo de software ágil y validan rápidamente los requisitos del cliente.

A continuación se mencionan los beneficios de las pruebas ágiles:

• En las pruebas se incluye un equipo ágil multifuncional, que a su vez entrega los resultados a intervalos frecuentes.
• Ahorra mucho tiempo y dinero.
• Incluye menos documentación y comentarios de vez en cuando del usuario final.
• No solo el evaluador, sino todo el equipo, incluido el gerente, el cliente y el desarrollador, participan en la comunicación cara a cara.
• Como resultado de las reuniones diarias, los problemas se pueden determinar de antemano.
• Incremento de la productividad del equipo y mejor comprensión de los aspectos técnicos del proyecto.

P # 15) ¿Qué son las pruebas negativas?

Responder: La prueba negativa es el método para garantizar que se mantenga la estabilidad de un producto o aplicación, o digamos que no falla cuando se proporciona una entrada inesperada. El objetivo principal de esta forma de prueba valida la aplicación frente a posibles datos de entrada no válidos.

Esta forma de prueba también se conoce como 'Prueba de falla' o 'prueba de ruta de error' y su objetivo principal es verificar la confiabilidad de la función de la aplicación en escenarios negativos. También expone la debilidad del software, detecta las fallas y da una idea clara de la corrupción de datos.

P # 16) ¿Diferenciar las pruebas ad-hoc y las pruebas exploratorias?

Responder: Existen varias diferencias entre las pruebas ad-hoc y las pruebas exploratorias.

Veamos las diferencias en la siguiente tabla:

P # 17) ¿Por qué se prefieren las pruebas de automatización a las pruebas manuales?

Responder: Bueno, tanto las pruebas de automatización como las pruebas manuales tienen su importancia y existencia en el mundo de las pruebas.

A continuación se presentan algunos aspectos importantes debido a los cuales se prefieren las pruebas de automatización sobre las pruebas manuales:

• Se puede utilizar el mismo script de prueba cada vez que se ejecuta la prueba, por lo que la prueba de automatización se considera la más confiable y eficiente.
• Principalmente preferido en caso de pruebas de regresión y ejecución repetida.
• Las pruebas de automatización se consideran rentables en el caso de ejecución a largo plazo y, por lo tanto, aseguran una mejor calidad del software.
• Los scripts de prueba son reutilizables, rápidos y todos pueden ver los resultados.
• Las herramientas utilizadas para las pruebas de automatización son más rápidas y fiables en comparación con el enfoque manual.

Aunque, algunos factores más determinan que se prefieran las pruebas de automatización a las pruebas manuales. Los anteriores son los factores principales.

P # 18) ¿Qué entiende por 'eficacia de prueba' y 'eficacia de prueba'?

Respuesta: Prueba de eficiencia se puede definir como el cálculo del número de recursos y código de prueba consumidos para realizar o decir ejecutar una función en particular. También determina la cantidad de recursos utilizados en la creación de productos de software.

Esto se puede determinar mediante la fórmula:

Prueba de eficiencia = (Número de defectos resueltos / número total de defectos presentados) * 100

Efectividad de prueba se puede definir como la medida de evaluación del entorno de prueba y su efecto en la aplicación de software. Aquí se evalúa la respuesta del cliente cuando se cumple el requisito de la aplicación.

Esto se puede determinar mediante la fórmula:

Efectividad de la prueba = (Número de defectos encontrados / Número de casos de prueba ejecutados)

P # 19) Explique el proceso de Adaptación del Proyecto.

Responder: La personalización del proyecto es un proceso constante y continuo que asegura que el desempeño del proyecto sea correcto y de acuerdo con los requisitos comerciales. Todo el proceso incluye revisar y modificar los datos del proyecto según la necesidad operativa actual de la organización.

El proceso de revisión se realiza a nivel organizativo, pero la implementación de los planes de adaptación se realiza a nivel de proyecto. El objetivo principal y los requisitos de la organización, así como las relaciones con los clientes y los usuarios, son los dos factores principales que deben considerarse en el proceso.

Pocos aspectos según los objetivos organizacionales bajo el proceso de adaptación son:

• Enfoque del proyecto
• Estrategias
• Controles y procesos involucrados
• Funciones y responsabilidades

P # 20) ¿Cómo diferencia entre Prioridad y Severidad del defecto dentro del proyecto?

Responder: Tanto 'Prioridad' como 'Severidad' se asignan al error para categorizar los problemas / errores en el orden en el que se deben tomar para corregirlos. Estos se basan en varios factores.

Entendamos más junto con sus diferencias en la siguiente tabla:

P # 21) ¿Por qué es necesario realizar pruebas de rendimiento para cualquier aplicación?

Responder: En un lenguaje sencillo, las pruebas de rendimiento se realizan para determinar el comportamiento y la respuesta de una aplicación en diversas situaciones. Esto ayuda a recopilar información sobre la estabilidad, escalabilidad, velocidad, etc. de la aplicación.

Las razones para realizar pruebas de rendimiento se pueden entender a partir de los siguientes puntos:

• Determina el tiempo de respuesta y el rendimiento de un componente de la aplicación bajo la carga de trabajo.
• Se calcula el tiempo de respuesta de la actividad del usuario.
• Requiere programadores experimentados con un extenso lenguaje técnico.
• Determina el comportamiento de la aplicación bajo carga, es decir, cuando el número de usuarios aumenta instantáneamente.

P # 22) ¿Qué son las pruebas basadas en especificaciones?

Responder: Como el propio nombre lo define, las pruebas basadas en especificaciones se realizan en función de la especificación de requisitos de la aplicación donde las especificaciones funcionales sirven como base de las pruebas realizadas.

Esta forma de prueba es la misma que la 'prueba de caja negra' donde el usuario ingresa varios datos y luego se observa la salida. Es apropiado en todos los niveles de prueba con especificaciones y plan de prueba.

P # 23) Explique CMMI.

Responder: CMMI son las siglas de Capability Maturity Model Integration. Este modelo fue desarrollado por el Software Engineering Institute (SEI). Se basa en el principio de que los procesos involucrados en la gestión y desarrollo de un producto o sistema determinan la calidad.

También proporciona pautas para la mejora de procesos para el producto o incluso para toda la organización.

CMMI se divide en 5 niveles como se indica a continuación:

• Nivel 1: Inicial
• Nivel 2: Administrado
• Nivel 3: Definido
• Nivel 4: Administrado cuantitativamente
• Nivel 5: Optimizado

P # 24) Explique las ventajas de implementar CMMI.

Responder: La implementación de CMMI tiene varias ventajas.

Se enumeran a continuación:

• Proporciona cobertura e informes detallados del ciclo de vida del producto y, por lo tanto, ayuda a mejorar los procesos.
• Los estándares existentes de la organización, sus procesos y procedimientos se mejoran como parte de la implementación de CMMI.
• Como resultado de la implementación de CMMI, hay un aumento en la entrega a tiempo, así como en la satisfacción del cliente.
• También conduce a una gestión eficaz y a un mayor ahorro de costes, ya que existe una detección temprana de errores.

P # 25) Consiga algunas herramientas de prueba de automatización.

Responder: Algunas de las herramientas de prueba de automatización se enumeran a continuación:

• Selenio
• agua
• Molino
• JABÓN
• Telurio

P # 26) ¿Podemos hacer pruebas de regresión en pruebas unitarias?

Responder: Definitivamente. La prueba de regresión es para probar el defecto no deseado que podría haberse introducido en el código como un efecto secundario de corregir otros defectos. La prueba unitaria es la ejecución de prueba de ejecutar una pequeña parte independiente e individual del código.

Las pruebas de regresión se pueden realizar en cualquier nivel, desde las pruebas unitarias hasta las pruebas de integración y finalmente las pruebas de aceptación. Las pruebas de regresión son pruebas basadas en la perspectiva, mientras que las pruebas unitarias son el enfoque de nivel (de abajo hacia arriba, de arriba hacia abajo).

Q #27) ¿Cuál es la diferencia entre la prueba de humo y la prueba de cordura?

Responder:

• La prueba de humo es la prueba de las características destacadas antiguas o las características existentes de la compilación, mientras que la prueba de Sanity es la validación de los módulos recién agregados, los defectos corregidos en la compilación.
• La prueba de humo ocurre primero y luego es seguida por la prueba de Cordura.
• Las pruebas de humo cubren las pruebas de funcionalidades críticas proporcionadas por el software para que se extiendan por todo el software. Las pruebas de cordura, por otro lado, se reducen solo a los módulos agregados recientemente y se prueban en profundidad.

Q #28) ¿Cuáles son sus actividades diarias como tester manual en su oficina?

Manual: Lo primero que verifico en mi sistema es actualizar el tablero para ver el estado de los requisitos / mejoras o errores en la iteración actual. A esto le siguen las llamadas de scrum diarias y las sesiones de informes, debates y lluvia de ideas para definir escenarios de prueba y casos de prueba.

Estos casos se ejecutan luego de volver a redactarlos según la revisión. Servir de enlace con los clientes para los requisitos no funcionales es también una de las principales actividades en mi plato.

Q #29) ¿Cuáles son sus actividades diarias como miembro del probador de automatización en su oficina?

Automatización: Mi día comienza con una reunión de estado diaria que analiza los resultados de automatización de ayer, en caso de que haya activado un lote de casos de prueba en la nueva compilación.

El ciclo de ejecución se puede llamar una verificación de estado, para ver qué tan saludable es la compilación.

A continuación, se informan los defectos basados ​​en las fallas del script, los cambios de diseño en la funcionalidad; mantener los scripts / bibliotecas o funciones, automatizar y registrar un nuevo script para los nuevos requisitos y, si es necesario, una nueva función en la biblioteca de funciones.

A veces, los scripts de prueba deben volver a ejecutarse individualmente para encontrar defectos de regresión a través de la automatización y agregarlos también al conjunto de pruebas.

P # 30) ¿Cómo diferencia entre un requisito y un defecto y una mejora?

Responder : A requisito es una historia de usuario que es esencial para ser implementada, probada y entregada.
Un mejora es una característica agregada o improvisada a la existente.
A defecto es más bien una desviación completa de las historias de usuario esperadas.

Además, si un defecto descubre un área determinada de un requisito que no se indica a menos que se indique lo contrario en la especificación, también puede denominarse como requisito o como parte de él.

Q #31) ¿Qué hace cuando su desarrollador niega haber arreglado un error que presentó?

Responder : Un factor importante que decide la reparación de un defecto es la “Prioridad” que se le asigna. Si el defecto es de alta prioridad, un tapón de exhibición, que bloquea una funcionalidad principal y se reproduce consistentemente, entonces es necesario corregirlo en la construcción.

Lo mismo debe transmitirse a los desarrolladores de manera eficaz, ya que, juntos, los probadores y los desarrolladores contribuyen a la calidad del producto que se enviará.

Otros aspectos que pueden ayudar a convencer al desarrollador de que corrija un error en un período corto son los informes de calidad del error y hacer que los desarrolladores comprendan el hecho de que la corrección del error es de suma importancia en el lanzamiento.

Q #32) ¿Qué hace cuando su desarrollador niega que lo que presentó ES UN ERROR?

Responder : Una fase más importante del ciclo de vida del defecto es 'Rechazado', lo que significa que el informe de incidente registrado no es válido. El documento de requisitos comerciales que establece los requisitos puede ayudar a comprender el software y, por lo tanto, la naturaleza del incidente informado.

Analice el error y exponga sus hallazgos al desarrollador y al equipo. Si es un defecto, nunca deje de registrarlo. A veces, los evaluadores tienen que proporcionar un análisis de brechas y presentar el mismo a los desarrolladores. Si eso no resuelve los conflictos, la gente mayor del equipo debería colaborar.

Q #33) ¿Qué viene primero Re-testing o Regression testing?

Responder : Volver a probar es lo primero, ya que es volver a ejecutar el código; en términos más simples, es una ejecución repetida de pasos predefinidos. No tiene que ser necesario después de arreglar un código. Pero una prueba de regresión sirve para evaluar los efectos secundarios de un defecto resuelto.

Ciertamente, resolver un defecto y agregar otro al código no es el propósito del proceso de prueba. Los mejores hallazgos y las mejores capturas de probadores suelen ser defectos de regresión. Una compilación nunca debe publicarse sin someterse a una prueba de regresión.

Q #34) ¿Qué es una alternativa a las pruebas beta?

Responder : Las pruebas beta se llevan a cabo en el sitio del cliente con la menor participación de los desarrolladores, registrando las fallas en el entorno de producción real. Si dicha práctica no la lleva a cabo una empresa, entonces una idea más segura puede ser enviar el producto primero a los clientes que no están en la cola para obtener la última versión.

Durante un par de días, ciertos consultores de servicio en las instalaciones del cliente pueden usar el software, registrar y monitorear las actividades que aseguran la estabilidad de la versión en su entorno, de modo que incluso si se deja un error importante por solucionar, se puede probar antes. entregándolo al cliente objetivo. Otro enfoque es el intercambio de pruebas de los requisitos dentro de un equipo para realizar pruebas imparciales.

Q #35) ¿Cuáles son los inconvenientes de la implementación / metodología ágil que enfrentó?

Responder : Los inconvenientes son los siguientes:

1. Los sprints suelen estar muy limitados por plazos.
2. La documentación no es la prioridad
3. El cambio entre PBI (elementos de la cartera de productos) puede ser frecuente.

Q #36) ¿Por qué es importante el análisis de impacto?

Responder : Para practicar el análisis de impacto basado en riesgos, se debe realizar. Al hacerlo, los casos de prueba se pueden diseñar de manera que todos los errores graves, críticos desde el punto de vista del cliente, se puedan resolver antes de tiempo. Debe realizarse un buen estudio del negocio, las necesidades del cliente y su uso del software.

Por ejemplo, el riesgo más importante asociado con el software en el ámbito bancario es la seguridad. Cualquier formulario nuevo agregado al software ya existente puede ser vulnerable. Se recomienda realizar una buena cantidad de pruebas de seguridad agregando los enlaces adecuados, la redirección y la navegación a la página adecuada, instalando un proxy si es necesario.

Q #37) ¿Con la ayuda de un ejemplo, cada prueba de rendimiento, prueba de estrés y prueba de carga?

Responder : El mejor caso aquí que se puede tomar es un sitio web en vivo.

Pruebas de rendimiento se realiza para verificar las fallas en el sistema cuando se somete a una condición similar a un escenario en tiempo real. No es necesario realizarlo en condiciones de estrés. Los resultados de las pruebas de rendimiento ayudan a establecer si el sistema está listo para entrar en producción.

Para un flujo de reserva de boletos simple, un problema de rendimiento puede haber causado lentitud. Por ejemplo, algunas consultas que usan combinaciones son un poco más lentas y han implementado cláusulas innecesarias o almacenamiento de datos de manera inapropiada en la base de datos.

Pruebas de estrés es un tipo de prueba de rendimiento que se realiza poniendo el software en condiciones extremas (cargas pesadas y no distribuidas, recursos computacionales limitados, alta concurrencia).

Si un sistema muestra cierto comportamiento, como la pérdida o la corrupción de datos, el recurso utilizado incluso después de eliminar el estrés, la falta de respuesta o las excepciones no controladas, significa que ha fallado en las pruebas de estrés. A veces, la falla del disco, un aumento innecesario de los recuentos de GDI también puede ser el resultado.

Por ejemplo, Si el sitio web alojado en una máquina que ya consume una gran cantidad de memoria o lo bombardea con solicitudes repetidas, no debe bloquearse ni cerrar la sesión.

Prueba de carga está observando el comportamiento del sistema mientras aumenta constantemente la carga en el sistema hasta que se alcanza un umbral. Los modelos de carga de trabajo, las métricas y los niveles de carga suelen ser la entrada para las pruebas de carga.

Por ejemplo, el tiempo para buscar la disponibilidad de asientos para un tren aumenta gradualmente cuando se acerca el momento de la reserva de la cuota de Tatkal, ya que el número de usuarios que inician sesión en el sistema aumenta con el tiempo de reserva de Tatkal acercándose a las 10 am u 11 am.

Q #38) ¿Cuál ha sido uno de sus mayores desafíos al realizar pruebas de regresión?

Responder : Puede haber varios desafíos al realizar las pruebas de regresión.

• Volver a ejecutar las pruebas repetidamente puede no resultar tan emocionante para los evaluadores.
• Consume mucho tiempo, ya que a veces estas pruebas requieren un pensamiento innovador.
• Valor comercial comprometido.
• La selección incorrecta de casos de prueba de regresión podría omitir un defecto de regresión importante.
• Por tanto, reproducir el defecto en la producción se vuelve inconsistente.
• Amplia suite para ejecutar.

Q #39) Si se le pide que documente escenarios de prueba, casos de prueba, planes de prueba, estrategia de prueba, ¿con qué empezará y en qué secuencia seguirá el resto?

Responder : La secuencia será Estrategia de prueba, Plan de prueba, Escenarios de prueba y finalmente Casos de prueba.

Q #40) ¿Qué pasa si me olvido de documentar cualquiera de los anteriores? Digamos que echo de menos documentar el plan de prueba, ¿cuáles serán las consecuencias?

Responder : Si nos perdemos de documentar el plan de prueba, habrá un vacío para el alcance de la prueba de su enfoque objetivo y énfasis en las pruebas. Entonces será difícil determinar las características que se probarán, las técnicas para probar, aprobar o reprobar los criterios y, en última instancia, un riesgo importante asociado con la prueba.

Q #41) ¿Cómo comenzaría a probar la compilación que obtuvo recientemente? ¿Hay algún enfoque que siga, por ejemplo, ¿Primero comenzar la prueba de humo, luego la prueba de cordura?

Responder : Prueba de humo> Prueba de cordura> Prueba exploratoria> Prueba de funcionalidad> Prueba de regresión y validación del producto final.

Q #42) Explique el formato del informe de errores que siguió.

Responder :

Un informe de error debe contener la siguiente información:

• ID de error
• Asignación a requisito / mejora / error existente
• Resumen de error / título
• Una versión del producto
• Prioridad
• Configuración (especificaciones del sistema)
• Prerrequisitos
• Pasos
• Gastos esperados
• Resultado real
• Registros. Instantáneas, videoclips
• Estado
• Otras observaciones

Q #43) ¿Cómo se seleccionan los casos de prueba de regresión o cómo se forma el conjunto de pruebas de regresión?

Responder : Si. Este es un resultado del análisis de impacto. Es un mapeo simple de las funciones utilizadas o a las que se accede en diferentes áreas que está probando, su integración con otras funciones y en todas partes como prueba de flujo o de extremo a extremo de un sistema.

También puede detectar defectos presentados anteriormente para la misma funcionalidad en versiones anteriores. Idealmente, un defecto debe ser probado por regresión usando al menos cinco casos de prueba diferentes que usan la funcionalidad.

Q #44) ¿Puede venir con un ejemplo de los siguientes defectos?

• Defecto de alta gravedad de prioridad baja
• Defecto de alta prioridad y baja gravedad

Responder : Un defecto que bloquea la aplicación cuando se reproduce solo en una marca de tiempo determinada en un sistema operativo en particular puede ser un defecto de gravedad alta y prioridad baja.

Un defecto que se presenta en una vista que no se abre con un doble clic pero que se abre con un clic derecho puede ser un defecto de alta prioridad y baja gravedad.

Q #45) Escribe un caso de prueba eficaz para comprobar si un artículo determinado es un artículo técnico.

Responder: Si el color de la tinta de origen con el que escribe en papel blanco sigue siendo el mismo, entonces el papel es blanco. Por ejemplo, si escribe en un papel blanco con tinta roja, el color de la tinta permanece rojo en el bolígrafo y también aparece rojo en el papel.

Nota: Hay muchas otras respuestas a esta pregunta. Puede llegar a pensar en cualquier respuesta válida con una lógica subyacente.

Q #46) ¿Qué son las pruebas de Charter?

Responder: Una sesión de prueba realizada en base a los objetivos y agendas enumerados en una carta antes de comenzar la prueba se conoce como prueba de la carta.

Las pruebas aquí se realizan en un intervalo de tiempo fijo con un enfoque menor en la documentación y más en las pruebas. Es una variante diferente de prueba exploratoria en la que los ingenieros de prueba verifican el software en un marco de tiempo ( Por ejemplo, solo 2 horas) basado en algunas heurísticas desarrolladas.

Q #47) ¿Cuál es su enfoque cuando tiene que entregar una versión de alta prioridad en muy poco tiempo?

Responder: En tales casos, un plan bien pensado puede resultar beneficioso.

Se puede hacer lo siguiente para ayudar con las pruebas en un escenario de escasez de tiempo:

• Usar scripts de automatización actualizados existentes para ejecutar pruebas de regresión.
• Prueba de escenarios basados ​​en flujo de un extremo a otro.
• Ejecutando casos de prueba de alta prioridad y, si el tiempo lo permite, cambie a los casos de menor prioridad.
• Volver a probar los errores de alta prioridad archivados en versiones anteriores.
• Prueba rápida de software
• Se puede pedir a los desarrolladores que ejecuten pruebas unitarias para obtener más cobertura en las pruebas.

Q #48) ¿Escribe casos de prueba en cualquier dispositivo / objeto presente (Ejemplo: una silla)?

Responder: Un consejo aquí sería: Empiece siempre por reunir los requisitos. Muestra su madurez hacia el ciclo de vida del desarrollo de software. No dude en hacer preguntas después de seleccionar el objeto.

En este caso:-

• ¿Qué tipo de silla es? ¿Silla de oficina, mesa-silla de estudio, sillón, mesa-silla de comedor, silla de confort?
• ¿Qué material se utiliza para hacer la silla: madera, acero, plástico, tapicería?
• Pregunte por las dimensiones (altura, peso según el tipo de silla).
• Pregunte por disponibilidad. Y en base a eso, comience a redactar sus casos.

Los casos de prueba diferirían para cada tipo de silla, lo que es mejor dejarlo para su capacidad de pensamiento ( Por ejemplo, propósito de la silla, dimensiones según el tipo de silla, portátil-no potable, peso ligero, opciones de compra).

Para cada silla, un El caso de prueba de rendimiento puede ser: para derivar la resistencia a la tracción o la capacidad máxima de carga.

Q #49) ¿Se puede automatizar todo?

Responder: - Hasta cierto punto, sí. Pero las herramientas de automatización, como otros programas, tienen sus limitaciones. Además, el software en prueba o la Aplicación en prueba se seguirán actualizando.

Por lo tanto, no hay garantía de que las pruebas de software se puedan ejecutar sin intervención manual. Después de todo, una herramienta es tan inteligente como lo es el probador. Es solo una prueba de software más. Es el código, los scripts y las bibliotecas los que deben ser lo suficientemente inteligentes como para probar y encontrar defectos.

Conclusión

Espero que este ejercicio le ayude a prepararse con algunas preguntas y le brinde un excelente comienzo para sus entrevistas y refine su confianza al responder las preguntas. Además, puede haber otras preguntas basadas en escenarios que pueden surgir de su currículum / perfil.

Por lo tanto, siempre es recomendable practicar una entrevista simulada con pre-mano de uno mismo, de modo que la entrevista resulte ser una situación beneficiosa tanto para el entrevistador como para el candidato. Recuerde que un analista de calidad es más que un ingeniero de pruebas, cuyos comentarios son importantes no solo para la calidad del producto, sino también para el proceso que se sigue para probar el software.

¡Gracias y mucha suerte con las entrevistas!

Lectura recomendada

• Preguntas y respuestas de la entrevista
• Más de 25 preguntas y respuestas más populares de la entrevista ADO.NET
• Las 25 mejores preguntas y respuestas de la entrevista de pruebas ágiles
• Preguntas de la entrevista de Spock con respuestas (las más populares)
• Preguntas y respuestas de la entrevista de prueba ETL
• Las 20 preguntas y respuestas más populares de la entrevista de TestNG
• Las 30+ preguntas y respuestas más populares de la entrevista sobre pepino
• Las 50 preguntas y respuestas más populares de la entrevista CCNA