Todo lo que siempre quisiste saber sobre las versiones de prueba y nunca te atreviste a preguntar

  • ¿Conoces el procedimiento que debe seguirse para verificar que un programa funcione correctamente?

  • ¿Sabes qué es la versión beta de un software? ¿Has probado alguna?

Por: Maestro Guillermo Pérez Mendoza, Profesor de Posgrado de la Escuela Bancaria y Comercial y Socio Director de Genera Más.

La evolución de los sistemas de información marca el rumbo de los desarrolladores de software, y se ve impulsada por las novedades en el hardware, las comunicaciones y los sistemas de administración de negocios. Existe la necesidad constante de elaborar nuevas aplicaciones: algunas de ellas son versiones actualizadas, mientras que otras son desarrollos totalmente innovadores.
Dentro de los programas nuevos, se sigue una serie de metodologías para probar y comercializar la primera versión que se lanza al mercado. Para ello, las empresas de software cuentan con personas o departamentos que garantizan la calidad del producto mediante pruebas llamadas de caja blanca o de caja negra.

Las pruebas de caja blanca se utilizan para verificar el buen funcionamiento de todas las opciones del programa, y se realizan sobre las funciones internas de un módulo. Las pruebas de caja negra se utilizan para revisar las entradas que recibe el programa, así como las salidas o respuestas que produce, sin tener en cuenta su funcionamiento.

Las pruebas pueden ser aleatorias o se pueden controlar desde alguno de los módulos o procesos. Sin embargo, no garantizan que el programa funcione de acuerdo con los estándares planteados, así que se establece un periodo de pruebas con personas externas a la compañía desarrolladora.

Estas pruebas externas se llaman pruebas beta y, como mencionábamos anteriormente, las realizan personas que utilizan e inspeccionan el programa en un ambiente de pruebas externas controladas. Por ello, dichas personas cobran una importancia fundamental, pues se convierten en agentes de calidad de los productos: son los conejillos de Indias que notifican las fallas conforme utilizan el programa con datos y procesos reales.

Durante las pruebas beta se sigue una serie de protocolos establecidos por la empresa. Aunque pueden variar de empresa a empresa, normalmente consisten en llevar una bitácora del uso del sistema. En caso de falla, se deben documentar varios datos:

  1. El proceso en que ocurrió la falla
  2. El módulo que se estaba utilizando
  3. El contexto en que sucedió la falla
  4. El tipo de falla
  5. El código de error,
  6. Los resultados obtenidos,
  7. Los elementos sin funcionalidad,
  8. Los procesos cuyos resultados son incorrectos.

En la actualidad, una de las metodologías más utilizadas consiste en enviar de forma inmediata las notificaciones de las fallas a través de Internet. En este caso, la persona que descubre la falla elabora el informe con los parámetros y contextos en los que encontró el defecto del programa y lo envía por Internet, lo cual permite que esta actividad sea muy dinámica y que se reduzcan los tiempos de corrección y respuesta, que dependen del tipo de falla.

En la bitácora también deberán incluirse aspectos de compatibilidad con otros programas, pero es indispensable que se especifique si la falla se origina en el hardware o en el software. Es decir, es necesario distinguir si la falla ocurrió en el sistema operativo, en otros programas que se ejecutaron antes de que se presentara la citada falla, o si se originó a partir de un mal procedimiento operativo o un uso incorrecto por parte del usuario.

Para quienes tienen el privilegio de probar estos prototipos y versiones iniciales, esta actividad se convierte en un deporte y afición: ¡les encanta ser los primeros en utilizar las nuevas versiones de los sistemas operativos, las actualizaciones de los programas, los nuevos módulos o las aplicaciones innovadoras!

Los testers o probadores externos también hacen otras recomendaciones sobre los programas:

  • Mejoras en el diseño
  • Facilidad de uso
  • Procesos deseables
  • Procesos inútiles
  • Interfaces con otros dispositivos para su aplicación, etc.

El tener siempre una versión beta en las empresas desarrolladoras se ha convertido en una de las mejores prácticas empresariales para el desarrollo de sistemas, pues reduce las fallas cuando el programa se encuentra en uso, y su comercialización ya está avanzada entre los diversos usuarios.

Sin embargo, a pesar de las pruebas internas y externas, existen muchas posibilidades de fallas, como los famosos bugs, así que los programas se verifican y actualizan de forma constante. Cuando se identifica algún problema, éste se corrige lo más rápido posible y se comercializa una nueva versión o un “parche” con la corrección implementada.

Y a todo esto, ¿sabes de dónde proviene el término bug (bicho)?, el término bug (bicho) se utiliza desde 1945, pues un pequeño bicho que se introdujo en una computadora causó el primer error informático, el cual fue descubierto por Grace Murray Hooper. No obstante, hay quienes sostienen que Thomas Alva Edison ya utilizaba el término en sus trabajos para describir defectos en sistemas mecánicos.

¿Qué opinas? ¿Estarías dispuesto a convertirte en un probador de software beta? Recuerda que, aunque tiene su encanto, también incluye un aspecto de riesgo, así que te recomendamos que te informes antes de instalarlo en tu computadora. Es importante que conozcas esta terminología y las implicaciones de la versión de prueba llamada beta.