QA DC Consultorías II

Aseguramiento de calidad (QA) para
Sistema de Registro Único de Emisiones

de Gases de Efecto Invernadero y
Contaminantes Locales para el Ministerio
del Medio Ambiente
Octubre 2019
Alcance
El presente documento describe los trabajos realizados del proceso de Quality
Assurance (QA), para la revisión de negocio, seguridad y funcionalidad, del sistema
web Reporte Obligatorio Gases de Efecto Invernadero (GEI).
El Reporte Obligatorio con énfasis en los gases de efecto invernadero, se enmarca

dentro de la iniciativa Partnership for Market Readiness (PMR - Alianza para la
Preparación de Mercados), instancia creada en el año 2010 por el Banco Mundial y que
se articula como un foro para la innovación, el trabajo colectivo y la creación de
capacidades para ampliar y fortalecer la acción frente al cambio climático. En esta línea,
el PMR provee financiamiento y asistencia técnica para explorar, desarrollar y aplicar
instrumentos de precios al carbono en países beneficiarios a lo largo del mundo, con el
propósito de apoyar la implementación de políticas de mitigación de gases de efecto
invernadero.
El proceso de QA se enmarca dentro de tres etapas, en cada una de ellas se realizan

las actividades se aseguramiento de calidad según los procesos que se detallan en este
documento:
Etapa de Registro de Fuentes y Procesos: El Registro de Fuentes y Procesos

permitirá entregar la información relevante para el módulo de cuantificación de
emisiones en forma actualizada, subsanando así el actual problema de temporalidad
en los reportes, producto de los diferentes periodos de reporte en cada sistema actual
(F138, SICTER, SIV, Registro de Calderas y Turbinas). Además, se cuenta con los
diagramas de descarga de los establecimientos relevantes, así como también su
conexión con los diferentes equipos de abatimiento. Esta información es registrada en
el Ministerio del Medio Ambiente, y reenviada mediante servicios web a los distintos
sistemas de cuantificación de emisiones para el cumplimiento de la normativa vigente,
1
lo cual subsana las brechas e inconsistencias actualmente existentes entre los sistemas
que administran la SMA y MINSAL.
Etapa de Módulo de Cuantificación de Emisiones: Cada uno de los módulos de

cuantificación asociados al cumplimiento de Normas de Emisión, Planes de
Descontaminación, e Impuestos Verdes, recibe previamente la información proveniente
del Registro de Fuentes y Procesos, en este punto solamente se debe solicitar al titular
los nuevos antecedentes que permitan la cuantificación de la emisión, tales como,
consumo de combustible, horas de funcionamiento, estimaciones perfeccionadas
(previamente validad por la autoridad), entre otros, y en caso de tener sistemas de
medición continua, solamente deberán vincularlo a la fuente y equipo de abatimiento
previamente declarado. Por otro lado, toda fuente no asociada a un sistema de
medición relacionado a un Instrumento de Carácter Ambiental (ICA), pasa a un módulo
general de cuantificación de emisiones mediante factores de emisión.
2
Etapa de Módulo de Reporte: Corresponde a un módulo de generación de reportes,
tanto de emisiones como de fuentes, al cual tendrán acceso de todos los stakeholders
vinculados con la información de carácter ambiental relacionada a las emisiones de
fuentes fijas (MMA, SMA, MINSAL y Min. Energía).
3
Resumen ejecutivo
En el presente proyecto de QA, se realizan test automatizados para asegurar la
integridad del funcionamiento, ante las modificaciones normales del software construido
con la metodología ágil, en este caso se llevan a cabo pruebas de seguridad, usuario y
de aceptación. El paso a producción se aborda con la herramienta herramientas
DevOps de GitLab, que permite automatizar el deploy desde el repositorio Git,
asegurando así que la versión en producción es la versión master del repositorio,
además se usa un servidor de staging, que permite realizar las pruebas en un ambiente
idéntico al ambiente productivo.
Los objetivos de este proyecto son:
Elaborar una planificación y metodología para analizar, realizar los ajustes y

adecuaciones durante la marcha blanca el Reporte GEI, antes de ponerlo en
producción.
Identificar y subsanar brechas de seguridad en cada una de las etapas del Reporte GEI,
durante la marcha blanca.
Proponer y realizar mejoras que se adviertan en relación a la usabilidad y operatividad

de la plataforma del Reporte GEI.
Documentar tanto la metodología utilizada en los hallazgos como la subsanación de

ellos.
El alcance de este informe corresponde a los puntos 4.1 al 4.6 de los Términos de
Referencia:
4
4.1 Planificación y Metodología.
Se usa documentación liviana, en documentos ejecutivos breves y completos que
indiquen las mejoras y correcciones, para el uso del equipo de desarrollo, product owner
y usuarios finales de la aplicación.
Todas las entregas asociadas serán adjuntas mediante un CD y serán compartidas de

forma digital y trabajadas en dependencias del Ministerio del Medio Ambiente.
Metodología
Scrum
Scrum es una metodología de desarrollo de sistemas, que forma parte de las
metodologías ágiles, teniendo como principal característica el desarrollo incremental,
enfocado en los requerimientos principales del sistema, acoge requisitos cambiantes,
las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana
a través del proyecto.
Roles
Product Owner
El Product Owner es el encargado de optimizar y maximizar el valor del producto, siendo
la persona encargada de gestionar el flujo de valor del producto a través del listado de
requerimientos. Adicionalmente, es fundamental su labor como interlocutor con los
stakeholders y sponsors del proyecto, así como su faceta de altavoz de las peticiones
y requerimientos de los clientes. Si el Product Owner también juega el rol de
representante de negocio, su trabajo también aporta valor al producto.
Consultor de Negocio
Este rol es similar al Product Owner, en cuanto al aporte de los requerimientos de
negocio, desde el punto de vista técnico y validaciones en las pruebas de usuario y
revisión de los datos iniciales del sistema.
Consultor de desarrollo
Este rol aporta apoyo en el manejo de las mejores prácticas y conocimientos de las
herramientas de desarrollo, lenguajes de programación y patrones de desarrollo y
diseño arquitectónico.
5
QA
Este rol es el responsable de dirigir y organizar las pruebas que son aplicadas al sistema
para asegurar la calidad del producto, velar por la correcta aplicación de las pruebas
automatizadas en conjunto con los desarrolladores y dar el paso a producción en
acuerdo con los usuarios del sistema.
Arquitecto
Este rol es responsable de dirigir, decidir e implementar las tecnologías, piezas de
software necesarios para el funcionamiento de los sistemas, su interacción, estructura
de servidores, patrones de desarrollo, diseño y directrices de seguridad.
Desarrollador
Este rol es el responsable de la construcción de los requerimientos en los lenguajes de
programación y estructuras de datos definidas para dar solución al problema de negocio
planteado por los product owner y estructurado por el arquitecto de sistemas.
Diseñador
Este rol es el responsable de aplicar directrices de usabilidad, diseño gráfico y digital a
los sistemas construidos, de tal forma que sea de fácil comprensión y acorde con las
directrices de diseño dictadas por el Gobierno de Chile y el Ministerio de Medio
Ambiente.
Sprint
Scrum se basa en el principio ágil de desarrollo iterativo e incremental. Sprint es
el período de trabajo para desarrollar un incremento de producto, y se
recomiendan duraciones entre una y cuatro semanas. Al final de cada Sprint el
equipo de desarrollo y QA, entregan una pieza de software completa y funcional,
que contiene un conjunto de funcionalidades del proyecto.
Sprint de QA
El sprint de QA tiene como objetivo realizar todas las tareas de pruebas, ya sea
con herramientas de testing o pruebas de usuario presencial, además en este
sprint se realiza la preparación de la data e instructivos para las pruebas. El
resultado de las pruebas da como resultado el paso a staging con las
observaciones al equipo de desarrollo, para reingresar la funcionalidad al sprint
de desarrollo siguiente.
6
Control de versiones
En base a los lineamientos de Gobierno Digital proporcionados e instruidos por el
Ministerio del Medio Ambiente el control de versiones será llevado sobre la herramienta
Git, se utiliza el procedimiento de pull request, que permite integrar los desarrollos al
código master. Al contar con las herramientas DevOps de GitLab, se realizan los deploy
desde Git master, lo que permite asegurar que la versión de producción está completa
en el repositorio Git.
Git es un software de control de versiones, pensando en la eficiencia y la confiabilidad

del mantenimiento de versiones de aplicaciones cuando éstas poseen un gran número
de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos
de computadora y coordinar el trabajo que varias personas realizan sobre archivos
compartidos.
El uso de GIT como método de versionamiento conlleva las siguientes ventajas:

Modelo distribuido: El desarrollo es propio e identificable. Permite que otros
desarrolladores vean sólo lo que es necesario. No todo tiene que ser público. Hay otras
ventajas para el modelo distribuido, tales como la velocidad y la posibilidad de trabajar
offline
Fácil ramificación y fusión: Ramificaciones rápidas y ligeras. Por lo que se puede
trabajar las características del desarrollo hasta que están listos para la corriente
principal.
Flujo de trabajo flexible: En comparación con VCS centralizados, GIT tiene las
cualidades que permiten elegir un propio flujo de trabajo. Puede ser tan simple como
un flujo de trabajo centralizado a tan jerárquica como el flujo de trabajo de dictador
teniente.
Integridad de los datos está garantizada: GIT utiliza SHA1, por lo que cualquier
corrupción de datos debido a razones externas puede ser fácilmente detectada.
Para el trabajo con el sistema GIT se usa un software complementario GitLab.
GitLab es un servicio web de control de versiones y desarrollo de software colaborativo

