Preguntas y respuestas para entrevistas – pruebas manuales

Prepárate para las entrevistas de trabajo de pruebas de software con nuestra completa lista de comprobación de pruebas manuales de 114 preguntas, diseñada tanto para candidatos principiantes como experimentados.

Índice

Preguntas de entrevista sobre pruebas manuales para principiantes

Pregunta nº. 1. ¿Qué entiendes por pruebas de software?

Respuesta: La prueba de software es el proceso de evaluación de un sistema para comprobar si cumple los requisitos de la empresa. Mide la calidad global del sistema en términos de atributos como: corrección, integridad, usabilidad, rendimiento, etc. Básicamente, se utiliza para garantizar la calidad del software a los interesados en la aplicación.

Pregunta nº. 2. ¿Por qué son necesarias las pruebas?
Respuesta: Necesitamos pruebas de software por las siguientes razones:

• Las pruebas garantizan a las partes interesadas que el producto funciona según lo previsto.
• Los errores evitables que se filtran al usuario/cliente final sin las pruebas adecuadas dan mala reputación a la empresa de desarrollo.
• Los errores descubiertos antes en el SDLC conllevan menores costes y menor uso de recursos para su reparación.
• Ahorra tiempo de desarrollo al detectar los problemas en una fase más temprana del desarrollo.
• El equipo de pruebas añade otra dimensión al desarrollo de software, aportando una perspectiva diferente al proceso de desarrollo del producto.

Pregunta 3. ¿Cuándo debemos dejar de probar el software?
Contesta: Las pruebas (tanto manuales como automatizadas) pueden detenerse cuando se cumplen una o varias de las siguientes condiciones:

• Tras la ejecución de los casos de prueba: la fase de prueba puede detenerse cuando se haya ejecutado un ciclo completo de casos de prueba con un valor de porcentaje de éxito acordado tras la última corrección de error conocida.
• Una vez cumplidos los plazos de las pruebas – Las pruebas pueden detenerse una vez cumplidos los plazos, cuando no queden problemas de alta prioridad en el sistema.
• Basado en el tiempo medio entre fallos (MTBF): el MTBF es el intervalo de tiempo entre dos fallos. Según las decisiones de las partes interesadas, si el MTBF es relativamente grande, se puede detener la fase de pruebas.
• Basado en el valor de la cobertura del código – La fase de pruebas puede detenerse cuando la cobertura automatizada del código alcance un determinado valor umbral con un porcentaje suficiente de éxito y sin un error crítico.

Pregunta nº. 4. ¿Qué es la garantía de calidad y cuáles son las distintas actividades que intervienen en ella?

R: La garantía de calidad es un enfoque de proceso que comprueba que el proceso de desarrollo del producto es correcto y cumple todas las normas. Se considera una medida preventiva. Identifica fallos en el proceso de desarrollo del software. Incluye actividades como revisión de documentos, revisión de casos de prueba, recorridos, inspección, etc.

Pregunta nº. 5. ¿Qué es el control de calidad y cuáles son los distintos tipos de pruebas que intervienen en el control de calidad?

R: El control de calidad es un enfoque centrado en el producto que comprueba si la solución desarrollada cumple todos los requisitos especificados. Se considera una medida correctiva porque pone a prueba el producto creado para encontrar errores. Incluye distintos tipos de pruebas, como pruebas funcionales, pruebas de rendimiento, pruebas de usabilidad, etc.

Pregunta nº. 6. ¿Cuál es la diferencia entre verificación y validación?
Respuesta: Las principales diferencias entre verificación y validación son:

1.	La verificación es el proceso de evaluación de diversos artefactos, así como del proceso de desarrollo del software. Se lleva a cabo para garantizar que el producto que se está desarrollando cumple las normas.	La validación es el proceso de verificar que un producto de software desarrollado se ajusta a los requisitos empresariales especificados.
2.	Es un proceso estático de análisis de documentos, no el producto final real.	Consiste en probar dinámicamente un producto de software ejecutándolo.
3.	La verificación es un enfoque orientado al proceso.	La validación es un enfoque orientado al producto.
4.	Responde a la pregunta: «¿Estamos construyendo bien el producto?».	Responde a la pregunta: «¿Estamos construyendo el producto adecuado?»
5.	Los errores detectados durante la validación requieren menos costes/recursos para corregirlos que los errores detectados durante la fase de validación.	Los errores detectados durante la validación requieren más costes/recursos. Una avería descubierta más tarde tiene un coste mayor para arreglarla.

Pregunta nº. 7. ¿Qué es el SDLC – Ciclo de vida del desarrollo de software?
R: SDLC significa ciclo de vida de desarrollo de software. Se refiere a todas las actividades realizadas durante el desarrollo de software: recopilación de requisitos, análisis de requisitos, diseño, codificación o implementación, pruebas, despliegue y mantenimiento.

Pregunta 8. Explica el STLC – ciclo de vida de las pruebas de software.
R: El ciclo de vida de las pruebas de software se refiere a todas las actividades realizadas durante las pruebas de un producto de software. Las fases incluyen:

• Análisis y validación de requisitos – En esta fase se analizan y validan los documentos de requisitos y se define el alcance de las pruebas.
• Planificación de las pruebas – Esta fase define la estrategia del plan de pruebas, la estimación del esfuerzo de las pruebas junto con la estrategia de automatización y la selección de herramientas.
• Diseño y análisis de pruebas – Aquí se diseñan los casos de prueba, se preparan los datos de prueba y se implementan los scripts de automatización.
• Preparación del entorno de prueba – Se prepara un entorno de prueba que simule con precisión el entorno real.
• Ejecución de pruebas – Se preparan los casos de prueba, se informa de los errores y se vuelven a probar una vez resueltos.
• Cierre de la prueba e informes – Se preparará un informe de cierre de la prueba que resuma los resultados finales de la prueba, las conclusiones y las métricas de la prueba.

Pregunta nº. 9. ¿Cuáles son los distintos tipos de pruebas?
Respuesta: Las pruebas pueden definirse a grandes rasgos en dos tipos:

• Pruebas funcionales – Las pruebas funcionales consisten en verificar las especificaciones funcionales del sistema.
• Pruebas no funcionales – Las pruebas no funcionales son un tipo de prueba que consiste en comprobar los requisitos no funcionales de un sistema, como el rendimiento, la escalabilidad, la seguridad, la resistencia, la portabilidad, etc.

Según cómo se realice la prueba, puede clasificarse en:

