Sqa
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Sqa as PDF for free.
More details
- Words: 2,820
- Pages: 9
Pruebas de Integración de Productos: Un enfoque práctico Normalmente un producto de software tiene sus procesos de pruebas de integración para verificar que los módulos o componentes que lo conforman funcionan correctamente en conjunto o integrados. 1. PRUEBAS DE INTEGRACION Las pruebas de integración en los proyectos de desarrollo de software, no solo se presentan en la integración entre módulos de un mismo producto sino que se están planteando proyectos que ofrecen soluciones conformadas por varios productos de software, lo cual le da una nueva dimensión al proceso de pruebas de integración. Estas corresponden a las pruebas de integración entre productos, en el cual podríamos considerar los productos como componentes más grandes, sin embargo existen características que las hacen particulares considerando que son productos construidos por empresas diferentes y que obedecen a estándares de construcción diferentes, en as más diversas plataformas (Figura 1). Para el proceso de pruebas de integración se han establecido los siguientes aspectos:
1. Identificar las aplicaciones que forman parte de la solución y su participación en el proceso, es decir la función
2.
3.
4.
de la aplicación dentro de la solución. Cada una de las aplicaciones debe estar certificada funcionalmente, es decir haber concluido los procesos de pruebas funcionales. Es requisito que las aplicaciones hayan finalizado su proceso de pruebas funcionales o al menos hayan logrado un alto nivel de estabilidad ya que si esto no se cumple, durante la ejecución de las pruebas de integración es más difícil establecer la procedencia de las no conformidades identificadas lo que ocasiona desperdicio de tiempo del equipo de trabajo intentando localizar su procedencia. Identificar la forma de acceso e invocación de cada una de las aplicaciones o componentes de la solución, para esto se definen estándares que describen la manera de acceder a las aplicaciones y la ubicación dentro de la pantalla de los puntos de acceso. Validar los estándares de presentación de la solución. Cada una de las aplicaciones deben cumplir con estos estándares, los cuales son definidos por el cliente y normalmente corresponden a la imagen que quiere proyectar. Estos estándares son variables de acuerdo con el cliente, si bien son aspectos que se validan en las pruebas de unidad, como se plantean para un proyecto de integración que varía de cliente en cliente y para un producto terminado estas pruebas se ejecutan como parte de las pruebas de integración. Identificar la interacción entre las aplicaciones, es decir cuales aplicaciones requieren interacción y que mecanismo usará para hacerla. Está interacción se define desde dos puntos de vista: • Sincronización de Datos.
•
Integración Funcional.
Para llevar a cabo adecuadamente estos procesos se requiere: • •
Especificar si en la integración se construirá un repositorio central de datos. Especificar los mecanismos de comunicación entre las aplicaciones.
En lo posible no se debe realizar interacción directa entre cada par de aplicaciones ya que dependiendo del número de productos que participen, aumenta la complejidad del mantenimiento de la solución. Es recomendable el uso de uno o más mediadores que permita estandarizar el mecanismo de integración. 5.
6. 7.
Identificar el mecanismo de autenticación en las aplicaciones. Debe ser un mecanismo unificado para la solución. A pesar de que son varias aplicaciones, la autenticación de usuarios debe realizarse una vez. La administración de usuarios debe realizarse desde una de las aplicaciones y debe ser replicado en forma automática en las demás aplicaciones. Para facilitar el proceso de integración se usa un repositorio central de datos que comparte información entre diferentes aplicaciones. El repositorio central de datos debe validarse de acuerdo con la estructura de las fuentes que lo alimentan.
Material de Estudio (2ª Unidad) - Aci-554
8. Se debe disponer de una herramienta que permita realizar consultas y reportes sobre el repositorio central. 9.
En caso que existan aplicaciones con buscador, este se debe centralizar, es decir definir un buscador sobre el cual se registran los demás buscadores existentes de la aplicación. 10. Validación del cumplimiento de los requerimientos del ambiente de pruebas Integrado. Las versiones del software base de las aplicaciones puede ser muy variado. El ambiente de pruebas debe corresponder al definido por el arquitecto de la solución y se debe verificar que no existan conflictos entre los productos y versiones requeridos para el funcionamiento de cada uno de los productos que integra la solución. 11. Establecer si la solución incluye un instalador único o múltiples instaladores, dependiendo de la complejidad de la solución y del número de aplicaciones que componen la solución, así como la diversidad de software base. 12. La documentación de las soluciones debe tener una apariencia unificada.
Figura 1. Integración de Productos para ofrecer Solución al cliente.
Para garantizar la estabilidad de la aplicación y el cumplimiento de propuestos se plantean las siguientes pruebas :
los requerimientos
Look & Feel A partir de los estándares de presentación definidos sedefinen los requerimientos de pruebas genéricos que se validan en cada una de las aplicaciones que componen la solución. Se lleva registro de los requerimientos ejecutados y los hallazgos obtenidos. En caso que alguno de los requerimientos no aplique sobre alguno de los productos también se deja registro de ello, describiendo las razones por las cuales no se considera dentro del producto. Autenticación Unica de Usuarios Se valida el registro de los usuarios a la solución, la conexión se realiza una vez y este debe ser reconocido en cada una de las aplicaciones de la solución, sin que se solicite nuevamente login y usuario al invocar la ejecución de alguna de ellas. Se debe verificar que los accesos del usuario en cada aplicación corresponden a los definidos en cada producto de la solución. Administración de Usuarios Se validan los requerimientos de administración de usuarios (creación de usuarios, modificación de datos, cambio de password, eliminación de usuarios, activación y desactivación de usuarios).Esta función normalmente se implementa a través del mediador.
Material de Estudio (2ª Unidad) - Aci-554
Operación en Ambiente Integrado Consiste en validar que cada producto funciona adecuadamente en la plataforma definida para la solución, sin que exista conflicto entre el software base instalado e incluso entre las mismas aplicaciones. Para realizar esta validación se realiza la selección de los procesos que se ejecutarán en el ambiente integrado, los cuales no cubren la totalidad de los procesos de la aplicación, sino aquellos de mayor relevancia de acuerdo con el alcance del producto. Esta selección se enfocará en los requerimientos positivos. Se deja a criterio del ingeniero de pruebas la selección de requerimientos negativos si lo considera necesario. Búsqueda Unificada Se validan que a partir de un buscador central se tenga acceso a los buscadores de las demás aplicaciones. Se debe establecer cuales de las aplicaciones tienen buscador y se valida que exista compatibilidad entre los parámetros de búsqueda y que los resultados sean correctos y completos. Repositorio Central de Datos Se realiza validación de la estructura del repositorio central de datos para garantizar que no exista conflicto con los tipos de datos y longitudes de los mismos. El repositorio debe tener en cuenta la estructura de los datos fuentes y destinos para garantizar su correcta operación. Además, debe considerar que los destinos pueden ser múltiples aplicaciones. Visualizador del repositorio central de datos El repositorio central de datos varía de proyecto en proyecto, por lo cual se requiere validar que se puedan realizar consultas y reportes sobre este. Sincronización de Datos Se refiere a la definición de datos comunes entre las aplicaciones, tales como las ubicaciones o zonas geográficas. Es información que maneja más de una aplicación y que debe permanecer sincronizada, por lo que se define una fuente, los destinos y un mecanismo de sincronización para cada destino, que podría ser por equivalencias u homologación. Las pruebas van orientadas a realizar validación de la sincronización de datos, es decir que la replicación de los datos básicos comunes entre aplicaciones se cumpla adecuadamente. Los mecanismos empleados son muy variados y van desde APIs hasta mediadores que permiten configuración flexible de la información.
Integración Funcional Se validan la sincronización a nivel de procesos, es decir la interacción entre los productos a partir de la ejecución de procesos y la transferencia de información a otros procesos. Se deben identificar los procesos de las aplicaciones que interactúan y el mecanismo de intercambio de información. Este puede realizarse a través de interfaces directas entre aplicaciones o mediante el uso de herramientas altamente configurables que actúan como mediadores. Instalador En caso que se construya un instalador único para la aplicación, se debe validar el correcto funcionamiento de este, es decir que realice la instalación de los productos de Material de Estudio (2ª Unidad) - Aci-554
software que componen la solución y el software adicional requerido para su adecuada operación. Adicionalmente, se debe validar que el instalador maneje situaciones de excepción. Documentación en Línea Se realiza la validación de la documentación en línea de acuerdo con los siguientes aspectos: - Look & Feel de la aplicación - Inclusión de funcionalidades relacionadas con integración. - Eliminación de funcionalidades debido a la integración. PRUEBAS NO FUNCIONALES Adicionalmente, dependiendo de las características de la solución se pueden requerir la ejecución de pruebas No Funcionales tales como:
• • • • • •
Pruebas de desempeño (carga) Pruebas de Resistencia (stress) Pruebas de Seguridad Pruebas de Rendimiento Pruebas de Volumen Pruebas de Concurrencia
Material de Estudio (2ª Unidad) - Aci-554
2. EQUIPO DE PRUEBAS El equipo de pruebas involucrado en las pruebas de integración es el siguiente:
• • • • •
Coordinador de Proyectos: Responsable de asegurar la asignación de cumplimiento del plan de pruebas de integración. Líder de Proyecto: Responsable del proceso de pruebas de la solución.
recursos
para
el
Lider de Componente : Un componente agrupa varios productos cuyas funcionalidades se relacionan. El líder de componente es responsable del proceso de pruebas de integración entre las aplicaciones que conforman su componente. Especialista Componente: Actua como consultor del líder de componente y como apoyo al proceso de pruebas de integración. Líder de Producto: Responsable del proceso de pruebas funcionales integración de este con otros productos.
de
su
producto
y
la
Además, cada líder de producto es responsable de validar el cumplimiento del proceso de pruebas para cada uno de los aspectos de integración. Y para cada aspecto se asigna un líder que responde por el proceso completo dentro de la solución.
Líder SQA Aspecto
Look and Feel
Aplicación A
Aplicación B
Material de Estudio (2ª Unidad) - Aci-554
Líder SQA
Líder SQA
Aplicación C
Material de Estudio (2ª Unidad) - Aci-554
Líder SQA
3. METODOLOGÍA DE PRUEBAS Para la realización de las pruebas de integración, se utiliza una metodología de pruebas propias, la cual tiene como etapas: Planeación, Análisis, Diseño y construcción de instrumentos, ejecución de pruebas, control y seguimiento, análisis de resultados y retroalimentación. Se construye una matriz de descomposición funcional para el proyecto de integración, en la cual se relacionan todos los procesos relevantes para la integración y a la cual se asociarán las matrices de requerimientos de cada proceso de integración. Una vez identicazos los aspectos relevantes de la integración se realiza la construcción de matrices de requerimientos de pruebas. Inicialmente se construyen matrices genéricas que son aplicadas sobre cada uno de los productos y se generan las particularidades requeridas. Por ejemplo, una vez definido el diseño gráfico de la aplicación se debe validar en cada una de las aplicaciones que componen la aplicación, con base e la información de los estándares gráficos se construye una matriz genérica, la cual contiene los requerimiento derivados del diseño. Sobre esta matriz es posible que haya que registrar las características particulares de cada aplicación, para lo que se genera una matriz particular. Como estas matrices se deben aplicar sobre cada producto de la solución, es el líder de SQA responsable del producto quién se encarga de realizar las pruebas del aspecto respectivo. Por lo que un aspecto, por ejemplo Look and Feel puede ser validado por ingenieros de SQA diferentes en cada una de las aplicaciones. Existen procesos para los cuales no se requieren matrices particulares por cada aplicación, sino que se genera una única matriz para toda la solución, por lo cual se asigna a un único responsable para el proceso de pruebas. Se construirán matrices genéricas administración de usuarios y buscador.
de
integración
para
la
autenticación de usuarios,
Los instrumentos para prueba para verificación de la operación en ambiente integrado se hace de la siguiente manera: -
-
Se construiye una matriz DF que incluiye una selección de los procesos que se validan. En esta Matriz DF se hace una aclaración que indica que los procesos corresponden a un subconjunto de las funcionalidades del producto. Se selecciona un subconjunto de requerimientos de pruebas para validar los procesos en el ambiente integrado.Esta selección se enfocará en los requerimientos positivos.Se deja a criterio del líder de pruebas la selección de requerimientos negativos si lo considera necesario. Para las pruebas de integración funcional, el líder de pruebas de integración elabora un inventario de pruebas para los procesos. Con base en estos procesos el líder de pruebas de la aplicación a partir de la cual se origina el proceso construye los instrumentos requeridos para las pruebas funcionales y en colaboración con los líderes de las aplicaciones destino ejecutan las pruebas. El responsable del proceso es el líder de pruebas de la aplicación que inicia el proceso de integración funcional.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
7
4. REPORTE DE HALLAZGOS El reporte de No Conformidades identificadas durante el proceso de pruebas de integración se hace teniendo en cuenta las siguientes consideraciones: Es importante identificar a que proceso corresponde la no conformidad, si corresponde a las pruebas integración o funcional. En caso que corresponda a una no conformidad funcional se reporta al correspondiente producto base. Las no conformidades de integración, se reportan a la integración. Para cada uno de los productos creados se crea un componente que corresponde a cada uno de los aspectos a considerar en las pruebas de integración los cuales corresponden a: • Invocación de Aplicaciones • Look and Feel
• • • • • • • •
Autenticación de Usuarios Administración de Usuarios Buscador Sincronización de Datos Integración Funcional Repositorio de Datos Instalador Documentación
Por ejemplo, en caso que las No Conformidades correspondan a la configuración para la sincronización de datos, estas serán reportadas a la sincronización de datos. En caso que las No conformidades correspondan a la estructura del repositorio, serán reportadas al componente Repositorio. Al identificar una no conformidad durante el proceso de pruebas, el ingeniero de pruebas debe identificar la procedencia, es decir cual es la aplicación que genera la no conformidad para que sea reportada a ella. Si no se identifica claramente la procedencia se puede perder tiempo valioso intentando establecer su origen. Las no conformidades se asignan al líder de desarrollo de cada producto que participa en la solución.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
8
5. PLATAFORMA DE PRUEBAS De acuerdo con los requerimientos técnicos de cada uno de los productos que componen la solución, se define el ambiente de la solución y los mecanismos que se usarán para realizar la integración, esto lo realiza el arquitecto de la solución. Dado la diversidad de las plataformas sobre las cuales se implementan los productos, es posible que el ambiente de integración esté formado por una gran variedad de software y diferentes versiones de los mismos. Una vez implementado el ambiente de pruebas, se debe realizar la validación del ambiente de pruebas para garantizar que corresponde al definido. Las versiones de producto no pueden ser alteradas sin la autorización de líder de pruebas de la solución y con la previa aprobación del arquitecto de la solución. En caso de modificaciones en las versiones del software base se debe analizar el impacto de estas en el proceso de pruebas. 6. METRICAS DE INTEGRACION Cada proyecto requerirá unas métricas particulares dependiendo de las características de la solución y lo que se necesite medir. Sin embargo, a nivel general se plantean los siguientes indicadores de integración: 1. Número total de No Conformidades por aspecto (Look & Feel, Integración funcional, sincronización de datos, etc) y por severidad. 2. Número total de No Conformidades correspondientes al proceso funcional e identificadas durante el proceso de pruebas de integración. 3. Desviación de tiempos reales versus tiempos estimados en la planeación de pruebas. 4. Total de Horas Hombres invertidas en las actividades de pruebas. 5. Total de Horas Hombres invertidas por aspecto, por producto y por solución. 6. Tiempos promedios de solución de no conformidades por parte del equipo de desarrollo. 7. Tiempos promedios de validación de no conformidades. 8. Tiempos totales de regresión, es decir el tiempo invertido en pruebas de regresión. 9. Tiempos Promedios de Pruebas de integración por proyecto. 10. Nro de No conformidades por proyecto versus número de productos involucrados en la solución.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
9
1. Identificar las aplicaciones que forman parte de la solución y su participación en el proceso, es decir la función
2.
3.
4.
de la aplicación dentro de la solución. Cada una de las aplicaciones debe estar certificada funcionalmente, es decir haber concluido los procesos de pruebas funcionales. Es requisito que las aplicaciones hayan finalizado su proceso de pruebas funcionales o al menos hayan logrado un alto nivel de estabilidad ya que si esto no se cumple, durante la ejecución de las pruebas de integración es más difícil establecer la procedencia de las no conformidades identificadas lo que ocasiona desperdicio de tiempo del equipo de trabajo intentando localizar su procedencia. Identificar la forma de acceso e invocación de cada una de las aplicaciones o componentes de la solución, para esto se definen estándares que describen la manera de acceder a las aplicaciones y la ubicación dentro de la pantalla de los puntos de acceso. Validar los estándares de presentación de la solución. Cada una de las aplicaciones deben cumplir con estos estándares, los cuales son definidos por el cliente y normalmente corresponden a la imagen que quiere proyectar. Estos estándares son variables de acuerdo con el cliente, si bien son aspectos que se validan en las pruebas de unidad, como se plantean para un proyecto de integración que varía de cliente en cliente y para un producto terminado estas pruebas se ejecutan como parte de las pruebas de integración. Identificar la interacción entre las aplicaciones, es decir cuales aplicaciones requieren interacción y que mecanismo usará para hacerla. Está interacción se define desde dos puntos de vista: • Sincronización de Datos.
•
Integración Funcional.
Para llevar a cabo adecuadamente estos procesos se requiere: • •
Especificar si en la integración se construirá un repositorio central de datos. Especificar los mecanismos de comunicación entre las aplicaciones.
En lo posible no se debe realizar interacción directa entre cada par de aplicaciones ya que dependiendo del número de productos que participen, aumenta la complejidad del mantenimiento de la solución. Es recomendable el uso de uno o más mediadores que permita estandarizar el mecanismo de integración. 5.
6. 7.
Identificar el mecanismo de autenticación en las aplicaciones. Debe ser un mecanismo unificado para la solución. A pesar de que son varias aplicaciones, la autenticación de usuarios debe realizarse una vez. La administración de usuarios debe realizarse desde una de las aplicaciones y debe ser replicado en forma automática en las demás aplicaciones. Para facilitar el proceso de integración se usa un repositorio central de datos que comparte información entre diferentes aplicaciones. El repositorio central de datos debe validarse de acuerdo con la estructura de las fuentes que lo alimentan.
Material de Estudio (2ª Unidad) - Aci-554
8. Se debe disponer de una herramienta que permita realizar consultas y reportes sobre el repositorio central. 9.
En caso que existan aplicaciones con buscador, este se debe centralizar, es decir definir un buscador sobre el cual se registran los demás buscadores existentes de la aplicación. 10. Validación del cumplimiento de los requerimientos del ambiente de pruebas Integrado. Las versiones del software base de las aplicaciones puede ser muy variado. El ambiente de pruebas debe corresponder al definido por el arquitecto de la solución y se debe verificar que no existan conflictos entre los productos y versiones requeridos para el funcionamiento de cada uno de los productos que integra la solución. 11. Establecer si la solución incluye un instalador único o múltiples instaladores, dependiendo de la complejidad de la solución y del número de aplicaciones que componen la solución, así como la diversidad de software base. 12. La documentación de las soluciones debe tener una apariencia unificada.
Figura 1. Integración de Productos para ofrecer Solución al cliente.
Para garantizar la estabilidad de la aplicación y el cumplimiento de propuestos se plantean las siguientes pruebas :
los requerimientos
Look & Feel A partir de los estándares de presentación definidos sedefinen los requerimientos de pruebas genéricos que se validan en cada una de las aplicaciones que componen la solución. Se lleva registro de los requerimientos ejecutados y los hallazgos obtenidos. En caso que alguno de los requerimientos no aplique sobre alguno de los productos también se deja registro de ello, describiendo las razones por las cuales no se considera dentro del producto. Autenticación Unica de Usuarios Se valida el registro de los usuarios a la solución, la conexión se realiza una vez y este debe ser reconocido en cada una de las aplicaciones de la solución, sin que se solicite nuevamente login y usuario al invocar la ejecución de alguna de ellas. Se debe verificar que los accesos del usuario en cada aplicación corresponden a los definidos en cada producto de la solución. Administración de Usuarios Se validan los requerimientos de administración de usuarios (creación de usuarios, modificación de datos, cambio de password, eliminación de usuarios, activación y desactivación de usuarios).Esta función normalmente se implementa a través del mediador.
Material de Estudio (2ª Unidad) - Aci-554
Operación en Ambiente Integrado Consiste en validar que cada producto funciona adecuadamente en la plataforma definida para la solución, sin que exista conflicto entre el software base instalado e incluso entre las mismas aplicaciones. Para realizar esta validación se realiza la selección de los procesos que se ejecutarán en el ambiente integrado, los cuales no cubren la totalidad de los procesos de la aplicación, sino aquellos de mayor relevancia de acuerdo con el alcance del producto. Esta selección se enfocará en los requerimientos positivos. Se deja a criterio del ingeniero de pruebas la selección de requerimientos negativos si lo considera necesario. Búsqueda Unificada Se validan que a partir de un buscador central se tenga acceso a los buscadores de las demás aplicaciones. Se debe establecer cuales de las aplicaciones tienen buscador y se valida que exista compatibilidad entre los parámetros de búsqueda y que los resultados sean correctos y completos. Repositorio Central de Datos Se realiza validación de la estructura del repositorio central de datos para garantizar que no exista conflicto con los tipos de datos y longitudes de los mismos. El repositorio debe tener en cuenta la estructura de los datos fuentes y destinos para garantizar su correcta operación. Además, debe considerar que los destinos pueden ser múltiples aplicaciones. Visualizador del repositorio central de datos El repositorio central de datos varía de proyecto en proyecto, por lo cual se requiere validar que se puedan realizar consultas y reportes sobre este. Sincronización de Datos Se refiere a la definición de datos comunes entre las aplicaciones, tales como las ubicaciones o zonas geográficas. Es información que maneja más de una aplicación y que debe permanecer sincronizada, por lo que se define una fuente, los destinos y un mecanismo de sincronización para cada destino, que podría ser por equivalencias u homologación. Las pruebas van orientadas a realizar validación de la sincronización de datos, es decir que la replicación de los datos básicos comunes entre aplicaciones se cumpla adecuadamente. Los mecanismos empleados son muy variados y van desde APIs hasta mediadores que permiten configuración flexible de la información.
Integración Funcional Se validan la sincronización a nivel de procesos, es decir la interacción entre los productos a partir de la ejecución de procesos y la transferencia de información a otros procesos. Se deben identificar los procesos de las aplicaciones que interactúan y el mecanismo de intercambio de información. Este puede realizarse a través de interfaces directas entre aplicaciones o mediante el uso de herramientas altamente configurables que actúan como mediadores. Instalador En caso que se construya un instalador único para la aplicación, se debe validar el correcto funcionamiento de este, es decir que realice la instalación de los productos de Material de Estudio (2ª Unidad) - Aci-554
software que componen la solución y el software adicional requerido para su adecuada operación. Adicionalmente, se debe validar que el instalador maneje situaciones de excepción. Documentación en Línea Se realiza la validación de la documentación en línea de acuerdo con los siguientes aspectos: - Look & Feel de la aplicación - Inclusión de funcionalidades relacionadas con integración. - Eliminación de funcionalidades debido a la integración. PRUEBAS NO FUNCIONALES Adicionalmente, dependiendo de las características de la solución se pueden requerir la ejecución de pruebas No Funcionales tales como:
• • • • • •
Pruebas de desempeño (carga) Pruebas de Resistencia (stress) Pruebas de Seguridad Pruebas de Rendimiento Pruebas de Volumen Pruebas de Concurrencia
Material de Estudio (2ª Unidad) - Aci-554
2. EQUIPO DE PRUEBAS El equipo de pruebas involucrado en las pruebas de integración es el siguiente:
• • • • •
Coordinador de Proyectos: Responsable de asegurar la asignación de cumplimiento del plan de pruebas de integración. Líder de Proyecto: Responsable del proceso de pruebas de la solución.
recursos
para
el
Lider de Componente : Un componente agrupa varios productos cuyas funcionalidades se relacionan. El líder de componente es responsable del proceso de pruebas de integración entre las aplicaciones que conforman su componente. Especialista Componente: Actua como consultor del líder de componente y como apoyo al proceso de pruebas de integración. Líder de Producto: Responsable del proceso de pruebas funcionales integración de este con otros productos.
de
su
producto
y
la
Además, cada líder de producto es responsable de validar el cumplimiento del proceso de pruebas para cada uno de los aspectos de integración. Y para cada aspecto se asigna un líder que responde por el proceso completo dentro de la solución.
Líder SQA Aspecto
Look and Feel
Aplicación A
Aplicación B
Material de Estudio (2ª Unidad) - Aci-554
Líder SQA
Líder SQA
Aplicación C
Material de Estudio (2ª Unidad) - Aci-554
Líder SQA
3. METODOLOGÍA DE PRUEBAS Para la realización de las pruebas de integración, se utiliza una metodología de pruebas propias, la cual tiene como etapas: Planeación, Análisis, Diseño y construcción de instrumentos, ejecución de pruebas, control y seguimiento, análisis de resultados y retroalimentación. Se construye una matriz de descomposición funcional para el proyecto de integración, en la cual se relacionan todos los procesos relevantes para la integración y a la cual se asociarán las matrices de requerimientos de cada proceso de integración. Una vez identicazos los aspectos relevantes de la integración se realiza la construcción de matrices de requerimientos de pruebas. Inicialmente se construyen matrices genéricas que son aplicadas sobre cada uno de los productos y se generan las particularidades requeridas. Por ejemplo, una vez definido el diseño gráfico de la aplicación se debe validar en cada una de las aplicaciones que componen la aplicación, con base e la información de los estándares gráficos se construye una matriz genérica, la cual contiene los requerimiento derivados del diseño. Sobre esta matriz es posible que haya que registrar las características particulares de cada aplicación, para lo que se genera una matriz particular. Como estas matrices se deben aplicar sobre cada producto de la solución, es el líder de SQA responsable del producto quién se encarga de realizar las pruebas del aspecto respectivo. Por lo que un aspecto, por ejemplo Look and Feel puede ser validado por ingenieros de SQA diferentes en cada una de las aplicaciones. Existen procesos para los cuales no se requieren matrices particulares por cada aplicación, sino que se genera una única matriz para toda la solución, por lo cual se asigna a un único responsable para el proceso de pruebas. Se construirán matrices genéricas administración de usuarios y buscador.
de
integración
para
la
autenticación de usuarios,
Los instrumentos para prueba para verificación de la operación en ambiente integrado se hace de la siguiente manera: -
-
Se construiye una matriz DF que incluiye una selección de los procesos que se validan. En esta Matriz DF se hace una aclaración que indica que los procesos corresponden a un subconjunto de las funcionalidades del producto. Se selecciona un subconjunto de requerimientos de pruebas para validar los procesos en el ambiente integrado.Esta selección se enfocará en los requerimientos positivos.Se deja a criterio del líder de pruebas la selección de requerimientos negativos si lo considera necesario. Para las pruebas de integración funcional, el líder de pruebas de integración elabora un inventario de pruebas para los procesos. Con base en estos procesos el líder de pruebas de la aplicación a partir de la cual se origina el proceso construye los instrumentos requeridos para las pruebas funcionales y en colaboración con los líderes de las aplicaciones destino ejecutan las pruebas. El responsable del proceso es el líder de pruebas de la aplicación que inicia el proceso de integración funcional.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
7
4. REPORTE DE HALLAZGOS El reporte de No Conformidades identificadas durante el proceso de pruebas de integración se hace teniendo en cuenta las siguientes consideraciones: Es importante identificar a que proceso corresponde la no conformidad, si corresponde a las pruebas integración o funcional. En caso que corresponda a una no conformidad funcional se reporta al correspondiente producto base. Las no conformidades de integración, se reportan a la integración. Para cada uno de los productos creados se crea un componente que corresponde a cada uno de los aspectos a considerar en las pruebas de integración los cuales corresponden a: • Invocación de Aplicaciones • Look and Feel
• • • • • • • •
Autenticación de Usuarios Administración de Usuarios Buscador Sincronización de Datos Integración Funcional Repositorio de Datos Instalador Documentación
Por ejemplo, en caso que las No Conformidades correspondan a la configuración para la sincronización de datos, estas serán reportadas a la sincronización de datos. En caso que las No conformidades correspondan a la estructura del repositorio, serán reportadas al componente Repositorio. Al identificar una no conformidad durante el proceso de pruebas, el ingeniero de pruebas debe identificar la procedencia, es decir cual es la aplicación que genera la no conformidad para que sea reportada a ella. Si no se identifica claramente la procedencia se puede perder tiempo valioso intentando establecer su origen. Las no conformidades se asignan al líder de desarrollo de cada producto que participa en la solución.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
8
5. PLATAFORMA DE PRUEBAS De acuerdo con los requerimientos técnicos de cada uno de los productos que componen la solución, se define el ambiente de la solución y los mecanismos que se usarán para realizar la integración, esto lo realiza el arquitecto de la solución. Dado la diversidad de las plataformas sobre las cuales se implementan los productos, es posible que el ambiente de integración esté formado por una gran variedad de software y diferentes versiones de los mismos. Una vez implementado el ambiente de pruebas, se debe realizar la validación del ambiente de pruebas para garantizar que corresponde al definido. Las versiones de producto no pueden ser alteradas sin la autorización de líder de pruebas de la solución y con la previa aprobación del arquitecto de la solución. En caso de modificaciones en las versiones del software base se debe analizar el impacto de estas en el proceso de pruebas. 6. METRICAS DE INTEGRACION Cada proyecto requerirá unas métricas particulares dependiendo de las características de la solución y lo que se necesite medir. Sin embargo, a nivel general se plantean los siguientes indicadores de integración: 1. Número total de No Conformidades por aspecto (Look & Feel, Integración funcional, sincronización de datos, etc) y por severidad. 2. Número total de No Conformidades correspondientes al proceso funcional e identificadas durante el proceso de pruebas de integración. 3. Desviación de tiempos reales versus tiempos estimados en la planeación de pruebas. 4. Total de Horas Hombres invertidas en las actividades de pruebas. 5. Total de Horas Hombres invertidas por aspecto, por producto y por solución. 6. Tiempos promedios de solución de no conformidades por parte del equipo de desarrollo. 7. Tiempos promedios de validación de no conformidades. 8. Tiempos totales de regresión, es decir el tiempo invertido en pruebas de regresión. 9. Tiempos Promedios de Pruebas de integración por proyecto. 10. Nro de No conformidades por proyecto versus número de productos involucrados en la solución.
Material de Estudio (2ª Unidad) - Aci-515, Soporte Internet.
9
Related Documents
Sqa
May 2020 7
Sqa
November 2019 9
Sqa
October 2019 5
Sqa Terms
November 2019 6
Sqa-0602qf
July 2020 9