Tipos de pruebas

Utilizando los distintos tipos de pruebas se deben seguir los formatos estándar y la documentación para realizar el seguimiento de los resultados de las pruebas funcionales del sistema y de todas las demás. Si se observa una falla, se debe generar un informe del incidente para que éste sea analizado y reparado desde el código. No se deben perder de vista estos documentos con el propósito de garantizar la calidad del software, y seguir el progreso del proceso de pruebas.

Pruebas de Caja Negra

En las siguientes pruebas se comprobó la autenticación, la carga de registros en la base de datos MYSQL 5.6.13 con las funciones creadas por php.

N° de Pruebas	Descripción	Puntuación
		Criterio - MySQL
		Deficiente	Aceptable	Bueno	Excelente
1	Registro en la base de datos			x
2	Ingresar usuario y clave			x
3	Nombre de usuario en la página de bienvenida			x
6	Consultas de claves			x
7	Eliminar registro de claves			x
8	Insertar contacto y clave				x
9	Actualizar registros			x
10	Busca de un solo registro		x

Pruebas de Caja Negra

Se realizan prueba e funcionalidad en PHP.

N° de Pruebas	Descripción	Puntuación
		Criterio - PHP
		Deficiente	Aceptable	Bueno	Excelente
1	Integración con base de datos			x
2	Conexión por usuarios			x
3	Acceso a los contactos únicos del usuario			x

Aspectos a mejorar:

Ninguno pero podemos utilizar joomla o wordpress para mejorar la presentación de la página y garantizar a su vez él envió de mensajes con servidor POP3 y SMTP.

Pruebas de Caja Negra

Se realizan pruebas sobre la página web en aspectos de diseño y estructura.

N° de Pruebas	Descripción	Puntuación
		Criterio – HTML5
		Deficiente	Aceptable	Bueno	Excelente
1	Presentación de la pagina			x
2	Facilidad de navegación			x
3	Estructura adecuada				x

Aspectos a mejorar:

Ninguno

N° de Pruebas	Descripción	Puntuación
		Criterio – HTML5
		Deficiente	Aceptable	Bueno	Excelente
1	Estilo de la pagina			x
2	Ambiente agradable a la vista				x

Aspectos a mejorar:

Ninguno

Prueba de Caja Blanca (Conociendo el código fuente)

Se realizan pruebas para obtener registros con el método POST y consulta en SQL.

N° de Pruebas	Descripción	Puntuación
		Criterio - MySQL
		Deficiente	Aceptable	Bueno	Excelente
1	Consultas en la base de datos			x
2	Agregar usuarios			x
3	Administración por phpmyadmin				x
4	Creación de base de datos				x
5	conexión por php			x
6	consultas por php				x
7	Eliminar contactos por php			x
8	Agregar contacto por php				x
9	Actualizar datos por php			x
10	Buscar contacto por php		x
11

Aspectos a mejorar:

Mejorar las búsquedas de usuarios mostrando los contactos únicos del usuario y no todo el registro.

Prueba de Caja Blanca (Conociendo el código fuente)

Se realizan pruebas de JAVASCRIPT en aspectos de cifrado en ciclos FOR y condiciones o restricciones para formularios en HTML.

N° de Pruebas	Descripción	Puntuación
		Criterio – HTML5
		Deficiente	Aceptable	Bueno	Excelente
1	Aplicación de funciones				x
2	Condiciones para cada textbox			x
3	Mensajes al realizar una acción				x
4	Función de cifrado				x

Aspectos a mejorar:

La función de cifrado trabaja a través de una única clave pero como un aspecto a mejorar es el cifrado asimétrico para documentos anexándolo como una opción adicional que queda a elección del usuario.

Pruebas de funcionalidad.

Se han establecido pruebas de funcionalidad de sistema ya que tienen mucho que ver con las pruebas de aceptación. Se dice que un programa es aceptable cuando:

-  Hace lo que debe hacer

-  No hace lo que no debe hacer.