• Pruebas de caja negra: en las pruebas de caja negra, el probador no necesita tener ningún conocimiento de la arquitectura interna ni de la implementación del sistema. El comprobador se comunica con el sistema mediante una interfaz, proporciona entradas y verifica las salidas recibidas.
• Pruebas de caja blanca – En las pruebas de caja blanca, el probador analiza la arquitectura interna del sistema, así como la calidad del código fuente, basándose en diversos parámetros, como la optimización del código, la cobertura del código, la reutilización, etc.
• Pruebas de caja gris – En las pruebas de caja gris, el probador tiene acceso parcial a la arquitectura interna del sistema, por ejemplo el probador puede tener acceso a los documentos de diseño o a la estructura de la base de datos. Esta información ayuda al probador a probar mejor la aplicación.

Pregunta nº. 10. ¿Qué es la prueba manual?
Respuesta: La prueba manual es un tipo de prueba que consiste en verificar los requisitos de la aplicación ejecutando manualmente un conjunto predefinido de casos de prueba, sin utilizar ninguna herramienta de automatización.

Pregunta.11. ¿Qué son las pruebas automatizadas?
Respuesta: Las pruebas automatizadas son un tipo de pruebas de software que implican la ejecución automatizada de casos de prueba mediante una herramienta de automatización. Ayuda a reducir el tiempo de ejecución de las pruebas, porque los guiones de prueba escritos una vez pueden ejecutarse automáticamente cualquier número de veces sin intervención humana.

Pregunta nº. 12. ¿Cuáles son algunas ventajas de las pruebas automatizadas?
Respuesta: Algunas ventajas de las pruebas automatizadas son:

• Ejecutar pruebas mediante automatización es rápido y ahorra mucho tiempo.
• Los guiones de prueba cuidadosamente redactados eliminan la posibilidad de error humano durante las pruebas.
• La ejecución de las pruebas puede programarse para una ejecución nocturna mediante herramientas de CI como Jenkins, que también pueden configurarse para entregar diariamente los resultados de las pruebas a las partes interesadas.
• Las pruebas automatizadas consumen muchos recursos. Tras la automatización de las pruebas, la ejecución de las mismas casi no requiere tiempo de control de calidad.

Pregunta nº. 13. ¿Cuáles son algunas desventajas de las pruebas automatizadas?
Respuesta: Algunas desventajas de las pruebas automatizadas son:

• Requiere expertos en pruebas automatizadas que escriban guiones de prueba.
• Se requiere un esfuerzo adicional por adelantado para escribir los guiones.
• Los scripts de automatización se limitan a validar las pruebas codificadas. Esta prueba puede pasar por alto algún error que sea muy perceptible y fácilmente identificable para un humano (control de calidad manual).
• Incluso un pequeño cambio en la aplicación requiere actualizaciones de script y mantenimiento.

Pregunta nº. 14. ¿Qué son las pruebas de rendimiento?
Respuesta: Las pruebas de rendimiento son un tipo de pruebas no funcionales que evalúan el rendimiento del sistema bajo cargas previstas o superiores. Durante las pruebas de rendimiento, se evalúan varios parámetros de rendimiento: tiempo de respuesta, fiabilidad, utilización de recursos, escalabilidad, etc. Los distintos tipos de pruebas de rendimiento son: pruebas de carga, pruebas de estrés, pruebas de resistencia, pruebas de impacto y pruebas de volumen.

Pregunta nº. 15. ¿Qué es un entorno de pruebas?
Respuesta: Un entorno de pruebas es un entorno utilizado para probar una aplicación. La configuración del entorno de prueba puede consistir en los requisitos de hardware y software de la aplicación sometida a prueba, incluyendo: sistema operativo, configuraciones de hardware, configuraciones de software, base de datos, etc.

Pregunta 16. ¿Qué es un plan de pruebas?
R: Un plan de pruebas es un documento formal que describe el alcance de las pruebas, el enfoque que se utilizará, los recursos necesarios y el tiempo estimado para realizar el proceso de pruebas. Se deriva de los documentos de requisitos (especificaciones de requisitos del software).

Pregunta nº. 17. ¿Qué es un escenario de prueba?
Respuesta: El escenario de prueba se deriva del caso de uso. Se utiliza para probar exhaustivamente la funcionalidad de la aplicación. Un único escenario de prueba puede incluir varios casos de prueba. Las pruebas de escenarios son especialmente útiles cuando las pruebas son limitadas en el tiempo.

Pregunta nº. 18. ¿Qué es un caso de prueba?
Respuesta: Un caso de prueba se utiliza para comprobar la conformidad de una aplicación con la especificación de sus requisitos. Es un conjunto de condiciones con supuestos, valores de entrada y resultados esperados en forma documentada.

Pregunta nº. 19. ¿Cuáles son algunos atributos de un caso de prueba?
Contesta: Un caso de prueba puede tener los siguientes atributos:

• TestCaseId – identificador único del caso de prueba.
• Resumen de la prueba – Un resumen inequívoco del caso de prueba.
• Descripción – Descripción detallada del caso de prueba.
• Prerrequisito o condición previa – Conjunto de requisitos previos que deben cumplirse antes de que puedan ejecutarse los pasos de la prueba.
• Pasos de la prueba – Pasos detallados para ejecutar un caso de prueba.
• Resultado esperado – Resultado esperado para que la prueba pase.
• Resultado real – El resultado real después de realizar los pasos de la prueba.
• Resultado de la prueba – Estado de aprobado/no aprobado de la prueba.
• Estado de automatización – Identificador de automatización, si la aplicación está automatizada o no.
• Fecha – La fecha en que se realizó la prueba.
• Ejecutado por (Ejecutado por – Nombre de la persona que ejecuta el caso de prueba).

Pregunta nº. 20. ¿Qué son los datos de prueba?
Respuesta: Los datos de prueba son datos que se utilizan para probar el software con diversas entradas y ayudan a comprobar si la salida respectiva coincide o no con el resultado esperado. Estos datos se generan en función de las necesidades de la empresa.

Pregunta nº. 21. ¿Qué es un script de prueba?
Respuesta: Un script de prueba es un caso de prueba automatizado escrito en cualquier lenguaje de programación o script. Básicamente, es un conjunto de instrucciones para evaluar el funcionamiento de la aplicación.

Pregunta nº. 22. ¿Qué es un error de prueba de software?
R: Como todos somos humanos, es natural que cometamos errores. El error es un caso similar que se produce al probar software debido, por ejemplo, a un escenario que falta en los requisitos, problemas de diseño o errores de implementación.

