0% encontró este documento útil (0 votos)
114 vistas8 páginas

ISTQB

Las pruebas de software son necesarias para mejorar la calidad y reducir los riesgos de fallos costosos. Dos ejemplos de fallos caros fueron el cohete Ariane 5 que se destruyó debido a un error de software, y una máquina de radioterapia que dio dosis letales a pacientes. Las pruebas ayudan a detectar errores temprano para corregirlos a bajo costo. La calidad de software incluye atributos funcionales como la funcionalidad y no funcionales como la fiabilidad y mantenibilidad

Cargado por

Juanis Romero
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
114 vistas8 páginas

ISTQB

Las pruebas de software son necesarias para mejorar la calidad y reducir los riesgos de fallos costosos. Dos ejemplos de fallos caros fueron el cohete Ariane 5 que se destruyó debido a un error de software, y una máquina de radioterapia que dio dosis letales a pacientes. Las pruebas ayudan a detectar errores temprano para corregirlos a bajo costo. La calidad de software incluye atributos funcionales como la funcionalidad y no funcionales como la fiabilidad y mantenibilidad

Cargado por

Juanis Romero
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

ISTQB

¿Porque son necesarias las pruebas?

La importancia económica del software

- El funcionamiento de maquinaria y equipamiento depende en gran medida de software


- No es posible imaginar grandes sistemas, en el ambito de las finanzas ni el control de trafico
automotor, entre otros, funcionando sin software

Calidad software
- Cada vez mas, la calidad software se ha convertido en un factor determinante del exito de
sistemas técnicos o comerciales y productos

Pruebas para la mejora de la calidad


- Las pruebas y revisiones aseguran la mejora de la calidad de productos software asi como de la
calidad del proceso de desarrollo en si.

Ejemplo de fallo 1: Lanzamiento del Ariane 5


Vuelo 501, tuvo lugar el 4 de junio de 1996, fue la primera prueba de vuelo del sistema desechable
de lanzamiento del Ariane 5. No fue un exito, la lanzadera se destruyo 37 segundos despues del
lanzamiento debido a un mal funcionamiento en el software de control, haciendo del mismo
defecto software uno de los mas caros de la historia. El software del Ariane 5 reutilizo las
especificaciones del Ariane 4,pero la trayectoria de vuelo del Ariane 5 era considerablemente
distinta y superaba el rango para el cual el codigo reutilizado habia sido disenado. En particular, la
mayor aceleracion del Ariane 5
provoco un fallo en los ordenadores de respaldo (“back-up”) y navegacion inercial primarios, tras lo
cual las toberas de la lanzadera fueron dirigidas por datos espurios. Las pruebas previas al vuelo
nunca fueron ejecutadas sobre el codigo reajustado bajo condiciones de vuelo simuladas del Ariane
5, por lo tanto el error no fue descubierto antes del lanzamiento.

Ejemplo de fallo 2: Rayos X letales


Una serie de pacientes recibieron una dosis letal de radiacion debido a un fallo de software:
El Therac-25 era una maquina para radiacion terapeutica
producida por la empresa Atomic Energy of Canada Limited.
Estuvo involucrada con, al menos, seis accidentes conocidos entre 1985 y 1987, en los cuales los
pacientes fueron objeto de una sobredosis masiva de radiacion, que en algunos casos fueron del
orden de centenas de “gray”. Al menos cinco pacientes murieron por sobredosis. Estos accidentes

Página 1
destacan los riesgos del control software de sistemas de seguridad critica (“safety-critical
systems”).

Causas de defectos (“defect”) software


- Error humano
Un defecto ha sido introducido en el codigo software, en los datos o en los parametros de
configuracion
Causas de error humano
Plazos, demandas excesivas debidas a la complejidad,
distracciones
- Condiciones ambientales
Cambios en las condiciones ambientales
Causas de condiciones ambientales negativas/adversas
Radiacion, magnetismo, campos electromagneticos, polucion, manchas solares, fallo de discos
duros, fluctuaciones en el suministro de energia electrica

Error (“Error”) , defecto (“defect”), fallo (“failure”)


- Error (“Error”) (IEEE 610):
Accion humana que produce un resultado incorrecto. [Según IEEE 610]. Ejemplo un error de
programacion
- Defecto (“Defect”):
Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en
desempenar las funciones requeridas, por ejemplo una sentencia o una definicion de datos
incorrectas. Si se localiza un defecto durante una ejecucion puede causar un fallo en el componente
o sistema
- Fallo (“Failure”):
Manifestacion fisica o funcional de un defecto. Si un defecto es encontrado durante la ejecucion de
una aplicacion puede producir un fallo
- Desviacion de un componente o sistema respecto de la prestacion, servicio o resultado esperados.
[Segun Fenton]

Los defectos causan un fallos

