ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

Planeacion De Pruebas


Enviado por   •  28 de Mayo de 2014  •  1.490 Palabras (6 Páginas)  •  191 Visitas

Página 1 de 6

4.1 Conceptos Introductorios.

Las pruebas de Software es una actividad que se realiza cuyo objetivo es, confirmar si lo que se está probando es lo que el usuario final necesita y sobre todo que todo se encuentre sin errores. Muchas veces el desarrollador no comprende bien los conceptos del analista y realiza una modificación o crea un nuevo módulo que no corresponde a la necesidad actual.

O bien puede pasar el caso de que el desarrollador por querer corregir alguna incidencia no se da cuenta y daña otras partes del sistema que si estaban funcionando.

4.2 Planeación de las Pruebas

En SuKarne tienen un proceso bien definido que abarca desde que se levanta un ticket con alguna incidencia (ya sea error o necesidad) hasta que se libera la incidencia corregida a productivo. Dicho proceso abarca lo que es las pruebas.

Existe una persona encargada del área de Calidad; esta persona se encarga de asignar los tickets con sus respectivas prioridades para la realización de las pruebas.

Él manda un correo semanalmente con los datos de los tickets y con las fechas establecidas para realizar las pruebas correspondientes en esa semana.

4.3 Componentes del Plan de Pruebas

SuKarne se compone de muchas áreas diferentes pero las que se involucran para la corrección de alguna incidencia son:

Mesa de Ayuda: Es el área que se encarga de recibir el reporte de la incidencia que se presente y de generar un “ticket” para que se le dé solución lo más pronto posible.

Esta es la pantalla principal de la página de Mesa de Ayuda.

Aquí se observa un ticket en específico.

1.- Se Observa el Estatus en el que se encuentra y la prioridad.

2.- Se observa una pequeña descripción de la incidencia y la documentación que subió el analista.

3.- Se Observa el Sistema al que corresponde, a quién está asignada la incidencia y demás campos informativos.

En esta pantalla observamos la ruta de dónde el desarrollador va a tomar la porción de código y la ruta de la base de datos a utilizar para realizar la modificación y/o reparación de la incidencia.

Área de Análisis: Mesa de Ayuda pasa la incidencia a esta área para que ellos documenten qué y cómo solucionar el error. Ellos forman el documento de análisis. El cuál se conforma por

1.- Información General:

En Este espacio se llena una tabla con la información básica que debe de contener el documento, Nombre del Proyecto, quién lo desarolló, objetivo, fecha, etc.

Aquí se selecciona si es en un ambiente de desarrollo “Nuevo” o si es algo “Ya Liberado”, qué tipo de Desarrollo es, si es “Nuevo”, si es “Mejora” o si es corrección de un “Error” y la prioridad que tiene el ticket.

En los siguientes puntos del Folio de Análisis se redacta cómo se encuentra actualmente el sistema, la problemática que se presenta, y que posible solución se propone para atacar la incidencia.

Se indica el caso de uso que debe de seguir, si existen condiciones especiales.

Qué reglas de negocio aplican y la descripción del desarrollo.

Área de Desarrollo:

Una vez liberado el Folio de Análisis el Desarrollador toma esa documentación y la utiliza como una guía para atacar la incidencia que se presenta, ya sea corrección de algún error o simple y sencillamente una mejora o un módulo nuevo necesario para el correcto funcionamiento del Nuevo Sistema Comercial.

Al terminar de realizar las modificaciones el desarrollador crea un documento llamado “Folio de Desarrollo”.

Dicho documento consiste en detallar los cambios y/o mejoras que se le hicieron al Sistema.

En el folio de desarrollo se explica la descripción del desarrollo, si se le agregaron nuevas funciones, qué archivos fueron modificados, qué validaciones o recomendaciones se hacen. El o los branchs que se utilizaron para realizar la mejora y/o corrección.

Se observa también que dentro del Folio de Desarrollo se detalla si hubo alguna modificación en algún reporte dentro del código.

A lo que respecta a la base de Datos qué tablas se modificaron, qué vistas, qué procedimientos, meta catálogos, meta campos o archivos de carga inicial.

Al Final el desarrollador realiza sus pruebas unitarias y las documenta para que quede evidencia de que lo que realizó funcionó correctamente.

En las pruebas unitarias queda plasmado

...

Descargar como (para miembros actualizados)  txt (9 Kb)  
Leer 5 páginas más »
Disponible sólo en Clubensayos.com