basado en Git. Además de gestor de repositorios, el servicio ofrece también alojamiento
de wikis y un sistema de seguimiento de errores, todo ello publicado bajo una Licencia
de código abierto. El área de TI del Ministerio de Medio Ambiente ha dispuesto una
plataforma GitLab, que permite mantener las versiones de código de los sistemas
desarrollados, se ha creado un repositorio Git en este servicio, para alojar los sistemas
desarrollados en el presente proyecto.
DevOps (development -desarrollo- y operations -operaciones-) es una práctica de

ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev)
y la operación del software (Ops). La principal característica del movimiento DevOps es
defender enérgicamente la automatización y el monitoreo en todos los pasos de la
construcción del software, desde la integración, las pruebas, la liberación hasta la
7
implementación y la administración de la infraestructura. DevOps apunta a ciclos de
desarrollo más cortos, mayor frecuencia de implementación y lanzamientos más
confiables, en estrecha alineación con los objetivos comerciales.
Quality Assurance QA
El presente proyecto basa su ejecución guiado por las directrices de calidad dictadas
por las normas ISO25000 System and Software Quality Requirements and
Evaluation. Proporcionando un marco de trabajo y ejecución de los trabajos tendientes
a asegurar la calidad del software construido.
Ciclo de Vida del Proyecto QA
8
ISO25000 System and Software Quality Requirements and Evaluation
El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE (System and
Software Quality Requirements and Evaluation) es organizar, enriquecer y unificar las
series que cubren dos procesos principales: especificación de requisitos de calidad del
software y evaluación de la calidad del software, soportada por el proceso de medición
de calidad del software.
ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements
and Evaluation), es una familia de normas que tiene por objetivo la creación de un
marco de trabajo común para evaluar la calidad del producto software.
La familia ISO/IEC 25000 es el resultado de la evolución de otras normas anteriores,
especialmente de las normas ISO/IEC 9126, que describe las particularidades de un
modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso
de evaluación de productos software. Esta familia de normas ISO/IEC 25000 se
encuentra compuesta por cinco divisiones.
La Norma ISO 25000, proporciona una guía para el uso de las series de estándares
internacionales llamados requisitos y Evaluación de Calidad de Productos Software
(SQuaRE). La norma establece criterios para la especificación de requisitos de calidad
de productos software, sus métricas y su evaluación, e incluye un modelo de calidad
para unificar las definiciones de calidad de los clientes con los atributos en el proceso
de desarrollo.
Las características de calidad y sus mediciones asociadas pueden ser útiles no
solamente para evaluar el producto software sino también para definir los
requerimientos de calidad. La serie ISO/IEC 25000:2005 reemplaza a dos estándares
relacionados: ISO/IEC 9126 (Software Product Quality) e ISO/IEC 14598 (Software
Product Evaluation).
Testing preprogramado
Esta metodología de trabajo permite crear pruebas de integridad y acoplamiento de
código, estas pruebas son construidas por el equipo de desarrollo y forma parte de un
pool de pruebas unitarias que son ejecutadas en el sprint de desarrollo antes de pasar
al sprint de QA, además el pool de pruebas es ejecutado por el procedimiento de deploy
con las herramientas de GitLab, el cual no permite realizar pasos a producción si el
código no cumple satisfactoriamente con los test.
Link herramientas automatizadas para testing: automated-testing-6
Desarrollo guiado por pruebas de software

Es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las
pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir
las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En
primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación,
se implementa el código que hace que la prueba pase satisfactoriamente y
9
seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por
pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean
traducidos a pruebas, de este modo, cuando las pruebas pasen se garantiza que el
software cumple con los requisitos que se han establecido.
Requisitos
Para que funcione el desarrollo guiado por pruebas, el sistema que se programa tiene
que ser lo suficientemente flexible como para permitir que sea probado
automáticamente. Cada prueba es suficientemente pequeña para que se pueda
determinar unívocamente si el código probado pasa o no la verificación que ésta le
impone. El diseño se ve favorecido ya que se evita el indeseado "sobre diseño" de las
aplicaciones y se logran interfaces más claras y un código más cohesivo.
Ciclo de desarrollo conducido por pruebas
En primer lugar, se debe definir una lista de requisitos y después se ejecuta el siguiente
ciclo:
1. Elegir un requisito: Se elige de una lista el requisito que se cree que da mayor
conocimiento del problema y que a la vez sea fácilmente implementable.
2. Escribir una prueba: Se comienza escribiendo una prueba para el requisito.
Para ello el programador debe entender claramente las especificaciones y los
requisitos de la funcionalidad que está por implementar. Este paso fuerza al
programador a tomar la perspectiva de un cliente considerando el código a través
de sus interfaces.
3. Verificar que la prueba falla: Si la prueba no falla es porque el requisito ya
estaba implementado o porque la prueba es errónea.
10
4. Escribir la implementación: Escribir el código más sencillo que haga que la
prueba funcione. Se usa la expresión "Déjelo simple" ("Keep It Simple, Stupid!"),
conocida como principio KISS.
5. Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas
funciona correctamente.
6. Eliminación de duplicación: El paso final es la refactorización, que se utiliza
principalmente para eliminar código duplicado. Se hace un pequeño cambio
cada vez y luego se corren las pruebas hasta que funcionen.
7. Actualización de la lista de requisitos: Se actualiza la lista de requisitos
tachando el requisito implementado. Asimismo, se agregan requisitos que se
hayan visto como necesarios durante este ciclo y se agregan requisitos de
diseño (P. ej. que una funcionalidad esté desacoplada de otra).
Tener un único repositorio universal de pruebas facilita complementar TDD con otra
práctica recomendada por los procesos ágiles de desarrollo, la "Integración Continua".
Integrar continuamente el trabajo con el del resto del equipo de desarrollo permite
ejecutar toda batería de pruebas y así descubrir si la última versión es compatible con
el resto del sistema. Es recomendable y menos costoso corregir pequeños problemas
cada pocas horas que enfrentarse a problemas enormes cerca de la fecha de entrega
fijada.
Características
Una característica de esta forma de programación es el evitar escribir código
innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mínimo código
posible, y si el código pasa una prueba, aunque se sepa que es incorrecto, da una idea
de que se tiene que modificar nuestra lista de requisitos agregando uno nuevo.
La generación de pruebas para cada funcionalidad hace que el programador confíe en
el código escrito. Esto permite hacer modificaciones profundas del código
(posiblemente en una etapa de mantenimiento del programa), pues se conoce que si
se logra pasar todas las pruebas se tiene un código que funcione correctamente.
Otra característica del Test Driven Development es que requiere que el programador
primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de
prueba realmente funcionen y puedan recoger un error.
Pruebas de usuario y herramientas de testing

En los sprint de QA se construyen pequeños instructivos, basados en las historias de
usuario de las funcionalidades, y se llevan a cabo las pruebas con usuarios
presenciales y/o herramientas automatizadas. Las funcionalidades que no satisfagan
las pruebas, serán re inyectadas al proceso de desarrollo para su corrección.
Las pruebas de software (en inglés software testing) son las investigaciones empíricas
y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la
calidad del producto a la parte interesada o stakeholder. Es una actividad más en el
proceso de control de calidad.
11
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de
software. Dependiendo del tipo de pruebas, estas actividades pueden ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos
modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.
El objetivo de las pruebas es presentar información sobre la calidad del producto a las
personas responsables de éste. Las pruebas de calidad presentan los siguientes
objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad,
facilitar información para la toma de decisiones, evitar la aparición de defectos.
Teniendo esta afirmación en mente, la información que puede ser requerida es de lo
más variada. Esto hace que el proceso de testing sea completamente dependiente del
contexto en el que se desarrolla.
El ambiente ideal de las pruebas es aquel que es independiente del desarrollo del
software, de esta manera se logra objetividad en las pruebas.
A pesar de lo que muchos promueven, no existen las "mejores prácticas" como tales.
Toda práctica puede ser ideal para una situación, pero completamente inútil o incluso
perjudicial en otra.
Por esto, las actividades técnicas, documentación, enfoques y demás elementos que
condicionan las pruebas a realizar deben ser seleccionadas y utilizadas de la manera
más eficiente según contexto del proyecto.
Pruebas estáticas
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, dado que no se realiza una ejecución de
código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo
de seguir los flujos de la aplicación.
Pruebas dinámicas
Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.
Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con
mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible
medir con mayor precisión el comportamiento de la aplicación desarrollada.
Test-driven development (TDD)

Es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las
pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir
las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En
primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación,
se implementa el código que hace que la prueba pase satisfactoriamente y
seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por
pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean
12
traducidos a pruebas, de este modo, cuando las pruebas pasen se garantiza que el
software cumple con los requisitos que se han establecido.
Procedimiento de aceptación
Al final de cada sprint de QA, se realizan pruebas de aceptación por parte de los product
owner del proyecto, estas pruebas dan como resultado el paso a producción de un
conjunto de funcionalidades, o la reinyección al sprint de desarrollo para su corrección.
Paso a Staging
Se implementa un procedimiento de pasos a staging, coordinado por el arquitecto del
proyecto, vía GitLab, que permita mantener en forma ordenada las versiones de los
módulos y un historial de cambios fácil de seguir y documentar.
Servidor de pruebas
Staging
Este servidor es un espejo del servidor de producción y será utilizado para llevar a cabo
las pruebas de usuario y de aceptación.
Un servidor provisional o staging, es un tipo de servidor que se utiliza para probar un

software, sitio web o servicio en un entorno similar a la producción antes de ponerlo en
funcionamiento. Es parte de un entorno de ensayo o sitio de ensayo, donde sirve como
servidor temporal de alojamiento y prueba para cualquier nuevo software o sitio web.
Un servidor provisional o staging, principalmente permite ensamblar, implementar y

probar un software o sitio web en una instancia de servidor similar al servidor de
producción. Normalmente, el software o un sitio web se implementa en el servidor de
ensayo desde el servidor de desarrollo o una vez que se completa el desarrollo. Un
servidor provisional ayuda a identificar el comportamiento, la experiencia y el
rendimiento del software o del sitio web, ya que será visible en el servidor de
producción. Esto ayuda a los desarrolladores de software o al personal de control de
calidad a identificar y resolver cualquier problema, error, rendimiento, usabilidad y otros
problemas antes de que el software o el sitio web se implemente en el servidor de
producción.
El servidor de ensayo puede ser un servidor de base de datos de ensayo, un servidor

de sitio web de ensayo y un servidor de aplicaciones de ensayo y más.
13
Ambiente de desarrollo
Development
Esta etapa es realizada directamente en el computador de cada desarrollador,
permitiendo la libertad de trabajo, en cuanto a pruebas de concepto y pruebas unitarias
respectivas. El ambiente de desarrollo debe contener las siguientes herramientas:
Servidor de producción
Production
Server productivo, expuesto a los usuarios finales. La configuración de hardware de
este server, es determinado según las necesidades de performance del software
resultante del proyecto y el flujo de usuarios concurrentes del servicio, en caso de alta
demanda se evalúan configuraciones en cluster.
Se ha elegido, para el despliegue de los sistemas en los ambientes de producción, la

herramienta Docker, la cual permite encapsular las piezas de software que conforman
los sistemas en un contenedor fácil de trasladar, desplegar cambios y dar soporte a las
exigencias de comportamiento y carga de uso de los sistemas.
Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones

dentro de contenedores de software, proporcionando una capa adicional de abstracción
y automatización de virtualización de aplicaciones en múltiples sistemas operativos.
Docker utiliza características de aislamiento de recursos del kernel Linux, tales como
cgroups y espacios de nombres (namespaces) para permitir que "contenedores"
independientes se ejecuten dentro de una sola instancia de Linux, evitando la
sobrecarga de iniciar y mantener máquinas virtuales. 3
El soporte del kernel Linux para los espacios de nombres aísla la vista que tiene una
aplicación de su entorno operativo, incluyendo árboles de proceso, red, ID de usuario
4
y sistemas de archivos montados, mientras que los cgroups del kernel proporcionan
aislamiento de recursos, incluyendo la CPU, la memoria, el bloque de E/S y de la red.
Desde la versión 0.9, Docker incluye la biblioteca libcontainer como su propia manera
de utilizar directamente las facilidades de virtualización que ofrece el kernel Linux,
además de utilizar las interfaces abstraídas de virtualización mediante libvirt, LXC
(Linux Containers) y systemd-nspawn.
De acuerdo con la firma analista de la industria 451 Research, "Docker es una
herramienta que puede empaquetar una aplicación y sus dependencias en un
contenedor virtual que se puede ejecutar en cualquier servidor Linux. Esto ayuda a
permitir la flexibilidad y portabilidad en donde la aplicación se puede ejecutar, ya sea
en las instalaciones físicas, la nube pública, nube privada, etc."
8
14
Docker implementa una API de alto nivel para proporcionar contenedores livianos que
ejecutan procesos de manera aislada.
Construido sobre las facilidades proporcionadas por el kernel Linux (principalmente
cgroups y namespaces), un contenedor Docker, a diferencia de una máquina virtual, no
requiere incluir un sistema operativo independiente. En su lugar, se basa en las
8
funcionalidades del kernel y utiliza el aislamiento de recursos (CPU, la memoria, el

bloque E / S, red, etc.) y namespaces separados para aislar la vista de una aplicación
del sistema operativo. Docker accede a la virtualización del kernel Linux ya sea
directamente a través de la biblioteca libcontainer (disponible desde Docker 0.9), o
indirectamente a través de libvirt, LXC o systemd-nspawn.
Mediante el uso de contenedores, los recursos pueden ser aislados, los servicios
restringidos, y se otorga a los procesos la capacidad de tener una visión casi
completamente privada del sistema operativo con su propio identificador de espacio de
proceso, la estructura del sistema de archivos, y las interfaces de red. Contenedores
múltiples comparten el mismo núcleo, pero cada contenedor puede ser restringido a
utilizar solo una cantidad definida de recursos como CPU, memoria y E/S.
Usar Docker para crear y gestionar contenedores permite simplificar la creación de
sistemas altamente distribuidos, permitiendo que múltiples aplicaciones, las tareas de
los trabajadores y otros procesos funcionen de forma autónoma en una única máquina
física o en varias máquinas virtuales. Esto permite que el despliegue de nodos se realice
a medida que se dispone de recursos o cuando se necesiten más nodos, lo que permite
una plataforma como servicio (PaaS - Plataform as a Service) de estilo de despliegue
y ampliación de los sistemas como Apache Cassandra, MongoDB o Riak. Docker
también simplifica la creación y el funcionamiento de las tareas de carga de trabajo o
las colas y otros sistemas distribuidos.
Validación de Data y creación de SEEDs de Base de Datos
Database
El sistema contiene un componente importante de datos base para su funcionamiento,
correspondiente a un modelo datos de negocio, que debe ser revisada y aceptada por
los consultores de negocio, siguiendo los mismos procedimientos de QA, que se
realizan sobre el software.
Database Seeding
El Seeding de la base de datos es la inicialización de una base de datos con datos.
El Seeding de una base de datos es un proceso en el que se proporciona un conjunto
inicial de datos a una base de datos cuando se está instalando.
Es especialmente útil cuando se quiere poblar la base de datos con datos que se
desean desarrollar en el futuro. Este suele ser un proceso automatizado que se ejecuta
en la configuración inicial de una aplicación. Los datos pueden ser datos ficticios o datos
necesarios, como una cuenta de administrador inicial.
15
Modelos que contienen Seeding
En módulos del proyecto Reporte G.E.I. contienen una considerable cantidad de
registros de Seed, estos modelos contendrán los datos de los tipos de Fuente, sus
formas de caracterización, los tipos de combustibles asociados, unidades de medida,
procesos, predecesores y sucesores válidos para el diagrama de descarga, entre otros.
Pruebas y Validación de la data de Seeding

La validación de datos es un proceso que asegura la entrega de datos limpios y claros
a los programas, aplicaciones y servicios que lo utilizan. Comprueba la integridad y
validez de los datos que se están introduciendo en diferentes softwares y sus
componentes. La validación de los datos garantiza que los datos cumplen con los
requisitos y los parámetros de calidad.
La validación de datos también se conoce como validación de entrada y es parte
esencial del procesamiento de datos.
La validación de datos ayuda principalmente a garantizar que los datos enviados a las
aplicaciones conectadas sean completos, precisos, seguros y consistentes. Esto se
logra a través de controles de validación de datos y reglas que rutinariamente
comprueban la validez de los datos. Estas reglas generalmente se definen en un
diccionario de datos o se implementan a través de un software de validación de datos.
La validación es una verificación automática para garantizar que los datos ingresados
sean razonables y factibles. La validación no puede garantizar que los datos sean
realmente precisos.
Los sistemas de gestión de bases de datos permiten la implementación de algunos
métodos de validación útiles. Estos son necesarios porque es más fácil tratar de evitar
que los usuarios ingresen basura que intentar corregir los errores más adelante.
Revisión e Implementación de validaciones en los Modelos

Se implementan validaciones a nivel de modelo de datos en la etapa de desarrollo, A
pesar de esto es necesario realizar inspecciones aleatorias a nivel de negocio, para
esto se realizan pruebas e inspecciones con usuarios expertos, idealmente con los
asesores de negocio tendientes a evaluar la correctitud en la carga de datos.
Tecnologías de Software
 Framework: Laravel PHP
Link framework Laravel: Laravel
 Sistema Operativo: Linux Centos
Link Linux Ubuntu: Ubuntu
 Motor de base de datos: Postgres
Link Postgres: Postgres
16
Pruebas de Vulnerabilidad
El presente proyecto contempla la aplicación de un conjunto de pruebas de
vulnerabilidad, tendientes a identificar y mitigar brechas de seguridad a las que estén
expuestos los sistemas, estas pruebas y aplicación de herramientas de hacking,
están basadas en los principios del Ethical Hacking.
Pruebas de Penetración
Las pruebas de penetración son una práctica para poner a prueba un sistema
informático, red o aplicación web para encontrar vulnerabilidades que un atacante
podría explotar. Las pruebas de penetración pueden ser automatizadas con
aplicaciones de software, o se pueden realizar manualmente. De cualquier manera, el
proceso incluye la recopilación de información sobre el objetivo antes de la prueba
(reconocimiento), la identificación de posibles puntos de entrada, intentos de entrar (ya
sea virtualmente o de manera real) y el reporte de los resultados.
El principal objetivo de las pruebas de penetración consiste en determinar las

debilidades de seguridad.
Pruebas de Vulnerabilidad de Datos

Las pruebas de vulnerabilidad de datos son una práctica para poner a prueba un
sistema informático, red o aplicación web para encontrar vulnerabilidades que un
atacante podría explotar para acceder al conjunto de datos del sistema tendientes a
extraer información o corromper los contenedores y estructuras de datos de la
aplicación.
Ethical Hacking: La ética hacker es un conjunto de principios morales y filosóficos

surgidos, y aplicados a, las comunidades virtuales de hackers, aunque no son
exclusivas de este ámbito, ya que muchos de sus valores pueden aplicarse fuera del
ámbito de la informática y al acto de hackear. La expresión se suele atribuir al periodista
Steven Levyen su ensayo seminal Hackers: Heroes of the Computer Revolution,
publicado en 1984, donde describe y enuncia con detalle los principios morales que
surgieron a finales de los años cincuenta en el Instituto Tecnológico de Massachusetts
(MIT) y, en general, en la cultura de los aficionados a la informática de los años sesenta
y setenta. Los principios clave pueden resumirse en el acceso libre a la información y
en que la informática puede mejorar la calidad de vida de las personas.
17
Planificación
4.2 Aseguramiento de Calidad para el Registro de Fuentes y

Procesos.
Alcance
El presente informe aborda el trabajo realizado tendiente a asegurar la calidad del
sistema Web: Registro de Fuentes y Procesos, para lo cual se siguió el marco
metodológico presentado para el proyecto, aplicando el ciclo de vida de QA, a cada uno
de los elementos de negocio del sistema, además se ha abordado la mitigación de
errores de ingreso de datos, en las interfaces de usuario a través de soluciones de
integridad referencial y validación de predecesores y sucesores en la creación del
diagrama de descarga. Además, se han ejecutado herramientas de hacking ético, para
identificar las vulnerabilidades de los servidores que alojan en el sistema Web y su base
de datos.
18
Resultados previos
Ciclo de Vida de QA
Ejecución de pruebas en Interfaces de Usuario

Se han aplicado un conjunto de pruebas automatizadas y de usuario, siguiendo el ciclo
de vida de QA planteado en la metodología del presente proyecto, se ha detectado la
falta de integridad referencial entre los tipos de Fuente y sus Combustible, se
recomienda desplegar solo los combustibles que el tipo de fuente es capaz de usar,
reduciendo así el error de ingreso de datos. Asimismo, se ha detectado una idéntica
mejora en los modelos Combustible y sus Unidades de Medida.
19
Mitigación y Correcciones
Tipo Fuente - Combustible