El icono del libro en el angulo superior derecho de la diapositiva significa que las definiciones han
sido extraidas del glosario del ISTQB

El papel del proceso de pruebas en el proceso de desarrollo, mantenimiento y operaciones


- Mejora de la calidad de un producto software:
El proceso de pruebas ayuda a suministrar/aportar al software los atributos deseados, por ejemplo
retirar defectos que conducen a fallos
- Reduccion del riesgo de detectar errores:
Actividades de pruebas software adecuadas reduciran el riesgo de encontrar errores durante la
fase de operaciones software
- Satisfacer compromisos:

Página 2
La ejecucion de pruebas puede ser un requisito obligatorio por parte del cliente, debido a normas
legales asi como al cumplimiento de estandares propios de una industria

El coste de los defectos

- El coste de eliminar defectos se incrementa


con el tiempo de permanencia del defecto en el sistema
- La deteccion de errores en etapas tempranas
permite la correccion de los mismos a costes reducidos

Pruebas y la Calidad
- Definicion: Software (segun IEEE 610):
Programas de ordenador, procedimientos y posiblemente documentacion y datos pertenecientes a
la operacion de un sistema basado en un ordenador. [IEEE 610]
- Definicion: Calidad software (segun ISO/IEC 9126): La totalidad de la funcionalidad y
prestaciones de un producto software que contribuyen con su capacidad de satisfacer necesidades
explicitas o implicitas. [Segun ISO 9126]
- Definicion: Calidad (segun IEEE Std 610):
Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o
necesidades y expectativas del usuario/cliente. [Segun IEEE 610]

Pruebas y la Calidad
- De acuerdo a la norma ISO/IEC 9126 la calidad software
consiste en:
- Funcionalidad Atributos funcionales de calidad
- Fiabilidad
- Usabilidad
- Eficiencia Atributos no-funcionales de calidad
- Mantenibilidad

Página 3
- Portabilidad
- Tipos de Aseguramiento de la Calidad (QA):
- Actividades constructivas con el objeto de prevenir defectos, por ejemplo a traves de la aplicacion
de metodos apropiados de ingenieria de software
- Actividades analiticas con el objeto de detectar defectos, por ejemplo a traves de pruebas
conducentes a la correccion de defectos y prevencion de fallos, incrementando asi la calidad del
software

Aseguramiento de la calidad constructivo


Proceso de calidad - Gestion de la calidad

Consigna
- Los defectos evitados no requieren ser reparados
- Los defectos introducidos en el pasado no deben ser repetidos
- Prevenir defectos

Aseguramiento de la calidad analitico


- Calidad de producto – Procedimiento de Verificacion y Pruebas

Página 4
Consigna:
- Los defectos deben ser detectados tan pronto
como sea posible respecto del proceso
- Pruebas estaticas evaluacion sin la ejecucion del programa
- Pruebas dinamicas incluye la ejecucion del programa

Pruebas y la Calidad - Atributos funcionales de calidad


- Funcionalidad significa:
- Correccion: La funcionalidad satisface los atributos / capacidades requeridos
- Completitud: La funcionalidad satisface todos los requisitos (funcionales)
- Funcionalidad (“functionality”) incluye (segun ISO/IEC 9126):
- Adecuacion (“suitability”)
- Exactitud (“accuracy”)
- Interoperabilidad (“interoperability”)
- Seguridad (“security”)
- Cumplimiento de funcionalidad(“functionality compliance”)

Atributos no funcionales de calidad


- Fiabilidad (“reliability”):
- Madurez(“maturity”), tolerancia a defectos (“fault tolerance”), recuperabilidad (“recoverability”),
cumplimiento de fiabilidad (“reliability compliance”)
- Caracteristicas: En determinadas condiciones, el software / sistema mantendra su capacidad /
funcionalidad a lo largo de un periodo de tiempo
- Fiabilidad = Calidad / tiempo
- Usabilidad (“usability”):
- Comprensibilidad (“understandability”), aprendibilidad (“learnability”), operabilidad
(“operability”), atractivo (“attractiveness”), cumplimiento de usabilidad(“usability compliance”)
- Caracteristicas : Facil de usar, facil de aprender, conforme a normas, uso intuitivo
- Eficiencia (“efficiency“):
- Comportamiento del sistema: funcionalidad y respuesta temporal

Página 5
- Caracteristicas: El sistema requiere la utilizacion de un minimo de recursos (por ejemplo tiempo
de CPU) para ejecutar una tarea determinada

