Analisis Del Proceso de Pruebas de Calidad de Software

Análisis del proceso de pruebas de calidad de software
1. ¿Por qué son necesarias las pruebas?
Los sistemas de software son importantes hoy en día teniéndose en cuenta que son
creadas, desarrolladas y usadas por humanos por lo cual en cualquier etapa de su
desarrollo puede saltar errores y Si no se ha identificado ese defecto y la o las
aplicaciones se ejecutan, hay un alto riesgo de que la aplicación no haga lo que debería
hacer o el objeto para lo cual fue creada, es decir se genera un fallo o desperfecto.
2. Pruebas
Según la norma iso / iec / ieee 24765: 2010 se debe tener en cuenta lo siguiente:
Verificación: Evaluación de un sistema determinando si un producto en una fase de

desarrollo satisface las condiciones impuestas previamente.
Validación: Evaluación de un sistema durante o al final del proceso de desarrollo para
determinar en qué momento satisfacen los requerimientos establecidos.
Con base en esto se da una respuesta respecto a la pregunta: ¿qué es un proceso de
pruebas y para qué implementarlo?
3. Proceso de pruebas.
las pruebas deben estar alineadas al proceso de desarrollo; por ello es importante en
el proceso de pruebas incluir la Revisión de los requerimientos, realización de análisis
documentales, identificación de defectos, pruebas funcionales y no funcionales,
pruebas dinámicas y estáticas, pruebas de integración, informes de confianza en el
nivel de calidad, información para la toma de decisiones, planes de mejora continua.
4. Principios de las pruebas.
Se ha propuesto una serie de principios que permiten establecer unas pautas comunes
para que las empresas de desarrollo de software las conozcan y adapten a sus
procesos
de pruebas.
 Las pruebas demuestran la presencia de defectos.

 Pruebas exhaustivas no existen.
 Pruebas tempranas
 Agrupación de defectos
 Paradoja del pesticida
 Las pruebas dependen del contexto
 Falacia de ausencia de errores
5. Modelo en V en pruebas de calidad de software.
Modelo en V puede tener diferentes niveles de desarrollo en función del proyecto y el
producto software.
Pruebas de componentes: Localizar defectos y comprobar el funcionamiento de

módulos software, programas, objetos, clases, etc., que puedan probarse por
separada.
Pruebas de integración: Probar las interfaces entre los componentes o módulos; como
validación de usuario en el sistema operativo, el sistema de archivos en integración
con el hardware, etc.
Diseño de casos de pruebas teniendo en cuenta los objetos de prueba típicos:
1. Base de datos de subsistemas

2. Infraestructura
3. Interfaces
4. Configuración del sistema
5. Datos de configuración
Pruebas de sistema: Se debe elaborar un plan de pruebas de forma clara y bien

estructurada teniendo en cuenta:
1. Procesos de negocio en sistema completamente integrado

2. Procesos operativos y de mantenimiento.
3. Procedimientos de usuario
4. Formularios
5. Informes
6. Datos de configuración
Pruebas de aceptación: La aceptación de los criterios previstos en un contrato de

desarrollo de software, acordado entre la fábrica de software y el cliente.
Pruebas de backup / restauración: Recuperación de desastres, gestión de usuarios;

tareas de mantenimiento, carga de datos y tareas de migración; comprobaciones
periódicas de vulnerabilidades de seguridad; pruebas de aceptación contractual y
normativa; pruebas alfa y beta.
Teniendo en cuenta la importancia en aplicar el modelo V que se tenga claro por parte
de los probadores o tester la definición de equivocación, defecto o falta y falla.
Clasificaciones de las pruebas: Clasificar las pruebas en funcionales, no funcionales y
estructurales.
Pruebas funcionales: Se orientan en el comportamiento externo de un producto o

aplicativo software, en las pruebas de caja negra.
Pruebas no funcionales: Pruebas necesarias para medir las características de los

sistemas y software que pueden cuantificarse según una escala variable.
Pruebas estructurales: Se debe tener claridad sobre la diferencia al clasificar los tipos
de pruebas, en un análisis sólido del plan de pruebas y a estructurar los casos de
pruebas y creación de la respectiva matriz.
6. Técnicas de caja negra
Partición de equivalencia: Lograr objetivos de cobertura de entrada y salida, con

entradas humanas, vía interfaces a un sistema, o parámetros de interfaz de las
pruebas de integración.
Análisis de valor límite: Se identifica la clase de equivalencia válida por lo tanto

debería ser un valor válido para la aplicación.
Tabla de decisión: Representan relaciones lógicas entre las condiciones y las acciones.
En esta regla se generan condiciones, acciones y reglas para estas.
Máquinas de estado finito: En el sistema se puede mostrar como máquinas de estado

esta forma de modelar permite ver el software en términos de sus estados, las
transiciones entre los estados, las entradas o los acontecimientos que disparan el
cambio de estado y las acciones que pueden resultar de esas transiciones.
Grafo causa efecto: Ayuda a seleccionar, de una manera sistemática los casos de
prueba
Prueba de caso de uso: Las pruebas pueden derivarse de casos de uso. Un caso de uso
describe las interacciones entre los actores, incluyendo usuarios y el sistema Los casos
de uso se pueden definir a nivel abstracto o a nivel del sistema.
Prueba de dominios: Se identifican las variables y las funciones. Las variables pueden
ser de entrada o de salida. Para cada una, se toman pocos valores representativos de
los posibles de la clase de equivalencia para cada clase.

Analisis Del Proceso de Pruebas de Calidad de Software

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

Analisis Del Proceso de Pruebas de Calidad de Software

Cargado por

Copyright:

Formatos disponibles

Análisis del proceso de pruebas de calidad de software

1. ¿Por qué son necesarias las pruebas?

Verificación: Evaluación de un sistema determinando si un producto en una fase de

4. Principios de las pruebas.

 Las pruebas demuestran la presencia de defectos.

Pruebas de componentes: Localizar defectos y comprobar el funcionamiento de

Diseño de casos de pruebas teniendo en cuenta los objetos de prueba típicos:

1. Base de datos de subsistemas

Pruebas de sistema: Se debe elaborar un plan de pruebas de forma clara y bien

1. Procesos de negocio en sistema completamente integrado

Pruebas de aceptación: La aceptación de los criterios previstos en un contrato de

Pruebas de backup / restauración: Recuperación de desastres, gestión de usuarios;

Pruebas funcionales: Se orientan en el comportamiento externo de un producto o

Pruebas no funcionales: Pruebas necesarias para medir las características de los

6. Técnicas de caja negra

Partición de equivalencia: Lograr objetivos de cobertura de entrada y salida, con

Análisis de valor límite: Se identifica la clase de equivalencia válida por lo tanto

Máquinas de estado finito: En el sistema se puede mostrar como máquinas de estado

También podría gustarte