Está en la página 1de 30

Calidad del Software

Motivación de la importancia de
SQA
Definiciones
• Las pruebas son el proceso de encontrar diferencias
entre el comportamiento esperado (requerido),
especificado por los modelos del sistema, y el
“Se ha concluido el comportamiento observado del sistema (existente).
• Desde el punto de vista del modelado, las pruebas
software. Ahora son un intento de falsificación del sistema con
respecto a los modelos del sistema. “Si los

sólo falta que experimentos no rompen la teoría se fortalece


nuestra confianza en ella”.
• Definimos las pruebas como el intento sistemático de
funcione” localizar errores en forma planeada en el software
implementado (compare con: "las pruebas son el
proceso de demostrar que no hay errores
presentes").
Objetivos
• Sin embargo, las pruebas están orientadas al
quebrantamiento del sistema.
• El objetivo de las pruebas es maximizar la cantidad de
defectos descubiertos
La confiabilidad es una medida del éxito con que el
comportamiento de un sistema se apega a la especificación
de su comportamiento.
La confiabilidad del software es la probabilidad de que un
sistema de software no causará la falla del sistema durante
Panorama de un tiempo especificado bajo condiciones especificadas [IEEE].
La falla es cualquier desviación del comportamiento
las pruebas observado con respecto al especificado.
Un error significa que el sistema está en un estado tal que el
procesamiento adicional del sistema conducirá a una falla, lo
cual causa que el sistema se desvíe del comportamiento
pretendido.
Un defecto es la causa mecánica o algorítmica de un error.
Técnicas de control de calidad

Evitar los Detectarlos


Tolerarlos.
defectos, y
Detecta errores en forma estadística (sin código).
Técnicas:
1. Desarrollo de metodologías
• La suposición de la mayoría de estas técnicas es que el
sistema contiene menos defectos si se maneja la
complejidad con enfoques basados en modelos

Evitar 2. Administración de la configuración


• La suposición es que el sistema contiene mucho menos
defectos. defectos si se controla el cambio.
3. Técnicas de verificación
• trata de encontrar defectos antes de cualquier ejecución
del Sistema. No está en un estado lo bastante maduro.
Supone que los requerimientos son correctos.
4. Revisiones
• la inspección manual de algunos o todos los aspectos del
sistema sin ejecutar, de hecho, el sistema
Se basa en la depuración y las pruebas; son experimentos no
controlados y controlados, respectivamente, que se usan
durante el proceso de desarrollo para identificar errores y
encontrar los defectos subyacentes antes de lanzarse el
sistema.
1. La depuración asume que los defectos pueden
Detectar encontrarse iniciando a partir de una falla no planeada.
• la depuración para corrección. Desviación entre los
defectos requerimientos no funcionales y los especificados
• La depuración del desempeño. Ejemplo, tiempo de
respuesta.
2. La prueba es una técnica de detección de defectos que
trata de crear fallas o errores en forma planeada.
• “Una prueba satisfactoria es la que identifica errores”.
• Las pruebas unitarias encuentran diferencias entre el
modelo de diseño de objetos y sus componentes
correspondientes.
• Pruebas de integración: son las actividades
relacionadas con la localización de defectos cuando
se prueban juntos componentes que se han probado
de manera individual
• Las pruebas estructurales encuentran
diferencias entre el modelo del diseño del
sistema y un subconjunto de subsistemas
integrados.
Pruebas básicas • Las pruebas de sistema prueban todos los
componentes juntos, vistos como un solo sistema
• Las pruebas funcionales encuentran diferencias
entre el modelo de caso de uso y el sistema.
• Las pruebas de desempeño encuentran
diferencias entre los requerimientos no
funcionales y el desempeño real del sistema.
• Las pruebas de aceptación y de instalación.
Revisa los requerimientos contra el acuerdo del
proyecto.
Tolerancia: suponen que puede lanzarse un sistema con
Tolerancia de errores y que las fallas del sistema pueden manejarse
recuperándose de ellas en el momento de la ejecución.
defectos “La tolerancia de defectos es la recuperación de una falla
mientras el sistema está ejecutando”.
Problemas comunes en el
proceso de desarrollo de SW
Cuando se encuentra diferencias:
1. los desarrolladores identifican el defecto que causa la falla
observada y modifican el sistema para corregirlo
2. En otros casos se identifica al modelo como causa de la
diferencia y se actualiza éste para que refleje el estado del
sistema
Las pruebas no son determinantes
Comentarios • Restricciones de tiempo y presupuesto
• Los defectos son descubiertos por los usuarios finales
pertinentes • requerimientos pobres
• calendario irreal
• pruebas inadecuadas
• falta de comunicación
• cambios en los requerimientos después de que el proyecto
ha iniciado.
Se ha visto
las pruebas
como trabajo
Está actitud conduce a
que pueden
realizar los
muchos problemas
principiantes

Comprensión detallada del


Comentarios sistema. Es decir:
pertinentes “desmantelar cosas”
Conocimiento en técnicas
de pruebas, y aplicarlas en
forma eficaz y eficiente.
La figura muestra un par de
vías que no está
Para hablar sobre errores y
fallas necesitamos
comparar el
comportamiento desead
con el comportamiento
Defectos, observado.
Cuando se ejecuta un caso
errores y fallas de prueba podemos
demostrar que el sistema
contiene un defecto.
Defectos algorítmicos
Comunicación
Implementación
Falla mecánica
Objetivos: revela defectos, así
• La validación es el
como uno que se utiliza para
proceso de evaluación de
evaluar los atributos de calidad
un sistema o componente
del software, como
de software durante o al
confiabilidad, seguridad,
final del ciclo de
usabilidad y corrección.
desarrollo para
determinar si satisface
los requisitos
Validación y especificados.
• La verificación es el
verificación proceso de evaluación de
un sistema o componente
de software para
determinar si los
productos de una
determinada fase de
desarrollo satisfacen las
condiciones impuestas al
inicio de esa fase [11].
• También tenga en cuenta que las pruebas y la depuración,
o la localización de fallas, son dos actividades muy
diferentes. El proceso de depuración comienza después de
Testing y que se han realizado las pruebas y el evaluador ha notado
que el software no se comporta como se especifica.
debugging • La depuración o localización de fallas es el proceso de (1)
localizar la falla o defecto, (2) reparar el código y (3) volver
a probar el código.
Es el conjunto de métodos,
prácticas, estándares,
documentos, actividades,
políticas y procedimientos
que los ingenieros de
software utilizan para
desarrollar y mantener un
Procesos en IS sistema de software.

Cómo proceso debe ser


administrado. Es decir
definido y documentado.
Permiten a una organización evaluar su proceso de software
actual y captar la comprensión de su estado.
Mejora incremental del proceso, en consonancia con la
evolución histórica del proceso y la aplicación de los
principios de calidad.
Modelos CMM
Bootstrap
ISO-9000
TMM
Probadores experimentados
Software de mayor calidad
La capacidad de cumplir con los objetivos presupuestarios y
Beneficios de programación
Planificación mejorada
Capacidad de cumplir con objetivos de prueba cuantificables
El CMM está clasificado
arquitectónicamente cómo
un modelo de mejora por
etapas (evolutivo).
Cada etapa indica:
Cómo debe proceder
un organización
Beneficios Conjunto de áreas de
proceso claves en cada
fase.
Procedimiento de
evaluación
Prácticas clave
Opiniones críticas.

1. Gerentes
CV 2. Desarrolladores
3. Clientes y usuarios
Testing y
debugging
• Un componente es una parte del sistema que puede
aislarse para la prueba. Un componente puede ser un
objeto, un grupo de objetos o uno o más subsistemas.
• Un caso de prueba es un conjunto de entradas y resultados
esperados que ejercita a un componente con el propósito
de causar fallas y detectar defectos
• Un stub de prueba es una implementación parcial de
Conceptos componentes de los cuales depende el componente
probado.
• Un manejador de pruebas es una implementación parcial
de un componente que depende del componente probado
• Una corrección es un cambio a un componente.
Un caso de prueba en un sentido práctico es un elemento
relacionado con la prueba que contiene lo siguiente
información:
• Un conjunto de entradas de prueba.
• Condiciones de ejecución.
• Resultados esperados
Una prueba es un grupo de casos de prueba relacionados, o
un grupo de casos de prueba y procedimientos de prueba
Conceptos relacionados (pasos necesarios para llevar a cabo una
prueba).
Un banco de pruebas es un entorno que contiene todo el
hardware y software necesarios para probar un componente
de software o un sistema de software.
Una métrica es una medida cuantitativa del grado en que un
sistema, componente del sistema o proceso posee un
atributo dado.
Una métrica de calidad es una medida cuantitativa del grado en que un
elemento posee un atributo de calidad determinado.
• Correcto: el grado en el que el sistema realiza su función prevista.
• Confiable: el grado en el que se espera que el software realice sus
funciones requeridas en condiciones establecidas durante un período
de tiempo establecido.
• Usabilidad: se relaciona con el grado de esfuerzo necesario para
aprender, operar, preparar la entrada e interpretar la salida del
software
• Integridad: se relaciona con la capacidad del sistema para resistir
ataques intencionales y accidentales.
Conceptos • Portable: se relaciona con la capacidad del software para transferirse
de un entorno a otro
• Mantenible el esfuerzo necesario para realizar cambios en la
interoperabilidad del software, el esfuerzo necesario para vincular o
acoplar un sistema a otro.
• Capacidad de prueba la cantidad de esfuerzo necesario para probar el
software y garantizar que funcione de acuerdo con los requisitos
especificados o la capacidad del software para revelar defectos en
condiciones de prueba.
• Pruebas estáticas y dinámicas
Un principio se puede definir como:
1. una ley, doctrina o suposición general o fundamental;
2. una regla o código de conducta;
3. las leyes o hechos de la naturaleza que subyacen al
Principios funcionamiento de un dispositivo artificial.
En el dominio del software, los principios también pueden
referirse a reglas o códigos de conducta relacionados con los
profesionales que diseñan, desarrollan, prueban y mantienen
sistemas de software.
Principio 1. La prueba es el proceso de ejercitar un
componente de software utilizando un conjunto seleccionado
de casos de prueba, con la intención de (i) revelar defectos y
(ii) evaluar la calidad.
Principio 2. Cuando el objetivo de la prueba es detectar
defectos, entonces un buen caso de prueba es aquel que
tiene una alta probabilidad de revelar defectos aún no
detectados.
Principios Principio 3. Los resultados de las pruebas deben
inspeccionarse meticulosamente.
Principio 4. Un caso de prueba debe contener la salida o el
resultado esperado.
Principio 5. Deben desarrollarse casos de prueba para
condiciones de entrada válidas y no válidas.
Principio 6. La probabilidad de que existan defectos
adicionales en un componente de software es proporcional al
número de defectos ya detectados en ese componente.
Principio 7. Las pruebas deben ser realizadas por un grupo
que sea independiente del grupo de desarrollo.
Principio 8. Las pruebas deben ser repetibles y reutilizables.
Principios Principio 9. Se deben planificar las pruebas.
Principio 10. Las actividades de prueba deben integrarse en
el ciclo de vida del software.
Principio 11. Una prueba es una tarea creativa y desafiante.
Herramientas para confeccionar
y evaluar pruebas.
Confección y evaluación de las
pruebas

También podría gustarte