Por tanto se debe asegurar que el comportamiento del sistema se adhiere a los requisitos funcionales.

a. Todos los requisitos funcionales del sistema deben ser realizables por el sistema.

b. Las pruebas de funcionalidad son de caja negra en naturaleza. Se focalizan en las entradas y salidas apropiadas para cada función.

c. Las entradas incorrectas e ilegales se deben manejar también por el sistema.

d. Todas las funciones deben ser probadas.

e. Las pruebas a nivel sistema incluyendo pruebas de funcionalidad deben ser diseñadas en el tiempo en que se toman los requisitos, e incluirse en el plan maestro del proyecto y por ende en el plan de prueba del sistema.

Pruebas de secuencias y actividades del proceso.

Estas pruebas permiten indagar que tanto la secuencia de actividades desde el punto de vista de los actores del sistema, como la secuencia de mensajes desde el punto de vista de los objetos del sistema tengan coherencia con lo que se expresa en cada uno de ellos. Las pruebas basadas en el diagrama de secuencias son orientadas principalmente a pruebas de caja blanca.

Los casos de prueba generados comprueban de forma global que los procesos, flujos e interacciones planteados en los diagramas de actividades y de secuencias de procesos son reflejados fielmente por TODO el producto de software.

Para realizar estas pruebas se debe tener en cuenta:

1.                  Adquirir la comprensión del dominio del sistema y del diagrama de secuencias y actividades del sistema completamente, (Si es necesario lea todo el documento de casos de uso y el documento de requisitos).

2.      Identificar las secuencias que comprometen directamente transiciones en la bases de datos del sistema.

3.      Comprobar que las transacciones generadas por unas secuencias son registradas en la base de datos.

4.      Identificar los procesos del sistema y en qué casos de uso se utilizan, encontrando concordancia así entre el diagrama de casos de uso y el diagrama de actividades.

5.      Ubicar los procesos del sistema del diagrama de actividades en los módulos e interfaces en los cuales se lleven a cabo.

6.      Corroborar el flujo correcto entre procesos mostrado en el diagrama de actividades. Se deberán elegir las que sean más comunes, reales y factibles al interior del sistema.

7.      Tener en cuenta la duración, como se realiza y en dónde se realiza el proceso con el fin de poder describir con más claridad el caso de prueba que prueba el flujo correcto entre procesos.

Prueba de acoplamiento con el usuario

Permite asegurar que el producto de software sea coherente con el ambiente en donde este será implantado y el usuario final en cuanto a sus habilidades y conocimientos.

Se debe chequear que los siguientes aspectos sean comprensibles por el usuario final según sus habilidades y conocimientos y además sean concordantes con el ambiente en el cual opere el aplicativo:

·       Etiquetas (label) de las interfaces.

·       Información de interacción con el usuario (Mensajes emergentes, explicaciones, errores y salidas).

·       Tooltips y ayudas.

·       Títulos de ventanas, componentes (Arboles, Menús, Tablas, entre otros).

Es importante tener en cuenta que se requiere tener una descripción de los usuarios del sistema agrupada según sus roles con el fin de identificar habilidades, conocimientos y ambiente en el cual se desempeña el usuario.

Prueba de entradas

Son consideradas entradas del sistema cualquier información que el usuario suministre y esté dispuesto en:

·      Cajas de texto (textbox, passwordfield).

·      Áreas de texto (textarea).

·      Listas de selección (list).

·      Barra de selección deslizable (slider).

·      Arboles de entrada (tree).

·      Caja de ajuste de valor (Spinner).

·      Caja de opciones (combox).

·      Campos en tablas modificables (Grid).

·      Botones (button).

·      Botones de opción (radiobutton).

·      Botones de selección (checkbox).

·      Vínculos (link).

·      Archivos (files).

·      Dispositivos externos de hardware (devices).

·      Otros que apliquen la definición (ver observaciones).

