Aplicar el método científico a las pruebas de software

¿Cómo se aplica el método científico a las pruebas de software?

Christin Wiedemann: Las pruebas de software siempre pueden beneficiarse de un enfoque más estructurado. El método científico no es en realidad un conjunto de métodos, sino de un conjunto más amplio de principios rectores. Se trata de conocimiento. Los científicos quieren averiguar cómo funciona el mundo; los examinadores de software quieren saber cómo funciona el software que están probando. Esas dos misiones comparten mucho en común.

El método científico está basado en la observación y la experimentación. Las pruebas [de software] son la misma cosa. Hemos creado pruebas que son muy similares a los experimentos, y luego las ejecutamos y observamos lo que sucede. Esa es la misma forma en que los científicos ponen a prueba sus hipótesis. Realizamos experimentos, medimos los resultados y analizamos los datos para averiguar lo que realmente está sucediendo.

¿Cuáles son algunos de los conceptos importantes que se transfieren bien desde el laboratorio de ciencias al laboratorio de pruebas de software?

Wiedemann: Los científicos experimentales se dan cuenta de que no podemos probar que una hipótesis es absolutamente cierta. Nosotros solo podemos probar dónde se equivocan las hipótesis de algún modo. El concepto de falsabilidad empírica simplemente está demostrando que las ideas están mal a través de experimentos. Las pruebas son muy similares en el hecho de que no podemos probar que el software está libre de fallos; solo podemos encontrar maneras de hacer que la aplicación falle a través de pruebas.

Si le pregunta a un gerente de negocios qué tanto probar el software, probablemente dirá que pruebes todo. Los buenos probadores les hacen saber que no podemos probar todo. Haría falta un número infinito de pruebas para llegar a todos los escenarios posibles. Solo podemos buscar condiciones bajo las cuales falla el software.

Si las pruebas no encuentran fallas, podemos tener más confianza de que va a trabajar, pero todavía no estamos nunca completamente seguros. Después de muchos intentos fallidos de refutar una hipótesis, los científicos reúnen confianza en la hipótesis. Les da credibilidad a sus teorías. Los probadores de software realmente están haciendo lo mismo.

Entonces, ¿cómo los ingenieros de calidad de software mejoran la credibilidad de sus pruebas y resultados?

Wiedemann: La revisión por pares es una parte importante de la credibilidad de un científico. La revisión por pares es muy importante para la ciencia en general. Es casi una parte oficial del método científico. Los compañeros pueden ser muy críticos, no en el sentido de dar una retroalimentación negativa, sino en términos de cuestionar sus respuestas.

La mayor parte del pensamiento crítico es cuestionar sus premisas. Me gusta decir, ‘Se trata de cuestionar las respuestas, no se trata de responder las preguntas’. Las revisiones de los pares cuestionarán sus suposiciones y cuestionarán los resultados que ha encontrado. No para suprimirlos, sino para ver si se pueden hacer mejor, y eso realmente debería ser el objetivo para todos nosotros.

Esto es definitivamente algo que los probadores pueden hacer más. Tener nuestro trabajo revisado por nuestros compañeros aumenta la credibilidad de los examinadores y la credibilidad de nuestras pruebas. No se trata de señalar los errores de los demás. Diferentes personas aportan diferentes prejuicios y puntos de vista, lo que aumenta el valor y la credibilidad de las pruebas. Evaluar la información elimina los prejuicios, distorsiones y supuestos. Es también una gran manera de aprender unos de otros.

¿Puede explicar la diferencia entre la inducción y la deducción?

Wiedemann: Como seres humanos, tenemos un montón de diferentes procesos de pensamiento. Utilizamos la inducción, deducción, abstracción y otros constantemente, no solo en las pruebas, sino en nuestra vida cotidiana. Es importante entender exactamente lo que estamos haciendo cuando pensamos en la calidad del software, porque pensamos de esta manera todo el tiempo, pero no siempre estamos en lo correcto.

Tanto la inducción, como la deducción son maneras de llegar a conclusiones basadas en el conocimiento previo. La deducción es cuando hacemos una conclusión específica a partir de conocimientos generales. Si sé que diez de las últimos diez aplicaciones móviles que he probado tienen un problema de red en particular, entonces podría asumir que la siguiente aplicación móvil que pruebe tendrá el mismo problema de red. Eso es trabajar desde la premisa de que todas las aplicaciones móviles tienen este defecto, por lo que mi aplicación móvil actual debe tenerlo también. Si esa premisa es verdadera, entonces sí, la aplicación móvil actual debe tener ese defecto. El problema es que mi premisa en realidad podría ser falsa.

La inducción es cuando hacemos una conclusión general desde conocimientos específicos. Así que si he probado una sola aplicación móvil y justo tuvo un error específico, entonces yo podría razonar que todas las aplicaciones móviles tienen ese defecto. En este caso, yo sé de hecho que mi premisa es verdadera, sé que esta aplicación móvil individual es deficiente porque la he probado. Sin embargo, mi conclusión en realidad no viene como una necesidad de mi premisa. Una aplicación móvil defectuosa no significa que todas las aplicaciones móviles son defectuosas. Es importante que los probadores de software prestemos atención a la manera en que pensamos, de modo que podamos mejorar nuestro pensamiento crítico.