Guía 04 - Aprovisionamiento de Ambientes y Pruebas

Objetivo del documento

 

El presente documento tiene como objetivo detallar las especificaciones del ambiente, se describe la información necesaria de aprovisionamiento de los usuarios en los ambientes, así como el mecanismo para asignación de usuarios, roles y permisos a los desarrolladores e integradores de los nuevos trámites / servicios / procesos. 

 

Aprovisionar: Proporcionar o poner al alcance del usuario el ambiente de la digitalización / interoperabilidad del trámite / servicio / proceso.

 

  1. Requisitos usuarios y permisos

Se deberá establecer la información necesaria de acceso y permisos de usuario para el ambiente solicitado, se proporcionará los datos de los usuarios que tendrán acceso al ambiente proporcionado.

 

El ambiente se refiere al hardware y software donde se ejecuta una aplicación, dependiendo del proceso de desarrollo, de la cantidad de ambientes por los cuales se irá propagando una aplicación desde el desarrollo hasta producción.

 

1.1 Usuarios

Usuario

Nombre de Usuario

Puesto

Medio de Autentificación

CURP

Identificador del usuario a  registrar (Sin espacios o caracteres inválidos)

Nombre completo del usuario

Puesto que desempeña el usuario en la dependencia

Medio de autenticación, cuenta de usuario, Firma electrónica, etc.

CURP para identificar al usuario, en caso de no tener usar el generico:

XEXX010101HNEXXXA4 (Hombre) y

XEXX010101MNEXXXA8 (Mujer),

 

1.2. Transacciones y roles

Rol asignado

Descripción de actividades

Nivel de Autenticación

Nombre del rol que se habilitaran para la dependencia

Descripción detallada de las actividades que desempeñará el rol

Sin Autenticación

Autenticación Simple

eFIRMA

 

Autenticación Simple: la autenticación de acceso básica es un método diseñado para permitir a un navegador web, u otro programa cliente, proveer credenciales en la forma de usuario y contraseña cuando se le solicita una página al servidor.

 

eFIRMA: La efirma, o firma electrónica, es un archivo digital que sirve para identificarse al momento de realizar trámites en línea, y consta de varios elementos de seguridad para poder garantizar la confianza del usuario.

 

1.3 Permisos

Rol

Módulo

Ver

Crear 

Editar

Borrar

Nombre del rol al que se le habilitada las características

Nombre del módulo dentro del sistema/plataforma a la cual se hace referencia el permiso, ejemplo:

Usuarios, Catálogos, Reportes

Marcar con X para habilita

Marcar con X para habilitar

Marcar con X para habilitar

Marcar con X para habilitar

 

1.4 Relación Roles - Usuarios

Rol

Usuarios

Nombre del rol al que se le habilitará las características

Usuario asignado al rol

 

 

 

  1. Características del ambiente y la infraestructura (máquina virtual)

Indicar las características del ambiente solicitado, si se requiere el ambiente para desarrollo, pruebas, preproducción o producción y características de su máquina virtual del mismo.

 

Característica

Descripción

Ejemplo

Ambiente

Elegir entre:

desarrollo, pruebas, preproducción o producción

Desarrollo

Objetivo

Objetivo

 

Tipo de ambiente

Elegir entre:

  • Infraestructura local
  • Nube
  • Nube

Comentarios

Observaciones

 

SO

Sistema operativo instalado

Ubuntu Server / 18  / 64bits

vCPU

Numero de nucleos en el procesador 

4

Memoria Ram

Memoria ram de la infraestructura

8

LUN. S.O.

Tamaño en GB de la partición virtual (o volumen) dentro del conjunto RAID.

Una LUN (Logical Unit Number) es una parte del conjunto de discos (RAID), el cual, se presentará o asignará a un Servidor (ej: Windows, UNIX o Mainframe) para su utilización, es decir, una LUN es un disco lógico, desde el punto de vista de la Cabina de Almacenamiento.

100

Función Principal

Definir el tipo de función: 

Webserver, Aplicaciones, Base de datos, repositorio, etc

Web Server Base de Datos

PUBLICACIÓN A INTERNET

Definir si se requiere publicación a Internet

Salida a internet

PRERREQUISITOS

Definir si se requieren librerías o paquetes específicos, por ejemplo versiones de JAVA, c, c++, composer, etc.

Composer

USUARIOS

Definir que usuarios se requieren crear y con que privilegios. 

gobmx / sudo all

Observaciones

indicar si hay algo que tomar en cuenta o características adicionales

No Aplica

 

3. Firmas de elaboración, revisión y aprobación

En este apartado se deberán asentar los nombres y cargos de los servidores públicos responsables de la elaboración, revisión y aprobación del documento, incluir las firmas autógrafas de los mismos.

 

 

 

Formato G04-F02 Plan y Evidencias de Pruebas de Calidad del Proceso.

 

Objetivo del documento

Este documento tiene como objetivo establecer las técnicas, herramientas y actividades relacionadas con la ejecución y validación del plan de pruebas; incluye responsabilidades de cada una de las tareas, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de cada una de las pruebas, permitiendo garantizar el cumplimiento de los requerimientos planteados.

 

Los siguientes son ejemplos de los niveles, tipos y métodos de prueba que pueden ser utilizados para conformar la estrategia de atención del Trámite / Servicio / Proceso.

 

Los niveles de prueba no listados, tales como pruebas unitarias y pruebas de integración de componentes, se consideran responsabilidad del equipo de desarrollo y están generalmente fuera del alcance de los servicios.

 

Nivel de pruebas

Descripción

Pruebas de humo