En esta prueba se realizan varias comprobaciones que tienen en cuenta el comportamiento - Las comprobaciones típicas son:

·      El nombre de las entradas concuerda con la entrada misma y es suficientemente claro para que el usuario ingrese el dato.

·      La ubicación de la entrada y de su nombre deben tener una relación ubicación-diseño clara para el usuario.

·      Se deben aceptar todas las entradas válidas.

·      Se deben rechazar todas las entradas inválidas teniendo en cuenta que el sistema debe seguir estando disponible.

·      El sistema debe retornar información de reconocimiento a las entradas correctamente.

·      las opciones no deben ser excesivas o pocas según sea el caso.

·      Se debe comprobar que las entradas no pueden ser redundantes y su interrelación debe ser correcta, no se deben repetir datos de entrada en las interfaces y adicionalmente no deberían haber datos derivados que ingrese el usuario.

·      los botones y otros componentes realizan la operación para la que fueron diseñados y respondan a sus eventos de manera adecuada.

·      Se debe chequear que la activación y desactivación de un componente sea la esperada.

·      No hayan vínculos rotos, y que estos direccionen al lugar correcto.

·       Si un componente posee valores por defecto, se debe verificar su correctitud.

·       Se debe comprobar que las entradas sean correspondientes a los roles de usuario.

·       Verificar que los procesos de importación de archivos sean correctos.

·       Verificar el comportamiento del sistema en relación con la interacción de entrada del usuario y el hardware.

·       Verificar que los archivo adjuntados cumplan los requisitos funcionales asociados a ellos.

Pruebas de salidas

Son consideradas salidas del sistema cualquier información que el sistema suministre y esté dispuesto en:

·         Cajas de texto (textbox, passwordfield).

·         Áreas de texto (textarea).

·         Listas de selección (list).

·         Barra de selección deslizable (slider).

·         Arboles de entrada (tree).

·         Caja de ajuste de valor (Spinner).

·         Caja de opciones (combox).

·         Campos en tablas (Grid).

·         Botones (button).

·         Botones de opción (radiobutton).

·         Botones de selección (checkbox).

·         Vínculos (link).

·         Archivos (files).

·         Dispositivos externos de hardware (devices).

·         Otros que apliquen la definición (ver observaciones).

Las comprobaciones a realizar son:

·      La información de las salidas no contenga información redundante o innecesaria.

·      El nombre de la salida concuerda con la salida misma y es suficientemente claro para que el usuario comprenda el dato.

·      La ubicación de la salida y de su nombre deben tener una relación ubicación-diseño clara para el usuario.

·      Comprobar que las salidas contengan datos correctos y válidos.

·      Las salidas no pueden ser redundantes y su interrelación debe ser correcta, no se deben repetir datos de salida en las interfaces.

·      Verificar que no hayan vínculos rotos, y que estos direccionen al lugar correcto.

·      Comprobar que las salidas sean correspondientes a los roles de usuario.

·      Verificar que los procesos de exportación de archivos sean correctos.

·      Verificar el comportamiento del sistema en relación con la interacción de salida del usuario y el hardware.

·      Verificar que los archivos generados por el sistema cumplan los requisitos funcionales asociados a ellos. Por ejemplo cuando el sistema genera reportes en pdf u en otro formato.

• Definir qué es y que no es una entrada y una salida y en qué momento una se convierte en otra.

Prueba de manejo de errores

Se deben contemplar errores de hardware y de software. Es así como la aplicación debe estar en capacidad de capturar el error, tratarlo y entregar al usuario una alerta descriptiva del mismo, que le permita tomar las acciones pertinentes para solucionarlo. Algunos de los errores más comunes son:

• Errores de bases de datos.
• Errores de comunicación entre dispositivos.
• Errores de memoria.
• Errores de compatibilidad.
• Errores del lenguaje de programación.
• Errores inesperados.

Por otro lado verificar que los mensajes de error estén codificados, tipificados, que describan la posible causa del mismo y que den una posible solución.