- Mantenibilidad (“maintainability”):
- Analizabilidad (“analysability”), modificabilidad (“changeability”),
estabilidad (“stability”), testabilidad (testability”), cumplimiento de
mantenibilidad (“maintainability compliance”)
- Caracteristicas: Medida del esfuerzo requerido para realizar cambios en los componentes de un
sistema
- Portabilidad (“portability”):
- Adaptabilidad (“adaptability”), instalabilidad (“installability”), coexistencia (“co-existence”),
reemplazabilidad (“replaceability”), cumplimiento de portabilidad (“portability compliance”)
- Capacidad del software de ser transferido a un nuevo entorno (software, hardware, organizacion)
- Caracteristicas: Facil de instalar y esinstalar, parametros

Atributos de la calidad

- Algunos atributos de la calidad de un producto software se influyen mutuamente. Debido a esta


interdependencia y en funcion del objeto de prueba, los atributos deberan ser caracterizados por
una prioridad. Por ejemplo eficiencia versus portabilidad
- Se realizaran distintos tipos de pruebas con el objeto de
medir distintos tipos de atributo

- Adquirir conocimiento sobre los defectos en un objeto


de prueba (“test object”)
Los defectos contenidos en un objeto de prueba deben ser detectados y descritos de tal forma que
se facilite su correccion

- Confirmacion de la funcionalidad
La funcionalidad del sistema debe ser implementada tal y como ha sido especificada.

- Generar informacion
Se debe proporcionar informacion relativa a los posibles riesgos relativos a un sistema software
antes de su entrega a los usuarios. La obtencion de esta informacion puede ser uno de los
objetivos de las pruebas

- Ganar confianza
Un sistema software que ha sido probado de forma adecuada se considera que cumple con la
funcionalidad esperada y cuenta con un alto nivel de calidad.

.Cuantas pruebas son suficientes?


- Criterios de salida (“exit criteria”)
- No encontrar (mas) defectos es un criterio apropiado para finalizar las actividades de pruebas. Sin
embargo son necesarias otras metricas para reflejar de forma adecuada el
nivel de calidad alcanzado

- Pruebas basadas en riesgos (“risk-based testing”)

Página 6
El nivel de riesgo determina el grado en el cual se ha probado, es decir: responsabilidad en caso de
fallos, probabilidad de la ocurrencia de fallos, aspectos relativos a factores economicos y propios
del proyecto
- Pruebas basadas en plazos y presupuesto (“time and
budget testing”)
La disponibilidad de recursos: (personal, tiempo, presupuesto) pueden determinar la medida del
esfuerzo del proceso de pruebas

Caso de prueba (“test case”), base de prueba (“test basis”)


- Caso de prueba (“test case”) segun IEEE Std 829:
La definicion de un caso de prueba incluye, al menos, la siguiente informacion (segun IEEE Std 610)
- Precondiciones
- Conjunto de valores de entrada
- Conjunto de resultados esperados
- Poscondiciones esperadas
- Identificador unico
- Dependencia de otros casos de prueba
- Referencia al requisito que sera
- Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados (opcional)
- Prioridad (opcional)
- Base de prueba (“test basis” o “test base”):
Conjunto de documentos que definen los requisitos de un componente o sistema. Utilizado como
fundamento para el desarrollo de casos de prueba.

Desarrollo software y revisiones


- Codigo (“code”), codigo fuente (“source code”):
Programa de ordenador escrito en un lenguaje de
programacion que puede ser leido por una persona
- Depuracion (“debugging”):
Localizacion y correccion de defectos en el codigo fuente
- Desarrollo software (“software development”):

Es un proceso complejo / secuencia de actividades cuyo objetivo es desarrollar un sistema basado


en un ordenador. Normalmente sigue un modelo de desarrollo software.

Desarrollo software y revisiones


- Requisito (“requirement”):
Un requisito describe un atributo funcional deseado o considerado obligatorio
- Revision (“review”) [segun IEEE Std 1028]:

Evaluacion de un producto o del estado de un proyecto para detectar discrepancias respecto de los
resultados planificados y para recomendar mejoras

Resumen:

- Los fallos del software pueden causar importantes danos


- La calidad del software es la suma de los atributos que se refieren a la capacidad del software de
satisfacer un conjunto de requisitos dados
- El aseguramiento de la calidad constructivo se ocupa de la prevencion de defectos

Página 7
- El aseguramiento de la calidad analitico se ocupa de la deteccion y correccion de defectos
- Los atributos funcionales y no funcionales de la calidad definen la calidad total del sistema
- Cada prueba debe contar con criterios de salida (“exit criteria”). Al alcanzar los criterios de salida
concluiran las actividades de prueba.
- Los probadores (“testers”) buscan fallos en el sistema e informan sobre los mismos (proceso de
pruebas - “testing”). Los desarrolladores buscan defectos y los corrigen (depuracion -
“debugging”).

Para practicar para el examen puedes ir a la página: [Link]


[Link]#test

BIBLIOGRAFÍA
WIKIPEDIA
CTFL_2010_Final_V1.10c_ES_040_TRB_UIO_ISTQB.PDF

Página 8

También podría gustarte