Descripción conversor grados Celcius y Fahrenheit

 El sistema muestra la pantalla con las siguientes características

o Título de la página: CelFar
o Títulos de la aplicación:
 “CelFar”
 Conversor de temperaturas entre grados Celcius y Fahrenheit (las
palabras Celcius y Fahrenheit tienen asociado un link a wikipedia)
o Campo numérico (Tamaño máximo: 6 dígitos, separador decimal: “.”).
Inicialmente este campo se encuentra vacío.
o Botón “convertir!”
o Resultado. Inicialmente este campo dice: “Pendiente de cálculo...”
 Si se completa el campo texto con el valor que desea convertir, y se selecciona
“convertir!” o la tecla enter:
o Caso normal
 El sistema emite el resultado del cálculo: (x*9/5)+32 (siendo x el
valor ingresado)
o Caso alternativo
 Si el valor tiene menos de 7 dígitos (es decir, sin contar el separador
de decimales y el signo) y es menor a -273, el sistema emite un
mensaje “El valor ingresado está debajo del 0 absoluto” (con un link
a wikipedia a la página de 0 absoluto)
 Si el campo se deja vacío o el valor ingresado no es numérico, el
sistema emite el mensaje “El valor ingresado no es un número
(recuerde que los decimales deben expresarse con '.' y no con ',')”
 Si el valor tiene más de 6 dígitos (es decir, sin contar el separador de
decimales y el signo), el sistema emite el mensaje: “El valor
ingresado es muy largo”
 Cuando se modifica el valor el campo numérico, el sistema reemplaza el resultado
de la operación anterior por el mensaje “Pendiente de cálculo...”
¿Qué es una Especificación?
Como pueden ver en el texto de Celfar, la Especificación es un documento que explica qué
es lo que tiene que hacer y tener el software que vamos a testear.
Yendo a una definición un poco más formal, la Especificación Funcional es un documento
que detalla todas las funcionalidades que debe tener una aplicación.
Cuando hablamos de funcionalidades nos referimos a determinadas acciones o
comportamientos que debería realizar un software. Por ejemplo, ingresar al sistema, sería
una funcionalidad.
En el desarrollo de software generalmente hay mucha gente involucrada por lo que se
vuelve más complicada y compleja la comunicación entre todos. En un proceso de
desarrollo de software vamos a encontrar un cliente (quien tiene una necesidad) y un
proveedor (quien satisface dicha necesidad).
Cuando un cliente solicita el desarrollo de un software está describiendo algo que todavía
no existe y por lo tanto es importante que se pueda definir bien cómo debe funcionar ese
software (qué debe hacer, y qué no debe hacer).
Para que el cliente se anime a comprar (o a esperar por) algo que aún no existe es muy
importante que el cliente y el equipo de proyecto se puedan poner de acuerdo sobre qué va
a recibir el cliente cuando el proyecto termine, es decir, cómo va a funcionar esa aplicación.
La persona encargada de crear este documento y de pasárnoslo a los Testers es el Producto
Owner (o Analista Funcional). Y algo muy muy importante, que SIEMPRE tenemos que
tener en cuenta, es que es nuestro documento de referencia. ¿Qué significa esto? Que cada
vez que probemos un software, no podemos hacer lo que queramos, sino que tenemos que
probar que el software cumpla con los puntos detallados en la Especificación.
Hoy en día, las largas especificaciones de requerimientos están siendo menos usada, el
motivo es que, con la llegada de las metodologías ágiles, estas descripciones se reemplazan
por pequeñas historias de usuario (breves descripciones) que hacen mucho más fácil la
descripción, comprobación y validación de una funcionalidad (así también como la
modificación temprana de la misma).

Bug:

Es todo aquello que se podría definir como error dado que no cumple con lo acordado entre
el Cliente - Product Owner - Equipo, ya sea, un error involuntario de programación, una
malinterpretación de las especificaciones o una omisión en los requerimientos. La palabra
bug nos remonta a una recordada, costosa y graciosa anécdota, pero que tuvo por
protagonistas a la Nasa, un vuelo al espacio, un insecto (bug) en un componente y un total
desastre.
Versión
Puede entenderse como un código de identificación del programa, que a medida que
se hacen cambios este código va incrementándose. En clase lo definimos algo así
como diferentes "niveles" del programa.