Conceptos bsicos de pruebas de software

1.

Definicin de conceptos bsicos: defecto, error, bug, falla, incidente, etc

Defecto.- Existen dos terminologas que describen lo que es un defecto.

Defecto basado en propiedad: Direcciona la ausencia de una propiedad garantizada en un
software, en este caso un defecto esta estticamente ligado al cdigo del programa, el cual
no cumple con los rendimientos especificados.
Defecto basado en riesgo: Pueden ser derivados de la judicatura de la responsabilidad del
producto, es decir, un software defectuoso genera riesgos pudiendo causar daos
potenciales, adems de presentarse como un uso inadecuado del software.
Fallas.- Se los conocen tambin como defectos, que para su fcil comprensin y para evitar
confusiones ante usuarios del software, se prefiere llamarlos fallas.
Bug.- Describen una caracterstica no deseada del programa desde un punto de vista del
usuario, a su vez Bug subsume el trmino de defecto por lo que un Bug puede ser causado
por varios defectos del programa, o varios bugs son responsables de un defecto del
programa.
Errores.- Describen una equivocacin en el ciclo de vida de un software que conduce a un
resultado incorrecto. Generalmente causada por los desarrolladores del software,
incurriendo a equivocaciones humanas o por su falta de comprendimiento en el ambiente
de programacin.
Fracasos.- Resultado inesperado en la ejecucin de un programa, el fracaso apunta a la
existencia de un defecto. Los defectos son estticos mientras que los fracasos son
dinmicos. Ocasionalmente detectados cuando se enva datos de input al programa.
Incidente.- Condicin que viola la especificacin de un programa. La causa puede ser
externa como un ambiente de pruebas en mal estado, una herramienta de pruebas errnea,
errores mientras se realiza la prueba, o insuficientes derechos de usuario del que realiza
las pruebas.
Caso de prueba.- Descripcin de una prueba atmica, por medio de parmetros de
entrada, condiciones de ejecucin y resultados esperados. Las condiciones de ejecucin son
requeridas para preparar el programa para pruebas.
2.

Qu son pruebas de software y sus objetivos

El testingo pruebas de software puede definirse como el proceso de observar, analizar y

registrar resultados de la funcionalidad, performance o calidad del sistema o de un
componente del mismo, en condiciones especficas.
El objetivo principal de las pruebas de software es encontrar fallas. En objetivos ms
especficos se incluyen seguridad, aplicabilidad, continuidad, capacidad de control,
funcionalidad, usabilidad, integrabilidad, performance y eficiencia. Estos objetivos son:
Disminuir costos para remover defectos.
Disminuir costos de causas de defectos (Debido a un fallo del sistema).
Evaluar la calidad del software.
Satisfacer normas y leyes.
Evitar demandas y problemas relacionados con los clientes.
Aumentar la confiabilidad en el software desarrollado o en una empresa que
desarrolle productos de software.
Soportar debugging (depuracin) de la mejor manera posible.

3.

Planificacin de pruebas de software vs. ejecucin de las pruebas de software

La planificacin de pruebas de software es una etapa que consiste en seleccionar los

productos de trabajo que van a ser probados, elegir el entorno de pruebas y tambin se
decide los criterios y procedimientos que sern aplicados en las pruebas . [5]
En cambio la ejecucin de pruebas, utiliza los requerimientos y criterios de la planificacin
para realizarla sobre el software, consiste en realizar interacciones de pruebas y en cada
una de ellas registrar los hallazgos, errores o no conformidades del software. Esta etapa
debe realizar el mayor nmero de iteraciones y regresiones de prueba para poder verificar
que se encuentre el menor nmero de inconformidades en el software.[6]
En conclusin en la fase de Planificacin de pruebas se determina de qu manera se va a
probar al software y a cules componentes , y en la parte de ejecucin se realiza estos
procedimientos en iteraciones para poder comprobar que tanto se diferencia el software
planificado del real.

4.

Pruebas de software y ciclo de vida del proyecto de software (modelo V)

El ciclo de vida de un proyecto de software en el modelo V consiste de las siguientes fases:

Anlisis y levantamiento de requerimientos
Diseo del sistema
Implementacin

 Testeo
