¿Qué, cómo,

dónde, cuándo y
por qué?
h_melluso@alianza.edu.uy
alianzapro.alianza.edu.uy
 Introducción
En este apartado trataremos de despejar las cinco
preguntas esenciales a cualquier actividad que
desarrollamos en nuestra vida y vamos a empezar
a explicar las bases sobre las que vamos a
desarrollar este curso.
 ¿Qué es Software?
Es el conjunto de los programas de cómputo,
procedimientos, reglas, documentación y datos
asociados, que forman parte de las operaciones
de un sistema de computación.

Extraído del estándar 729 del IEEE7

 ¿Qué probamos?
La actividad que realizamos, el testing de software,
consiste en probar requerimientos dados por una de
las partes interesadas (también conocidas como
stakeholders). Nos centraremos en este curso en el
testing funcional, el mismo es aquel que realiza
pruebas que valida que los requisitos funcionales de
un software determinado, funcionen de la manera para
la que fueron diseñados.
 ¿Cómo probamos?
El primer acercamiento hacia el testing de software y el más
extendido, es conocido como Testing funcional, el cual consiste
en realizar pruebas en base a los requerimientos del stakeholder
del sistema.
Podemos realizar pruebas de tipo funcional y no funcional para
evaluar el estado de un sistema, programa o aplicación.
La técnica más utilizada para probar aplicaciones de manera
funcional (en lo que este curso se centra) es la técnica de caja
negra o black-box.
 ¿Cómo probamos?
La definición de la misma es “Testing, tanto funcional como no funcional, que
se desarrolla sin referencias internas de los componentes o del sistema.
La técnica de caja negra es un procedimiento que consiste en derivar casos de
prueba haciendo un análisis de requerimientos, sin conocer o referenciar la
estructura del sistema.”
Lo que esta definición nos está queriendo decir, es que dados unos
requerimientos, se establecen unas pruebas a realizar que dependen de los
mismos. Sabemos que tiene que hacer la aplicación (gracias a los
requerimientos), pero no sabemos como lo tiene que hacer internamente.
 ¿Cómo probamos?
Por ejemplo, un requerimiento válido sería:
“Dados un usuario y contraseña válidos, cuando el usuario las introduce en el sistema y
presiona entrar, el sistema debe permitir al usuario ver la página principal”.
De esto nosotros sabemos cómo se debe comportar el sistema, pero realmente no
conocemos que va a hacer el mismo para conseguir el resultado que estamos
esperando.
Nosotros solamente vemos la entrada de datos (introducción de usuario y contraseña) y
la salida de los mismos (dadas unas credenciales válidas puedo entrar, dadas unas
credenciales inválidas, no puedo entrar).

Como no podemos ver la parte interna o interpretar el código, decimos que es una
prueba de caja negra porque solo podemos identificar entradas y salidas, conociendo
resultados esperados mediante requerimientos.
 ¿Por qué probamos?
El objetivo principal por el cual probamos (testeamos también es un término correcto), es tan simple
como para validar que se cumple con lo pedido por los stakeholders. Pero podemos ir un poco más
allá para comprender el sentido de nuestra tarea.
Probamos también, para detectar los errores de la manera más temprana posible. Un axioma de esta
nuestra disciplina es que cuanto antes se detecte un error, es más barato y sencillo de solucionar. La
detección temprana de defectos es un valor agregado que el proceso formal de testing trae consigo y
que es considerado fundamental.
Necesitamos probar, porque muchas veces, el objeto de prueba necesita ser comprobado para
revelar errores que él mismo pudiera tener, para ayudar a que sea seguro utilizarlo. Muchas cosas en
las que nosotros confiamos nuestras vidas, están controladas mediante computadoras, estas
computadoras contienen software, el cual es susceptible a errores y el cual es desarrollado por seres
humanos. Por poner un ejemplo, la mayoría de los controles de un avión trabajan con la tecnología
fly-by-wire y básicamente están controlados por computadoras y sensores que dicen todo el tiempo
en la posición que están, pudiendo detectar y actuar automáticamente a pequeños cambios de
dirección, mantener un rumbo fijo corrigiendo solos, entre otros beneficios.
 ¿Por qué probamos?
