Pruebas rápidas de software : el estilo de las pruebas rápidas se centra en el probador (en lugar de centrarse en la técnica) y es una combinación de pruebas heurísticas, pruebas basadas en el riesgo y pruebas exploratorias.




¿En qué se diferencia Rapid Software Testing de las pruebas de software normales?


La práctica de las pruebas de software difiere de una industria a otra, de una compañía a otra, de un tester a otro y de una persona a otra. Pero hay algunos elementos que la mayoría de los proyectos de prueba tienen en común. Llamemos a esos elementos comunes "pruebas normales". En nuestra experiencia, las pruebas normales implican escribir casos de prueba contra algún tipo de especificación. Estos casos de prueba son

planes o procedimientos fragmentarios que especifican libremente lo que hará un probador para probar el producto. Se espera que el probador realice estos casos de prueba en el producto, repetidamente, durante el transcurso del proyecto.


Las pruebas rápidas difieren de las pruebas tradicionales en varias formas principales:


  • No pierdas el tiempo. La acción más rápida es ninguna acción en absoluto. Entonces, en las pruebas rápidas eliminamos cualquier actividad que no sea necesaria. Las pruebas tradicionales, en comparación, son un desastre inflado Se necesita algo de entrenamiento y experiencia para saber qué eliminar, por supuesto. En general, simplifique la documentación y dedique las pruebas principalmente a las áreas de riesgo. No repita las pruebas solo porque alguien le dijo que la repetición es buena. Asegúrese de obtener un buen valor de información de cada prueba. Considere el costo de oportunidad de cada actividad de prueba.





  • MisiónEn Rapid Testing no comenzamos con una tarea ("escribir casos de prueba"), comenzamos con una
    misión. Nuestra misión puede ser "encontrar problemas importantes rápidamente". Si es así, entonces escribir casos de prueba puede no ser el mejor enfoque para el proceso de prueba. Si, por otro lado, nuestra misión es "complacer a los auditores de la FDA", entonces no solo tendremos que escribir casos de prueba, sino que tendremos que escribir ciertos tipos de casos de prueba y presentarlos en un formato específicamente aprobado. Partiendo de una comprensión de nuestra misión, hacemos un balance de nuestra situación y buscamos las acciones más eficientes y efectivas que podamos tomar en este momento para avanzar hacia el cumplimiento de esa misión.




  • Habilidades. Hacer cualquier prueba bien requiere habilidad. Las pruebas normales minimizan la importancia de la habilidad al centrarse en el formato de la documentación de la prueba en lugar de la solidez de las
    pruebas. La prueba rápida, como la describimos, destaca la habilidad. No es una técnica mecánica como hacer palomitas de microondas o llenar formularios en el DMV. Las pruebas robustas son muy importantes, por lo que practicamos el pensamiento crítico y las habilidades de diseño experimental. Un probador novato no hará muy bien la RT a menos que sea supervisado y entrenado por un probador senior que esté capacitado (o autodidacta) en el arte. Esperamos que los artículos y presentaciones en este sitio lo ayuden a trabajar en esas habilidades.






  • Riesgo. Las pruebas normales se centran en la cobertura funcional y estructural del producto. En otras palabras, si el producto puede hacer X, intente con X. Rapid Testing se enfoca en problemas importantes. Comprendemos el producto que estamos probando hasta el punto en que podemos imaginar qué tipos de problemas tienen más probabilidades de ocurrir y qué problemas tendrían más impacto si ocurrieran. Luego, ponemos la mayor parte de nuestro esfuerzo en probar esos problemas . Las pruebas rápidas se preocupan por descubrir la información más importante lo antes posible.



  • Heurística Debemos tener cuidado de no pensar demasiado en el problema de las pruebas, por lo que utilizamos la heurística (traducción flexible: reglas generales) para ayudarnos a salir de la parálisis del análisis y realizar pruebas
    más rápidamente. Las heurísticas son esencialmente reflejos, sesgos para responder de cierta manera, que generalmente nos ayudan a probar las cosas correctas en el momento correcto. Los evaluadores rápidos recopilan, memorizan y practican utilizando heurísticas útiles. En las pruebas normales, también se usan las heurísticas, pero los evaluadores a menudo no las conocen y no las controlan por completo.




  • Exploración. La prueba rápida también es un aprendizaje rápido, por lo que utilizamos pruebas exploratorias. Evitamos casos de prueba previos a la secuencia de comandos a menos que haya una necesidad clara y convincente. Preferimos dejar que la próxima prueba que tenemos sea influenciada por la última prueba que hicimos. Esto es algo bueno, porque no estamos atrapados por nociones preconcebidas sobre lo que debemos probar, sino que nos permitimos desarrollar mejores ideas a medida que avanzamos. Otros enfoques para realizar pruebas rápidamente, como la automatización extensiva de pruebas, corren el riesgo de que termines con muchas pruebas muy rápidas que no te ayudan a encontrar los problemas importantes del producto.



  • Teaming Los probadores rápidos engañan. Es decir, hacen cosas que nuestros antiguos maestros de primaria considerarían hacer trampa: averiguamos las cosas de antemano cuando sea posible, tomamos prestado el trabajo de otras personas, utilizamos todos los recursos y herramientas que podemos encontrar. Por ejemplo, una técnica importante de las pruebas rápidas es la prueba de pares: dos cabezales, una computadora. Esta idea ha demostrado ser valiosa en la práctica de la Programación Extrema, y ​​también funciona para las pruebas. En nuestra experiencia de pruebas normales, los probadores suelen trabajar en silencio y solos, en lugar de buscar insectos como una manada de lobos rápidos.