Pregunta nº. 23. ¿Qué es un «bicho»?
Respuesta: Un fallo es un defecto en un producto de software detectado en el momento de la prueba que hace que funcione de forma inesperada.

Pregunta nº. 24. ¿Qué es un «defecto»?
R: Un defecto es una no conformidad con un requisito del producto detectada en la producción (después de que el producto se haya puesto en servicio).

Pregunta nº. 25. ¿Cuáles son algunos atributos de la notificación de defectos?
Contesta: Algunos de los atributos de notificación de errores son:

• DefectId – identificador único del defecto.
• Resumen del defecto – un resumen de una línea del defecto, en lugar del nombre del defecto.
• Descripción del defecto: descripción detallada del defecto.
• Pasos para reproducir – pasos para reproducir el error.
• Resultado esperado – el comportamiento esperado del que se desvía la aplicación debido a un error.
• Resultado real: el estado actual de la aplicación en relación con el error.
• Gravedad del error – En función de la gravedad del error, este campo puede establecerse como leve, medio, grave o «show stopper».
• Prioridad – En función de la urgencia del error, este campo puede ajustarse en una escala de P0 a P3.

Pregunta nº. 26. ¿Cuáles son algunas de las herramientas para gestionar errores o defectos?
Respuesta: Algunas de las herramientas de gestión de defectos más utilizadas son: Jira, Bugzilla, Redmine, Mantis, Quality Center y otras.

Pregunta nº. 27. ¿Qué es la densidad de defectos?
R: La densidad de defectos es una medida de la densidad de defectos en un sistema. Se puede calcular dividiendo el número de errores identificados por el número total de líneas de código (o métodos o clases) de la aplicación o programa.

Pregunta nº. 28. ¿Qué es la prioridad por defecto?
R: La prioridad del defecto es la urgencia de la rectificación del defecto. Normalmente, la prioridad de un defecto se establece en una escala de P0 a P3, teniendo un defecto P0 la mayor urgencia de reparación.

Pregunta nº. 29. ¿Qué es la gravedad del defecto?
R: La gravedad de un defecto es la gravedad del defecto que afecta a la funcionalidad. Según la organización, podemos tener distintos niveles de gravedad de los defectos, que van de leves a críticos o «show stopper» (el defecto más crítico que detiene el desarrollo o la implantación del software).

Pregunta nº. 30. Pon un ejemplo de defectos con prioridad baja – gravedad baja, prioridad baja – gravedad alta, prioridad alta – gravedad baja y prioridad alta – gravedad alta.
Contesta: A continuación tienes ejemplos para distintas combinaciones de prioridad y gravedad:

• Prioridad baja-Gravedad baja: un error ortográfico en una página por la que los usuarios no navegan con frecuencia.
• Prioridad baja-Gravedad alta: aplicaciones de choque en algunos casos muy marginales.
• Prioridad alta-Gravedad baja: Un ligero cambio en el color del logotipo o un error ortográfico en el nombre de la empresa.
• Prioridad alta-Gravedad alta: problema con la función de inicio de sesión.

Pregunta 31. ¿Qué es un «bloqueador»?
Respuesta: El bloqueador es un fallo de alta prioridad y gravedad. También impide o bloquea la comprobación de alguna otra parte importante de la aplicación.

Pregunta nº. 32. ¿Qué es un fallo crítico?
R: Un fallo crítico es un fallo que afecta a la funcionalidad principal de la aplicación y la aplicación no puede entregarse sin solucionar este fallo. Se diferencia de un error de bloqueo en que no afecta ni bloquea la comprobación de otras partes de la aplicación.

Pregunta nº. 33. Explica el ciclo de vida de un bicho o los distintos estados de un bicho.

Contesta: Un fallo en el desarrollo de software pasa por las siguientes fases

• Nuevo – el error o defecto está en estado Nuevo cuando se detecta.
• Asignado – El fallo recién detectado está en estado Asignado tras ser asignado al desarrollador adecuado.
• Abierto – Cuando el desarrollador está trabajando en un fallo, éste se encuentra en estado Abierto.
• Rechazado/No es un fallo – Un fallo se encuentra en el estado Rechazado si el desarrollador considera que el fallo no es auténtico.

• Aplazado – Un fallo aplazado es un fallo cuya corrección se aplaza durante un cierto periodo de tiempo (para futuras versiones) en función de la urgencia y criticidad del fallo.
• Corregido – Cuando el desarrollador resuelve el error, se marca como corregido.
• Probado(Test) – Cuando se arregla un fallo, se asigna a un probador y se marca como probado durante este periodo.
• Reabierto – Si el probador no está satisfecho con la resolución del problema, el fallo pasa al estado Reabierto.
• Verificado – Tras la fase de Pruebas, si el probador considera que el fallo está resuelto, se marca como verificado.
• Cerrado – Una vez verificado el error, éste pasa al estado Cerrado.

Pregunta nº. 34. ¿Cuáles son las diferentes técnicas de diseño de pruebas?

Respuesta: Las técnicas de diseño de pruebas son diversas normas de diseño de pruebas que permiten crear casos de prueba sistemáticos y generalmente aceptados. Las distintas técnicas de diseño de pruebas pueden dividirse en técnicas de diseño de pruebas estáticas y técnicas de diseño de pruebas dinámicas.

1. Técnicas de diseño de pruebas estáticas: técnicas de diseño de pruebas que implican probar sin ejecutar código. Las distintas técnicas de diseño de pruebas estáticas pueden dividirse a su vez en dos partes: manuales y mediante herramientas.

• Técnicas manuales de diseño de pruebas estáticas
• Recorrido
• Revisiones informales
• Revisiones técnicas
• AuditControl
• Revisión de la gestión (Revisión técnica)

2. Técnicas de diseño de pruebas estáticas mediante herramientas

• Análisis estático del código: implica analizar diferentes rutas y flujos en la aplicación y diferentes estados de los datos de prueba.
• Conformidad con las normas de programación – Se evalúa la conformidad del código con diversas normas de programación.
• Análisis de métricas de código – Se necesita una herramienta de análisis estático para evaluar diversas métricas, como líneas de código, complejidad, cobertura del código, etc.

3. Técnicas de diseño de pruebas dinámicas – Las técnicas de diseño de pruebas dinámicas implican realizar pruebas ejecutando el sistema sometido a prueba.

