Está en la página 1de 27

PRUEBAS Y TESTEO

DE SOFTWARE
Desarrollo de Sistemas 2
Pruebas de Software
• 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.
• Las pruebas son básicamente un conjunto de actividades
dentro del desarrollo de software. Dependiendo del tipo de
pruebas, estas actividades podrán 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.
Pruebas de Software
Permite tener una planeación de la aplicación de las
pruebas y el tipo de pruebas que harán que el sistema
funcione correctamente

Al momento de liberarse por completo, se crea seguridad


en los usuarios finales de que el sistema no fallará

Existen dos actividades fundamentales para la etapa de


pruebas: las pruebas de componentes y las pruebas del
sistema
• En la primera se prueban las partes del sistema por separado
• En la segunda se prueban los componentes ya integrados, el
sistema como un todo
Objetivos del proceso de
pruebas
• Demostrar al desarrollador y al cliente que el software
satisface sus requerimientos. En este caso, se debe tener
por lo menos una prueba para cada requerimiento que
se haya documentado.
• Para describir defectos en el software en el que el
comportamiento de éste es incorrecto.
• Se contemplan comportamientos indeseables en el sistema,
tales como: caídas en el sistema, cálculos incorrectos, entre
otros.
Incluye:
• Objetivo del Plan
• Objetivo de las Pruebas
• Marco del Plan de Pruebas
• Alcance del Plan de Pruebas
• Descripción del módulo para pruebas
• Definición y Desarrollo de pruebas
• Resultados de las Pruebas
• Casos de Prueba:
• Se le llama así al diseño de entradas y salidas esperadas
para probar el sistema. El objetivo de su diseño es crear un
conjunto de casos de prueba que sean efectivos para
descubrir defectos en los programas y muestren que el
sistema cumple con los requerimientos
Incluye…
• Programación de la aplicación de las pruebas
• Cronograma en Project
• Seguimiento y reporte por defectos:
• Se debe contar con un formato en donde se vayan
anotando los defectos encontrados en cada uno de los
módulos del sistema y de forma global, también se
reportarán las correcciones realizadas así como el
responsable de hacerlo con la finalidad de dar un correcto
seguimiento a los resultados de las pruebas
Tipos de pruebas de software

• Todos los tipos de pruebas de software que existen,


básicamente, se pueden agrupar en dos grupos: las pruebas
funcionales y las pruebas no funcionales.
Dentro de las pruebas funcionales tenemos:
• Pruebas unitarias.
• Pruebas de aceptación.
• Pruebas de integración.
• Pruebas de regresión.

Las pruebas no funcionales son:


• Pruebas de carga.
• Pruebas de estrés.
• Pruebas de escalabilidad.
• Pruebas de portabilidad.

Tal vez hayas oído hablar de las pruebas de caja blanca y las pruebas de caja
negra, pero lo que ocurre con las mismas es que no son tipos de pruebas,
sino técnicas de pruebas de software.
• Pruebas funcionales
Las pruebas funcionales se llevan a cabo para comprobar las características críticas
para el negocio, la funcionalidad y la usabilidad. Las pruebas funcionales garantizan
que las características y funcionalidades del software se comportan según lo
esperado sin ningún problema. Valida principalmente toda la aplicación con
respecto a las especificaciones mencionadas en el documento Software
Requirement Specification (SRS). Los tipos de pruebas funcionales incluyen pruebas
unitarias, pruebas de interfaz, pruebas de regresión, además de muchas.

• Pruebas unitarias
Las pruebas unitarias se centran en probar piezas/unidades individuales de una
aplicación de software al principio del SDLC. Cualquier función, procedimiento,
método o módulo puede ser una unidad que se someta a pruebas unitarias para
determinar su corrección y comportamiento esperado. Las pruebas unitarias son
las primeras pruebas que los desarrolladores realizan durante la fase de desarrollo.

• Pruebas de integración
Las pruebas de integración implican probar diferentes módulos de una aplicación
de software como grupo. Una aplicación de software se compone de diferentes
submódulos que trabajan juntos para diferentes funcionalidades. El propósito de
las pruebas de integración es validar la integración de diferentes módulos juntos e
identificar los errores y problemas relacionados con ellos.
• Pruebas no funcionales
Las pruebas no funcionales son como pruebas funcionales; sin embargo, la
principal diferencia es que esas funciones se prueban bajo carga para el
rendimiento de los observadores, fiabilidad, usabilidad, escalabilidad, etc.
Las pruebas no funcionales, como las pruebas de carga y esfuerzo,
normalmente se llevan a cabo mediante herramientas y soluciones de
automatización, como LoadView. Además de las pruebas de rendimiento,
los tipos de pruebas no funcionales incluyen pruebas de instalación,
pruebas de confiabilidad y pruebas de seguridad.

