¿Cuáles son las mejores estrategias para probar el software?

Recomendaría intentar averiguar qué es lo que se está probando. Tanto los enfoques tradicionales como los más nuevos, como el ágil, están llenos de jerga.

1. Para grandes software (o hardware), los clientes enfrentan muchos problemas. No encontrarás más de una fracción de estos.
2. La prueba es pensar en preguntas no intuitivas sobre el software. ¿Por qué los hombres prefieren realizar sus negocios mientras están de pie? por Nilanjan Bhattacharya en Counterfactuals. Sin jerga, se requiere mucha creatividad para formular preguntas sobre el software.
3. La automatización no tiene nada que ver con las pruebas: ¿Qué es la automatización de pruebas de software? por Nilanjan Bhattacharya en Contrafactuals

Creo que esto es suficiente para que comiences y te mantenga ocupado.

Múltiples ambientes, sin conversaciones cruzadas. Sandbox es como un laboratorio, para probar pruebas iniciales de conceptos. El desarrollo es donde ocurre el desarrollo real basado en el equipo con el resultado final de un producto final. LIT (Pruebas de carga e integración) es donde se probará la aplicación y se verificará la integración con los sistemas comerciales críticos. UAC (Prueba de aceptación del usuario) es donde la aplicación será “probada” por una “base de usuarios” simulada para la factibilidad y se realizarán pruebas de facilidad de uso. La etapa es donde la aplicación será diseñada e instalada como lo sería en un entorno de producción final. La etapa es crítica, ya que aquí es donde se realizarán actualizaciones, parches y revisiones importantes y se probarán antes de la graduación para pinchar. Finalmente, la producción, donde la aplicación encontrará su hogar final en el entorno de producción.

El detalle importante aquí es que hay equipos completamente separados, bajo una administración completamente separada, en TODOS los entornos, EXCEPTO el entorno limitado y el desarrollo. Cuando se produce una graduación de un entorno a otro, el paquete completo de la aplicación se proporciona con instrucciones y ahora se elimina por completo del acceso del equipo que se gradúa. Si la aplicación falla en cualquier entorno, se devuelve en su totalidad al equipo anterior para corregirla.

Cada equipo, en cada entorno, proporciona controles y equilibrios para cada equipo / env. Esta separación de entornos y, lo que es más importante, la separación de la administración en cada entorno evita que el “código incorrecto” y las “malas prácticas” se gradúen junto con la aplicación.

Probar cada permutación puede llevar un poco de tiempo. Incluso si tiene piscinas llenas de dinero y tiempo, no puede probar todo.

En general, creo que un enfoque basado en el riesgo es bastante bueno. Concéntrese en las áreas de alto riesgo y alto impacto si el riesgo se realiza en la producción.

No hay nada como “MEJOR”. Todo depende del contexto. En general, son mejores los enfoques incrementales, que deberían basarse en ciclos de retroalimentación pequeños y diversos.