Template Activos Neoris

Gestión Integral del Taller
Plan de Testing
1
Indices
1
INDICES
2
2
VERSIONADO
4
3
INTRODUCCIÓN
5
3.1
PROPÓSITO DEL DOCUMENTO
5
3.2
DESTINATARIOS
5
3.3
REFERENCIAS
5
4
AMBIENTES
5
5
HERRAMIENTAS DE PRUEBAS
5
6
ADMINISTRACIÓN DEL TESTING
6
6.1
SEGUIMIENTO Y CONTROL DEL TESTING
6
6.2
REVISIONES DE CASOS DE PRUEBA (PR)
6
6.3
CRITERIOS DE ENTRADA
6
6.4
CRITERIOS DE ACEPTACIÓN (O DE SALIDA)
6
6.5
SUSPENSIÓN Y CAMBIOS EN LOS REQUERIMIENTOS
8
6.6
PROCEDIMIENTO PARA EL REPORTE DE DEFECTOS
8
6.7
PLAN DE TRABAJO DE TESTING
8
6.8
ENTREGABLES
9
6.8.1
CASOS DE PRUEBA
9
6.8.2
ESTADO DE LAS PRUEBAS / REPORTES DE PROGRESO
9
6.8.3
REPORTE FINAL DE LAS PRUEBAS
9
7
7.1
8
ANEXO CONTROL DE CAMBIOS NRO. XX
DESCRIPCIÓN DEL CAMBIO E IMPACTO DEL MISMO
ANEXO METODOLOGÍA DE TESTING
9
9
10
8.1
CONCEPTOS DE TESTING
10
8.2
DESCRIPCIÓN DE LOS TIPOS DE TESTING
11
8.2.1
TESTING DE UNIDAD
11
8.2.2
TESTING FUNCIONAL TRONCAL
12
8.2.3
TESTING DE INTEGRACIÓN
12
8.2.4
TESTING FUNCIONAL
12
8.2.5
TESTING NO FUNCIONAL
12
8.2.6
TESTING DE REGRESIÓN
12
8.2.7
TESTING DE ACEPTACIÓN
12
8.2.8
AUTOMATIZACIÓN DETESTING
13
8.2.9
TESTING DE PERFORMANCE
13
8.3
ALCANCE DEL TESTING
13
8.3.1
GENERACIÓN DE LA DOCUMENTACIÓN
13
8.3.2
NAVEGACIÓN DEL SITIO
13
8.3.3
VERIFICACIÓN DE LOS REQUERIMIENTOS DEL CLIENTE
13
8.3.4
VERIFICACIÓN FUNCIONAL
14
8.3.5
VALIDACIÓN DE DATOS Y MANEJO DE ERRORES
14
8.3.6
COMPATIBILIDAD DE PLATAFORMAS Y NAVEGADORES
14
8.3.7
FORMATO Y PRESENTACIÓN
14
Plan de testing
2 de 15
9
ANEXO SUPUESTOS Y RIESGOS DEL TESTING
14
9.1
SUPUESTOS
14
9.2
RIESGOS
14
Plan de testing
3 de 15
2
Versionado
Versión
Fecha
Plan de testing
Motivo
Autor
4 de 15
3
3.1
Introducción
Propósito del documento
El presente documento contiene el Plan de testing (de aquí en más el Plan) para el proyecto GIT (de aquí
en más, el Proyecto).
El presente Plan describe las actividades que se llevarán a cabo para la realización de las pruebas
que verificarán y validarán la correctitud y completitud del producto de software a desarrollar
durante el Proyecto, además incluye la metodología, preparación de las tareas del Testing,
ambientes de Testing, plan de trabajo, las herramientas del Testing, y la cobertura de tipos de
testing necesaria para verificar los requerimientos funcionales y estéticos del producto a desarrollar
en el proyecto.
La información registrada en este documento servirá de base para la toma de decisiones y el control
interno y externo respecto al proceso de testing del producto de software.
3.2
Destinatarios
Nombre
Milena Massin
Javier Gonzalez
Eugenio Lattanzio
Juan Pablo Hidalgo
3.3
Referencias
Documento
Narrativa
Plan de CM
Planilla de solicitud de Ambientes
4
Rol
Project Manager (PM)
Solution Tester Officer (STEO)
Developer (DEV)
Solution Analyst (SAN)
Quality Assurance (QA)
Fuente
Ambientes
Se define el montaje de los siguientes ambientes:
 Ambiente de testing
 Ambiente de producción (opcional)
