Nuestra filosofía de Pruebas de Software II

Continuando con nuestro artículo anterior, donde hablamos sobre nuestros tres temas de filosofía de pruebas de software centrados en lo que es la calidad, el impacto y el propósito de la prueba, es hora de continuar con nuestro enfoque de prueba de software.

Enfoque

• • La prueba es un proceso intelectual que requiere pensamiento crítico, lógico y lateral. Por lo tanto, cualquier cosa que desaliente tal pensamiento al realizar tales pruebas puede ser potencialmente dañina.
  • Durante la prueba, un tester debe usar los sombreros de un detective, un científico y un explorador para hacer las preguntas correctas que puedan exponer la información importante que necesitan el equipo y las partes interesadas.
  • No hay mejores prácticas, solo buenas prácticas. La aplicación ciega de una práctica a una situación porque funcionó en otro lugar, puede causar más daño que beneficio. Entender el contexto de cualquier práctica en la que se usará es crucial.
  • Ningún software está libre de errores. Por lo tanto, es de suma importancia encontrar los errores que son críticos e importantes para el equipo, los interesados ​​y las audiencias.
  • Hay innumerables escenarios que pueden contener las pruebas, por lo tanto, nunca se puede decir que se haya probado completamente un producto. La definición de hecho en las pruebas debe considerarse y acordarse cuidadosamente dentro del equipo y las partes interesadas.
  • Si bien todos los enfoques de prueba deben considerarse dentro de su contexto, la mayoría de las veces, el uso de casos de prueba completamente detallados y explícitamente definidos NO es el mejor uso del tiempo de los testers. Permitir que el probador varíe su ejecución de prueba sin afectar los objetivos generales puede introducir una mayor probabilidad de encontrar los errores que son más importantes.
  • Todos los casos de prueba deben ser explícitos sobre el punto del caso de prueba y lo que está tratando de probar.
  • Algunas cosas no pueden ser automatizadas. Algunas cosas pueden, pero no deberían ser. La creencia de que la automatización tiene un alto costo inicial que ahorrará dinero y recursos en el futuro es una declaración falsa. Aquellos que intentan automatizar todo se encuentran gastando más dinero en respaldar estos marcos al tiempo que reciben pocos beneficios.
  • Para tener éxito, los testers deben acercarse a un producto intentando probar que tiene errores en lugar de probar que el producto es correcto. De lo contrario, podríamos ser víctimas de sesgos de confirmación y fallar problemas. La comprobación no está probando.
  • Al desarrollar planes de cobertura de prueba, los testers deben utilizar heurísticas y oráculos para cubrir las cosas que son más importantes para el equipo, las partes interesadas y el público.
  • El valor de cualquier acción tiene 3 componentes: el beneficio obtenido al completar la acción y los costos incurridos al realizar la acción, y los costos ocultos de no obtener el beneficio de realizar otras acciones que ya no se pueden realizar. Elegir la acción correcta en cualquier punto en el tiempo significa lograr un equilibrio entre estos 3 elementos.

La próxima semana continuaremos discutiendo nuestra filosofía detrás de las pruebas de software, donde abordaremos los resultados detrás de estas pruebas.

Manténte conectado con nosotros para conocer más información sobre las tendencias y los servicios de prueba de software.

Este articulo fue escrito por Alex Dillon
CEO y Fundador de TechAID
Twitter: @masterpiece91