• Técnicas de diseño de pruebas basadas en especificaciones – Las técnicas de diseño de pruebas basadas en especificaciones también se denominan pruebas de caja negra. Estas técnicas consisten en probar la especificación del sistema sometido a prueba sin conocer su arquitectura interna.
• Técnicas de diseño de pruebas basadas en estructuras – También denominadas pruebas de caja blanca. En estas técnicas, es necesario conocer el código o la arquitectura interna del sistema para realizar las pruebas.
• Basadas en la experiencia – Las técnicas basadas en la experiencia se basan en la experiencia o intuición del probador. Las dos formas más comunes de pruebas basadas en la experiencia son: las pruebas ad hoc y las pruebas exploratorias.

Pregunta nº. 35. ¿Qué es la prueba estática?

R: Las pruebas estáticas son un tipo de pruebas para revisar los productos de trabajo o la documentación que se crean a lo largo de un proyecto. Permite revisar las especificaciones, los requisitos empresariales, la documentación, los procesos y los requisitos funcionales en la fase de prueba inicial.

Para que los probadores implicados puedan comprender los requisitos con más detalle antes de iniciar el ciclo de vida de las pruebas, cuyo objetivo es ayudar a obtener un producto de calidad.

Pregunta nº. 36. ¿Qué es la Prueba Dinámica?

Respuesta: El tipo de prueba que se realiza ejecutando la aplicación sometida a prueba manualmente o mediante automatización se denomina prueba dinámica.

Pregunta nº. 37. Explica los distintos tipos de técnicas de diseño de pruebas basadas en especificaciones.

Respuesta: Las técnicas de diseño de pruebas basadas en especificaciones también se denominan pruebas de caja negra. Consiste en probar la especificación del sistema sometido a prueba sin conocer su arquitectura interna. Existen distintos tipos de pruebas basadas en especificaciones o técnicas de pruebas de caja negra:

• Partición de equivalencia: agrupar los datos de la prueba en grupos lógicos o clases de equivalencia con el supuesto de que todos los elementos de datos que se encuentren en las clases tendrán el mismo efecto en la aplicación.
• Análisis de valores límite: pruebas que utilizan valores límite de clases de equivalencia tomados como entradas de prueba.
• Tablas de decisión: pruebas mediante tablas de decisión que muestran el comportamiento de la aplicación en función de distintas combinaciones de valores de entrada.
• Gráfico causa-efecto – Prueba que utiliza una representación gráfica del resultado y de todos los factores que influyen en él.
• Pruebas de transición de estados – Pruebas basadas en el modelo de máquina de estados.
• Pruebas de casos de uso – Pruebas realizadas utilizando casos de uso.

Pregunta nº. 38. Explica la partición de clases de equivalencia.

R: La distribución de clases de equivalencia es una técnica de prueba de caja negra basada en la especificación. Al dividir las clases de equivalencia, el conjunto de datos de entrada que definen diferentes condiciones de prueba se dividirá en grupos lógicamente similares, de modo que el uso de un solo dato de prueba de un grupo de prueba pueda considerarse similar al uso de todos los demás datos de ese grupo.

Por ejemplo, para probar un programa Cuadrado (un programa que da como resultado el cuadrado de un número), puede haber clases de equivalencia: el conjunto de los números negativos, los enteros, los decimales, el conjunto de los números grandes, etc.

Pregunta nº. 39. ¿Qué es el análisis del valor límite?

Respuesta: El análisis de valores límite es una técnica de prueba de software para diseñar casos de prueba que toma los valores límite de las distribuciones de clases de equivalencia como entrada para los casos de prueba, por ejemplo. si los datos de la prueba se encuentran en el intervalo 0-100, el análisis del umbral incluirá los datos de la prueba – 0,1, 99, 100.

Pregunta 40. ¿Qué es la prueba de la tabla de decisión?

Respuesta: La prueba de tablas de decisión es un tipo de técnica de diseño de pruebas basada en especificaciones o técnica de prueba de caja negra en la que las pruebas se realizan utilizando tablas de decisión que representan el comportamiento de una aplicación en función de varias combinaciones de valores de entrada.

Las tablas de decisión son especialmente útiles para diseñar casos de prueba para escenarios empresariales complejos que impliquen la validación de aplicaciones con múltiples combinaciones de entradas.

Pregunta 41. ¿Qué es un gráfico causa-efecto?

Contesta: La prueba gráfica de causa y efecto es una técnica de diseño de pruebas de caja negra en la que se utiliza una representación gráfica de la entrada para diseñar las pruebas, es decir j. causas y resultados, es decir j. de consecuencia. Esta técnica utiliza varias notaciones que representan Y, O, NO, etc. entre las condiciones de entrada que conducen a la salida.

Pregunta nº. 42. ¿Qué es la prueba de transición de estado?

Respuesta: La prueba de transición de estados es una técnica de diseño de pruebas de caja negra basada en un modelo de máquina de estados. Probar las transiciones entre estados se basa en el concepto de que un sistema puede definirse como un conjunto de múltiples estados, y la transición de un estado a otro se producirá como resultado de un suceso.

Pregunta nº. 43. ¿Qué es la prueba de casos de uso?

Respuesta: La prueba de casos de uso es un enfoque de prueba de caja negra en el que la prueba se realiza mediante casos de uso. El escenario del caso de uso se considera una interacción entre la aplicación y los actores (usuarios). Estos casos de uso se utilizan para ilustrar los requisitos y, por tanto, también pueden servir de base para las pruebas de aceptación.

Pregunta nº. 44. ¿Qué es la cobertura de las pruebas?

Respuesta: Es una métrica que mide la cantidad de pruebas realizadas en el software al ejecutar los casos de prueba. La cobertura de las pruebas de cualquier software puede calcularse como un porcentaje del número de áreas de prueba o elementos de cobertura cubiertos en relación con el número total de áreas de prueba.

Cuanto mayor sea la cobertura de las pruebas, más partes del software estarán cubiertas por casos de prueba y, por tanto, más eficaces serán las pruebas.

Pregunta nº. 45. ¿Qué son las pruebas basadas en estructuras?

Responde: Las técnicas de diseño de pruebas basadas en estructuras también se denominan pruebas de caja blanca. En estas técnicas, es necesario conocer el código o la arquitectura interna del sistema para realizar las pruebas. Los distintos tipos de pruebas basadas en la estructura o técnicas de prueba de caja blanca son:

• Prueba de sentencias: técnica de prueba de caja blanca en la que se diseñan scripts de prueba para ejecutar comandos en el código de la aplicación. Su cobertura se mide como el número de líneas de código o sentencias ejecutadas por los scripts de prueba.
• Prueba de decisión/prueba de rama: técnica de prueba en la que se diseñan guiones de prueba para ejecutar diferentes ramas de decisión (por ejemplo, condiciones si-si) en una aplicación. Su cobertura se mide como porcentaje de puntos de decisión sobre el número total de puntos de decisión de la aplicación.
• Pruebas de condición – Las pruebas de condición son un enfoque de prueba en el que probamos una aplicación con resultados Verdadero y Falso para cada condición. Por tanto, para n condiciones, tendremos 2n guiones de prueba.
• Pruebas de condiciones múltiples – En las pruebas de condiciones múltiples, se prueban diferentes combinaciones de resultados de condiciones al menos una vez. Por tanto, para una cobertura del 100%, tendremos 2^n guiones de prueba. Esto es muy agotador y es muy difícil conseguir una cobertura del 100%.
• Pruebas de determinación de condiciones – Se trata de una forma optimizada de probar múltiples condiciones, descartando las combinaciones que no afectan a los resultados.
• Pruebas de rutas – Pruebas de rutas independientes en el sistema (las rutas son declaraciones ejecutables desde los puntos de entrada a los de salida).

Pregunta nº. 46. ¿Qué es la cobertura del código?

R: La cobertura del código es una medida de la cantidad de código cubierto por los guiones de prueba. Da una idea de la parte de la aplicación cubierta por las pruebas.

Pregunta 47. ¿Qué es la prueba de enunciados y la cobertura de enunciados en la prueba de caja blanca?

Respuesta: La prueba de sentencias es un enfoque de prueba de caja blanca en el que se diseñan guiones de prueba para ejecutar sentencias de código.

La cobertura de sentencias es una medida del porcentaje de sentencias de código ejecutadas por los scripts de prueba sobre el número total de sentencias de código de la aplicación. La cobertura de comandos es la métrica menos preferida para comprobar la cobertura de las pruebas.

Pregunta nº. 48. ¿Qué es la prueba de decisión o prueba de rama?

R: La prueba de decisión o prueba de rama es un enfoque de prueba de caja blanca en el que la cobertura de la prueba se mide por el porcentaje de puntos de decisión (por ejemplo, condiciones if-else) ejecutados del número total de puntos de decisión de la aplicación.

Pregunta 49. ¿Cuáles son los distintos niveles de las pruebas?

Responde: Las pruebas pueden realizarse a distintos niveles durante el proceso de desarrollo. Llevar a cabo actividades de comprobación a varios niveles ayuda a identificar pronto los defectos. Los distintos niveles de prueba son –

1. Pruebas unitarias

2. Pruebas de integración

3. Pruebas del sistema

4. Pruebas de aceptación

Pregunta nº. 50. ¿Qué son las pruebas unitarias?

Respuesta: Las pruebas unitarias son el primer nivel de las pruebas y consisten en probar módulos de software individuales. Suelen llevarla a cabo los promotores.

Pregunta nº. 51. ¿Qué son las pruebas de integración?

R: Las pruebas de integración se realizan después de las pruebas unitarias. En las pruebas de integración, probamos un grupo de módulos relacionados. Su objetivo es encontrar problemas de interconexión entre módulos.

Pregunta nº. 52. ¿Cuáles son los distintos tipos de pruebas de integración?

R: Los distintos tipos de pruebas de integración son –

1. Pruebas de integración «big bang» – En las pruebas de integración «big bang», las pruebas comienzan una vez integrados todos los módulos.

2. Pruebas de integración descendente – En la integración descendente, las pruebas/integración comienzan desde los módulos de nivel superior hacia los módulos de nivel inferior.

3. Pruebas de integración ascendente – En la integración ascendente, las pruebas comienzan desde los módulos de nivel inferior hacia los módulos de nivel superior de la jerarquía.

4. Pruebas de integración híbridas – Las pruebas de integración híbridas son una combinación de pruebas de integración descendentes y ascendentes. En este enfoque, la integración parte de la capa intermedia y las pruebas se realizan en ambas direcciones

Pregunta nº. 53. ¿Qué es un talón?

R: En el caso de las pruebas de integración descendente, muchas veces los módulos de nivel inferior no evolucionan cuando se inician las pruebas/integración con los módulos de nivel superior. En estos casos, se utilizan stubs o módulos ficticios para simular el funcionamiento de los módulos proporcionando una salida fija o esperada en función de los valores de entrada.

Pregunta 54. ¿Qué es un conductor?

R: En el caso de las pruebas de integración ascendentes, los controladores se utilizan para simular el funcionamiento de los módulos de nivel superior, con el fin de probar los módulos relacionados de nivel inferior en la jerarquía.

Pregunta 55. ¿Qué es la prueba del sistema?

R: La prueba del sistema es un nivel de prueba que comprueba el software en su conjunto. Durante las pruebas del sistema, se comprueba que la aplicación cumple sus requisitos empresariales.

Pregunta nº. 56. ¿Qué son las pruebas de aceptación?

Respuesta: Las pruebas de aceptación son las que realiza un posible usuario final o cliente para comprobar que el software cumple los requisitos de la empresa y puede ser aceptado para su uso.

Pregunta nº. 57. ¿Qué es la prueba UAT?

Respuesta: Las pruebas UAT son la última fase del ciclo de vida de las pruebas. Su objetivo principal es verificar que el software funciona de acuerdo con los requisitos de la empresa. También se asegura de que la aplicación sea fácil de usar y pueda manejar mejor los escenarios complejos antes de lanzar el producto a los usuarios reales.

Pregunta nº. 58. ¿Qué es la prueba de extremo a extremo?

R: Las pruebas de extremo a extremo son un tipo de prueba en el que se comprueba toda la aplicación para verificar que cada característica del software funciona como se espera y que no quedan lagunas. Garantiza que la aplicación sea fácil de usar y cumpla los requisitos de la empresa.

Pregunta nº. 59. ¿Qué es la prueba alfa?

Respuesta: La prueba alfa es un tipo de prueba de aceptación que realizan probadores o empleados internos de la organización en el lugar de trabajo del desarrollador.

Pregunta 60. ¿Qué es una prueba beta?

Respuesta: Las pruebas beta son las que realizan los usuarios finales en su lugar de trabajo. Permite a los usuarios proporcionar información directa sobre el software a la empresa desarrolladora.

Pregunta nº. 61. ¿Qué son las pruebas ad hoc?

Respuesta: Las pruebas ad hoc son una forma no estructurada de realizar pruebas, sin documentación formal ni planificación adecuada.

