Prueba Unitaria.

Definición.

Es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo, de forma que cada caso sea independiente del resto.

Para que una prueba unitaria sea útil, debe configurar su entorno de ejecución antes de ejecutarse, de modo que la prueba unitaria pueda comprobar de manera coherente el código que se pretende probar. Una vez que la prueba se ha implementado y comprobado, se activa en el control de código fuente y se usará durante el resto de la vigencia del producto para garantizar que el método sigue comportándose como estaba previsto.

Características de una buena prueba unitaria

Las pruebas unitarias se tienen que poder ejecutar sin necesidad de intervención manual. Esta característica posibilita que podamos automatizar su ejecución.

Las pruebas unitarias tienen que poder repetirse tantas veces como uno quiera. Por este 

motivo, la rapidez de las pruebas tiene un factor clave. Si pasar las pruebas es un proceso lento no se pasarán de forma habitual, por lo que se perderán los beneficios que éstas nos ofrecen.Las pruebas unitarias deben poder cubrir casi la totalidad del código de nuestra aplicación. 

Una prueba unitaria será tan buena como su cobertura de código. La cobertura de código marca la cantidad de código de la aplicación que está sometido a una prueba. Por tanto, si la cobertura es baja, significará que gran parte de nuestro código está sin probar.

Las pruebas unitarias tienen que poder ejecutarse independientemente del estado del entorno. 

Las pruebas tienen que pasar en cualquier ordenador del equipo de desarrollo.

La ejecución de una prueba no puede afectar la ejecución de otra. Después de la ejecución de una prueba el entorno debería quedar igual que estaba antes de realizar la prueba.
Las diferentes relaciones que puedan existir entre módulos deben ser simulada para evitar
dependencias entre módulos.

Es importante conocer claramente cuál es el objetivo del test. Cualquier desarrollador debería
poder conocer claramente cuál es el objetivo de la prueba y su funcionamiento. Esto sólo se
consigue si se trata el código de pruebas como el código de la aplicación.

Es importante tener en cuenta que aunque estas son las características de una buena prueba, no siempre será posible ni necesario cumplir con todas estas reglas y será la experiencia la que nos guiará en la realización de las mismas.

Formato pruebas de software.

Descripción de ítem.

·         Titulo prueba. Especifica el nombre de la prueba a realizar.

·         Tipo prueba. Describe el tipo de prueba que se va a realizar.

·         Código identificación. Código que identifica la prueba.

·         Versión. Número de veces que se ha aplicado el mismo tipo de prueba.

·         Fecha realización. Fecha en la que se realiza la prueba.

·         Descripción general. Especificaciones de la prueba.

·         Precondiciones. Parámetros requeridos  para realizar la prueba.

·         Datos ingresados. Datos que serán usados para la ejecución de la prueba.

·         Resultados esperados. Aspectos  que se espera que arroje la ejecución de la prueba.

·         Proceso realizado. Ejecución de los procesos según la prueba aplicada.

·         Resultados obtenidos. Los aspectos que son arrojados por la aplicación de la prueba.

·         Evidencia. Pantallazo que valide los resultados obtenidos.

Ambiente de la prueba.

·         Software. Programas que se ejecutan simultáneamente con el programa que es objeto de la prueba.

·         Hardware. Descripción de los recursos físicos del equipo en la cual se ejecuta la aplicación que es objeto de la prueba.

·         Severidad. Grado de daño que ocasiona el sistema el defecto encontrado.

·         Prioridad. Que tan pronto es necesario que corrijan el defecto encontrado.

·         Observación. Aspectos que se deben de tener encuentra para corregir la deficiencia. 

Casos de prueba.

Facebook

Caso de prueba #1.

·         crear cuenta en Facebook  con cuentas diferentes de correo diferentes a Hotmail.

Precondiciones: Tener correo electrónico.

Conjunto de valores de entrada: Nombre, apellidos, cuenta de correo, sexo, fecha de nacimiento, contraseña.

Conjunto de resultados esperados: Que se cree una cuenta en Facebook.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Llenar el formulario de registro con los datos solicitados para cumplir con el proceso de inscripción, si es exitoso se crea cuenta en Facebook  de lo contrario se genera un mensaje de error informando como corregir los datos erróneos el formulario de registro.