También es importante que el sistema sea capaz de responder al error de forma que siga estando disponible una vez que se lanzó la respectiva alerta.

Prueba de uniformidad de interfaces

Esta prueba permite comprobar los siguientes aspectos:

·         Las interfaces en conjunto a través de toda la aplicación están interrelacionadas, son uniformes en conversiones, formatos (colores, fuentes, tamaños de fuentes), estilos (negrita, subrayados, cursivas, tachado), abreviaciones de lenguaje entre otros.

·         Las imágenes utilizadas se visualizan correctamente,  no se superponen de forma no controlada y son coherentes a través de la aplicación.

·         Los componentes o elementos del aplicativo de software tiene estándares definidos para su ubicación.

Prueba de compatibilidad

Esta prueba busca comprobar la compatibilidad del aplicativo frente a diferentes entornos como:

· Navegadores: no solo se prueba la compatibilidad entre distintos navegadores sino también entre versiones de un mismo navegador.

· Framework cliente y servidor.

· Sistemas operativos cliente y servidor.

· Plataformas de hardware cliente y servidor.

Pruebas de seguridad

La prueba de la seguridad evalúa las características del sistema que se relacionan con la disponibilidad, integridad, y confidencialidad de los datos y de los servicios del sistema.

En ésta prueba se chequean generalmente los siguientes aspectos:

·         Password Checking (Prueba de contraseña): Se inspecciona la contraseña para asegurar que los usuarios si seleccionen  una contraseña que contemple las condiciones de aceptación de la misma establecidas en los requisitos. Las reglas y las condiciones que especifican una contraseña como válida se pueden utilizar para diseñar las pruebas.

·         Los ingresos legales e ilegales por medio de contraseñas: Se prueba que los resultados de los intentos de ingresos legales e ilegales al sistema sean los esperados.

·         Pruebas de snifffer y spoofing.

·         Verificación de concurrencia de sesiones.

·         Chequeos de expiración de sesiones.

·         Expiración de contraseña: Si se decide que las contraseñas expirarán después de cierto período, las pruebas se debe diseñar para asegurar que el período de la expiración sea el correcto y que los usuarios puedan ingresar y cambiar correctamente su contraseña apropiadamente.

·         Cifrado: Se deben diseñar pruebas para evaluar la correctitud de los algoritmos de cifrado y de desciframiento para los sistemas donde se codifican los datos y los mensajes.

·         Visualización: Se deben evaluar los privilegios al visualizar las interfaces para asegurar que no ocurren ingresos no autorizados. Deben determinarse qué tipos de información privada se pueden deducir por navegación legal e ilegal.

·         Las Puertas abiertas: Se deben identificar cualquier entrada desprotegida en el sistema que puede permitir el acceso a través de los canales inesperados (puertas traseras abiertas). Las pruebas deben intentar lograr la entrada ilegal y observar los resultados en el sistema.

·         Virus: se deben diseñar las pruebas para asegurar que los antivirus del sistema previenen o disminuyen la entrada de virus en el mismo.

Posibles riesgos de software

RIESGO	TIPO	DESCRIPCION
Rotación de personal	proyecto	Personal con experiencia abandona el proyecto
No disponibilidad del hardware	proyecto	El hardware esencial para el proyecto no será entregado a tiempo
Cambios de requerimientos	Proyecto y producto	Habrá más cambios de requerimientos
Retrasos en las especificaciones	Proyecto y producto	Las especificaciones de las interfaces esenciales no estarán a tiempo
Subestimación del tamaño	Proyecto y producto	El tamaño del proyecto se ha subestimado
Cambio de tecnología	Negocio	Un producto competitivo se pone en venta antes que el sistema se complete
Competencia del producto	Negocio	La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología
Cambio de gestión	proyecto	Habrá un cambio de gestión organizacional con diferentes prioridades
Bajo rendimiento de la herramienta CASE	producto	Las herramientas CASE que ayudan al proyecto no tienen el rendimiento esperado.