Estos ambientes deben responder a los requerimientos de hardware y software de base
especificados en la propuesta.
5
Herramientas de Pruebas
[Adaptar la sección según la herramienta utilizada en el proyecto]
La herramienta que se utilizará como soporte al Testing es QAPM (Quality Assurance Process
Manager), accesible desde http://qapm.ar.neoris.net
Plan de testing
5 de 15
6
Administración del Testing
En las siguientes secciones se describen los procesos para la Administración del Proyecto, la
mecánica y la documentación de las herramientas usadas por el equipo de Testing en la planeación
y ejecución de los tipos de testing para el proyecto <Nombre del proyecto>.
6.1
Seguimiento y Control del Testing
Documentos
Informes de Avances de Testing
Planilla de Pasaje de Ambiente
6.2
Periodicidad
Quincenal
Cada vez que sea necesario
Revisiones de Casos de Prueba (PR)
En lo posible, las personas que realizan los PR deberán tener conocimiento del negocio por haber
participado del proyecto en este momento o en etapas anteriores, o que tengan conocimientos en
negocios o proyectos de complejidades similares.
-
Criterio de selección de la muestra. Se pueden tomar uno o un conjunto de estos criterios:
o Por complejidad del CU (es el más común).
o Porque un CU tuvo varias actualizaciones.
o Por solicitud del Solution Tester (STE) que escribió los casos de prueba complejos/muy
complejos de un CU y necesita corroborar la calidad.
- Controles que se realizan.
Los controles son los que se enumeran en el checklist PR de casos de prueba, más el
cumplimiento de las prácticas propuestas en la nivelación de escritura de casos de prueba
especificadas en el documento INS_STD_SPE_CasosDePruebaBasicos.xls.
- Contabilización de los resultados y su registro.
Las revisiones quedan registradas en la planilla de checklist PR de casos de prueba.
La evidencia se sube al foro de cada proyecto.
6.3
Criterios de Entrada
A continuación se listan los requerimientos que se deben satisfacer para la aceptación del
contenido del proyecto por el equipo de Testing y el comienzo formal de las pruebas de Testing:
Toda la documentación relacionada con los requerimientos y diseños está sujeta a revisiones
constantes para su administración, con la finalidad de tener un control de las versiones hasta llegar
al documento final el cual estará bajo el control de la administración de la configuración.
Todo el hardware, software y herramientas necesarias para el ambiente de pruebas, deben estar
disponibles para su uso.
6.4
Criterios de Aceptación (o de salida)
A continuación se listan los criterios que deben ser satisfechos para la liberación del producto a
producción:
- Todos los casos de prueba estarán ejecutados (los casos de prueba tienen al menos un evento
asociado en un estado final) Los Casos de Prueba que fallaron tendrán un evento asociado donde
se reporta la incidencia/error.
Los estados finales de un evento son:
Plan de testing
6 de 15
o
OK: estado que se asocia a un Evento cuando se ejecuta un Caso de Prueba y no se
produce ningún error.
o Pérdida de Vigencia: cuando un error que había sido reportado, ya no está vigente, es
decir, ya no tiene sentido corregirlo por cambio en la funcionalidad.
o No Aplica Definitivo: este estado es asignado cuando se comprueba que el estado No
Aplica Desarrollo ha sido asignado correctamente a un Evento.
o Cerrado: cuando se comprueba que el error ha sido corregido el error que había sido
reportado.
o Sin valor de referencia para comparar: este estado es asignado a un evento cuando
no se puede realizar la ejecución de un Caso de Prueba debido a que la funcionalidad
que especifica el caso aún no está desarrollada.
Los estados intermedios de un evento que deben llegar a un estado final son:
o Pendiente: es el estado que se asocia a un Evento cuando como resultado de la
ejecución del Caso de Prueba, se produce un error.
o Suspendido: es asignado a un Evento cuando el error es reconocido como tal, pero
por el momento no se procederá a la corrección del mismo porque existen otras tareas
de mayor prioridad que deben realizarse.
o No Corresponde al recurso: este estado es asignado por el DEV cuando la incidencia
asignada no le corresponde corregirla, permitiéndole al PM asignarla al
programador correspondiente.
o No Aplica Desarrollo: cuando el DEV o el PM interpretan que el error reportado no es
tal. Las posibles causas son: inconsistencia en la documentación, factibilidad técnica,
etc.
o Falta Definición Cliente: es cuando para un error reportado no se sabe que acción
seguir, por ejemplo si debe corregirse ó si no aplica, debido a que no hay una definición
clara por parte del Cliente de cuál es el funcionamiento esperado.
o Cerrado: cuando el STE comprueba que el error ha sido corregido, es decir, vuelve a
ejecutar el Caso de Prueba y ya no se produce el error que había sido reportado.
o Corregido: cuando el DEV ha corregido el error, es decir, vuelve a ejecutar el Caso de
Prueba y ya no se produce el error reportado.
o No se pudo reproducir: cuando el DEV ejecuta el Caso de Prueba para reproducir el
error reportado y proceder a su corrección, pero el mismo no se produce.
o Asignado: cuando el PM asigna un DEV al Evento para que éste corrija el error
reportado.
- Todos los problemas que continúan abiertos están siendo revisados por los responsables para
definir el impacto potencial y ser formalmente diferidos con un estimado apropiado. [Puede
suceder que el cliente adelante la liberación de un módulo/funcionalidad, y que todavía no se
hayan cerrado todos los eventos reportados. En este caso se libera dicho módulo al cliente para
que realice la prueba de aceptación aclarando que aún tiene eventos (incidencias, errores)
abiertos. Se hace una nueva planificación considerando el impacto y los riesgos para cerrar los
puntos pendientes. Esta situación puede tener varias causantes, no únicamente el ejemplo que
demos aquí.]
- Todas las fases de Testing completadas. [Planificación de testing ; Ejecución del Testing;
Aceptación del Testing; Revisiones por Pares]
- La solución será entregada y posteriormente probada por el cliente. Los errores resultantes del
Testing de Aceptación se clasifican en distintos niveles de criticidad (Muy Severo, Severo, Muy
Conveniente Resolver, Conveniente Resolver).
Como condición de aceptación, se considera que la solución, un subsistema o un módulo son
aceptables cuando, como resultado de la ejecución del “Test de Aceptación” se encuentre una
distribución en la criticidad de los errores que sigan los siguientes porcentajes respecto a la
totalidad de los casos de prueba:
Plan de testing
Criticidad del Error
% sobre Totalidad de Casos de Prueba
Alta
Media
Baja
0%
1%
5%
7 de 15
Cuando el cliente apruebe la entrega de la solución y su funcionamiento, mediante las cartas de
aceptación, será responsable del uso de la solución.
6.5
Suspensión y cambios en los Requerimientos
Los procesos de prueba se suspenderán y el desarrollador será contactado dadas las siguientes
circunstancias:
-
6.6
Revisión de fallas básicas
Múltiples anomalías de alto nivel de prioridad (Crítico)
Múltiples anomalías de nivel medio que no corresponden a las especificaciones
Procedimiento para el Reporte de Defectos
Se evalúan los casos de prueba con el estado de Ejecutado OK / Ejecutado Error comparando los
resultados obtenidos en la ejecución de los casos de prueba contra los resultados esperados. Si los
resultados obtenidos coinciden exactamente con los resultados esperados descriptos en el caso de prueba,
el caso de prueba tendrá un estado de Ejecutado OK. Si los resultados actuales no coinciden con los
resultados esperados listados en el caso de prueba, el caso de prueba es fallido y tendrá un estado
Ejecutado Error. Cada vez que un caso de prueba queda en estado Ejecutado Error se genera un evento
que debe ser calificado según su criticidad de la siguiente manera:
Criticidad
Alta
Media
Baja
Ninguno
Descripción
Son eventos producto del mal funcionamiento del sistema
impidiendo continuar con su uso.
Son eventos graves que pueden no afectar el funcionamiento del
sistema pero necesitan ser corregidos.
Es un aporte al sistema que mejora la funcionalidad de los
procesos
Indica que el evento no presenta ningún tipo de criticidad
Se define entonces como evento a aquellos pedidos de cambios correctivos que surgen a partir de que un
caso de prueba queda en estado Ejecutado Error.
6.7
Plan de Trabajo de Testing
A continuación se detallan los tipos de testing a realizar en el proyecto GIT y en qué ambientes se llevarán
a cabo.
Tipos de testing
Testing de unidad
Testing de integración
Testing funcional
Testing no funcional
Testing de regresión
Testing de aceptación
Plan de testing
Desarrollo
Ambientes
Testing