Poscondiciones esperadas: Es posible crear cuentas de Facebook con correos diferentes al Hotmail tales como el gmail y la cuenta del  correo institucional del Tdea.

Caso de prueba #2.

·         cuantas conversaciones puede tener al mismo tiempo en Facebook

Precondiciones: Entrar a Facebook con un usuario y su respectiva contraseña.

Conjunto de valores de entrada: Tener la página principal de Facebook abierta.

Conjunto de resultados esperados: Que se ejecute una ventana de chat por cada persona que en el momento se encuentre conectada a la aplicación de Facebook.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Se muestra una ventana por cada conversación iniciada.

Poscondiciones esperadas: Se puede visualizar 4 conversaciones en pantalla, las demás se almacenan en un cuadro desplegable en la parte inferior a la izquierda, que marca el número de conversaciones que se encuentran ocultas.

Caso de prueba #3.

·         Que tipos de formatos de imagen permite Facebook subir y ser publicadas.

Precondiciones: Tener un archivo de imagen con un  formato: (JPG-GIF-PNG-TIF-BMP).

Conjunto de valores de entrada: Seleccionar los archivos de imagen.

Conjunto de resultados esperados: Publicar las imágenes en la aplicación de Facebook.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Se selecciona el link para los archivos de imagen, luego se seleccionan los archivos, si es de preferencia se añaden las etiquetas y el nombre o se hace un comentario y se da clic en publicar.

Poscondiciones esperadas: Se puede subir las imágenes en cualquier formato tales como: (JPG-GIF-PNG-TIF-BMP).

Whatsapp

Caso de prueba #1

·         Registro en la aplicación de Whatsapp.

Precondiciones: Tener acceso a internet.

Conjunto de valores de entrada: Número de teléfono celular.

Conjunto de resultados esperados: Quedar registrado en la aplicación de whatsapp.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Se llena el formulario de registro con los datos solicitados, y se espera el código de verificación que llegara al celular al cual corresponde el número registrado.

Poscondiciones esperadas: Se puede hacer el registro desde diferentes dispositivos tales como blackberry, android o un computador.

Caso de prueba #2.

·         Registro de whatsapp con un número diferente de celular que no corresponde al celular que corre la aplicación.

Precondiciones: Tener acceso a internet.

Conjunto de valores de entrada: Número de teléfono celular.

Conjunto de resultados esperados: Quedar registrado en whatsapp utilizando un número celular diferente al celular que se está corriendo la aplicación.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Se llena el formulario de registro con los datos solicitados, y se espera el código de verificación que llegara al celular al cual corresponde el número registrado.

Poscondiciones esperadas: Whatsapp permite registrarse utilizando otro número celular, no chequea que el número de celular que se ha  escrito en el formulario de registro  sea equivalente al número de celular  que corre la aplicación.

3. Caso de prueba #3

·         Formatos de imagen que permite subir whatsapp.

Precondiciones: Tener un archivo de imagen con un formato: (JPG-GIF-PNG-TIF-BMP).

Conjunto de valores de entrada: Seleccionar la imagen a enviar.

Conjunto de resultados esperados: Enviar la imagen.

Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados: Se selecciona la imagen y se envía.

Poscondiciones esperadas: Se puede subir las imágenes en cualquier formato tales como: (JPG-GIF-PNG-TIF-BMP).

Especificaciones del software y hardware:

Procesado: Intel(R)Core(TM)i5-3210M CPU @ 2.50GHz 4(CPUs), ~2.5GHz.

Memoria instalada (RAM): 8,00 GB (7,71 GB utilizable).

Tipo de sistema: Sistema operativo de 64 bits, procesador x64.

Disco duro: 1000GB.

Windows 8 versión 6.2 (compilación 9200)

Calidad interna y externa del software.

Definiciones.

Mantenibilidad.

-Analizable. Capacidad del producto de software para ser diagnosticado y mostrar las deficiencias o las causas de los fallos, permitiendo la identificación de las partes que deben ser modificadas.

-Cambiable. Capacidad del producto de software de aceptar determinada modificación sin afectar sus demás componentes.

-Estabilidad. Capacidad del producto de software de evitar efectos provocados después de alguna modificación implementada.

-Comprobable. Capacidad del producto de software de permitir que una modificación que se le haya hecho sea validada.