Pregunta nº 62. ¿Qué es la prueba del mono?

Respuesta: La prueba del mono es un tipo de prueba que se realiza aleatoriamente, sin casos de prueba ni entradas de prueba predefinidos.

Pregunta nº. 63. ¿En qué se diferencian las pruebas mono de las pruebas adhoc?

R: En el caso de las pruebas Adhoc, aunque no haya casos de prueba predefinidos o documentados, los probadores siguen teniendo una visión general de la aplicación. Mientras que en el caso de las pruebas de mono, los probadores no entienden la aplicación.

Pregunta nº. 64. ¿Qué es la prueba exploratoria?

R: La prueba exploratoria es un tipo de prueba en la que se añaden y actualizan nuevos casos de prueba a medida que se explora el sistema o se ejecutan los casos de prueba. A diferencia de las pruebas con guión, en las pruebas exploratorias, el diseño y la ejecución de las pruebas tienen lugar en paralelo.

Pregunta nº. 65. ¿Qué es la prueba de carga?

R: Las pruebas de carga son un tipo de pruebas de rendimiento cuyo objetivo es determinar el rendimiento de una aplicación bajo una carga prevista. Durante las pruebas de carga, evaluamos el tiempo de respuesta, el rendimiento, la tasa de errores, etc. parámetros de aplicación.

Pregunta nº. 66. ¿Qué son las pruebas de estrés?

R: Las pruebas de estrés son un tipo de pruebas de rendimiento en las que se controla el comportamiento de una aplicación bajo una carga superior a la esperada. Las pruebas de estrés se realizan para detectar fugas de memoria y la robustez de la aplicación.

Pregunta nº. 67. ¿Qué es la prueba de volumen?

R: Las pruebas de volumen son un tipo de prueba de rendimiento que evalúa el rendimiento de una aplicación con una gran cantidad de datos. Comprueba la escalabilidad de la aplicación y ayuda a identificar los cuellos de botella con grandes volúmenes de datos.

Pregunta nº. 68. ¿Qué es la prueba de resistencia o Soak test?

Respuesta: Las pruebas de resistencia son un tipo de pruebas de rendimiento cuyo objetivo es encontrar problemas, como fugas de memoria, cuando una aplicación se somete a pruebas de estrés durante un largo periodo de tiempo.

Pregunta nº. 69. ¿Qué es la prueba del pico?

R: La prueba de picos es un tipo de prueba de rendimiento que mide el rendimiento de una aplicación cuando el número de usuarios activos aumenta repentinamente durante una prueba de estrés.

Pregunta nº. 70. ¿Qué es la prueba de interfaz de usuario?

Respuesta: Las pruebas de interfaz de usuario o UI son un tipo de pruebas cuyo objetivo es encontrar fallos en la GUI de una aplicación y comprobar si la GUI se ajusta a las especificaciones.

Pregunta nº. 71. ¿Qué son las pruebas de usabilidad?

Respuesta: Las pruebas de usabilidad son un tipo de pruebas cuyo objetivo es determinar la facilidad de uso de una aplicación. Su finalidad es detectar fallos de usabilidad en la aplicación.

Pregunta nº. 72. ¿Qué son las pruebas de accesibilidad?

Respuesta: Las pruebas de accesibilidad son un tipo de pruebas diseñadas para determinar la facilidad de uso o funcionamiento de una aplicación específicamente para personas con discapacidad.

Pregunta 73. ¿Qué es la prueba de compatibilidad?

Respuesta: La prueba de compatibilidad es la verificación del software para determinar su compatibilidad con un entorno concreto: sistema operativo, plataforma o hardware.

Pregunta nº. 74. ¿Qué es la prueba de configuración?

Respuesta: La prueba de configuración es un tipo de prueba que se utiliza para evaluar los requisitos de configuración del software junto con el efecto de cambiar la configuración requerida.

Pregunta nº 75. ¿Qué son las pruebas de localización?

R: Las pruebas de localización son un tipo de pruebas en las que evaluamos la adaptación de una aplicación (una versión localizada de la aplicación) en una cultura, ubicación o país concretos.

Pregunta nº. 76. ¿Qué es la prueba de la globalización?

R: Las pruebas de globalización son un tipo de pruebas que evalúan el rendimiento de una aplicación en todo el mundo en diferentes culturas, idiomas, lugares y países.

Pregunta nº. 77. ¿Qué son las pruebas negativas?

Respuesta: Las pruebas negativas son un tipo de prueba que evalúa la resistencia de una aplicación (graceful exiting o notificación de errores) cuando se le proporcionan datos de entrada o de prueba no válidos.

Pregunta nº. 78. ¿Qué son las pruebas de seguridad?

Respuesta: Las pruebas de seguridad son un tipo de pruebas cuyo objetivo es evaluar la integridad, autenticación, autorización, disponibilidad, confidencialidad y no repudio de la aplicación sometida a prueba.

Pregunta nº. 79. ¿Qué son las pruebas de penetración?

R: Las pruebas de penetración o pen testing son un tipo de pruebas de seguridad en las que se evalúa una aplicación (explotándola de forma segura) en busca de varios tipos de vulnerabilidades que podrían ser aprovechadas por cualquier hacker.

Pregunta nº. 80. ¿Qué es la prueba de robustez?

Respuesta: Las pruebas de robustez son un tipo de pruebas que se realizan para determinar la robustez de una aplicación, es decir. j. la capacidad del sistema para comportarse con moderación en caso de pasos de prueba y entradas de prueba defectuosos.

Pregunta nº. 81. ¿Qué es la prueba de concurrencia?

Respuesta: Las pruebas de concurrencia son pruebas multiusuario en las que se evalúa una aplicación analizando su comportamiento cuando los usuarios acceden a la misma función de forma concurrente.

Pregunta nº. 82. ¿Qué es la prueba del backend?

Respuesta: Las pruebas de backend son un tipo de pruebas que implican probar el backend del sistema, lo que incluye probar las bases de datos y las API de la aplicación.

Pregunta nº. 83. ¿Qué son las pruebas A/B?

Respuesta: Las pruebas A/B son un tipo de pruebas en las que se expone a los usuarios finales a dos variantes de un producto de software y, basándose en un análisis del comportamiento del usuario en cada variante, se selecciona la variante mejor y se utiliza.

Pregunta nº. 84. ¿Qué es el análisis de riesgos?

Respuesta: El análisis de riesgos es el análisis de un riesgo identificado y la asignación de un nivel de riesgo adecuado a un defecto en función de su impacto en la aplicación.