Mantenimiento
Las pruebas de software en el modelo V es la fase de testeo del ciclo de vida del mismo, el
cual consiste en algunas fases, que sern enumeradas a continuacin:
1. Prueba de Componente (Conocida como prueba unitaria)
Se realiza pruebas de cada componente para verificar si ests ya estn listas para
ser usadas
2. Prueba de Componente Central
Esta fase de prueba a diferencia de la primera, se testea con un sistema similar al
que se est elaborando
3. Prueba de Integracin
Es una prueba que no es realizada dentro de las estaciones de trabajo de los
desarrolladores pero permiten integrar el sistema para verificar la funcionalidad.
4. Prueba de Rendimiento
Una primera prueba de rendimiento que puede ser opcional, en la que se efectan
las primeras visualizaciones de cuellos de botella del sistema actual.
5. Pruebas de Sistema
Esta prueba es ms extensa que la de integracin en la cual se centra menos en
menor parte en lo tcnico. Son usadas por usuarios que no tienen conocimiento del cdigo
fuente del sistema.
6. Prueba de Rendimiento
Est prueba consiste en verificar el rendimiento del sistema, realizada por personas
que no son los desarrolladores del mismo, para conocer las limitaciones de los algortimos,
etc.
7. Prueba de Aceptacin
Aqu los clientes son los encargados de hacer la prueba y dar una pequea
conclusin si est .
8. Prueba Piloto
Prueba en la que se tienen clientes claves para la instalacin del sistema casi
finalizados para poder dar los ltimos retoques del mismo.
9. Uso Productivo
Aqu el software ya se pone en funcionamiento.
10. Mantenimiento
Es opcional pero necesario, debido a que todo software debe entrar en fase de
mantenimiento para poder mejorar su funcionalidad.
5.

Clasificacin de pruebas de software:

Desde el punto de vista de las caractersticas de las pruebas (estticas y dinmicas)

Estticas:
Las tcnicas de pruebas estticas consideran al programa en un punto dado que
usualmente no necesitan ser ejecutados.
Se subdividen en verificacin y anlisis esttico, de las cuales las tcnicas estticas dan
pistas directas para los defectos en lugar de identificar los fracasos.
Verificacin
Las tecnicas de verificacion tienen la mira en chequear un programa formalmente contra
sus especificaciones, algunos pueden probar la correctitud del programa, a su vez esto no
puede darse sin otras tcnicas de testeo como las tcnicas formales las cuales son basadas
en especificacin y consistencia del programa, por lo que la especificacin del programa es
probada. No es posible validar un programa mediante tcnicas formales por no ser
suitables para detectar problemas en la especificacin, por lo cual se requiere una
especificacin exhaustiva.
Las verificaciones formales son solo usadas en programas cuyos campos son como los de
control del poder de una planta, en la aviacin o militar.
Para probar lo correctitud de un programa puede por instancia ser hecha usando axiomas
de lgica (Floyd-)Hoare y siguiendo aserciones inductivas.
Las tcnicas formales son muy poderosas pero el esfuerzo es tremendo y a menudo
imprctico aun para programas pequeos.
Anlisis esttico
No ejecutan el programa bajo consideracin y no necesariamente requieren de
herramientas de soporte, el cdigo es interpretado y analizado.
El uso de herramientas es fuertemente sugerida como tcnicas de anlisis esttico siendo
estables para la automatizacin.
Iniciando anlisis estticos es posible en un punto temprano de desarrollo, aunque en
general ningn defecto es encontrado pero solo pistas a ellos.
Anlisis de estilo es una tcnica que chequea el cdigo fuente por su conformidad con las
convenciones predefinidas.
Control de anlisis de flujo estticamente chequea el cdigo en orden para detectar
anomalas. La meta es detectar el cdigo que no puede ser ejecutado por razones
semnticas y que las iteraciones no se pueden escapar una vez dentro.
Anlisis de flujo de dato o deteccin de anomalas, es usado para detectar partes del
programa que se desvan de las expectativas.

Dinmicas:
Tcnicas dinmicas estn basadas en ejecutar el cdigo en orden para detectar fracasos,
conforman un gran nmero de tcnicas las cuales pueden ser categorizadas en seis.
Orientado a estructura
Significa que un programa es testeado contra su propio codigo, fuerza a los probadores que
chequeen el cdigo en detalle, el esfuerzo y la habilidad requerida de los empleados para
las tcnicas orientadas a estructura son altos pero es posible encontrar defectos
efectivamente.
Orientado a funciones
Los probadores leen los documentos de las especificaciones y disear casos de prueba
correspondiente. Aun as la orientacin de las funciones pueden ser llamadas orientacin a
la especificacin. Los casos de prueba son derivados en una manera sistemtica en vez de
aproximacin por fuerza bruta.
Anlisis dinmico
La clase de fracasos revelados por los anlisis dinmicos pueden ser crticas y en el mismo
tiempo difcil de reproducir. Los problemas de recurso pueden ocurrir despus de que un
software haya sido terminado. Aquellos defectos son muy caros de arreglar, al igual que
encontrar defectos, anlisis dinmicos pueden ser usados para visualizar un rendimiento
de programa y puede deducir informacin en tiempo de ejecucin. Los anlisis dinmicos
pueden alentar la ejecucin y su dependencia en el lenguaje de programacin usado.

Pruebas de rendimiento
Pueden ser llamadas pruebas de eficiencia, son usadas para evaluar el comportamiento del
tiempo de ejecucin respecto a la utilizacin de recursos y tiempos de respuesta.
El rendimiento adecuado no es solo para el factor de usabilidad pero importante para la
calidad promedia del programa. Las pruebas de rendimiento son tambin conducidas para
asegurar que el programa trabaja bajo imprescindibles condiciones futuras.
Basado en experiencia
No se basan en una aproximacin estructural pero utiliza a un probador experimentado.
Tambin son llamados tcnicas libres de testeo. Los probadores necesitan tener grandes