Portabilidad.

-Adaptabilidad. Capacidad del producto de software para ser adaptado a diferentes entornos específicos, sin la necesidad de optar por mecanismos deferentes a los requeridos por el propio software.

-Instalabilidad. Capacidad del producto de software para ser instalado en un entorno determinado con las especificaciones necesarias para su funcionamiento.

-Coexistencia. Capacidad del producto de software para convivir con otro software que es independiente en un entorno común compartiendo los mismos recursos.

-Reemplazable. Capacidad del producto de software para ser usado en lugar de otro software, para el mismo propósito y en el mismo entorno.

Ley de residuos eléctricos y electrónicos.

¿Qué podemos hacer?

Los principales productores de dispositivos eléctricos y  electrónicos afirman que sus equipos tienen una vida útil que se acerca a los diez años, pero la realidad nos afirma que alrededor de los cuatro o cinco años la mayoría de estos dispositivos se vuelven obsoletos debido a los nuevos programas y las nuevas versiones de los sistemas operativos. El constante cambio de la tecnología y la gran innovación en la cual estamos presentes hace que el consumo aumente  y con sigo el cambio constante de dichos dispositivos generando una alarmante cantidad de desechos electrónicos generadores de gran contaminación.

Aspectos para poner en práctica.

*   La reutilización de los dispositivos es un factor a tener en cuenta, los dispositivos que ya no estén en la capacidad de realizar la tareas para las cuales se implementaron, pueden pasar a desempeñar tareas dentro de la misma organización donde los requisitos sean menores.

*   La donación de dispositivos que a nivel empresarial ya no estén en la capacidad de rendimiento pueden ser entregadas a organizaciones que los adecuan con fines sociales.

*     Utilizar la responsabilidad extendida de los productores de los dispositivos eléctricos y electrónicos que luego del uso por parte de los consumidores estos los recogen nueva mente contribuyendo a la mejora en los diseños para que sea mucho más fácil la reutilización de las materias primas con la cuales están fabricados.

*   Las empresas deberían poseer un plan de reciclaje de los desechos electrónicos que genera la misma minimizando el impacto ambiental al desecharlos.

*  Contar con una asesoría cuando se desea renovar los dispositivos eléctricos y electrónicos donde se evalué cual va hacer el uso que se le pretende dar con el fin de poder adquirir una máquina que cuente con las características necesaria para desempeñar dichas tareas prolongando su vida útil.

Principios del proceso de pruebas de software.

Principios.

1.El proceso de pruebas demuestra la presencia de defectos.

Las pruebas realizadas a un software contribuyen a detectar la presencia de algún desperfecto que se ha pasado por alto.

2.No es posible realizar pruebas exhaustivas.

Es una tarea compleja de realizar además del alto costo en  el tiempo y el dinero que trae consigo  la ejecución de un proceso de tan alta exigencia.

3.Pruebas tempranas (early testing).

Poder detectar un defecto en una fase de desarrollo de software temprana hace que su corrección se haga más fácil contribuyendo a la optimización de recursos como tiempo y dinero.

4.Agrupamiento de defectos (defect clustering).

Cuando se encuentra algún defecto en algún módulo de un programa de software que cumple con  ciertas características es probable que otro que se le asemeje pueda tener los mismos defectos.

5.Paradoja del pesticida.

Cuando se implementa una prueba a un producto de software que arroja algún defecto no es practico  aplicar la misma prueba sabiendo de antemano que nos arrojara la misma información que ya debió se corregida, es necesario probar  el software de diferentes maneras.

6.Las pruebas dependen del contexto.

Dependiendo de las características de producción e implementación que se le darán al software se generan las pruebas necesarias para determinar los posibles defectos.

7.La falacia de la ausencia de errores.

El proceso de pruebas de software implementado de un modo correcto detecta los fallos más relevantes esto no infiere en la calidad del sistema, un software libre de errores no implica que sea apto para su uso.

Definición persona de calidad.

Persona de calidad.

Una persona de calidad puede ser definida como aquella que es capaz de interpretar y dar respuesta a las exigencias laborales y personales en las que se desenvuelve, estando en la capacidad de generar diversas estrategias que le permitan el cumplimiento total de las tareas a realizar con los resultados esperados.