Se ha trabajado en la creación y preparación de seeders que permiten crear integridad
referencial a los datos base del sistema, esto se ha aplicado a los modelos de Tipo de
Fuente, Tipo de Combustible, esto permite que la interfaz de caracterización de fuentes
muestre solo los combustibles de la fuente elegida.
El código fuente y los datos base de esta solución, se encuentra implementado en los servidores
del Ministerio del Medio Ambiente, en el repositorio de control de versiones GitLab y se adjuntan
en digital en el CD que acompaña este informe.
20
Combustible - Unidad de Medida
Se ha trabajado en la creación y preparación de seeders que permiten crear integridad
referencial a los datos base del sistema, esto se ha aplicado a los modelos de Tipo de
Combustible y Unidad de Medida, esto permite que la interfaz de caracterización de
fuentes muestre solo las unidades de Medida del combustible elegido.
21
Pruebas Interfaz Diagrama de Descargas
La interfaz gráfica Diagrama de Descarga, le permite al usuario crear un diagrama que
muestra la interacción de las fuentes de emisión en su establecimiento, permitiendo
mostrar el flujo de las emisiones entre sus fuentes, su equipos de abatimiento y sus
ductos de descarga o chimeneas, pudiendo caracterizarlas inmediatamente, Se han
aplicado las pruebas a esta interfaz, siguiendo el ciclo de vida de QA propuesto en este
proyecto, detectándose que la mayoría de los errores cometidos por el usuario obedece
al ordenamiento incongruente del diagrama, es decir flujos ilógicos en su construcción.
22
Correcciones y Mitigación
Se propone crear un algoritmo de sucesores y predecesores válidos que permita al
sistema prevenir las incongruencias en ordenamiento del flujo correcto del diagrama de
descargas, para esto se ha preparado y creado un conjunto de datos base, que son
cargados vía seeders, estos datos son usados por un algoritmo de validación que es
ejecutado cada vez que el usuario agregue un flujo en el diagrama, alertando al usuario
del error y eliminando los flujos erróneos del diagrama. Esta solución apunta
principalmente a mitigar el desconocimiento del negocio por parte de los usuarios.
Ejecución de pruebas de seguridad
Consideraciones
Al momento de realizar los trabajos del presente informe, se cuenta con un servidor de
Staging, en la red interna del Ministerio de Medio Ambiente, todas las pruebas han sido
ejecutadas sobre este servidor que cuenta con S.O. Linux Ubuntu 18.04. y que
comparte recursos con otros sistemas que se encuentran en proceso de desarrollo y
pruebas. El sistema Web, Registro de fuentes y procesos, se ha montado sobre
contenedores Docker, separando los servicios en aplicativo y base de datos.
En cuanto se cuente con un servidor productivo, expuesto a internet, se procederá a
realizar nuevamente la totalidad de pruebas efectuadas, para probar el acceso, tanto
desde internet como desde la red interna del Ministerio.
Se aplicó un conjunto de pruebas de seguridad basadas en las herramientas de hacking
ético, estas pruebas apuntan a la seguridad de red, acceso a base de datos y acceso
23
a directorios, en cada una de ellas se realizó en un procedimiento tendiente a identificar
posibles puntos de vulnerabilidad del sistema.
Servidor Staging
IP: 10.100.2.48
Pruebas de Red
El servidor escaneado expone un conjunto de puertos con vulnerabilidades conocidas
y con una alta probabilidad de susceptibilidad ante ataques tendientes a bloquear la
comunicación o acceder a la información del S.O. y los aplicativos alojados. Son
especialmente susceptibles los puertos de acceso de base de datos, 5432 y 3306 que
exponen los motores de base de datos PostgreSQL y MySQL.
Puertos expuestos
21/tcp filtered ftp
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
83/tcp open mit-ml-dev
443/tcp open https
3306/tcp open mysql
5432/tcp open postgresql
8081/tcp open blackice-icecap
8082/tcp open blackice-alerts
9000/tcp open cslistener
24
Mitigación y correcciones
Se procede a cerrar al exterior los todos los puertos que no son necesarios para la
operación del sistema Web, Reporte de fuentes y procesos, dejando exclusivamente el
puerto 80 para el acceso al sistema desde el browser de los clientes. El puerto 22 se
ha dejado expuesto solo a la red interna del Ministerio del Medio Ambiente, para realizar
las tareas de deploy y mantención.
El código fuente y los scripts de esta solución, se encuentra implementado en los servidores
Pruebas de acceso a directorios

Al realizar estas pruebas se encuentra un alto nivel de vulnerabilidad, el sistema Web
se encuentra altamente susceptible a ataques de distinta naturaleza, dando acceso a
la intrusión y posibles cambios en los directorios del sistema, archivos de imágenes,
ejecución de comandos arbitrarios de forma remota, visibilidad desde escáneres CGI,
sitio vulnerable a 'shellshock' entre otras.
Shellshock, también conocida como Bashdoor, es una familia de bugs de seguridad

en la ampliamente usada Bash de Shell de Unix. El primero de estos bugs fue divulgado
el 24 de septiembre de 2014. Varios servicios de internet tal como algunas
implementaciones de servidores web usan Bash para ciertos pedidos y procesos, esto
le permitía al atacante ejecutar comandos arbitrarios en versiones vulnerables de Bash,
de esta forma el atacante podía ganar acceso no autorizado al sistema atacado.
Se procedió a realizar los cambios necesarios en el código del sistema, implementando
las mejores prácticas de desarrollo, también se implementaron un conjunto de script,
que permiten modificar las configuraciones de las piezas de software involucradas en
las vulnerabilidades detectadas.
25
Mitigación y correcciones generales

En base a los resultados entregados por las herramientas se procedió con el proceso
de aseguramiento de calidad. Además, como se mencionó anteriormente, tanto las
pruebas de vulnerabilidad como las correcciones realizadas, se implementarán en el
servidor de producción, tanto desde internet, como desde la red interna del Ministerio
de Medio Ambiente, para asegurar el mínimo de susceptibilidades en el servidor
definitivo del sistema.
4.3 Identificar y subsanar brechas de seguridad en el proceso de

aseguramiento de la calidad para el módulo Cuantificación de
Emisiones.
Esta revisión contempla el aseguramiento de la calidad en el reporte de los
componentes que construyen la emisión. Se incluye en esta revisión el aseguramiento
de la integridad de la plataforma y seguridad informática en todo el módulo de
cuantificación.
Este módulo incluye todos los formularios que serán utilizados por los administradores
de la plataforma (Usuario Enlace Nacional, Enlace Sectorial y Administrador) como la
vista asociada al usuario Industrial, Debe incluirse la revisión de los formularios Solicitud
a Sistema Sectorial, formulario Revisión de Solicitudes, Búsqueda y mantenedores de
solicitudes, entre otros.
Todos los hallazgos y propuestas de mejora identificados deben ser subsanados e

implementados, además de estar correctamente documentados, tanto de modo
catastro como la subsanación de brechas de seguridad.
Consideraciones
26
pruebas. El sistemas Web, Cuantificación de Emisiones, se ha montado sobre

Servidor Staging
IP: 10.100.2.48
Pruebas de Red
El servidor escaneado ya ha pasado por un proceso de mitigación en los trabajos que
se están realizando, por lo que se ha dejado el puerto 80 para el acceso al sistema
desde el browser de los clientes. El puerto 22 se ha dejado expuesto solo a la red
interna del Ministerio del Medio Ambiente, para realizar las tareas de deploy y
mantención. Sin embargo, el puerto 22 aun es accesible vía User-Password, lo cual
puede traer una brecha de seguridad en el acceso al servidor.
Puertos expuestos
22/tcp open ssh
80/tcp open http
Se procede regular el acceso al puerto 22 sólo vía RSA Key, cerrando todos los
restantes métodos de acceso, dejando así el acceso solo a los miembros del equipo de
desarrollo encargados del deploy y administración del servidor.
27
En criptografía, RSA (Rivest, Shamir y Adleman) es un sistema criptográfico de clave
pública desarrollado en 1979. Es el primer y más utilizado algoritmo de este tipo y es
válido tanto para cifrar como para firmar digitalmente.
La seguridad de este algoritmo radica en el problema de la factorización de números

enteros. Los mensajes enviados se representan mediante números, y el funcionamiento
se basa en el producto, conocido, de dos números primos grandes elegidos al azar y
mantenidos en secreto. Actualmente estos primos son del orden de 10 elevado a 300,
y se prevé que su tamaño crezca con el aumento de la capacidad de cálculo de los
ordenadores.
Como en todo sistema de clave pública, cada usuario posee dos claves de cifrado: una
pública y otra privada. Cuando se quiere enviar un mensaje, el emisor busca la clave
pública del receptor, cifra su mensaje con esa clave, y una vez que el mensaje cifrado
llega al receptor, este se ocupa de descifrarlo usando su clave privada.
Se cree que RSA será seguro mientras no se conozcan formas rápidas de

descomponer un número grande en producto de primos. Aunque se cree que la
computación cuántica podría proveer de una solución al problema de factorización,
existen investigadores que dudan que dichos avances vayan a volver obsoletos estos
algoritmos.
El código fuente y los scripts de esta solución, se encuentra implementado en los

servidores del Ministerio del Medio Ambiente, en el repositorio de control de versiones
GitLab y se adjuntan en digital en el CD que acompaña este informe.

Al realizar estas pruebas se encuentra un nivel medio de vulnerabilidad, el sistema Web
se encuentra aún susceptible a ataques, dando acceso a la intrusión y posibles cambios
en los directorios del sistema, dejando el sitio vulnerable a 'shellshock'.

28

4.4 Identificar y subsanar brechas de seguridad en el proceso de

la calidad para el módulo de Reporte.
Esta revisión incluye todos los formularios de reporte que se presentan en la plataforma,
además de asegurar el correcto funcionamiento de la plataforma, se debe revisar la
coherencia de los formularios y sus filtros de información.
Este módulo se debe revisar desde las distintas plataformas de usuario: Usuario Enlace
Nacional, Enlace Sectorial y Administrador.
Todos los hallazgos y propuestas de mejora identificados deben ser subsanados e

implementado, además de estar correctamente documentados, tanto de modo catastro
como la subsanación de brechas de seguridad.
Consideraciones
29
pruebas. El sistemas Web, Cuantificación de Emisiones, se ha montado sobre
Servidor Staging
IP: 10.100.2.48
Pruebas de Red
El servidor escaneado ya ha pasado por un proceso de mitigación en los trabajos que
se están realizando, por lo que se ha dejado el puerto 80 para el acceso al sistema
desde el browser de los clientes. El puerto 22 se ha dejado expuesto solo a la red
interna del Ministerio del Medio Ambiente, para realizar las tareas de deploy y
mantención. Sin embargo, el puerto 22 aun es accesible vía User-Password, lo cual
puede traer una brecha de seguridad en el acceso al servidor.
Puertos expuestos
22/tcp open ssh
80/tcp open http
Se procede regular el acceso al puerto 22 sólo vía RSA Key, cerrando todos los
restantes métodos de acceso, dejando así el acceso solo a los miembros del equipo de
desarrollo encargados del deploy y administración del servidor.
30
En criptografía, RSA (Rivest, Shamir y Adleman) es un sistema criptográfico de clave
pública desarrollado en 1979. Es el primer y más utilizado algoritmo de este tipo y es
válido tanto para cifrar como para firmar digitalmente.
La seguridad de este algoritmo radica en el problema de la factorización de números
enteros. Los mensajes enviados se representan mediante números, y el funcionamiento
se basa en el producto, conocido, de dos números primos grandes elegidos al azar y
mantenidos en secreto. Actualmente estos primos son del orden de 10 elevado a 300,
y se prevé que su tamaño crezca con el aumento de la capacidad de cálculo de los
ordenadores.
Como en todo sistema de clave pública, cada usuario posee dos claves de cifrado: una
pública y otra privada. Cuando se quiere enviar un mensaje, el emisor busca la clave
pública del receptor, cifra su mensaje con esa clave, y una vez que el mensaje cifrado
llega al receptor, este se ocupa de descifrarlo usando su clave privada.
Se cree que RSA será seguro mientras no se conozcan formas rápidas de
descomponer un número grande en producto de primos. Aunque se cree que la
computación cuántica podría proveer de una solución al problema de factorización,
existen investigadores que dudan que dichos avances vayan a volver obsoletos estos
algoritmos.


Al realizar estas pruebas se encuentra un nivel medio de vulnerabilidad, el sistema Web
se encuentra aún susceptible a ataques, dando acceso a la intrusión y posibles cambios
en los directorios del sistema, dejando el sitio vulnerable a 'shellshock'.

31
El código fuente y los script de esta solución, se encuentra implementado en los servidores del
Ministerio del Medio Ambiente, en el repositorio de control de versiones GitLab y se adjuntan
Mitigación y correcciones generales