Un clarísimo ejemplo de errores de software recientes que han costado vidas, son por ejemplo los
accidentes de los aviones Boeing 737-Max, los cuales por problemas de software y errores de cálculo
se tornan incontrolables, causando accidentes y por consiguiente la muerte de pilotos, tripulantes y
pasajeros.
En otro apartado, las pruebas traen consigo el beneficio ya dicho de la detección temprana,
encontrada por dentro del ciclo de desarrollo y no por usuarios finales. Con las pruebas de software
ayudamos a que no se pierda la confianza en el programa, con la consiguiente pérdida económica
que este perjuicio puede ocasionar. Todos tenemos al menos un ejemplo de haber instalado algún
tipo de programa, aplicación o similar, el cual funciona notoriamente mal y hemos desinstalado o
dejado de utilizar de inmediato o en un muy corto periodo de tiempo.
Teniendo un equipo de testing, este tipo de problemas suelen verse reducidos, si bien hay que tener
en cuenta que nosotros, los testers, somos guardianes del cumplimiento de los requerimientos, estén
estos alineados con lo que nosotros creemos a título personal que funciona bien o mal.
 ¿Cuándo probamos?
Se puede empezar a testear desde el momento en el que una idea es concebida. Existe la figura del
analista de negocio que está altamente ligado al testing, que es una persona que por definición
puede ver la viabilidad de las ideas, a nivel programático. Cualquiera de nosotros puede analizar un
requerimiento y verificar si es viable, a nivel informático o no, por ejemplo, si un amigo nos dice que
cree que puede saltar desde un tercer piso y que va a caer, dar un pequeña voltereta y salir ileso, lo
mas seguro es que cualquiera de nosotros, le digamos (o no) que la altura es demasiada y que
probablemente un salto así le podría ocasionar lesiones muy serias o incluso, la muerte. He ahí un
caso de análisis de viabilidad de un requerimiento, alguien trae una idea y nosotros mediante nuestro
conocimiento en la materia o bien mediante un estudio con mayor profundad del requerimiento,
podemos decir si realmente es viable realizar las cosas de la manera en la que nace la idea o si hay
otras maneras más adecuadas, mejor performantes o más económicas de hacer las cosas.
De esto deducimos que podemos empezar a probar desde que nace la idea, podemos probar
durante su programación y concepción y podemos continuar probando una vez que está hecha para
asegurarnos que cumple con lo requerido y que sigue vigente aunque sean añadidos cambios al
programa.
 ¿Dónde probamos?
En software manejamos distintos ambientes de desarrollo, siendo esto, en términos
más amigables,el lugar donde vive el programa/aplicación.
Normalmente si la aplicación fue desarrollada teniendo en cuenta que tiene que ser
probada, probablemente haya un ambiente de desarrollo que contenga los cambios
que todavía no se enviaron al usuario final para ser probados por la parte de
testing, estos ambientes, tienen distintas nomenclaturas, porque dependen mucho
de en qué parte del ciclo de desarrollo estemos probando,nombres que vamos a
oír: ambiente de testing, staging, desarrollo, development, preproducción, ambiente
de QA.
También es posible que lleguemos a tener casos en el que haya que probar en la
versión final que está siendo entregada al público o siendo utilizada en producción.
Puede darse que sea necesario dar un pantallazo general del estado de una
aplicación y nos sea brindada la anteriormente dicha.
 ¡Muchas gracias!

Fuentes:
kaner.com - Estandar 729 de la IEEE - Libro Lessons Learned in Software -
Testing: A Context-Driven Approach - Libro Testing Computer Software, 2nd
Edition - elaboración propia.