Consisten en la revisión del software a probar antes de iniciar el ciclo formal de pruebas, su objetivo es evaluar si el software está listo para ser probado. En éstas se ejecuta generalmente el flujo principal de las funcionalidades a fin de observar problemas de instalación y configuración, en caso de que sean no exitosas no se inicia el ciclo formal de pruebas. 

Generalmente se centran en evaluar los aspectos básicos necesarios, entre ellos:

  • Funcionalidad básica
  • Ambientes
  • Datos
  • Seguridad
  • Configuraciones

Pruebas de sistema

Realizada en ambiente de pruebas o preproducción por un equipo especializado e independiente al equipo constructor de la solución. Incluye pruebas funcionales y no funcionales e inician desde la etapa de análisis (pruebas estáticas dentro del ciclo de vida del desarrollo de software).

Pruebas de interoperabilidad de sistemas, aplicativos, servicios o procesos

Se refiere a la evaluación de la correcta integración entre distintos aplicativos, sistemas, servicios o procesos que conforman una plataforma o solución tecnológica.

Muy utilizadas en aseguramiento de calidad de sistemas ERP, y en las arquitecturas orientadas a servicios (BPM, SOA).

Generalmente incluyen la verificación y validación de los siguientes elementos:

  • Escenarios de integración empresarial utilizando múltiples esquemas de mensaje y grandes cargas de mensajes entre los distintos servicios, aplicaciones o procesos.
  • Flujos de información dentro y a través de las aplicaciones utilizando esquemas de mensaje simples con altos volúmenes de mensajes, incluyendo seguridad de dichos mensajes y la correcta identificación de emisores, receptores y trayectos de los mismos.
  • Evaluación de la correcta estandarización de estructuras de datos y mensajes para la eficiente utilización y distribución de los mismos de manera transversal entre los distintos aplicativos, servicios o procesos que integran la plataforma o solución tecnológica.
  • Utilización de tecnologías dedicadas a servicios, incluyendo soluciones comerciales y echas a la medida, principalmente:
  • ESB 
  • SOA
  • BMP
  • XML Parsing
  • Service Binding Interfaces and Encoding Styles
  • Message Queues (JMS) and Synchronous (HTTP) Requests
  • BPEL, JBI, and Proprietary Business Integration
  • Transformación usando  XSLT and XQuery
  • Adaptors to mock service objects

Pruebas de Regresión

Principalmente aplicadas en pruebas sobre mantenimientos de software, consisten en evaluar que los cambios introducidos no hayan propiciado fallas sobre la funcionalidad que ya se entregaba de manera correcta, para evaluar que funcionalidades deben ser probadas debe aplicarse análisis de impactos y riesgos. Este tipo de pruebas también se aplica durante el ciclo de pruebas de regresión al final de la estabilización. 

Pruebas de aceptación de usuario (UAT)

Se refiere a la evaluación de la calidad del software desde la perspectiva del usuario, con el fin de revisar si cubre sus necesidades y cumple sus expectativas. 

 

Métodos de Prueba

Descripción

Pruebas de caja negra

Consisten en la evaluación de la funcionalidad utilizando específicamente el Front del aplicativo, tal como lo haría el usuario final. No es necesario conocer la estructura interna del sistema para ejecutar este tipo de pruebas. 

Pruebas de caja blanca

Es necesario conocer la estructura interna del sistema, en este tipo de pruebas se evalúa el software desde dentro, no es relevante sólo si se entrega la funcionalidad sino cómo es procesada la información dentro del sistema para ofrecer dicha funcionalidad. 

Pruebas caja gris

Consistente en la evaluación de la funcionalidad, similares a caja negra, la diferencia es que en caja gris se realizan revisiones también sobre la estructura interna del sistema para verificar la funcionalidad, por ejemplo al dar de alta un registro se revisa, además del Front, que haya sido insertado efectivamente en la base de datos por medio de consultas directas.

 

Automatización de Pruebas

Descripción

Diseño, construcción e  implantación de frameworks

Se refiere a la construcción de frameworks de automatización de pruebas para cubrir las necesidades específicas de un cliente, proyecto o servicio, facilitando el diseño y ejecución posterior de pruebas automatizadas.

Existen distintos tipos de frameworks, con nivel de madurez distinto, los más comunes son:

  • Grabado y reproducción de pruebas.
  • Guiados por datos.
  • Guiados por palabras clave.
  • Híbridos.

 

 

 

  1. Formato de casos de pruebas técnicos

 

Formato que se utilizará para documentar las pruebas técnicas; estas pruebas serán documentadas conforme avance el desarrollo de la solución y se tengan versiones liberadas sobre las que se aplicarán estas pruebas.

 

 b

Ejemplo de llenado:

  v

2. Evidencias y resultados de pruebas de calidad.

 

En este apartado se deberán describir los objetivos de las pruebas, incluir la identificación y nombre de los módulos o componentes a probar, así como el ambiente donde se desarrollarán las pruebas.

 

Integrar en este apartado la documentación correspondiente a los casos de prueba, datos de prueba, y el documento donde habrán de conservarse los resultados y evidencias de las pruebas ejecutadas. Señalar la documentación de referencia del ambiente.

 

Ambiente

Componente / Producto

Caso de prueba

Fecha

Evidencia

Resultado

Seguimiento

Especificar los datos del ambiente.

Estos datos deberían ser los enviados

Especificar: el componente o producto de la solución tecnológica a probar.

Especificar el caso de prueba efectuado.

 

Referenciar la(s) evidencia(s) de la ejecución del caso de prueba.

Describir el resultado obtenido exitoso o fallido.

Describir el seguimiento que se llevará a cabo en base a la evidencia obtenida.

Desarrollo

validar referencia de pago

prueba de sistema

 

Informe de los resultados obtenidos

   

 

3. Firmas de elaboración, revisión y aprobación