En base a los resultados entregados por las herramientas se procedió con el proceso
de aseguramiento de calidad. Además, como se mencionó anteriormente, tanto las
pruebas de vulnerabilidad como las correcciones realizadas, se implementarán en el
servidor de producción, tanto desde internet, como desde la red interna del Ministerio
de Medio Ambiente, para asegurar el mínimo de susceptibilidades en el servidor
definitivo del sistema.
4.5 Proponer y realizar mejoras que se adviertan en relación a la

usabilidad y operatividad de la plataforma del Reporte GEI.
El proveedor debe proponer para cada uno de los procesos detallados anteriormente,
un listado de mejoras de usabilidad que entreguen una mejora a la experiencia tanto
para el usuario industrial como el usuario revisor de la plataforma.
32
Estas propuestas deben ser acordadas e implementadas en la marcha blanca del
Reporte GEI, antes de ponerlo en producción.
Dichas propuestas deberán ser documentadas, tanto la propuesta, su mejora en la

usabilidad de la plataforma como la implementación de ésta.
Pruebas automatizadas
Las pruebas automatizadas consisten en el uso de un software para controlar y
configurar las condiciones previas a las pruebas, la ejecución de las pruebas y la
comparación de los resultados reales con los resultados esperados. Se desarrollan
dentro del proyecto y están destinadas a cuidar el correcto funcionamiento de la lógica
interna del sistema.
Cada una de estas pruebas sigue una serie de pasos dentro del sistema, con el fin de
asegurar que las funcionalidades no hayan sido tocadas por los desarrolladores en el
proceso de QA.
Laravel Dusk
Para estas pruebas se utiliza Laravel Dusk, que proporciona una API de automatización
y prueba para navegador expresiva y fácil de usar. De forma predeterminada, Dusk no
requiere que instalar JDK o Selenium en el sistema. En su lugar, Dusk usa una
instalación de ChromeDriver independiente.
Sigue la práctica TDD (test-driven development) y funciona realizando pruebas desde

el navegador web, es decir, interactúa dentro del navegador presionando botones,
rellenando formularios, utilizando drag and drop, etc. Al momento de encontrar un fallo
dentro del código arroja un error y envía un screenshot para poder revisar con
detenimiento dónde se encuentra el problema.
Pruebas de concepto
Previo a utilizar Laravel Dusk como herramienta de testing, se realizaron pruebas de
concepto para asegurar que la tecnología funciona de forma adecuada dentro del
sistema. Para esto se escribieron diferentes pruebas y se ejecutaron en el navegador,
con el fin de revisar la correcta interacción y respuesta entre las instrucciones dadas y
el browser.
Para las pruebas automatizadas se utilizan diversos métodos y funciones de Laravel

Dusk, entre las que se encuentran:
● Visit: Redirige al usuario a una página en específico.

● ClickLink: Hace click en un enlace deseado, mediante la búsqueda del texto
que muestra el mismo.
33
● Type: Es una instrucción para escribir un texto o una selección de caracteres
específicos dentro de un cuadro de texto indicado en la misma función.
● AssertPathIs: Dentro de esta función se indica la ruta donde debería estar el
usuario y acusa si se encuentra allí o no.
● AssertSee: Acusa la presencia algún texto indicado en la página y que, por
ende, el usuario debería poder ver.
● AcceptDialog: Cierra un cuadro de diálogo de JavaScript haciendo click en el
botón OK.
● WhenAvailable: Espera por un tiempo determinado la presencia de alguna
ventana emergente, para luego interactuar con él.
● Keys: Este método permite ingresar secuencias de entrada más complejos a un
elemento dado a como lo haría normalmente el método type. Con este método
es posible presionar (y mantener presionadas) distintas teclas, como pueden ser
TAB, ENTER, ESCAPE, CONTROL, SHIFT, DELETE, las teclas desde el F1 al
F12, teclas de flechas, etc.
● Press: Presiona algún botón indicado por el selector.
● Pause: Establece una pausa por un tiempo determinado por el usuario y
después continúa la prueba.
● WaitFor: Espera la aparición de un elemento determinado por un período de
tiempo especificado por el usuario.
Integración de Dusk en el Sistema de Reporte de Gases de Efecto

Invernadero
Para integrar Laravel Dusk al sistema de Reporte de Gases de Efecto Invernadero se

llevó a cabo una serie pasos.
● Primero se realizó un pull del proyecto alojado en GitLab, para luego continuar
con la creación de nueva rama o branch para el mismo, llamada tests.
● Dentro de esta rama se instaló Laravel Dusk y se realizó la prueba de conceptos
para comprobar que la herramienta era la adecuada para probar los distintos
componentes del sistema, esto quiere decir, que se escribió una serie de
pruebas donde se interactuó con el sistema mediante el navegador web, para
comprobar que realizaba los pasos indicados en el código.
● Después de haber realizado estas pruebas, se hizo un push al repositorio en
GitLab, es decir, que los cambios realizados fueron integrados en la rama
master, la rama principal del proyecto.
34
Ejemplo de prueba automatizada
Se elige el requisito y se escribe la prueba:
Se verifica que la prueba falle:
35
Se escribe la implementación y se ejecuta la prueba automatizada:
Funcionalidades del módulo de Registro de Fuentes y Procesos
1. Ingreso y Acceso al Sistema
1.1. Pantalla de Bienvenida

Pantalla en la que se muestra una breve bienvenida, los datos del establecimiento,
usuario y CIIU del establecimiento, con funcionalidad de editar. Además, muestra el
botón para registrar fuentes.
36
1.2. Editar CIIU: Determina a qué etapas tendrá accesos el usuario
En esta funcionalidad el usuario puede cambiar el CIIU del establecimiento
seleccionando cuatro niveles de desagregación.
2. Etapas
2.1.Pantalla de Registro de Fuentes y Procesos: Muestra las Etapas de

registro
En esta funcionalidad se despliega un wizard para registrar fuentes en cuatro etapas
que indican los tipos de fuentes a registrar.
● Etapa 1: Fuentes de uso general

● Etapa 2: Fuentes de generación de energía eléctrica y vapor
● Etapa 3: Procesos con transformación de materia prima
● Etapa 4: Fuentes asociadas a Planes de Descontaminación Atmosférica (PDA)
El usuario tiene acceso a las etapas 1, 2 o 3 de acuerdo al tipo de CIIU del

establecimiento.
La etapa 4 se muestra cuando la comuna del establecimiento está afecta a un Plan de

Descontaminación Atmosférica.
3. Registro
3.1.
Etapa 1: Fuentes de uso general: Registro simple para establecimientos
principalmente no industriales
En esta funcionalidad se despliega un listado de tres tipos de fuentes de uso general,
en donde el usuario puede agregar, editar y eliminar una fuente. También, se muestra
un botón para enviar las fuentes registradas.
3.1.1. Agregar fuente de uso general.

Dentro de esta funcionalidad es posible seleccionar 3 tipos de fuentes. Luego de
seleccionar una de ellas, se despliegan todos los datos requeridos para registrar esa
fuente. Estos son:
● Nombre
● Marca
● Modelo
● N° de serie
● N° interno
● Año de fabricación
● Código ducto
● Año de instalación
● Fecha de operación inicial
● Fecha de primera declaración
37
● Fecha inscripción
● Tipo de combustible
● Consumo nominal
● Unidad de combustible
● CCF8
● Nombre CCF8
3.1.2. Características de Validación.

● El CCF8 se determina automáticamente con la información ingresada en las
fuentes.
● La caldera de agua caliente y el horno de panadería presentan un tipo de
combustible secundario adicional.
● Las opciones de combustible dependen de la fuente seleccionada, así como la
unidad de medida dependerá del tipo de combustible seleccionado.
3.1.3. Editar fuente de uso general

En la funcionalidad para editar la fuente de uso general se deben visualizar los mismos
campos que en la funcionalidad para agregar fuentes de uso general.
3.2. Etapa 2: Registro de fuentes de generación de energía eléctrica y vapor:

Registro mediante diagramas de descarga
En esta funcionalidad se debe presenciar un listado las fuentes, chimeneas y sistemas
de abatimiento (cajas) asociadas al proceso de generación de energía eléctrica y vapor
del establecimiento con las cuales se debe elaborar el diagrama de descarga. Además
de los botones de información, guardar, zoom, borrar y enviar.
● El diagrama se puede elaborar tomando las fuentes e incorporar éstas a la

pantalla, cada una de ellas permite el despliegue de líneas para la conexión entre
estas.
● Cada caja de fuente, sistema de abatimiento o chimenea presentará el botón
Caracterizar, donde se despliega la ventana con la información requerida para
el registro.
● Cada tipo de fuente, sistema de abatimiento y chimenea tiene una cantidad de
campos definidos en la base de datos, y la interfaz solicita sólo los campos
indicados.
3.2.1. Algoritmo de predecesores y sucesores

El diagrama de descarga sólo permite el flujo de la siguiente lógica fuentes-abatimiento-
chimenea o fuente- chimenea. El sistema permitirá incorporar más de un sistema de
abatimiento, además de permitir configuraciones en serie y en paralelo.
3.2.2. Caracterizar fuentes de generación de energía eléctrica y vapor

Esta funcionalidad contiene los campos requeridos para el ingreso de datos de la fuente
a registrar:
38
● Las chimeneas requieren de la altura, diámetro, latitud y longitud de la misma
para desplegar un mapa con la ubicación exacta de la misma.
● Los sistemas de abatimiento contienen menos datos requeridos, estos son el
nombre, marca, modelo, n° de serie, n° interno, año de fabricación y año de
instalación.
● Cada tipo de fuente tiene una cantidad de campos definidos en la base de datos,
y la interfaz solicitará sólo los campos indicados.
Esta etapa también contempla las características de validación mencionadas el punto

3.1.2 para las fuentes registradas.
3.3. Etapa 3: Registro de fuentes con transformación de materia prima:

Registro mediante diagramas de descarga.
En esta etapa en primer lugar se despliegan los tipos de procesos industriales, una vez
seleccionado el que corresponda, el sistema despliega un listado de fuentes y sistemas
de abatimiento relacionados con el proceso, posteriormente, a través del diagrama de
descarga se registran todas las fuentes, sistemas de abatimiento y chimeneas. Las
funcionalidades lógicas del diagrama de descarga son las mismas indicadas en el punto
3.2.
3.3.1. Campos según tipo de fuente

Cada fuente, chimenea y sistema de abatimiento contiene distintos campos que deben
ser ingresados a través del diagrama de descarga.
3.3.2. Unidades complementarias

Las unidades complementarias van a existir en el menú del programa para ser
agregadas al diagrama de descarga, no estarán afectas a los algoritmos de
predecesores y sucesores, y no tendrán el botón Caracterizar, sólo están disponibles
para ayudar al usuario a diagramar de mejor forma el proceso de su establecimiento.
3.4. Registro de fuentes sujetas a PDA: Registro simple de fuentes afectas

En esta funcionalidad se visualiza una ventana con las fuentes sujetas a PDA, y permite
el registro de las fuentes que no se encontraban en etapas anteriores y, por lo tanto,
que no se hayan registrado.
● Fuentes sujetas a PDA caracterizadas: Corresponde a las fuentes sujetas al PDA