cantidades de experiencia y grandes habilidades de testeo en orden de probar

efectivamente. La reproductibilidad de las pruebas son bajas.
Tcnicas lejanas
Las pruebas dinmicas son heursticas y aceptan que testear una generacin de caso es
borroso para algunos grados. Los dos mtodos principales son pruebas de atras-para-atras
y mutacin.
Desde el punto de vista de los negocios
Para negocios se puede encontrar que existe ms que nada la documentacin del programa,
chequeando la documentacin es vital, creando y manteniendo.
Se cuenta por 10 a 25% del costo total de desarrollos del software standard, escribiendo
una documentacin no puede ser comparado con escribir un programa computacional. Las
especificaciones incorrectas pueden ser reflejadas en la documentacin y existen errores
tipicos que estan hechos cuando se escriben.

6.

Diferencias entre pruebas estticas y pruebas dinmicas

Pruebas Estticas
No requiere ejecutar el cdigo de la aplicacin.
Estn ms orientadas al proceso de verificacin; ya que, slo se usan para evaluar o
analizar documentos de: Requisitos, Diseo, Planes de prueba, Manuales de Usuario,
etc, e incluso para examinar el cdigo fuente antes de ejecutarlo.
Su realizacin es ms usada en mdulos o aplicaciones pequeas, ya que requiere de
un gran esfuerzo.
Pruebas Dinmicas
Se realizan con la ejecucin de la aplicacin.
Permiten el uso de tcnicas de caja negra y caja blanca con mayor amplitud.
Permiten medir con mayor precisin el comportamiento de la aplicacin
desarrollada.
Estn ms orientadas a la validacin, porque slo se aplican sobre el cdigo del
producto para detectar defectos y determinar atributos de calidad del software.
7.

Diferencias entre pruebas alfa y pruebas beta

Las pruebas alfa son realizadas cuando nuestro software va entrar a una etapa en la que
necesita ser probado para poder verificar cuales son los problemas que tienen, pero tienen

la mayor parte del sistema est implementado y funcional, a diferencia de las pruebas beta
que son los testeos en los que se han solucionado casi todos los problemas obtenidos en el
testeo alfa y prcticamente el sistema est en completo funcionamiento.
Las dos pruebas necesitan que el sistema est ya en ejecucin con usuarios o clientes reales
que vayan a usarlo, debido a que por medio de ellos podremos saber qu es lo que debemos
terminar de completar.
8.

Pruebas de regresin

Evalan el correcto funcionamiento del software desarrollado luego de haber realizado

cambios funcionales o que este haya evolucionado; es decir, debe demostrar que se han
corregido errores de versiones anteriores y que no se han producido efectos secundarios.
9.

Contraste de definiciones

El estndar IEEE nos da una serie de conceptos y definiciones que se desarrollan alrededor
de una definicin importante, o principal, por decirlo de alguna manera. Esta definicin es
la de Elemento de Prueba.
En las definiciones al inicio de este documento se menciona al Caso de prueba que es lo
ms parecido al Elemento de Prueba de la IEEE.
Todos estos conceptos, se basan en la holgura que desprende usar un Elemento de Prueba
en una Prueba de Software. Una actividad cualquiera, la gestin, el desarrollo, el
mantenimiento, o la misma prueba o cualquier otro proceso de apoyo da como resultado
un Elemento de Prueba.
As, se puede decir que las fallas, defectos, errores, bugs, fracasos, incidentes, etc., todos se
desarrollan dentro de un ambiente de pruebas explcito y muy bien definido como
Elemento de Prueba.
10.

Complemento de conceptos

Base de pruebas.- El diseo de pruebas y los casos de prueba se basan en una nube de
conocimientos que permiten un caso de prueba controlado. Puede ser la base para la
documentacin, pero sobre todo para tener un entendimiento del comportamiento que se
requiere.
Riesgo del producto.- Algn especfico aspecto del producto puede ser riesgoso si en su
funcionalidad, calidad o estructura est, en alguna manera, defectuoso.
Referencias Bibliogrficas

1. IEEE International Standard. ISO/IEC/IEEE 29119-1. Software and systems

engineering - Software testing. (1st ed. 2013-09-01. part 1)
2. Burnstein, Ilene. Practical Software Testing. A Process-Oriented Approach. (2003.
Chapter 2)
3. CIBERTEC. Pruebas de Software.
http://cibertec.googlecode.com/files/Pruebas%20de%20Software.pdf
4. Impra Consultores. Diferencias entre software Alfa y Beta.
http://imprasc.com/imprablogs/2014/01/diferencias-entre-software-alfa-y-beta/
5. Ing. Alonso Morales.2011 Ejecucin de Pruebas.
http://es.scribd.com/doc/76765984/Ejecucion-de-pruebas-original
6. Roberto Miana .martes, 10 de abril de 2012 Calidad y Software.
http://calidadysoftware.blogspot.com/2012/04/testing-ii-planificacion-de-las-pruebas.html