|
A |
Adaptabilidad |
(Adaptability,ISO
9126) subcaracterística de portabilidad, que indica las
características del software que influyen en las posibilidades
de adaptación a diferentes entornos especificados, sin
realizar otras acciones que las indicadas para este propósito. |
|
|
Arnés de testeo |
(test harness) un
programa o script que permite la ejecución y la secuenciación
de los casos de test. |
|
|
Artefacto de
software |
(software
artefact) cualquier cosa que resulte del proceso de desarrollo
de software, por ejemplo documentos de requisitos,
especificaciones, diseños, software, etc. |
| |
Aseguramiento de
Calidad |
(Quality
Assurance, ISO 8402, 1994) Todas las actividades planificadas
y sistemáticas necesarias para aportar la confianza suficiente
en que un producto o servicio cumplirá con unos requisitos
dados de calidad. (Those planned and systematic actions
necessary to provide sufficient confidence that a product or
service will satisfy given requirements for quality.) |
| |
Atractivo |
(Attractiveness,ISO 9126) subcaracterística de facilidad de
uso, que indica las características del software que influyen
en la satisfacción de los deseos del usuario y las
preferencias a través de servicios, comportamiento y
presentación más allá de la demanda actual. |
|
B |
Base de testeo |
la información
y/o documentación que se utilice para diseñar los casos de
test |
|
C |
Calidad |
(Quality, ISO
8402, 1994) Conjunto de propiedades y de características de un
producto o servicio, que le confieren su aptitud para
satisfacer unas necesidades explícitas e implícitas. (The
totality of features and characteristics of a product or
service that bear on its ability to satisfy stated or implied
needs.) |
|
|
Cambiabilidad
|
Changeability,ISO
9126) subcaracterística de mantenimiento, que indica la
cantidad de esfuerzo requerido para una modificación o borrado
de un defecto |
|
|
Capacidad de
recuperación |
(Maturity,ISO
9126) subcaracterística de fiabilidad, que indica la capacidad
del sistema para restablecer su nivel de respuesta después de
un fallo crítico o error hardware |
|
|
Capacidad de ser
analizado |
(Analyzability,ISO 9126) subcaracterística de mantenimiento,
que indica la cantidad de esfuerzo requerido para diagnosticar
la causa de un fallo |
|
|
Caso de testeo
|
(test case)
conjunto de entradas, precondiciones para la ejecución y
salidas esperadas desarrolladas con el objetivo de testear
algo concreto del software (ejecutar un camino del programa en
particular, verificar la conformidad de un requisito concreto,
detectar tipos de errores específicos) |
|
|
Cobertura de
decisión |
(decision
coverage) numero de decisiones ejecutadas durante los tests
dividido entre numero total de decisiones en programa |
|
|
Cobertura de
instrucción |
(statement
coverage) numero de instrucciones ejecutadas durante los tests
dividido entre numero total de instrucciones en programa |
|
|
Coexistencia
|
(Co-existence,ISO
9126) subcaracterística de portabilidad, que indica la
capacidad del software de coexistir con otro software
independiente en un entorno común compartiendo recursos |
|
|
Complejidad
Ciclomatica de McCabe |
Si G es un grafo
de flujo, A es la cantidad de arcos en G y N es la cantidad de
nodos en G, la complejidad ciclomatica de McCabe es V(G) = A –
N + 2. |
|
|
Comportamiento
temporal |
(Time
behavior,ISO 9126) subcaracterística de eficiencia, que indica
las características del software que influyen en el tiempo de
respuesta y procesado y productividad cuando se ejecuta su
función |
|
|
Comprensión |
(Understandability,ISO 9126) subcaracterística de facilidad de
uso, que indica las características del software que influyen
en el esfuerzo del usuario para reconocer el concepto lógico y
su aplicación |
|
D |
Defecto |
(Fault, BCS
SIGIST) una manifestación de un error |
|
|
Driver |
es un programa
que invoca un componente bajo testeo, por ejemplo para simular
un componente cuyo código todavía no está disponible (está
todavía en desarrollo) o un componente externo. |
|
E |
Eficiencia |
(Efficiency,ISO
9126) conjunto de características que determinan la relación
entre el nivel de rendimiento del software y el número de
recursos usados, bajo ciertas condiciones dadas. Se divide en
las subcaracteríticas comportamiento temporal, utilización de
recursos |
|
|
Error |
Error, mistake,
BCS SIGIST) una acción humana que puede producir resultados
incorrectos |
|
|
Estabilidad |
(Stability,ISO
9126) subcaracterística de mantenimiento, que indica volumen
de riesgos de efectos inesperados tras una modificación |
|
F |
Facilidad de
aprendizaje |
(Learnability,ISO
9126) subcaracterística de facilidad de uso, que indica las
características software que influyen en el esfuerzo del
usuario para aprender su aplicación (i.e. Control, entrada,
salida) |
| |
Facilidad de
instalación |
(Installability,ISO 9126) subcaracterística de portabilidad,
que indica las características del software que influyen en el
esfuerzo requerido para instalar el software en un entorno
especificado |
|
|
Facilidad de
prueba |
(Testability,ISO
9126) subcaracterística de mantenimiento, que indica la
capacidad del software para permitir que sea validado tras ser
modificado |
| |
Facilidad de uso
|
(Usability,ISO
9126) conjunto de características que influyen en el esfuerzo
requerido para el uso y la evaluación individual de cada uso
por parte de un conjunto de usuarios dados. Se divide en las
subcaracteríticas comprensión, facilidad de aprendizaje,
operabilidad, atractivo |
|
|
Fallo |
(Failure, BCS
SIGIST) una desviación del funcionamiento esperado |
| |
Fiabilidad |
(Reliability,ISO
9126) grado en que el sistema responde bajo las condiciones
definidas durante un intervalo de tiempo dado. Se divide en
las subcaracteríticas madurez, tolerancia a fallos, capacidad
de recuperación |
| |
Funcionalidad
|
(Functionality,ISO 9126) grado en que las necesidades asumidas
o descritas se satisfacen. Se divide en las subcaracteríticas
idoneidad, precisión, interoperabilidad, seguridad |
|
G |
|
|
|
H |
|
|
|
I |
Idoneidad |
(Suitability,ISO
9126) subcaracterística de funcionalidad, que indica el grado
en que las funciones que soportan las tareas especificadas
están presentes |
| |
IEEE 829
|
(IEEE Standard
for Software Test Documentation)Estándar para elaborar la
documentación de testeo de software. |
| |
Inspeccion |
Una revision en
que el líder prepara un “checklist” que sirve como guía de la
reunión y contiene los puntos en que los revisores se tienen
que fijar. El líder distribuye el checklist, el artefacto bajo
testeo y otros materiales a los participantes antes de la
reunión. Los revisores tienen que estudiar el checklist y el
artefacto bajo testeo antes de la reunión. |
| |
Interoperabilidad
|
(Interoperability,ISO 9126) subcaracterística de
funcionalidad, que indica el grado en que el sistema puede
interactuar con otros sistemas |
|
|
ISO\IEC 9126 |
Estándar que
define un modelo de calidad de producto software. |
|
J |
|
|
|
K |
|
|
|
L |
|
|
|
M |
Madurez |
(Maturity,ISO
9126) subcaracterística de fiabilidad, que indica la
frecuencia con que ocurren los fallos |
| |
Mantenimiento
|
(Maintainability,ISO 9126) esfuerzo requerido para implementar
cambios. Se divide en las subcaracteríticas capacidad de ser
analizado, cambiabilidad, estabilidad, facilidad de prueba
|
|
N |
|
|
|
O |
Operabilidad |
(Operability,ISO
9126) subcaracterística de facilidad de uso, que indica las
características del software que influyen en el esfuerzo del
usuario para operar y control operacional |
| |
Outsourcing |
subcontrata de
las partes de procesos relacionados con las TICs para que sean
realizados por empresas externas |
|
P |
Portabilidad
|
(Portability,ISO
9126)conjunto de características que determinan la capacidad
del software para ser transferido de un entorno de operación a
otro. Se divide en las subcaracteríticas adaptabilidad,
facilidad de instalación, coexistencia, reemplazo |
|
|
Precisión |
(Suitability,ISO
9126) subcaracterística de funcionalidad, que indica el grado
de exactitud de los efectos del sistema (i.e. Salida) |
|
|
Punto de
equilibrio. |
Volumen en el que
los ingresos y los costos de una entidad son iguales. |
|
Q |
|
|
|
R |
Revision
|
reuniones de un
grupo definido de personas cuyo objetivo es encontrar errores
en un artefacto de software. Con revisiones para testear
requisitos, diseño, planes, manuales y software Participantes
de los revisiones son: los autores que han escrito el
artefacto; los revisores que tienen que detectar errores; el
secretario que documenta los errores encontrados; el
presentador que expone/explica el artefacto bajo testeo; el
líder que dirige la reunión, elige la fecha para la reunión y
invita a los participantes. Generalmente se distingue 2 tipos
de revisiones: inspecciones (formal) walkthroughs (más
informal) |
|
S |
Seguridad
|
(Security,ISO
9126) subcaracterística de funcionalidad, que indica el grado
en que un acceso no autorizado (accidental o deliberado) se
prevenga y se permita un acceso autorizado |
|
|
Sensitización
|
(Sensitization)
|
| |
Stakeholder |
(Stakeholder)
cualquier persona interesada en, afectada por y/o implicada
con el funcionamiento del sistema software. Por ejemplo, el
usuario, el cliente, nuestra empresa, etc. |
|
T |
Testear software
|
examinar un
artefacto de software con la intención de encontrar defectos
(tal que tus clientes no lo hagan) |
| |
Testeo de
aceptación |
(Acceptance test)
dirigido a los criterios de aceptación previamente
establecidos (por ejemplo con el cliente) |
|
|
Testeo de
aceptación por el usuario (UAT, beta) |
(User acceptance
test) testeo en su entorno real con usuarios reales Fase de
testeo en la empresa cliente. Distribuir una versión gratuita
de testeo |
| |
Testeo de caja
blanca |
(white/clear/transparent box testing) vease testeo de
estructuras |
|
|
Testeo de caja
negra |
(black box
testing) vease testeo de comportamiento |
| |
Testeo de caminos |
(Path testing)
Técnica que permite derivar una estructura de flujo de un
diseño procedural o código y usar esta estructura como una
guía para definir un conjunto básico de casos de test (caminos
de ejecución) |
| |
Testeo de
comportamiento |
(behavioural
testing ) desarrollo de los casos de test se basa en las
funcionalidades y/o el comportamiento que el software tiene
que tener (p.ej. requisitos, especificaciones, conocimiento
del dominio, repositorio de defectos, etc.) |
|
|
Testeo de
configuración |
(configuration
testing) Testeo de un sistema bajo diferentes configuraciones
de:
Hardware: discos duros, impresoras, CPU, sensores, tarjetas
gráficas, tarjetas de sonido
Sistemas operativos y/o versiones de un sistema operativo
Sistemas GUI (p.ej. MS Windows, X-Windos) y sus diferentes
versiones
Bases de datos
etc.. |
|
|
Testeo de estrés
|
(stress testing)
Testeo del comportamiento del sistema bajo cargas muy altas
con el objetivo de romper el sistema y encontrar los límites
del sistema. |
| |
Testeo de
estructuras |
(structural
testing) desarrollo de los casos de test se basa en los
detalles internos de estructura lógica del programa (p.ej.
código fuente, diagramas de flujo de datos/control, etc.) |
| |
Testeo de
integración |
El testing de los
interfaces de y la interacción entre las unidades previamente
testeadas mientras que se ensambla el sistema entero. Hay
varias estrategias para determinar el orden en qué orden vamos
a testear los interfaces: top-down, bottom-up, big-bang, etc. |
|
|
Testeo de
localización |
Testear de un
sistema de software la capacidad de estar configurado con
parámetros de localidad, por ejemplo: diferentes lenguajes,
diferentes conjuntos de caracteres (p.ej. ñ), diferencias en
zona de hora, diferencias en formato de hora y fechas (p.ej.
2pm, 9-30-2004), diferentes teclados, tamaño de papel (A4,
etc). |
|
|
Testeo de
regresión |
Testeo que se
necesita hacer después de cambios en el software para asegurar
que no se ha introducido defectos después de corregir un
error, después de añadir más funcionalidades, o durante el
desarrollo iterativo. |
|
|
Testeo de
rendimiento y carga |
Testeo basado en
los requisitos de rendimiento, por ejemplo utilización de
memoria, tiempo de respuesta (lapso de tiempo que transcurre
entre que un usuario hace una petición y que la respuesta es
recibida por éste) o throughput (cantidad de transacciones
procesadas por periodo de tiempo). |
|
|
Testeo de
seguridad |
Testear de un
sistema de software la capacidad de prevenir acceso no
autorizado. |
| |
Testeo de sistema |
el testing del
sistema entero con el objetivo de encontrar defectos que no
tienen su origen en la interacción de componentes. Puede
incluir testeo de funcionalidad, rendimiento y carga, estrés,
configuración, seguridad, instalabilidad, localización,
usabilidad. |
|
|
Testeo de
software |
el proceso, la
acción y el efecto de testear software. |
|
|
Test exitoso |
un test que
descubre defectos |
|
|
Test harness |
véase Arnés de
testeo |
| |
Testeo unitario
|
El testing de
unidades a componentes de software individuales. En IEEE
Standard Computer Dictionary: Unit testing. En BCS SIGIST:
Component testing. |
|
|
Testware |
cualquier
resultado de los procesos de testeo (casos de test, planes,
scripts, stubs, drivers, etc.) |
|
|
TMAP |
(Test Management
Approach)Metodología que abarca todos los aspectos
concernientes al testeo de software, desde gestión de alto
nivel a detalles del uso de técnicas TMAP. |
| |
TMM |
(Test Maturity
Model) Modelo del Software Engineering Institute (SEI) para la
evaluación y mejora del proceso de test en una organización. |
| |
Tolerancia a
fallos |
(Fault
tolerance,ISO 9126) subcaracterística de fiabilidad, que
indica el grado en que el sistema mantiene un nivel de
respuesta ante fallos del sistema o interfaces |
| |
TPI |
(Test Process
Improvement) Modelo que proporciona una idea general de la
madurez del proceso de testeo en una organización, a partir de
ahí se establecen unos pasos de mejora graduales y
controlados. |
|
U |
Utilización de
recursos |
(Resource
behavior,ISO 9126) subcaracterística de eficiencia, que indica
las características del software que influyen en el número de
recursos usados, y la duración de su uso, cuando se lleva a
cabo su función |
|
V |
Verificación |
“Estamos
construyendo el producto correctamente” (Are we building the
product right) |
|
|
Validación |
“Estamos
construyendo el producto correcto” (Are we building the right
product) |
|
W |
Walkthrough
|
Una revisión que
es menos formal que las inspecciones. El líder se llama
coordinador y es el autor, presentador, secretario. No hay
checklists como en las inspecciones. Walkthroughs se utilizan
más para diseños y código. Durante la reunión los
participantes van paso a paso a través del (pseudo) código
como un tipo de ejecución manual del código donde los
participantes simulan un ordenador. |