• Performance Testing
Las pruebas de rendimiento son un tipo de pruebas no funcionales,
realizadas para determinar la velocidad, estabilidad y escalabilidad de una
aplicación de software. Como su nombre indica, el objetivo general de esta
prueba es comprobar el rendimiento de una aplicación con respecto a los
diferentes puntos de referencia del sistema y de la red, como la utilización
de la CPU, la velocidad de carga de la página, el control de tráfico máximo,
la utilización de recursos del servidor, etc. Dentro de las pruebas de
rendimiento, hay varios otros tipos de pruebas, como pruebas de carga y
pruebas de esfuerzo.
Diseño del Plan de
Pruebas
• El plan de pruebas de software se elabora para atender los
objetivos de calidad en un desarrollo de sistemas,
encargandose de definir aspectos como por ejemplo los
módulos o funcionalidades sujeto de verificación, tipos de
pruebas, entornos, recursos asignados, entre otros aspectos.
• Un proceso de pruebas formal, está compuesto, cuando
menos por las siguientes 5 típicas etapas:

o Planeación de pruebas.
o Diseño de pruebas.
o implementación de pruebas.
o Evaluación de criterios de salida.
o Cierre del proceso.
Planeación de pruebas
Es la etapa en donde se ejecutan las primeras actividades correspondientes al
proceso de pruebas y tiene como resultado un entregable denominado plan de
pruebas el cual debe estar conformado en cuando menos por aspectos tales
como:

• Alcance de la prueba: determina que funcionalidades del producto y/o


software serán probadas durante el transcurso de la prueba. Este listado de
funcionalidades a probar se extrae con base a un análisis de riesgos realizado
de manera previa, que tienen en cuenta variables tales como el impacto que
podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una
funcionalidad. Producto de este análisis, se cuenta con información adicional
que permite determinar además del alcance detallado del proceso de
pruebas, la prioridad con la que las funcionalidades deben probarse y la
profundidad de las pruebas.
• Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas
requeriría el producto. No todos los productos de software requieren la
aplicación de todos los tipos de pruebas que existen, por esta razón, es
estrictamente necesario que el líder de pruebas se plantee preguntas que le
permitan determinar qué tipos de prueba son aplicables al proyecto en
evaluación. Los posibles tipos de prueba a aplicar son: pruebas de stress,
pruebas de rendimiento, pruebas de carga, pruebas funcionales, pruebas de
usabilidad, pruebas de regresión, entre otros
• Estrategia de Pruebas: teniendo en cuenta que no es viable probar con
base a todas las posibles combinaciones de datos, es necesario
determinar a través de un análisis de riesgos sobre que funcionalidades
debemos centrar nuestra atención. Adicionalmente, una buena
estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que
aplicaremos y la intensidad o profundidad a aplicar para cada nivel de
pruebas definido. En este punto también es importante definir los
criterios de entrada y salida para cada ciclo de pruebas a ejecutar.

• Criterios de Salida: entre las partes involucradas en el proceso, se define


de manera formal, bajo qué condiciones se puede considerar que una
actividad de pruebas fue finalizada. Los criterios de salida se deben
definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de
criterios de salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con éxito, número defectos
críticos y/o mayores aceptados, etc.

• Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se


debe incluir una estimación de tiempos, los roles y/o recursos que
harán parte del proceso, la preparación del entorno de pruebas,
cronograma base, etc.
Diseño de Pruebas
• Una vez elaborado y aprobado el plan de pruebas, el equipo
de trabajo debe iniciar el análisis de toda la documentación
existente con respecto al sistema, con el objeto de iniciar el
diseño de los casos de prueba. Los entregables claves para
iniciar este diseño pueden ser: casos de uso, historias de
usuario, arquitectura del sistema, diseños, manuales de
usuario (si existen), manuales técnicos (si existen). El diseño
de los casos, debe considerar la elaboración de casos
positivos y negativos. Los casos de prueba negativos permiten
validar cómo se comporta el sistema ante situaciones atípicas
y permite verificar la robustez del sistema, atributo que
constituye unos de los requerimientos no funcionales
indispensable para cualquier software. Por último, es
necesario definir cuáles son los datos de prueba necesarios
para la ejecución de los casos de prueba diseñados.
Implementación y Ejecución de
Pruebas
• La ejecución de pruebas debe iniciar con la creación de los
datos de prueba necesarios para ejecutar los casos de prueba
diseñados. La ejecución de estos casos, puede realizarse de
manera manual o automatizada; en cualquiera de los casos,
cuando se detecte un fallo en el sistema, este debe ser
documentado y registrado en una herramienta que permita
gestionar los defectos (Bug Tracker). Una vez el defecto ha
sido corregido por la firma desarrolladora en su respectivo
proceso de depuración, es necesario realizar un re-test que
permita confirmar que el defecto fue solucionado de manera
exitosa. Por último, es indispensable ejecutar un ciclo de
regresión que nos permita garantizar, que los defectos
corregidos en el proceso de depuración de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.
Evaluación de Criterios de
Salida
• Los criterios de salida son necesarios para determinar si es posible
dar por finalizado un ciclo de pruebas. Para esto, es conveniente
definir una serie de métricas que permitirán al finalizar un proceso
de pruebas, comparar los resultados obtenidos contra las métricas
definidas, sí los resultados obtenidos no superan la métricas
definidas, no es posible continuar con el siguiente ciclo de pruebas.

• Existen varios tipos de criterios de salida dentro de los cuales se


