Menú

Pruebas basadas en el contexto: 7 principios básicos con un ejemplo

context driven testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

7 principios básicos de las pruebas basadas en el contexto con un ejemplo:

cuál es un buen descargador de mp3 para android

Cuando conduzco al aeropuerto, suelo tomar la autopista que me lleva allí en el mínimo tiempo y evita los peajes. Pero ese día, tomé una ruta local más larga con un peaje. Porque quería unos minutos extra con mi amigo en el camino, que viajó una distancia muy larga para pasar el fin de semana con nuestra familia. La peor opción normal, en este caso, resultó ser la mejor.

Pero considere esto.

¿Qué pasa si tengo poco combustible?

¿Qué pasa si tengo poco efectivo?

Elegiría la opción diferente. ¿Por qué? El contexto.

¿Qué son las pruebas basadas en contexto?

(imagen crédito )

Cuando toma decisiones basadas en, lo siguiente es una decisión basada en el contexto:

  • Las personas involucradas
  • Circunstancias
  • Metas
  • Opciones Disponibles
  • Emociones, etc.

Entonces, ¿qué son las pruebas basadas en contexto?

Las pruebas basadas en el contexto son un cambio de mentalidad (o escuela de pruebas) desarrollado por Cem Kaner, James Bach y Bret Pettichord. Los detalles al respecto se pueden encontrar en su famoso libro: Lecciones aprendidas en pruebas de software .

Hay 7 principios básicos. Los siguientes se seleccionan directamente de su libro:

#1) El valor de cualquier práctica depende de su contexto.

#2) Hay buenas prácticas en contexto, pero no hay mejores prácticas.

#3) Las personas, que trabajan juntas, son la parte más importante del contexto de cualquier proyecto.

#4) Los proyectos se desarrollan con el tiempo de formas que a menudo no son predecibles.

#5) El producto es una solución. Si el problema no se resuelve, el producto no funciona.

#6) Las buenas pruebas de software son un proceso intelectual desafiante.

#7) Solo a través del juicio y la habilidad, ejercidos de manera cooperativa durante todo el proyecto, podemos hacer las cosas correctas en el momento adecuado para probar nuestros productos de manera eficaz.

No voy a explicar cada uno de ellos porque nos lo hace el los propios expertos aquí .

Simplemente voy a hacer una explicación basada en escenarios sobre mi opinión sobre las pruebas basadas en el contexto.

Un ejemplo de pruebas basadas en el contexto:

Digamos que estoy comenzando un proyecto de prueba: el Proyecto A, que incluye pruebas de un extremo a otro para una aplicación basada en web.

Cual seria mi estrategia?

Según los procesos estándar, esta será la secuencia de eventos:

  • Reúna los requisitos y comprenda la aplicación
  • Crea un plan de prueba
  • Cree documentación de prueba: escenarios de prueba, casos de prueba, matriz de trazabilidad, etc.
  • Tener toda la documentación revisada y aprobada
  • Configurar el entorno de control de calidad y los datos de prueba
  • Realizar ejecución de prueba
  • Crea informes de errores
  • Genere y comparta informes de estado de ejecución de pruebas, etc.

Si me hago la pregunta: '¿Cómo decidí que esto es lo que necesito hacer?' Mi respuesta sería, mejores prácticas, estándares de control de calidad, pautas de la industria, líneas de base de experiencia pasada, etc., ¿verdad?

Estoy repitiendo lo que me enseñaron a hacer o lo que he visto hacer a otros.

Ahora, ¿hay algo de malo en eso? Para nada. Esto incluso podría funcionar también porque hay un cierto sentido de repetibilidad y prueba de tiempo en este enfoque. Sin embargo, ¿allana el camino para obtener resultados óptimos?

Dudoso. ¿Por qué?