Pregunta nº. 85. ¿Qué diferencia hay entre las pruebas de regresión y el retesteo?

R: Las pruebas de regresión consisten en probar una aplicación para verificar que un nuevo cambio de código no afecta a otras partes de la aplicación. Al volver a probar, comprobamos si el problema solucionado se ha resuelto o no.

Pregunta nº. 86. ¿Cuál es la diferencia entre las pruebas de caja negra y de caja blanca?

Respuesta: Las pruebas de caja negra son un tipo de pruebas en las que no se requiere la arquitectura interna del código para realizarlas. Suele aplicarse en las pruebas del sistema y en las pruebas de aceptación.

Mientras que las pruebas de caja blanca requieren conocer el diseño interno y la implementación de la aplicación sometida a prueba. Suele utilizarse para pruebas unitarias y pruebas de integración.

Pregunta nº. 87. ¿Cuál es la diferencia entre las pruebas de humo y las de cordura?

R: La diferencia entre las pruebas de humo y las pruebas de cordura es la siguiente.

• La prueba de humo es un tipo de prueba en la que se prueban todas las funciones principales de una aplicación antes de realizar una prueba exhaustiva. Mientras que las pruebas de cordura son un subconjunto de las pruebas de regresión, que se realizan cuando se hace alguna corrección menor en la aplicación en una nueva compilación.
• Las pruebas de humo suelen estar documentadas o automatizadas. Aunque las pruebas de cordura no suelen estar documentadas ni guionizadas.

Pregunta nº. 88. ¿Cuál es la diferencia entre Liberar y Construir?

Respuesta: Una compilación es un archivo ejecutable proporcionado por los desarrolladores al equipo de pruebas para probar la aplicación. Pasa por varias iteraciones de correcciones y pruebas hasta que la aplicación funcione como se espera. Cuando la aplicación es estable y está lista para los usuarios finales, se lanza al mercado.

Mientras que la Versión es el software instalable que se proporciona a los usuarios finales después de que el equipo de pruebas lo haya certificado. Cuando se libera cualquier software a un cliente, va acompañado de notas de lanzamiento que incluyen el número de errores aún abiertos, las historias de usuario cubiertas, las peticiones de cambio y la versión de lanzamiento.

Preguntas avanzadas de la entrevista sobre pruebas manuales

Preguntas no. 89. ¿Cuál es la diferencia entre filtración de fallos y liberación de fallos?

Respuesta Una fuga de errores se produce cuando un software en fase de pruebas sale al mercado y el usuario final encuentra errores en él. Esto incluye los errores pasados por alto por el equipo de pruebas durante la fase de pruebas.

Mientras que una publicación de errores es cuando una versión concreta de un software se lanza al mercado con algunos errores conocidos que se corregirán en versiones posteriores. Este tipo de problemas son de baja prioridad y se mencionan en las notas de la versión cuando se comparten con los usuarios finales.

Pregunta nº. 90. ¿Qué quieres decir con Triaje de defectos?

R: El triaje de defectos es un proceso que prioriza los defectos en función de varios factores, como la gravedad, el riesgo, el tiempo necesario para solucionar el defecto, etc. A la reunión asisten varias partes interesadas: equipo de desarrollo, equipo de pruebas, jefe de proyecto, BA, etc. y decidir la prioridad de la corrección de errores.

Pregunta nº. 91. ¿Qué es una prueba de arnés? ¿Por qué necesitamos una prueba de arnés?

Respuesta: Un arnés de pruebas es una colección de guiones de pruebas y datos de pruebas que suele asociarse a las pruebas unitarias y de integración. Incluye stubs y drivers necesarios para probar módulos de software y componentes integrados.

Pregunta nº. 92. ¿Qué son las pruebas por parejas?

Respuesta: La prueba de todos los pares es un tipo de prueba en el que la aplicación se prueba con todas las combinaciones posibles de valores de los parámetros de entrada.

Pregunta nº. 93. ¿Qué es la prueba de conmutación por error?

Respuesta: La prueba de conmutación por error es un tipo de prueba que se utiliza para verificar la capacidad de una aplicación para asignar varios recursos (varios servidores) en caso de fallo y transferir parte del procesamiento a un sistema de copia de seguridad.

Pregunta nº. 94. ¿Qué son las pruebas fuzz?

R: Las pruebas Fuzz son un tipo de pruebas en las que se proporciona una gran cantidad de datos aleatorios como entrada a una aplicación, con el fin de encontrar brechas de seguridad y otros problemas en la aplicación.

Pregunta nº. 95. ¿Qué es una prueba piloto?

R: Las pruebas piloto son pruebas realizadas a modo de ensayo con un número limitado de usuarios que evalúan el sistema y aportan sus comentarios antes de la implantación completa.

Pregunta nº. 96. ¿Qué es la prueba dev-box?

R: En las pruebas dev-box, el probador realiza pruebas en el sistema del desarrollador para verificar que las principales características de la aplicación son estables y están listas para las pruebas.

Pregunta nº. 97. ¿Qué es la prueba de mutaciones?

Respuesta: La prueba de mutación es un tipo de prueba de caja blanca en la que se muta el código fuente de una aplicación para provocar determinados errores en su funcionamiento. A continuación, se ejecutan guiones de prueba para comprobar su corrección verificando los errores causados por el código mutado.

Pregunta nº. 98. ¿Qué es una matriz de trazabilidad de requisitos (RTM)?

R: En las pruebas de software, una matriz de trazabilidad de requisitos es una tabla que relaciona los requisitos de alto nivel con los requisitos detallados, los planes de prueba o los casos de prueba. La RTM ayuda a garantizar una cobertura de pruebas del 100%.

Pregunta nº. 99. ¿Qué es la complejidad ciclomática?

R: La complejidad ciclomática es una medida del número de caminos independientes en una aplicación o programa. Esta métrica proporciona una indicación de la cantidad de esfuerzo necesario para probar la funcionalidad completa. Puede definirse mediante la expresión –

L – N + 2P, donde:

L es el número de aristas del grafo

N es el número de nodos

P es el número de partes desconectadas

Pregunta nº. 100. ¿Cuáles son los criterios de acceso a las pruebas de software?

Respuesta El conjunto de requisitos previos necesarios para iniciar una actividad de prueba incluye el entorno de prueba, la herramienta de prueba, los datos de prueba, la conexión a la base de datos y muchos más.

Pregunta nº. 101. ¿Cuáles son los criterios de salida para las pruebas de software?

