Qwertyuiopasdfghjklzxcvbnmqwe
rtyuiopasdfghjklzxcvbnmqwertyu
iopasdfghjklzxcvbnmqwertyuiopa
sdfghjklzxcvbnmqwertyuiopasdfg
Instituto Tecnoló gico de Culiacá n
Tecnoló gico Nacional de México
hjklzxcvbnmqwertyuiopasdfghjkl
zxcvbnmqwertyuiopasdfghjklzxcv
bnmqwertyuiopasdfghjklzxcvbnm
qwertyuiopasdfghjklzxcvbnmqwe
rtyuiopasdfghjklzxcvbnmqwertyu
iopasdfghjklzxcvbnmqwertyuiopa
Ensayo
“Practical Software Testing: Defects, Hypotheses and Tests”
Alumno: Miranda Rivas Miguel Ángel
sdfghjklzxcvbnmqwertyuiopasdfg
Pruebas de Software
Profesor: Norma Rebeca Godoy Castro
hjklzxcvbnmqwertyuiopasdfghjkl Grupo;
zxcvbnmqwertyuiopasdfghjklzxcv
Lunes 30 de Septiembre del 2019, Culiacán, Sinaloa.
bnmqwertyuiopasdfghjklzxcvbnm
qwertyuiopasdfghjklzxcvbnmqwe
rtyuiopasdfghjk
Introducción
Durante el desarrollo de software tienden a surgir defectos o errores en el desarrollo del
mismo que, dependiendo durante que etapa sucedan y cuan pronto se detecten, pueden
tener consecuencias de distinta gravedad, desde bugs menores hasta entregar software de
muy baja calidad que afecte al cliente.
Estos pueden surgir de diversas fuentes como la mala comunicación o la poca capacitación
del ingeniero de software. Nomás detectarse, se buscará siempre solucionarlo dicho defecto
a la brevedad, por lo que resulta vital el conocer como lidiar con estos y crear herramientas
para reducir la frecuencia de los mismos y evitar así desviar recursos a su control.
Para ello, es importante conocer cuales son las fuentes comunes de defectos en el software
y que factores los propician para generar estrategias que reduzcan su frecuencia. Esta
información debe estar disponible para consultar y clasificada de forma clara y consistente;
a esto se le llama un repositorio de defectos.
1
Orígenes de Defectos
Los defectos en el software tienen efectos negativos en los usuarios del mismo, por ello, los
ingenieros de software se esfuerzan por producir software de calidad y con el menor
número de defectos. Aún bajo las mejores circunstancias se cometen errores que llevan a la
generación de defectos, estos pueden surgir de las siguientes fuentes:
1. Educación: El ingeniero de software no tuvo la educación suficiente para preparar el
artefacto de software; no sabe cómo hacer algo.
2. Comunicación: Existe mala comunicación dentro del equipo lo que lleva a que
distintas partes del código trabajen mal juntas.
3. Descuido: El ingeniero de software omitió hacer algo por error.
4. Transcripción: El ingeniero de software sabe que hacer, pero comete un error al
hacerlo.
5. Proceso: El proceso utilizado por el ingeniero dirige mal sus acciones, por ejemplo,
dando muy poco tiempo para una de las etapas.
Cuando surge un defecto, por cualquiera de estas circunstancias, el software puede fallar,
impactando al usuario desde con inconvenientes menores a hacerlo inutilizable. Por ello,
nuestra meta como testers es descubrir estos defectos antes de que el software sea
entregado.
Una de las formas en las que se hace estos es diseñando casos de pruebas con alta
probabilidad de revelar defectos. Esto se hace viendo las pruebas de software como una
actividad experimental; se crea una hipótesis de posibles defectos y se realizan pruebas, con
los resultados de estas se analizará si dichos errores existen o no.
Myers nos da una aproximación similar. El compara el rol de el tester al de un doctor que
diagnóstica un paciente conociendo sus síntomas y las enfermedades que podría tener. Así
mismo, el tester debe conocer los posibles defectos para crear hipótesis.
2
Orígenes de Defectos
Las hipótesis se utilizan para:
Diseñar casos de pruebas Crear conjuntos de prueba
Diseñar procedimientos de pruebas Evaluar el resultado de las pruebas
Seleccionar un nivel de prueba apropiado (unidad, integración, etc.)
Un experimento de pruebas exitoso probara que la hipótesis fue correcta, es decir, que el
defecto que se pensaba se encontró, y puede pasar a repararse.
Un modelo de falla (defecto) es la conexión entre el error cometido y el defecto del
software. Estos modelos suelen utilizarse para generar listas o diccionarios de fallas que se
consultan para desarrollar pruebas que estas fallas. La efectividad de estas es la relación
entre la cantidad de defectos esperados y los que se encontraron.
Para incrementar la efectividad de las pruebas y procesos de debugging, organizaciones de
software necesitan crear un repositorio de defectos, que almacene información de defectos
de todos los proyectos en un solo lugar. Para que este funcione debe existir una
clasificación con la que se organicen los reportes donde se clarifica el defecto y las posibles
razones del mismo.
Existen muchas fuertes de información sobre defectos y como catalogarlos, como son
Beizer y el Estándar de Clasificación de Anomalías de Software de la IEEE.
3
Clases de Defectos, el Repositorio de Defectos y el
Diseño de Pruebas
Los defectos pueden clasificarse de muchas maneras, y es importante para las
organizaciones adoptar un esquema de clasificación que aplicar a todos los proyectos. Sin
importar cual sea, algunos defectos pertenecerán a más de una categoría. Debido a esto,
desarrolladores y testers deben tratar de ser consistentes con los datos que recolecten, pues
estos se consultaran para guiar la planeación y el diseño de pruebas. Estas deben
seleccionarse para tener la mayor posibilidad de detectar un tipo particular de defecto.
Los defectos, dependiendo su punto de origen en el desarrollo del software, se asignan a las
siguientes clases:
Requisitos/especificaciones Diseño
Código Pruebas
Esta lista no incluye otro tipo de defectos que se encuentran más eficientemente con las
reseñas de software.
4
Defectos de Requisitos y Especificaciones
El comienzo del ciclo de vida del software es crítico para asegurar que se esta desarrollando
software de calidad. Defectos en las fases tempranas pueden persistir y ser difíciles de
remover en fases posteriores.
Dado que muchos documentos de requisitos se escriben en lenguaje natural es común que
haya especificaciones ambiguas, contradictorias o redundantes.
En los últimos años, muchas organizaciones han introducido el uso de lenguajes formales
para las especificaciones que, junto con herramientas, ayudan a prevenir descripciones
incorrectas de comportamientos del sistema. Algunos defectos específicos de
requisitos/especificaciones son:
1. Defectos de descripción funcional: La descripción de que hace el producto y como
se comporta es incorrecta, ambigua o incompleta.
Para detectarlos, técnicas de pruebas de caja negra que se basen en las especificaciones
funcionales del software son la mejor opción.
2. Defectos de característica: La descripción de las características (lo que hace el
software) está incompleta incorrecta o falta mencionar alguna.
3. Defectos de interacción de característica: Descripciones incorrectas de como
distintas características deben interactuar.
4. Defectos de descripción de interfaz: Fallos relacionados a como el software
interactúa con el software externo, el hardware y los usuarios.
Las pruebas de caja negra pueden planearse al nivel de unidad, integración, sistema y
aceptación para detectar defectos de requisitos/especificaciones.
5
Defectos de Diseño
Los defectos de diseño ocurren cuando componentes del sistema, interacciones entre estos
componentes, interacciones entre los componentes del sistema y el software/hardware
externos o el usuario están diseñados incorrectamente. Si el diseño de módulos no esta
descrito de forma detallada, los defectos aquí descritos evolucionaran en errores de
codificación.
1. Defectos de procesamiento y algorítmicos: Los pasos de procesamiento en el
algoritmo, tal como se describen en seudocódigo, son incorrectos.
2. Defectos de control, lógica y secuencia: El flujo lógico del seudocódigo no es
correcto. Normalmente, por usar operadores lógicos mal.
3. Defectos de datos: Surgen por el diseño incorrecto de las estructuras de datos. Las
reseñas de software y el uso de un diccionario de datos son buenos para detectar
estos defectos.
4. Defectos de descripción de interfaz de módulos: Estos son defectos derivados de
usar parámetros con tipos incorrectos o inconsistentes, que provocan errores al tratar
de comunicarse distintos módulos.
5. Defectos de descripción funcional: La descripción funcional tiene elementos
incorrectos, faltantes o poco claros. Estos defectos se detectan más fácilmente
durante una revisión de diseño.
6. Defectos de descripción de interfaz externa: Estos se derivan de derivan de
descripciones de diseño incorrectas que provocan errores al interactuar con el
hardware u otro software.
6
Defectos de Codificación
Los defectos de codificación se derivan de errores al implementar el código. Están
estrechamente relacionados con los defectos de diseño, en especial si el seudocódigo se uso
para el diseño detallado.
Pueden surgir de fallos al comunicarse con los diseñadores o no entender el lenguaje de
programación plenamente.
1. Defectos algorítmicos y de procesamiento: Estos incluyen, pero no se limitan a,
condiciones de desbordamiento sin chequeos comparar tipos de dato inapropiados y
orden incorrecto de operadores aritméticos.
2. Defectos de control, lógica y secuencia: Son expresiones de declaración de casos
incorrectas, bucles iterativos incorrectos y caminos faltantes.
3. Defectos tipográficos: Errores de sintaxis producidos por un error al escribir. Suelen
detectarse por el compilador.
4. Defectos de inicialización: Declaraciones de inicialización que son omitidas o son
incorrectas. Surgen de la mala comunicación entre los programadores o mal
entendimiento del entorno de programación.
5. Defectos de flujo de datos: Errores en la secuencia operacional en la que los datos
deben utilizarse. Como inicializaciones dobles o faltantes.
6. Defectos de datos: Son implementaciones incorrectas de estructuras de datos, como
declaraciones incorrectas de arreglos o contantes.
7. Defectos de interfaz de módulos: Estos surgen de tipos de parámetro incorrectos o
inconsistentes entre distintos módulos que deben comunicarse o del orden de los
mismo no siendo el correcto.
8. Defectos de documentación de código: Cuando la documentación no refleja
apropiadamente lo que el programa hace se trata de este tipo de error. Puede mal
encaminar a los testers a diseñar pruebas innecesarias.
9. Defectos de interfaz entre software y hardware: Defectos relacionados a problemas
con llamadas al sistema, buses de datos, uso de memoria o intercambio de datos con
el hardware.
7
Defectos de Pruebas
Los planes de pruebas, casos de prueba, arneses de prueba y los procedimientos de prueba
pueden contener defectos. Estos son detectados con mayor facilidad utilizando técnicas de
revisión.
1. Defectos de arneses de prueba (o código andamio): Para las pruebas de software es
necesario crear código auxiliar. Este debe ser diseñado cuidadosamente pues es
código que se reutilizara cuando se desarrollen nuevas versiones del software. Los
arneses de prueba pueden sufrir los mismos tipos de defectos de código y diseño
que otros tipos de software.
2. Defectos de diseño de casos de prueba y procedimiento de pruebas: Estos se
refieren a casos y procedimientos de pruebas incorrectos, incompletos o faltantes.
Estos se detectan sea en la revisión del plan o durante su uso y deben ser reparados.
8
Apoyo del Tester/Desarrollador para Desarrollar
un Repositorio de Defectos
Durante este capítulo, se mostraron algunos de los tipos de defectos más comunes que
ocurren durante el desarrollo de software.
Es importante, si eres miembro de una organización de pruebas, ilustrar a administración y
tus colegas los beneficios de desarrollar un repositorio de defectos donde almacenar
información sobre los mismos.
Debemos seguir el ejemplo de ingenieros en otras disciplinas que se percataron de la
utilidad de la información de defectos.
El desarrollar un repositorio de defectos debe ser parte de las políticas de
pruebas/debugging. Se comienza desarrollando un esquema de clasificación, para entonces
iniciar la recolección de datos de proyectos organizacionales.
Deben ser conscientes de documentar cada
defecto tras las pruebas, así como su
frecuencia. Esto para cada proyecto activo.
Los datos de defectos serán útiles para
planificar pruebas. Además, ayuda a
seleccionar técnicas de prueba apropiadas y
diseñar las pruebas necesarias.
Esta información, nos permitirá estimar
tiempos y costos con precisión. Así como
facilitar el alcanzar y mantener muchas de las
metas de madures TMM.
9
Conclusión
<PENDIENTE; INSERTE CONCLUSIÓN AQUÍ>
10
Fuentes
Burnstein, I. Practical software testing: a process-oriented approach. Springer Science &
Business Media. (2006). Págs. 39 – 58.
11