Porque con cada proyecto te vas a enfrentar a diferentes circunstancias:

  • Requisitos documentados frente a requisitos indocumentados
  • Equipos que trabajan de cerca frente a equipos distribuidos geográficamente
  • Equipos de desarrollo y pruebas pertenecientes a la misma empresa frente a la competencia
  • Tiempo suficiente vs. Horarios apretados
  • La composición de tu equipo - Recién llegados frente a experimentados. Entrenados vs. no entrenados.
  • Disponibilidad de herramientas: uso de herramientas de gestión manual vs.
  • Tipo de proyecto: necesita un estricto cumplimiento de las reglas (FDA o banca) frente a experimental (como las redes sociales)
  • La tecnología del proyecto.Por ejemplo:no probaría la web y una aplicación de Windows de la misma manera
  • Requisitos de los clientes (algunos quieren informes detallados diarios, otros solo quieren lo más destacado)
  • Proceso seguido (pruebas ágiles frente a tradicionales, escritas frente a pruebas exploratorias)

Esta lista no es exhaustiva y usted sabe tan bien como yo que hay muchas variables en cada proyecto.

Las pruebas basadas en el contexto son cuando dejas que estas circunstancias decidan tus prácticas de prueba, técnicas e incluso definiciones en lugar de las estándar percibidas por la industria ' mejores prácticas' .

Ahora, digamos que estos son los detalles con los que estoy trabajando para el Proyecto A:

  • Estoy trabajando con un equipo de 5 a 4 recién llegados y 1 probador experimentado.
  • No tengo requisitos documentados.
  • Mi equipo está en India y el equipo de desarrollo está en EE. UU., Por lo que trabajamos en zonas horarias opuestas.
  • El cliente quiere un informe de estado detallado diario
  • Usamos una herramienta de seguimiento de errores basada en la web, como Mantis o Bugzilla, y eso es todo lo que tenemos.
  • Tengo que hacer 2 rondas de prueba en 10 días con 3 días para la documentación de prueba

Aquí hay un plan de juego aproximado:

1) Dado que hay muchos recién llegados en el equipo, necesitamos muchas revisiones de pares.

2) También necesitamos al menos 2 reuniones de discusión de requisitos con BA y el equipo de desarrollo. Esto tiene que ser formal porque los equipos están ubicados en otro lugar y hay poco margen para que yo vaya a ellos con preguntas.

cómo ver anime en línea gratis

3) Es un cronograma de pruebas agresivo para la documentación. Cuanta más documentación escribamos, más revisiones necesitamos, lo que equivale a más tiempo. Entonces, tendremos que mantener una documentación mínima. Vamos a documentar solo los principales TC de extremo a extremo y el resto va a ser probado de forma exploratoria .

4) Los informes de estado diarios durante la ejecución de la prueba se crearán y enviarán EOD todos los días.

5) La mayoría de las pruebas son exploratorias, así que aconseje el tiempo para intentar hacer un breve resumen de cada prueba ejecutada. De esta manera sabemos qué se prueba y qué no.

6) Los defectos se informarán en tiempo real en Mantis. Dado que el equipo está trabajando en una zona horaria diferente, es posible que tengan que esperar un día entero antes de recibir noticias del equipo de control de calidad, en caso de que necesiten una aclaración. Por lo tanto, configure una llamada diaria en un equipo conveniente, donde el equipo de control de calidad demostrará la recreación de errores. De esa manera, no habrá necesidad de esperar o hacer un seguimiento.

Y así.

Una vez que tenga una estrategia general, escriba un plan de prueba básico que explique estos puntos. Ahora, está listo para entrar en un proyecto de prueba después de una cuidadosa consideración y una estrategia personalizada para el éxito.

En resumen:

Esto es Pruebas basadas en el contexto; haciendo de sus circunstancias (no de los estándares) las principales entradas e influencias de su estrategia de prueba. Nos insta a mirar a nuestro alrededor y tener en cuenta todo lo que te rodea.

Personalmente, estoy enamorado de este concepto porque con demasiada frecuencia las prácticas de prueba se perciben como rígidas y basadas en imitaciones. Alguien lo hizo y fue exitoso, así que yo también lo voy a hacer. Este es el tipo de imagen que asusta a la gente de intentar y permanecer en una carrera de pruebas.

Pero hay mucho margen para el pensamiento creativo, las habilidades analíticas y la toma de decisiones. Para saber más, lea sobre el tema en los enlaces proporcionados arriba.

Feliz prueba basada en el contexto

Lectura recomendada

^