que ya fueron registradas en etapas anteriores.
● Fuentes sujetas a PDA sin caracterizar: Corresponde a las fuentes sujetas al
PDA que no se encontraban en etapas anteriores y deben ser caracterizadas
para el PDA.
39
3.4.1. Caracterizar fuente sujeta a PDA
Dentro de la funcionalidad Caracterizar Fuente se despliega una ventana de donde se
ingresan los datos de la fuente a registrar. Los campos que se despliegan para el
ingreso de datos dependen del tipo de fuente seleccionado.
4. Secciones (Menú)
4.1. Sección de diagramas de descarga

En esta sección se encuentra un listado con los diagramas de descarga enviados y en
edición, separados en dos secciones: Generación de Energía y Vapor y los Procesos
con Transformación de Materia Prima. En cada diagrama del listado hay un botón de
información a su costado.
4.2. Sección de listado de envíos

En la siguiente sección se despliega un listado con las fuentes enviadas y en edición.
En cada fuente del listado que está en edición existe un botón de información. Este
botón redirige al wizard para agregar las fuentes correspondientes.
4.3. Sección de listado de fuentes

En esta sección se visualiza un listado de las fuentes registradas, junto con los datos
asociados a esa fuente. Además, se puede observar un botón para descargar los datos
en formato Excel.
Plantilla QA para el Registro de Fuentes y Procesos

Esta plantilla contiene todas las pruebas que deberá realizar el usuario a través del
sistema del Registro de Fuentes y Procesos. En él se detalla la funcionalidad que se
evalúa, el resultado que se espera, el resultado obtenido y un apartado de
observaciones para registrar requerimientos y comentarios que surjan durante la
ejecución de la prueba.
Pruebas automatizadas en el Registro de Fuentes y Procesos

Durante el proceso de QA del sistema de Registro de Fuentes y Procesos se realizaron
pruebas en la etapa 1, etapa 2, etapa 3, etapa de PDA y pruebas de acceso con el
sidebar, siguiendo la estructura planteada en el documento de descripción de
funcionalidades y siguiendo el flujo de procesos dispuesto en la plantilla de pruebas.
Las pruebas en el diagrama de descarga fueron realizadas de forma manual y se llevó
a cabo una serie de combinaciones entre fuentes, chimeneas y sistemas de
abatimiento, con el fin de comprobar cuáles conexiones deben ser permitidas y cuáles
no.
40
Resultados finales para el Registro de Fuentes y Procesos
Pruebas Acceso: Etapas por CIIU
Prueba Funcionalidad Resultado Esperado Observaciones
0 Acceso Pantalla de Visualización de la Existe un error en la descripción de la

bienvenida pantalla de bienvenida. bienvenida:
“(...) se registran las todas fuentes y
procesos (...) “.
Botón de notificación no habilitado.
1 Elección CIIU de Ingresar a la etapa 1. Ninguna.
Rubro no
Industrial
2 Elección de CIIU Ingresar a la etapa 1 y Ninguna.
Rubro Energía 2.
3 Elección CIIU Ingresar a la etapa 1, 2 Ninguna.
Rubro y 3.
Industriales
4 Variación de Ver las comunas Ninguna.
comunas Afectas a PDA con
accesos Etapa 4.
Pruebas Etapa N° 1: Fuentes de uso general
1 Acceso Acceder a "Registrar Ingresar a la pantalla Ninguna.

Fuente" que permite agregar
fuentes.
2 Acceder a "Agregar Ingresar a la pantalla Ninguna.
Fuente de Uso de caracterización de
General" fuentes.
3 Registro Seleccionar Fuente Desplegar la pantalla Ninguna.
a Registrar con información a
solicitar para el registro
de la fuente.
4 Incorporación de Visualizar campos en Es posible ingresar letras y
Información tono rojo si la símbolos en los campos n° de
solicitada información ingresada serie, n° interno y código de
es errónea. ducto.
Visualizar campos en Debería permitir el ingreso de
tono verde si la guiones (-) exclusivamente.
información ingresada
es correcta.
5 Ingreso "Tipo de Ver las opciones de Existen algunos nombres de
Combustible" combustible a elegir combustibles con mayúsculas
según la fuente y otros con minúsculas (en
seleccionada. todas las etapas).
41
6 Clasificación Una vez ingresada la Ninguna.
"CCF8" información se debe
desplegar la
clasificación CCF8 de
forma automática.
7 "Guardar" Registro La fuente debe quedar La información se lista de
listada con información forma correcta. Pero, es
ingresada. posible guardar letras y
símbolos en los campos n° de
serie, n° interno y código de
ducto.
Debería permitir el ingreso de
guiones (-) exclusivamente.
8 "Enviar" Registro Desplegar la pantalla No aparece un check, pero
principal del registro. aparece un diálogo de ÉXITO
La etapa 1 se debe al completar la tarea.
mostrar con un check.
Pruebas Etapa N° 2: Fuentes de producción de energía y vapor
1 Acceso Acceder a Registro Desplegar la ventana para Tooltip no habilitado.

"Diagrama de elaboración del diagrama de
descarga" descarga con las cajas de
fuentes, sistemas de
abatimiento y chimeneas.
2 Elaborar Generar Diagrama Generar el diagrama de Ninguna.
Diagrama en serie Fuente descarga con el despliegue de
(Caldera) - líneas solicitado.
Abatimiento-
Chimenea (tomar y
deslizar fuentes a
pantalla de
diagrama)
3 Generar Diagrama Generar el diagrama de No permite unión
Fuente-Abatimiento- descarga con el despliegue de entre abatimientos.
Abatimiento- líneas solicitado.
Chimenea
4 Generar Diagrama Generar el diagrama de Ninguna.
Fuente-Abatimiento- descarga con el despliegue de
Abatimiento(paralelo) líneas solicitado.
-Chimenea
5 Generar Diagrama No debe permitir la unión entre Ninguna.
Fuente-Fuente dos fuentes. Debe indicar que el
sucesor es inválido.
6 Seleccionar cajas y Eliminar las cajas puestas en el Ninguna.
utilizar botón diagrama de descarga.
"BORRAR", dejar
solo diagrama
Fuente-Abatimiento-
Chimenea
7 Registro Registrar diagrama Desplegar la pantalla con Ninguna.
(Fuente-Abatimiento- información a solicitar para el
Chimenea) a partir registro de la fuente.
del botón
"Caracterizar" de
cada caja
42
8 Registrar Fuente Visualizar campos en tono rojo Ninguna.
"Caracterizar" si la información ingresada es
errónea.
Visualizar campos en tono verde
si la información ingresada es
correcta.
9 Ingreso "Tipo de Debe mostrar las opciones de Ninguna.
Combustible" combustible según la fuente que
se está registrando, puede ser
una caldera, turbina o motor.
Además de mostrar la unidad de
combustible de acuerdo al
combustible seleccionado.
10 Agregar Al agregar el combustible debe Ninguna.
Quemadores según aparecer la opción para
corresponda incorporar los quemadores.
(Calderas-Turbinas) Al ingresar se debe mostrar una
pantalla con la opción
"AGREGAR QUEMADOR".
11 Ingresar a Desplegar una pantalla para Ninguna.
"AGREGAR agregar la información de los
QUEMADOR" quemadores de acuerdo a los
combustibles seleccionados.
12 Agregar de Registrar los quemadores sólo Ninguna.
información de para los combustibles
quemadores registrados. Debe aparecer una
opción para indicarlo como
sistema dual (combustible
primario y secundario).
13 Clasificación CCF8 Debe solicitar el campo Ninguna.
adicional "CCF8" para el
despliegue automático de la
clasificación "Nombre CCF8".
14 "Guardar" Registro La caja debe mostrar un Check Ninguna.
(verde) para indicar que se
guardó el registro.
15 Registrar La caja debe mostrar un Check Ninguna.
Abatimiento y (verde) para indicar que se
Guardar guardó el registro.
16 Registrar Chimenea Desplegar un mapa con la Ninguna.
y Guardar ubicación de la chimenea.
Además, la caja debe indicar un
Check (verde) para indicar que
el registro fue guardado.
17 Registrar Chimenea Desplegar un mapa con la Ninguna.
y Guardar ubicación de la chimenea.
Además, la caja debe indicar un
Check (verde) para indicar que
el registro fue guardado.
18 Probar Botón ZOOM Botón maximizar: Debe Ninguna.
: Maximizar - aumentar la pantalla.
Minimizar-Ajustar Botón minimizar: Debe disminuir
de pantalla.
Botón ajustar: Debe encuadrar
el diagrama de descarga.
19 "Guardar" Diagrama Solo debe permitir guardar si Guarda la
de descarga está toda la información información
registrada. incompleta y la deja
como en EDICIÓN.
43
20 "Enviar" Registro Se debe desplegar la pantalla No envía la
principal del registro. Y la etapa información
2 se debe mostrar con un incompleta. Sin
Check. embargo, al
presionar ENVIAR
(con la información
incompleta) aparece
un diálogo de
ÉXITO.
La información
finalmente queda en
estado de EDICIÓN.
Pruebas Etapa N° 3: Procesos con transformación de materia prima
1 Acceso Acceder a Etapa Desplegar el listado de Ninguna.