R: Los criterios de salida son un conjunto formal de condiciones que especifican una propiedad o estado acordado de una aplicación para indicar la finalización de un proceso o producto.

Pregunta nº. 102. ¿Cuál es la diferencia entre probar y depurar (pruebas y depuración)

Respuesta: Las pruebas las realiza principalmente el equipo de pruebas para encontrar fallos en el sistema. Mientras que la depuración es una actividad realizada por el equipo de desarrollo. Durante la depuración, se detecta y elimina la causa del error. Esto eliminará el error y evitará que se produzca en el futuro.

Otra diferencia entre ambas actividades es que las pruebas pueden realizarse sin ningún conocimiento interno de la arquitectura del software. Mientras que la depuración requiere conocimientos de arquitectura de software y programación.

Pregunta nº. 103. Explica la metodología ágil.

Respuesta: La metodología ágil de desarrollo de software se basa en un enfoque iterativo e incremental. En este modelo, la aplicación se divide en conjuntos más pequeños en los que trabajan juntos distintos equipos interfuncionales, lo que garantiza una entrega rápida y, al mismo tiempo, la adaptación a las necesidades cambiantes.

Pregunta nº. 104. ¿Qué es el scrum?

R: Scrum es el proceso de implantación de una metodología ágil. En un scrum, el tiempo se divide en sprints y el producto se entrega cuando se completan.

Pregunta nº. 105. ¿Cuáles son los distintos roles en el scrum?

Respuesta: Los diferentes roles en scrum son –

1. Propietario del producto – El propietario del producto es el dueño de todo el desarrollo del producto, asigna tareas al equipo y actúa como interfaz entre el equipo scrum (equipo de desarrollo) y las partes interesadas.

2. Scrum Master – El Scrum Master se asegura de que el equipo sigue las normas y dirige las reuniones.

3. Equipo Scrum – El equipo Scrum participa en las reuniones Scrum y realiza las tareas asignadas.

Pregunta nº. 106. ¿Qué es una reunión scrum?

R: Una reunión scrum es una reunión diaria dentro del proceso scrum. Esta reunión está dirigida por el scrum master y en ella se define una actualización del trabajo del día anterior junto con las tareas y el contexto del día siguiente.

Pregunta nº. 107. Explica el concepto de TDD (Desarrollo Dirigido por Pruebas).

Respuesta: El desarrollo dirigido por pruebas es una metodología de desarrollo de software en la que éste se guía por casos de prueba creados para la funcionalidad implementada. En TDD, primero se crean los casos de prueba y luego se escribe el código para superar las pruebas. Posteriormente, el código se refactoriza de acuerdo con las normas.

Pregunta nº. 108. ¿Cuál es la diferencia entre errores ocultos y enmascarados?

R: Un defecto latente es un defecto no identificado que está presente en la versión actual, pero que no es visible porque nunca se cumplieron las condiciones en las que podría encontrarse el defecto. Este tipo de defectos sólo aparecen cuando se desencadena un determinado acontecimiento que enmascara su presencia.

Mientras que un defecto enmascarado es un defecto existente que aún no ha causado ningún fallo porque otro defecto lo ha enmascarado o ha impedido que se detecte.

Pregunta nº. 109. ¿Qué es el ciclo PDCA en las pruebas de software?

R: El ciclo PDCA es la clave de la mejora continua de los procesos en el desarrollo de software. Incluye los 4 pasos siguientes –

• PLANIFICAR – Planificar intenciones, objetivos e iniciativas que ayuden a conseguir la satisfacción del cliente.
• HACER – Poner en práctica el plan. Para servir al cliente con mayor calidad y satisfacción, es necesario tener un buen plan que aplicar.
• COMPROBAR – Comprobar el progreso de la aplicación del plan. El resultado mostrará exactamente cómo se ha hecho la planificación.
• ACTUAR – Actuar sobre los resultados para introducir nuevas mejoras que ayuden a alcanzar los objetivos previstos.

Pregunta nº. 110. ¿Qué es la cascada de defectos?

R: El defecto en cascada es la inducción de un defecto por otro defecto. Se produce cuando el equipo de pruebas no detecta un defecto y desencadena otro.

Pregunta nº. 111. ¿Qué es una métrica de prueba?

Respuesta: Las métricas de prueba son un análisis cuantitativo que ayuda a controlar el progreso de un proyecto de software. Cada proyecto tiene su propio calendario, por lo que garantizar la entrega a tiempo del proyecto requiere fijar los entregables en distintos intervalos, y las métricas de las pruebas proporcionan este aspecto de la medición del progreso.

Pregunta nº. 112. ¿Qué es la prueba basada en el contexto?

Respuesta: La prueba basada en el contexto es un tipo de prueba que consiste en adoptar procedimientos y metodologías de prueba y, a veces, adaptarlos en función del contexto del proyecto.

En este tipo de pruebas, en lugar de seguir las mejores prácticas, seguimos lo que es mejor para el proyecto basándonos en las habilidades, la experiencia y el juicio del equipo de pruebas.

Pregunta nº. 113. ¿Cómo puedes probar una aplicación sin un documento de requisitos?

Contesta: Una aplicación puede probarse sin un documento formal de requisitos utilizando las siguientes medidas –

• Revisando solicitudes de naturaleza similar.
• Pruebas basadas en la experiencia ideal del usuario. Incluso sin tener ningún requisito, el probador puede comprobar la facilidad de uso de la aplicación.
• Utilizar pruebas exploratorias. Al no disponer de documentación, los probadores pueden utilizar pruebas exploratorias y probar la aplicación sobre la marcha con un enfoque más práctico.
• Hacer tantas preguntas como sea posible y hacer una lluvia de ideas con las distintas partes interesadas: jefes de producto, desarrolladores, etc.

Pregunta nº. 114. ¿Cómo escribir casos de prueba eficaces?

R: Podemos escribir casos de prueba eficaces utilizando los siguientes enfoques.

• Siguiendo técnicas de diseño de pruebas como el análisis de valores límite, la partición de clases de equivalencia, las pruebas de tablas de decisión, etc.
• Escribiendo casos de prueba claros y concisos, que no sean ambiguos.
• La adhesión a una nomenclatura uniforme también ayuda a crear casos de prueba eficaces.
• Evitar la redundancia conlleva una pérdida de recursos y de tiempo. Por tanto, los buenos casos de prueba no tienen por qué ser redundantes.
• Utilizar una matriz de trazabilidad de requisitos ayuda a garantizar la máxima cobertura de las pruebas.