Producción






8 de 15
6.8
Entregables
Nombre
Entregables
Descripción




Ubicación








6.8.1 Casos de Prueba
Los casos de prueba son un conjunto de acciones, datos de prueba, y los resultados de la prueba
esperados desarrollados para un objetivo específico de la prueba
El detalle de los Casos de Prueba para el Testing de Unidad se encontrar en una planilla Excel.
6.8.2 Estado de las Pruebas / Reportes de Progreso
Dentro del plan de trabajo de testing se deben establecer regularmente puntos de control para verificar el
progreso. Para cada punto de control un reporte de estado podrá ser consultado en el informe
correspondiente, que incluirá la siguiente la información:
-
Cantidad de casos de prueba definidos
Eventos reportados
Eventos en curso clasificados por criticidad
Eventos clasificados por estado
6.8.3 Reporte Final de las Pruebas
Al completar todas las fases del Testing, se podrán consultar Informes gráficos sobre el estado del mismo,
en el informe correspondiente, que incluirá:
-
7
7.1
Cantidad de casos de prueba definidos
Eventos reportados
Eventos en curso clasificados por criticidad
Eventos clasificados por estado
Informe de Pruebas No Funcionales
Anexo Control de Cambios Nro. XX
Descripción del Cambio e Impacto del mismo
A continuación se especifica el link al gantt del proyecto GIT para llevar el control de las actividades de
testing que deben realizarse: Test de Unidad *2, Testing Funcional Troncal*2, Escritura de Casos de Prueba,
Revisiones de Casos de Prueba*4, Ejecución de Casos de Prueba (Funcionales y de Integración, No
Funcionales *1, Regresión *3, Aceptación) y Ejecución de Pruebas del Cliente *5.
Nota:
*1: Si el Testing No Funcional se va a realizar por más de una estrategia (stress, instalabilidad, etc.) es posible abrir esta actividad
según sea necesario.
Plan de testing
9 de 15
*2: a) Si las piezas de código a testear son realizadas por más de un DEV, es posible encontrar esta actividad por cada DEVs
participante.
b) Para el Testing de Unidad es posible identificar las piezas de código a testear.
*3: Si bien el Testing de Regresión es difícil planificarlo, ya que se debe realizar ante cambios en el sistema, es conveniente
estimar el tiempo del mismo en base a la cantidad de casos de prueba identificados para el mismo y una cantidad estimada de
cambios al sistema.
*4: La identificación de los módulos a revisar debe ser realizada por el STE Coordinator del proyecto en base a la estimación de
tiempos consensuada con el PM en el momento de realizar la propuesta.
*5: La ejecución de las pruebas debe planificarse para cada ciclo de pruebas que el cliente realice.
8
8.1
Anexo Metodología de Testing
Conceptos de Testing
Para clasificar los conceptos de testing se definen:
o
Niveles de testing: los cuales indican el nivel de granularidad del mismo
o
Tipos de testing: Describen un procedimiento con un objetivo concreto, puede realizarse
aplicando una o más estrategias en función de las características a testear.
o
Estrategias: Describen un procedimiento para testear una característica especifica del
objeto del testing.
Son obligatorios los siguientes test: Testing Funcional Troncal, Testing de Integración, Testing de
Sistema y Testing de Aceptación.
El Testing de Unidad se realizará sólo en aquellos casos en los que se exprese la necesidad de
incluirlo.
Niveles de Testing
Testing de Unidad
Testing Funcional Troncal
Testing de Integración
Tipos de Testing
Descripción
Testing de Unidad
Es realizado por el desarrollador. Verifica que el
código de cada componente trabaja de acuerdo a
sus especificaciones y valida la lógica del programa.
Se utiliza la estrategia de caja blanca *1.
Testing Funcional
Troncal
Es ejecutado por el desarrollador. Los casos de
prueba se deben diseñar de forma tal que se recorra
el camino básico de ejecución del módulo y deben
ser identificados en la herramienta de confección de
casos de pruebas. Este testing debe asegurar una
calidad mínima del desarrollo que se entrega a
testing *1.
Testing de
Integración de
primer nivel
Es realizado por el desarrollador. Verifica que las
interfaces entre las componentes y la aplicación
funcionan correctamente y verifica que las interfaces
entre las entidades externas y las aplicaciones
funcionan correctamente. Se puede aplicar una
estrategia no incrementa o incremental (ascendente
o descendente) *1.
Testing de
Integración de
segundo nivel
Es realizado por el tester. Verifica la relación de
integración de funcionalidad que se da entre los
diferentes casos de usos del sistema *1.
Testing Funcional
Es realizado por el tester. Consiste en probar la
funcionalidad de un sistema, a partir de cumplir con
los requerimientos, sin tener en cuenta la forma en
cómo
éste
resuelve
internamente
las
especificaciones. Se utiliza la estrategia de caja
negra *1.
Testing No
Funcional
Es realizado por el tester. Consiste en verificar el
cumplimiento de los requerimientos no funcionales.
Se pueden aplicar los siguiente tipos de estrategias:
Performance (stress, capacidad, estabilidad,
volumen y carga ), configuration, compatibility,
security (caso de prueba sobre los distintos
Testing de Sistema
Plan de testing
10 de 15
permisos de usuarios) installability, usabilidad*1.
Testing de Aceptación
Testing de
Regresión
Es realizado por el tester. Valida, ante un cambio en
el sistema, que las partes del mismo, que no hayan
cambiado continúen funcionando correctamente,
luego de implementada la modificación. Se ejecutan
casos de prueba seleccionados de entre los que se
definieron para Testing Funcional y Testing No
Funcional *1.
Testing de
Aceptación
Es realizado por el cliente y, opcionalmente, puede
ser acompañado del tester. Valida el cumplimiento
de los requerimientos a partir del punto de vista del
usuario. Se ejecutan casos de prueba seleccionados
de entre los que se definieron para Testing de
Sistema *1.
Automatización de Testing
Automatización de
Testing
Testing de Performance
Testing
Performance
de
Es Opcional. Consiste en automatizar tareas
repetitivas como generación de datos, múltiples
regresiones y Workflows.
La automatización de testing permite que estas
mismas tareas realizadas, generalmente por el
tester o el desarrollador, sean realizadas por una
aplicación *1.
La finalidad de realizar pruebas de performance es
predecir anticipadamente problemas de rendimiento
y degradación de recursos del sistema antes de su
paso a producción, y facilitar su corrección *1.
*1: La descripción detallada de los tipos de testing y sus distintas estrategias se describen en el proceso de Testing
La existencia de un proceso de Testing implica que la funcionalidad del sitio y su contenido serán
desarrollados y entregados para pruebas como una serie de entregables de acuerdo con el plan de
trabajo general.
Este acercamiento facilita la integración del Testing dentro del ciclo de vida del proyecto y maximiza
la concurrencia del desarrollo con los esfuerzos de la prueba, mientras minimiza la necesidad de
repetir pruebas. En las fases tempranas del Testing, el énfasis estará en la verificación funcional de
páginas individuales y sus componentes funcionales. Este énfasis cambiará hacia la navegación,
flujo del proceso, y la verificación de la interfase durante el Testing de integración y finalmente la
verificación de la funcionalidad, ejecución y confiabilidad de las pruebas en un caso de prueba endto-end, una vez que se complete la integración del sitio.
El propósito de realizar el testing es:
-
-
8.2
Verificar la conformidad con los requerimientos, ejecutando todos los elementos de la prueba
end-to-end sobre el sistema completo en un ambiente de pruebas (espejo del ambiente de
producción).
Evaluar la eficiencia del sistema para uso operacional por encima de las expectativas de
aceptación del cliente.
Además de comprobar las múltiples funcionalidades del programa, se evaluarán las interfaces
externas y su seguridad.
Descripción de los tipos de Testing
8.2.1 Testing de Unidad
Este tipo de test se enfoca en un segmento relativamente pequeño de código verificando su
correcto funcionamiento y robustez desde el punto de vista interno. Se trata de verificar que la
pieza de software administre correctamente situaciones inverosímiles de ingreso de datos y
operación, a fin de que no finalice imprevistamente.
Plan de testing
11 de 15
Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de
ejecución posibles dentro del código bajo prueba; por lo tanto deben construirlos con acceso al
código fuente de la unidad a testear.
8.2.2 Testing Funcional Troncal
Testing funcional que recorre el camino básico. Es un conjunto de casos de prueba que permiten
asegurar una calidad mínima.
El STEO o STEC define los Casos de Prueba a ejecutar que forman parte del test funcional troncal.
El desarrollador es el responsable de ejecutarlo.
8.2.3
Testing de Integración
1. Test de Interacción de Primer Nivel: es realizado por el desarrollador. El objetivo de las pruebas
de integración es verificar si los componentes o subsistemas interactúan correctamente a través de
sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los
requisitos especificados en las verificaciones correspondientes.
2. Test de Interacción de Segundo Nivel: es realizado por el Tester. El objetivo de estas pruebas es
verificar la relación de integración de funcionalidad que se da entre diferentes casos de uso del
sistema.
8.2.4
Testing Funcional
Consiste en probar la funcionalidad de un programa sin tener en cuenta la forma en cómo éste
resuelve internamente las especificaciones que debe cumplir. El objetivo de esta prueba es
verificar que la pieza de software desarrollada produce los resultados esperados de acuerdo a los
requerimientos.
Los casos de prueba se construyen a partir de los requerimientos del programa, aplicando las
metodologías de caja negra: en esta técnica es posible aplicar distintos métodos por separados o
en combinación.
A) Particiones de equivalencia, B) Análisis de valores límites, C) Gráficos causa-efecto,
D) Conjetura de Errores.
También es posible tener en cuenta valores esperados, valores inválidos (otro tipo de datos) y
valores inesperados.
8.2.5
Testing No Funcional
Estos tests permiten verificar diferentes aspectos no relacionados con la funcionalidad del sistema,
tales como performance, instalación, seguridad (casos de prueba sobre los distintos permisos de
los usuarios) interfaces de usuarios (look and feel) y usabilidad.
Metodológicamente estos tests se ejecutan igual a un test de sistema, en el ambiente de testing,
para probar ciertos aspectos no funcionales del sistema.
8.2.6
Testing de Regresión
Se probará que aquellos programas no afectados por cambios siguen cumpliendo su función
correctamente. También deberán ser probadas las rutinas críticas de programas que hayan sido
modificados, y que no estén alcanzadas por los cambios.
Metodológicamente, este Test tiene la misma estructura que el Test de Funcionalidad, pero los
casos de prueba del mismo son una selección de aquellos que ejercitan las funciones críticas y los
casos de prueba de tests funcionales que detectan errores que ya han dado problemas de
regresión previamente. Puede contener casos de prueba definidos para Testing No Funcional.
8.2.7
Testing de Aceptación
Previa a la puesta en producción, se someterá al producto a un conjunto de casos de prueba que
permitirán certificar la calidad del mismo desde la óptica de los usuarios. Los casos de prueba a
Plan de testing
12 de 15
ejecutar son seleccionados de los definidos para Testing Funcional y es posible incluir casos de
prueba definidos para Testing No Funcional, según sea conveniente.
La ejecución de este test se realizará en conjunto con el cliente.
8.2.8
Automatización deTesting
La automatización de pruebas, o de acciones que realizan los usuarios repetidamente sobre las
aplicaciones, puede realizarse con distintas herramientas de automatización existentes en el
mercado creando paquetes de pruebas mediante scripts para:
-
8.2.9
hacer tareas repetitivas de generación de datos para las pruebas o el cliente.
cargar datos y facilitar la implementación de la aplicación en producción.
detectar rápidamente errores importantes que puedan detener una corrida de pruebas.
correr pruebas diariamente para asegurar que se puede comenzar las pruebas manuales sin
errores bloqueantes.
realizar múltiples regresiones.
hacer pruebas de compatibilidad.
cubrir tests de aceptación del cliente mostrando la funcionalidad de la aplicación y su
estabilidad.
Testing de Performance
El Objetivo del Testing de Performance es predecir anticipadamente problemas de rendimiento y
degradación de recursos del sistema antes de su paso a producción, y facilitar su corrección.
El testing de Performance:
- determina las características de velocidad, escalabilidad y estabilidad de una aplicación.
- se enfoca en determinar si el usuario del sistema va a estar satisfecho con las características
de performance de la aplicación.
- identifica coincidencias entre las expectativas de performance y la realidad
- soporta tunning, capacidad de planeamiento y optimización del trabajo.
Los principales son:
- Stress Testing. Mide como reacciona el sistema luego de que este sobrepasa sus límites o
sufre una caída por sobrecarga. Nos indica como va a reaccionar el sistema cuando este pasa
su límite de funcionamiento.
- Load Testing. Ayuda a definir la máxima carga de trabajo que un sistema puede manejar sin
tener una significante degradación de la performance del mismo. La diferencia con stress
testing es que este último evalúa la medida en que el sistema continúa trabajando cuando se
somete a cargas de trabajo extremas o cuando algunos de su hardware o software se han visto
comprometida.
8.3
Alcance del Testing
A continuación se lista y describe la naturaleza del Testing a realizar y las áreas de concentración.
8.3.1 Generación de la documentación
La generación de los documentos será revisada con exactitud y conforme a los requerimientos
declarados para el proyecto GIT.
8.3.2 Navegación del Sitio
Test de usabilidad: El Testing se ejecutará para verificar la navegación y los destinos correctos de
cada link implementados en cada página. Todos los links rotos o páginas huérfanas se identificarán
y se resolverán.
8.3.3 Verificación de los Requerimientos del Cliente
El Testing se ejecutará para verificar la correcta implementación de todos los requerimientos
funcionales y no funcionales acordados para el proyecto GIT.
Plan de testing
13 de 15
8.3.4 Verificación Funcional
El Testing se ejecutará para asegurar la correcta funcionalidad de los componentes especializados
tales como búsquedas, calculadoras y formas especiales.
8.3.5 Validación de Datos y Manejo de Errores
El Testing se ejecutará para verificar la correcta funcionalidad de los datos de entrada y asegura la
correcta recuperación de datos inválidos, perdidos, u otras condiciones del error.
8.3.6 Compatibilidad de Plataformas y Navegadores
La correcta funcionalidad del software implementado será totalmente verificada en los ambientes
identificados, además de los sistemas operativos y navegadores indicados, que hayan sido
definidos como posibles escenarios donde se ejecute el sistema.
8.3.7 Formato y Presentación
El Testing contemplará la verificación de uniformidad y presentación del formato de acuerdo al
desarrollo creativo del cliente, siguiendo los estándares visuales (loor and feel) establecidos para el
desarrollo del sitio.
9
Anexo Supuestos y riesgos del Testing
9.1
Supuestos
Ésta es una lista de supuestos básicos sobre cómo será administrado el proyecto en lo que afecta al
Testing. Si estos supuestos no se han tomado en cuentas, se volverán riesgos.
- Todos los requerimientos funcionales son definidos sobre la base de las necesidades del usuario.
- El ambiente de Testing es configurado como un espejo del ambiente de producción y acorde con
lo indicado en la propuesta como requerimientos de hardware y software de base en servidores.
- Los DEVs (Developers o equipo de desarrollo) ejecutan pruebas unitarias, indicadas por Testing,
antes de indicar que los módulos están listos para ser testeados..
- El número de casos de prueba y los tipos de tesing a realizar tendrá un impacto directo sobre el
total de tiempo que se toma para la ejecución del plan de pruebas.
- Durante el proceso de Testing, todas las interfaces requeridas están disponibles y accesibles en
el ambiente de Testing.
- Las pruebas se correrán en la versión actual del sistema GIT en el ambiente de Testing.
- El Testing se realizará en un ambiente controlado.
- El grupo de Testing no probará la documentación del usuario.
- Testing asignará la prioridad y la severidad de los defectos sobre la base de un lineamiento
definido con anterioridad.
- El Project Manager (PM) en conjunto con el Solution Tester (STEC) Coordinator desarrollarán el
Plan de Trabajo necesario para ejecutar las pruebas de Testing y su administración.
- El PM será el responsable de la pronta resolución de todos los defectos encontrados.
- La resolución de los defectos no impide que Testing siga haciendo pruebas.
- Suficiente tiempo ha sido considerado dentro del cronograma para todas las fases de Testing a
realizar.
9.2
Riesgos
Ésta es una lista de factores de riesgo que causarían que el proyecto se atrasara o no alcanzará las metas
de calidad.
- Falta de tiempo para ejecutar casos de prueba de los diferentes tipos de testing.
- No se cumplió con los criterios de entrada para comenzar el Testing.
- El documento de los Requerimientos Funcionales o Casos de uso no se actualiza a medida que
se solicitan correcciones de defectos. Por lo tanto los escenarios pueden ser inválidos.
- Desarrollo no incremental de los productos de software. El grupo de Testing recibe el sistema en
grandes bloques y no relacionados entre sí.
Plan de testing
14 de 15
Plan de testing
15 de 15