3 "Procesos con procesos.
transformaciones
materia Prima"
2 Generar Seleccionar un Debe mostrar el acceso Ninguna.
Diagrama Proceso e ir al a la pantalla para la
diagrama de elaboración del
descarga diagrama de descarga
con fuentes-
abatimiento-chimeneas
y unidades
complementarias.
3 Generar Generar el diagrama de Ninguna.
Diagrama acorde descarga con
al proceso despliegue de líneas
seleccionado de fuentes, abatimientos
(indicar procesos y chimeneas disponibles
seleccionado) acorde al proceso.
4 Generar Debe permitir la unión No permite unión entre
Diagrama Fuente- entre dos fuentes (para fuentes.
Fuente el proceso de
transformación de
materia prima).
5 Seleccionar cajas Debe eliminar las cajas Ninguna.
y utilizar botón puestas en el diagrama
"BORRAR", dejar de descarga.
solo diagrama
Fuente-
Abatimiento-
Chimenea
6 Registro Registrar Debe desplegar la Ninguna.
diagrama a partir pantalla con la
del botón información solicitada
"Caracterizar" de dependiendo de la
cada caja fuente seleccionada.
7 Registrar Todas Visualizar campos en Ninguna.
las Fuentes tono rojo si la
"Caracterizar" información ingresada
es errónea.
Visualizar campos en
tono verde si la
44
información ingresada
es correcta.
8 Ingreso "Tipo de Debe mostrar las Ninguna.
Combustible" opciones del
combustible a
seleccionar según la
fuente elegida. Y la
unidad de combustible
de acuerdo a
combustible
seleccionado.
9 Clasificación Debe solicitar el campo No se puede seleccionar el
CCF8 adicional "CCF8" para el CCF8.
despliegue automático
de la clasificación
"Nombre CCF8".
10 Agregar Al agregar el Ninguna.
Quemadores combustible debe
según aparecer opción de
corresponda incorporar los
(Calderas- quemadores. Cuando se
Turbinas) ingresa debe aparecer
la opción "AGREGAR
QUEMADOR".
11 Ingresar a Debe desplegar la Ninguna.
"AGREGAR pantalla para agregar
QUEMADOR" información de los
quemadores, de
acuerdo a los
combustibles
ingresados.
12 Agregar de Debe aparecer el Ninguna.
información de registro de los
quemadores quemadores, pero sólo
para los combustibles
registrado. Junto con la
opción para indicarlo
como sistema dual
(combustible primario y
secundario).
13 "Guardar" La caja debe indicar un Ninguna.
Registro Check (verde) cuando el
registro quede
guardado.
14 Registrar La caja debe indicar un Ninguna.
Abatimiento y Check (verde) cuando el
Guardar registro quede
guardado.
15 Registrar Desplegar un mapa con Ninguna.
Chimenea y la ubicación de la
Guardar chimenea. Además, la
caja debe indicar un
Check (verde) para
indicar que el registro
fue guardado.
16 Probar Botón Botón maximizar: Debe Ninguna.
ZOOM: Maximizar aumentar la pantalla.
- Minimizar- Botón minimizar: Debe
Ajustar disminuir de pantalla.
45
Botón ajustar: Debe
encuadrar el diagrama
de descarga.
17 "Guardar" Sólo debe permitir Si bien guarda la información
Diagrama de guardar si está toda la incompleta, la deja como en
descarga información registrada. EDICIÓN.
18 "Enviar" Registro Se debe desplegar la Envía la información
pantalla principal del incompleta. Al presionar
registro. Y la etapa 2 se ENVIAR (con la información
debe mostrar con un incompleta) aparece un
Check. diálogo de ÉXITO.
Pruebas Etapa N° 4: Planes de Descontaminación
Prueba N° Funcionalidad Resultado Esperado Observaciones
1 Acceso Acceder a Se debe ingresar a la La descripción de la etapa

"REGISTRAR pantalla que muestra las contiene un Lorem Ipsum.
FUENTES fuentes sujetas al PDA de
SUJETAS A acuerdo a la comuna en
PDA" que se encuentra.
Además, debe mostrar las
fuentes sujetas a PDA
caracterizadas en un
listado de fuentes
registradas en etapas
anteriores, sin opción de
registro. Y las fuentes
sujetas a PDA sin
caracterizar, con la opción
para caracterizar la fuente.
2 Registra fuente Desplegar una ventana con Ninguna.
sin caracterizar información para
en caracterizar la fuente.
"CARACTERIZ
AR FUENTE"
3 Registro Seleccionar Desplegar una pantalla con Ninguna.
Fuente a los campos a solicitar para
Registrar registrar la fuente.
4 Incorporación Visualizar campos en tono Ninguna.
de Información rojo si la información
solicitada ingresada es errónea.
Visualizar campos en tono
verde si la información
ingresada es correcta.
5 Ingreso "Tipo Debe mostrar las opciones Ninguna.
de del combustible a
Combustible" seleccionar según la fuente
elegida. Y la unidad de
combustible de acuerdo a
combustible seleccionado.
46
Pruebas Acceso: Navegación mediante barra lateral
1 Acceso Ingreso a Ingresar al listado de Botón de edición no habilitado.

listado de diagramas de No se muestra ningún listado de
diagramas de descarga. diagramas de descarga enviados y
descarga en edición recientes.
2 Ingreso a Ingresar al listado de Ninguna.
listado de envíos.
envíos
3 Ingreso a Ingresar al listado de Botón de edición no habilitado.
listado de fuentes registradas. Botón de descarga no habilitado.
fuentes
4 Preguntas Apoyo para el usuario En elaboración.
Frecuentes ante consultas.
5 Tutoriales Apoyo documental En elaboración.
para el usuario.
Durante la prueba de combinación de fuentes, chimeneas y sistemas de abatimiento

en los diagramas de descargas, se pudieron apreciar los siguientes resultados:
TIPO DE RESULTADO RESULTADO

COMBINACIONES CONEXIÓN ESPERADO ACTUAL
DEBE
PERMITIR
SÓLO EN NO PERMITE
FUENTE FUENTE EN SERIE ETAPA 3 EN ETAPA 3
DEBE
FUENTE CHIMENEA EN SERIE PERMITIR PERMITE
DEBE
FUENTE ABATIMIENTO EN SERIE PERMITIR PERMITE
NO DEBE
CHIMENEA CHIMENEA EN SERIE PERMITIR NO PERMITE
NO DEBE
CHIMENEA FUENTE EN SERIE PERMITIR NO PERMITE
DEBE
CHIMENEA ABATIMIENTO EN SERIE PERMITIR PERMITE
DEBE
ABATIMIENTO ABATIMIENTO EN SERIE PERMITIR NO PERMITE
NO DEBE
ABATIMIENTO FUENTE EN SERIE PERMITIR NO PERMITE
DEBE
ABATIMIENTO CHIMENEA EN SERIE PERMITIR PERMITE
DEBE
FUENTE ABATIMIENTO CHIMENEA EN SERIE PERMITIR PERMITE
DEBE
FUENTE CHIMENEA ABATIMIENTO EN SERIE PERMITIR PERMITE
NO DEBE
CHIMENEA FUENTE ABATIMIENTO EN SERIE PERMITIR NO PERMITE
47
NO DEBE
CHIMENEA ABATIMIENTO FUENTE EN SERIE PERMITIR NO PERMITE
NO DEBE
ABATIMIENTO CHIMENEA FUENTE EN SERIE PERMITIR NO PERMITE
NO DEBE
ABATIMIENTO FUENTE CHIMENEA EN SERIE PERMITIR NO PERMITE
DEBE
PERMITIR
SÓLO EN NO PERMITE
FUENTE FUENTE ABATIMIENTO CHIMENEA EN SERIE ETAPA 3 EN ETAPA 3
NO DEBE
FUENTE CHIMENEA CHIMENEA ABATIMIENTO EN SERIE PERMITIR NO PERMITE
DEBE
FUENTE ABATIMIENTO ABATIMIENTO CHIMENEA EN SERIE PERMITIR NO PERMITE
EN DEBE
FUENTE ABATIMIENTO ABATIMIENTO CHIMENEA PARALELO PERMITIR PERMITE
Se procedió a realizar los cambios necesarios en el código del sistema, corrigiendo
cada uno de los puntos de error informados por el proceso de QA, a continuación, se
realizaron las pruebas automatizadas y las pruebas manuales de las funcionalidades
corregidas en el servidor de testing, en el proceso mencionado todas las pruebas
resultaron sin errores detectados.
El código fuente y los script de esta solución, se encuentra implementado en los servidores del
Ministerio del Medio Ambiente, en el repositorio de control de versiones GitLab y se adjuntan
Funcionalidades del módulo de Reporte Único de Emisiones Atmosféricas
1. Ingreso y Acceso al Sistema

1.1. Pantalla de Bienvenida
Pantalla donde se observa el menú desplegado con la siguiente información:
● Establecimiento
● Declaraciones
● Administrar Declaraciones
● Administrar Solicitudes
● Preguntas Frecuentes
● Tutoriales
2. Menú Establecimiento
Información de caracterización del establecimiento, información precargada desde
ventanilla Única.
48
3. Menú Declaraciones
Ingreso a pantalla que permite el acceso a las declaraciones F138, Registrar
Mediciones y Declarar COV'S de manera independiente.
La pantalla despliega las declaraciones realizadas por el establecimiento indicando:
● Periodo de Declaración
● Tipo
● Fecha Declaración
● Estado
3.1. NUEVA DECLARACIÓN D.S. 138: Declaración de F138 Anual
En esta funcionalidad se despliega una nueva declaración en “DECLARACIONES
DEL ESTABLECIMIENTO” permitiendo el acceso a esta mediante el botón EDITAR.
3.1.1. EDITAR Declaración:

Pantalla muestra las fuentes registradas por el establecimiento previamente en el
registro de fuentes y procesos por cada etapa
3.1.2. ACTUALIZAR FUENTES

Permite la actualización e incorporación de nuevas fuentes registradas en el registro
de fuentes y procesos.
3.1.3. VER REGISTRO

Acceso a pantalla para ingreso de niveles:
● Consumo de Combustible Mensual
● Consumo de combustible Secundario mensual (si corresponde)
● Ciclo de Funcionamiento Semanal
● Periodos de Paralización
3.1.4. Opción “SIGUIENTE”
Permite el acceso a pantalla con detalle de emisiones para de cada fuente por
contaminante, mediante gráficas y tabla.
3.1.5. ENVIAR A LA AUTORIDAD

Funcionalidad permite el envío de la declaración a la autoridad.
3.2. REGISTRAR MEDICIONES: Registro de información de muestreo de

emisiones.
Pantalla muestra las fuentes registradas por el establecimiento previamente en el
registro de fuentes y procesos por cada etapa, con opción para REGISTRAR
MEDICIONES
3.2.1. REGISTRAR MEDICIONES

Pantalla permite la incorporación de información relativa a las mediciones de
contaminantes realizados.
49
3.2.2. AGREGAR CORRIDA (cambiar a AGREGAR MEDICIÓN)
Permite agregar una medición y su información asociada a un contaminante.
3.2.3. Select File

Funcionalidad que permite la carga del muestreo realizado.
3.3. REGISTRAR COV'S: Permite la declaración de estimación y/o

mediciones de compuestos orgánicos volátiles
Despliegue de pantalla con información que se solicitará para la declaración de
COV'S:
● Información Operacional Actual
● Estimación de Emisiones de COV'S
● Mediciones
3.3.1. BAJAR PLANTILLA
Permite obtener la plantilla base para incorporar la información operacional (formulario
3B).
3.3.2. CARGAR DETALLE OPERACIÓN

Permite la subir la plantilla base, incorporando información general de la operación.
3.3.3. CARGAR ESTIMACIÓN

Permite incorporar información relativa a la fuente que se ha estimado la emisión de
COV'S y cargar el informe correspondiente.
3.3.4. REGISTRAR MEDICIONES de COV'S

Pantalla permite la incorporación de información relativa a las mediciones de
contaminantes realizados.
Resultados finales para el Reporte Único de Emisiones Atmosféricas

Pruebas Acceso : Menú y Administración
Error tipográfico: “Registro
Acceder a Ingresar a la pantalla de Cuentificación de Emisiones”.
0
“Bienvenida” bienvenida. Botón de notificación no
funcional.
Ingresar a la pantalla con No se encuentra la sección, se
Acceder a
1 información del asumirá que se refiere a la
"Establecimiento"
establecimiento. sección de Bienvenida.
Ingresar a la pantalla con la
Acceso presentación del listado de
declaraciones y las opciones
Acceder a
2 "NUEVA DECLARACIÓN D.S. Ninguna.
"Declaraciones"
138 / REGISTRAR
MEDICIONES / REGISTRAR
COV’S”.
50
Acceder a Ingresar a pantalla con la
3 "Administrar información del Ninguna.
Declaraciones" establecimiento.
Acceder a
"CAMBIAR La declaración listada debe
5 ESTADO" y presentar algún cambio de No se puede cambiar estado.
seleccionar un estado.
estado
Debe mostrar una pantalla