pueden mencionar: cubrimiento de funcionalidades en general,
cubrimiento de funcionalidades críticas para el sistema, Número de
defectos críticos y mayores detectados, etc. También es importante
aclarar que el proceso de pruebas puede ser suspendido y/o
paralizado, debido entre otros, a aspectos relacionados con el
presupuesto y la calidad mínima del sistema requerida para el inicio
formal de pruebas.
Cierre del proceso
• Durante este periodo de cierre el cual históricamente se ha
comprobado que se le destina muy poco tiempo en la
planeación, se deben cerrar las incidencias reportadas, se
debe verificar si los entregables planeados han sido
entregados y aprobados, se deben finalizar y aprobar los
documentos de soporte de prueba, analizar las lecciones
aprendidas para aplicar en futuros proyectos, etc.
Casos de prueba
• Un caso de prueba o test case es, en ingeniería del software, un conjunto de condiciones o variables bajo las
cuales un analista determinará si una aplicación, un sistema software (software system), o una característica de
éstos es parcial o completamente satisfactoria.

• Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Con
el propósito de comprobar que todos los requisitos de una aplicación son revisados, debe haber al menos un caso
de prueba para cada requisito a menos que un requisito tenga requisitos secundarios. En ese caso, cada requisito
secundario deberá tener por lo menos un caso de prueba. Algunas metodologías como RUP recomiendan el crear
por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los
requisitos y el otro debe realizar la prueba negativa.

• Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se escriben basados en la
operación normal de programas de una clase similar.

• Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada, los
cuales son formulados antes de que se ejecute la prueba. La entrada conocida debe probar una precondición y la
salida esperada debe probar una postcondición.

• Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba, producir resultados, y luego un
equipo de expertos evaluaría si los resultados se pueden considerar como "correctos". Esto sucede a menudo en la
determinación del número del rendimiento de productos nuevos. La primera prueba se toma como línea base para
los subsecuentes ciclos de pruebas/lanzamiento del producto.

• Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se probará, la cual es tomada ya
sea de los requisitos o de los casos de uso, y la preparación requerida para asegurarse de que la prueba pueda ser
dirigida.
CONTROL DEL PROYECTO
Introducción

El control implica comparar la ejecución con la


planeación

Si se encuentran desviaciones , se debe prever la


acción correctiva necesaria para ejecutarla

Si no se encuentran desviaciones, se continúa con


las siguientes actividades que se tenían previstas
Durante el control:
Se debe ir a la par que la ejecución

Reportar avances

Identificar las desviaciones al Plan

Documentar previamente los cambios de acuerdo al Plan,


proponiendo estrategias para corregir

Registrar las lecciones aprendidas


Herramientas y su uso durante el Control:
A Herramienta ¿Cómo servirá durante el Control?
Alcance WBS Para identificar el trabajo ejecutado y
compararlo contra lo planeado
Al momento de ejecutar, se seguirá
esta estructura para confirmar el
alcance realizado.
Rec. Humanos Matriz de Para monitorear el desempeño de los
Roles y participantes en el proyecto y ajustar
Funciones sus roles y funciones, según sea
requerido.
Comunicación Matriz de Para distribuir la información del
Comunicación proyecto en pro de una comunicación
efectiva.
Tiempo Programa del Monitorear el apego al programa del
Proyecto proyecto e identificar desviaciones y
corregirlas.
Riesgos Matriz de Confirmar el seguimiento a la matriz y
Admón. de tomar la acción requerida.
Riesgos
CIERRE DEL PROYECTO
Introducción
Una vez que el proyecto ha llegado a su término, se debe continuar
con el cierre

Esta fase se considera importante entregar una serie de documentos


con la finalidad de realizar una entrega ordenada y formal de toda la
información generada durante el desarrollo del proyecto, así como dar
por concluido los acuerdos legales (si existieron) y las evaluaciones de
desempeño.

De acuerdo con esto existen dos tipos de cierre: el contractual y el


administrativo
Cierre del proyecto
• Dentro del cierre administrativo se deben incluir una
serie de documentos (CHAMOUN, 2002) tales como:
• Reporte Final: Permite de una manera rápida tener un
panorama de la información más importante del
proyecto, algunos documentos que incluye son:
• Presupuesto Final
• Programa Final
• Directorio de participantes
• Cartas de cierre para los patrocinadores y gerentes del
proyecto
• Reporte de control de cambios, entre otros.
Cierre…
• Programa de desfase del equipo:
• Este documento permitirá no generar estrés entre los
participantes durante las fases finales del proyecto debido a la
incertidumbre de la permanencia en el trabajo, o por involucrarse
en otro tipo de situaciones externas al proyecto.
• Aspectos como la salida del equipo, evaluaciones sobre su
desempeño, entregas finales antes del despido, son algunos
ejemplos de lo que se puede incluir.
• Archivos del proyecto:
• Se pueden entregar de forma impresa y ordenada en carpetas así
como de manera electrónica. Algunos documentos a incluir son el
plan del proyecto, bases de datos actualizadas (si se cuenta con
ellas), lecciones aprendidas, contratos, entre otros.

También podría gustarte