Acceder a
6 donde se pueda ver el estado Ninguna.
"BITÁCORA"
de la solicitud.
Acceder a Debe desplegar una pantalla

6 "OBSERVACIONE con la opción de incorporar un Ninguna.
S" comentario a la solicitud.
Debe desplegar una lista los

Ingresar
5 comentarios relacionados a la Ninguna.
Comentario
solicitud enviada.
Debe ingresar a la pantalla que

Acceder a
permite la opción de rechazar o
"Administrar
aprobar una solicitud.
6 Solicitudes" No se puede cambiar estado.
Debe mostrar el cambio de
RECHAZAR O
estado según la opción
APROBAR
seleccionada.
Preguntas Apoyo al usuario ante

7 En elaboración.
Frecuentes consultas.
Apoyo documental para el

8 Tutoriales En elaboración.
usuario.
Declaración F138
Debe desplegar una nueva

Acceder a
declaración listada en
"NUEVA
1 "DECLARACIONES DEL Ninguna.
DECLARACIÓN
ESTABLECIMIENTO" con la
D.S. 138"
opción EDITAR.
Errores tipográficos:
En la sección de Fuentes
Ingresar a la pantalla con
Declaración Generación de Energía y
fuentes registradas. Debe
Vapor, el botón dice
Acceder a mostrar las opciones de
“REGISTRAR
"EDITAR" en la ACTUALIZAR FUENTES /
2 PRODIUCCIÓN”.
declaración VER REGISTRO / IR A
En la sección de Procesos con
enlistada DIAGRAMA DE DESCARGA /
Transformación de Materia
SIGUIENTE / MATERIA
Prima, el botón dice
PRIMA (procesos).
“REGISTRAR PRODUCIÓN”.
51
Permite que se muestran
Acceder a
nuevas fuentes registradas en
3 "ACTUALIZACIÓ Ninguna.
registro de fuentes y
N FUENTES"
procesos.
Debe desplegar una pantalla

que permite el ingreso y
Acceder a "VER Considerar que en algunos
guardado de consumo y
REGISTRO" e casos esta información estar
4 niveles de actividad. Además,
ingresar de forma predeterminada (DS
debe mostrar estos registros
información 13, IV).
de niveles de actividad y
consumo de la fuente.
Permite visualización de
Abre la ventana donde
Acceder a "IR A diagrama generado en el
debería estar dibujado el
5 DIAGRAMA DE reporte de fuentes y procesos
diagrama, pero este no
DESCARGA" e ingreso de niveles de
aparece.
actividad y consumo.
Debe permitir el acceso a la

El texto asociado a las tablas
información con estimación de
no es visible.
emisiones en tablas y
Algunas fuentes listadas
gráficas. Además, debe
Acceder a contienen el texto
6 mostrar la opción de
"SIGUIENTE" “Secondaryfuel”. Se
verificación de información.
desconoce si esta información
Presenta las opciones de
debe estar presente.
CANCELAR / ENVIAR A LA
AUTORIDAD.
Opción Debe permitir volver al inicio

7 No hay botón CANCELAR.
"CANCELAR" de la declaración sin enviar.
Debe enviar la declaración DS

Opción "ENVIAR 138. Se debe visualizar listada
8 A LA en DECLARACIONES DEL Ninguna.
AUTORIDAD" ESTABLECIMIENTO con el
estado de ENVIADA.
52
Declaración de Mediciones
En las opciones “VER
Acceso a pantalla con MEDICIONES” y “REGISTRAR
Acceder a fuentes incorporadas en MEDICIONES” se encuentra el
1 "REGISTRAR registro de fuentes y error tipográfico “Contaminate” (en
MEDICIONES" procesos. Presenta opción de el label del formulario).
"REGISTRAR MEDICIÓN" No se muestra ningún diagrama
de descarga.
Acceso a pantalla permite
Seleccionar una ingresar información de la Dentro del formulario, hay un
Fuente y medición por contaminante. placeholder con el texto
2
"REGISTRAR Presenta opción AGREGAR “Comuestos Orgánicos Volátiles
Reporte MEDICIONES" CORRIDA / Select File / (COV)”
de GUARDAR
Medicione
s Incorporar
información y
3 Ninguna.
"AGREGAR
CORRIDA"
Cargar informe
No abre la ventana para elegir un
4 de medición
pdf.
"Select File"
Despliegue de pantalla con

"GUARDAR"
fuentes registradas de indicar
5 Mediciones No guarda la información.
"REGISTRAR MEDICIONES"
agregadas
en verde
Declaración de COV’S
Permite incorporación de
Acceder a
1 Información operacional, Ninguna.
"REGISTRAR COV’S"
estimaciones y mediciones
"BAJAR PLANILLA" Descarga planilla con
para carga de información necesaria para
2 No descarga la plantilla.
información caracterizar la operación (
operacional formulario 3B)
Ventana permite ingreso de

Declaració Completar Planilla y información principal y carga
3 n de COV’S "CARGAR DETALLE de planilla (no aparece planilla)
Ninguna.
OPERACIÓN" / Se presenta enlistada el
"SUBIR" registro de información
operacional actual
Ventana permite ingreso de

información principal y carga
"CARGAR
de informe
4 ESTIMACIÓN" de Ninguna.
Se presenta en listado la
COV’S / "SUBIR"
información de la estimación
registrada
53
Declaración de COV’S
Acceso a pantalla con fuentes
Acceder a incorporadas en registro de Ninguna (Aparece como
5 "REGISTRAR fuentes y procesos. Presenta INGRESAR MEDICIÓN e
MEDICIONES" opción de "REGISTRAR INGRESAR CORRIDA).
MEDICIÓN"
Acceso a pantalla que permite

Seleccionar una ingresar información de la
Fuente y medición por contaminante.
6 Ninguna.
"REGISTRAR Presenta opción AGREGAR
MEDICIONES" CORRIDA / Select File /
GUARDAR
Incorporar información
7 y "AGREGAR Ninguna.
CORRIDA"
Cargar informe de No abre la ventana para

8
medición "Select File" elegir el archivo.
Despliegue de pantalla con

"GUARDAR"
fuentes registradas de indicar
9 Mediciones No guarda la información.
"REGISTRAR MEDICIONES"
agregadas
en verde
Se procedió a realizar los cambios necesarios en el código del sistema, corrigiendo
cada uno de los puntos de error informados por el proceso de QA, a continuación, se
realizaron las pruebas automatizadas y las pruebas manuales de las funcionalidades
corregidas en el servidor de testing, en el proceso mencionado todas las pruebas
resultaron sin errores detectados.
54

QA DC Consultorías II

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

QA DC Consultorías II

Cargado por

Copyright:

Formatos disponibles

Aseguramiento de calidad (QA) para

Sistema de Registro Único de Emisiones

El Reporte Obligatorio con énfasis en los gases de efecto invernadero, se enmarca

El proceso de QA se enmarca dentro de tres etapas, en cada una de ellas se realizan

Etapa de Registro de Fuentes y Procesos: El Registro de Fuentes y Procesos

Etapa de Módulo de Cuantificación de Emisiones: Cada uno de los módulos de

Los objetivos de este proyecto son:

Elaborar una planificación y metodología para analizar, realizar los ajustes y

Proponer y realizar mejoras que se adviertan en relación a la usabilidad y operatividad

Documentar tanto la metodología utilizada en los hallazgos como la subsanación de

Todas las entregas asociadas serán adjuntas mediante un CD y serán compartidas de

Git es un software de control de versiones, pensando en la eficiencia y la confiabilidad

El uso de GIT como método de versionamiento conlleva las siguientes ventajas:

GitLab es un servicio web de control de versiones y desarrollo de software colaborativo

DevOps (development -desarrollo- y operations -operaciones-) es una práctica de

Ciclo de Vida del Proyecto QA

Link herramientas automatizadas para testing: automated-testing-6

Desarrollo guiado por pruebas de software

Ciclo de desarrollo conducido por pruebas

Pruebas de usuario y herramientas de testing

Test-driven development (TDD)

Un servidor provisional o staging, es un tipo de servidor que se utiliza para probar un

Un servidor provisional o staging, principalmente permite ensamblar, implementar y

El servidor de ensayo puede ser un servidor de base de datos de ensayo, un servidor

Se ha elegido, para el despliegue de los sistemas en los ambientes de producción, la

Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones

funcionalidades del kernel y utiliza el aislamiento de recursos (CPU, la memoria, el

Validación de Data y creación de SEEDs de Base de Datos

Pruebas y Validación de la data de Seeding

Revisión e Implementación de validaciones en los Modelos

El principal objetivo de las pruebas de penetración consiste en determinar las

Pruebas de Vulnerabilidad de Datos

Ethical Hacking: La ética hacker es un conjunto de principios morales y filosóficos

4.2 Aseguramiento de Calidad para el Registro de Fuentes y

Ejecución de pruebas en Interfaces de Usuario

Tipo Fuente - Combustible

Ejecución de pruebas de seguridad

Pruebas de acceso a directorios

Shellshock, también conocida como Bashdoor, es una familia de bugs de seguridad

Mitigación y correcciones generales

4.3 Identificar y subsanar brechas de seguridad en el proceso de

Todos los hallazgos y propuestas de mejora identificados deben ser subsanados e

Ejecución de pruebas de seguridad

En cuanto se cuente con un servidor productivo, expuesto a internet, se procederá a

La seguridad de este algoritmo radica en el problema de la factorización de números

Se cree que RSA será seguro mientras no se conozcan formas rápidas de

El código fuente y los scripts de esta solución, se encuentra implementado en los

Pruebas de acceso a directorios

Shellshock, también conocida como Bashdoor, es una familia de bugs de seguridad

El código fuente y los scripts de esta solución, se encuentra implementado en los

4.4 Identificar y subsanar brechas de seguridad en el proceso de

Todos los hallazgos y propuestas de mejora identificados deben ser subsanados e

Ejecución de pruebas de seguridad

El código fuente y los scripts de esta solución, se encuentra implementado en los

Pruebas de acceso a directorios

Shellshock, también conocida como Bashdoor, es una familia de bugs de seguridad

Mitigación y correcciones generales

4.5 Proponer y realizar mejoras que se adviertan en relación a la

Dichas propuestas deberán ser documentadas, tanto la propuesta, su mejora en la

Sigue la práctica TDD (test-driven development) y funciona realizando pruebas desde

Para las pruebas automatizadas se utilizan diversos métodos y funciones de Laravel

● Visit: Redirige al usuario a una página en específico.