Testing de Software

Temario
Introduccin
Quin hace las Pruebas?
Cundo se inicia el testing de software?
Cundo finalizan las pruebas?
Verificacin y validacin

Mitos sobre el Testing de software

QA, QC y Testing
Auditora e Inspeccin
Pruebas y depuracin
Resumen

Introduccin
Es el proceso de evaluacin de un sistema o de su componente(s) con la intencin de encontrar
si cumple los requisitos especificados.
La prueba se ejecuta en un sistema con el fin de identificar los vacos, errores, o los requisitos
faltantes en contra de las exigencias reales.
De acuerdo con la norma ANSI/IEEE 1059 el Testing se puede definir como:
Un proceso de anlisis de un elemento de software para detectar las diferencias entre las condiciones
existentes y las requeridas( es decir defectos/errores/bugs ) y para evaluar las caractersticas del
elemento de software.

Quin hace las Pruebas?

Depende del proceso y de los grupos de inters asociados al(os) proyecto(s).

En la industria de TI, las grandes empresas tienen un equipo con responsabilidades para evaluar
el software desarrollado en el contexto de los requisitos citados.
Los desarrolladores tambin llevan a cabo las pruebas llamadas Pruebas Unitarias.
En la mayora de los casos, los siguientes profesionales participan en la prueba de un sistema
dentro de sus respectivas capacidades:

Tester de Software
Desarrollador de software
Lder de Proyecto / Gerente
Usuario final

Cundo se inicia el testing de software?

Un inicio temprano de las pruebas reduce el costo y el tiempo para corregir y producir el
software libre de errores que se entrega al cliente.
Sin embargo, en el ciclo de vida de desarrollo de software( SDLC ) , las pruebas se puede iniciar
desde la fase de recopilacin de requisitos y continuar hasta el despliegue del software.
Tambin depende del modelo de desarrollo que se utiliza. Por ejemplo, en el modelo de
cascada, las pruebas formales se lleva a cabo en la fase de pruebas; pero en los modelos
incrementales, las pruebas se realizan al final de cada iteracin/incremento y toda la aplicacin
se prueba en el extremo.

Las pruebas se realizan en las diferentes formas en cada fase del CVDS:

Durante las fases de recopilacin de requisitos, anlisis y verificacin de requisitos tambin son
consideran como pruebas.
Revisar el diseo en la fase de diseo con la intencin de mejorar el diseo tambin se considera
como prueba.

Las pruebas realizadas por un desarrollador al finalizar el cdigo tambin se clasifican como
pruebas.

Cundo finalizan las pruebas?

Es difcil determinar cundo se terminan las pruebas de software, como las pruebas son un
proceso que nunca termina y nadie puede pretender que un software este probado al 100%.
Los siguientes aspectos son para ser considerados en la finalizacin del proceso de pruebas:

Plazos de pruebas.
La finalizacin de la ejecucin de los casos de pruebas.
La finalizacin de la cobertura funcional y de cdigo en cierto punto determinado.
La tasa de Bugs cae por debajo de cierto nivel y no hay errores de alta prioridad que se identifiquen.
Decisiones de gestin.

Verificacin y validacin
Estos dos trminos son muy confusos para la mayora de la gente, que los utilizan de manera
indistinta.

La siguiente tabla muestra las diferencias entre la verificacin y validacin.

N

Verificacin

Validacin

1 Verificacin responde a la preocupacin : "Se est

construyendo las cosas bien?.

Validacin responde a la preocupacin : "Se est

construyendo lo correcto?.

2 Asegura que el sistema software cumple con todas

las funcionalidades.

Asegura que las funcionalidades cumplen con el

comportamiento previsto.

3 La Verificacin tiene lugar primero e incluye la

comprobacin de la documentacin, cdigo, etc.

La Validacin se produce despus de la verificacin e

implica la comprobacin del producto global.

4 Hecho por los desarrolladores.

Hecho por los Testers.

5 Tiene actividades estticas, que incluyen la recogida

de opiniones, tutoriales, y las inspecciones para
verificar el software.

Cuenta con actividades dinmicas, que incluye la

ejecucin de software contra los requisitos.

6 Es un proceso objetivo y ninguna decisin subjetiva

debe ser necesaria para verificar un software.

Es un proceso subjetivo e implica decisiones

subjetivas sobre qu tan bien funciona el software.

Mitos sobre el Testing de software

A continuacin se presentan los mitos ms comunes acerca de las pruebas de software.

Mito 1: Las pruebas son demasiado costosas

Realidad: Hay un dicho, pagar menos por las pruebas durante el desarrollo de software o pagar
ms por el mantenimiento o correccin posterior. Las primeras pruebas ahorran tiempo y costo
en muchos aspectos, sin embargo la reduccin del costo sin pruebas puede resultar en el diseo
inadecuado de una versin intil del producto software.
Mito 2: Las pruebas consumen mucho tiempo
Realidad: Durante las fases del CVDS, las pruebas no son procesos que consuman tiempo. Sin
embargo diagnosticar y solucionar los errores detectados durante las pruebas adecuadas es una
actividad que consume tiempo, pero productivo.

Mito 3: Slo Productos completamente desarrollados se prueban

Realidad: Sin duda, la prueba depende del cdigo fuente, pero la revisin de los requisitos y el
desarrollo de casos de prueba es independiente del cdigo desarrollado. Sin embargo el
enfoque iterativo/incremental como un modelo de CVDS pueden reducir la dependencia de las
pruebas en el software desarrollado completamente.
Mito 4: La Prueba completa es Posible
Realidad: Se convierte en un problema cuando un cliente o tester piensa que la prueba completa
es posible. Es posible que todos los caminos hayan sido probados por el equipo, pero la
ocurrencia de pruebas completas nunca es posible. Puede haber algunos escenarios que no son
ejecutados por el equipo de pruebas o el cliente durante el CVDS y puedan ejecutarse una vez
que el proyecto ha sido implementado.

Mito 5: El Software Probado est libre de errores

Realidad: Esto es un mito muy comn que los clientes, gerentes de proyecto y el equipo
directivo crean. Nadie puede afirmar con absoluta certeza que una aplicacin de software es
100 % libre de errores , incluso si un probador con excelentes habilidades de prueba ha probado
la aplicacin..
Mito 6: Los defectos no detectados se deben a los
Realidad: No es un enfoque correcto culpar a los Testers para los bugs que quedan en la
aplicacin, incluso despus de la prueba que se ha realizado. Este mito se refiere al tiempo,
costo, restricciones y requisitos cambiantes. Sin embargo, la estrategia de prueba tambin
puede resultar en errores que no son detectados por el equipo de prueba.

Mito 7: Los Testers son Responsable de la Calidad del Producto

Realidad: Es una mala interpretacin muy comn que slo los Testers o el equipo de pruebas
deben ser responsables de la calidad del producto. Las responsabilidades de los testers incluyen
la identificacin de los bugs a stakeholders y es entonces su decisin si van a reparar el bug o
liberar el software. Liberar el software en el momento pone ms presin en los Testers, ya que
sern culpados por cualquier error.
Mito 8: La automatizacin de Pruebas se debe utilizar siempre que sea posible para reducir la
duracin del proyecto
Realidad: S, es cierto que la automatizacin de Pruebas reduce el tiempo de prueba, pero no es
posible iniciar la automatizacin de pruebas en cualquier momento durante el desarrollo de
software. La automatizacin de pruebas debe iniciarse cuando el software ha sido probado de
forma manual y es estable hasta cierto punto. Por otra parte, la automatizacin de pruebas no
se puede utilizar si los requisitos siguen cambiando.

Mito 9: Cualquiera puede probar una aplicacin de software

Realidad: La gente fuera de la industria de TI piensa y cree que cualquiera puede probar un
software y que las pruebas no son un trabajo creativo. Sin embargo los Testers saben bien que
es un mito. Se debe pensar en escenarios alternativos, tratar de quebrar un software con la
intencin de explorar errores potenciales no es posible para la persona que lo desarroll.
Mito 10: La nica tarea de un Tester es encontrar errores
Realidad: Encontrar errores en un software es la tarea de los Testers, pero al mismo tiempo, son
expertos en el dominio del software en particular. Los desarrolladores slo son responsables de
la componente o rea especfica que se les asigna, pero los Testers deben de entender el
funcionamiento general del software, lo que las dependencias hacen, y las repercusiones de un
mdulo en otro mdulo.

QA, QC y Testing
La mayora de la gente se confunde cuando se trata de precisar las diferencias entre
Aseguramiento de la Calidad, Control de Calidad y Testing.
A pesar de que estn relacionados entre s y hasta cierto punto, pueden ser considerados como
las mismas actividades, pero existen puntos distintivos que los diferencian.

La siguiente tabla muestra los puntos que diferencian a Aseguramiento de la calidad, control de calidad
y pruebas.
Aseguramiento de la Calidad

Control de Calidad

Pruebas

Incluye actividades que aseguren

la implementacin de procesos,
procedimientos y normas en el
contexto de la verificacin del
software desarrollado y los
requisitos previstos.

Incluye actividades que garanticen la

verificacin de un software
desarrollado con respecto a los
requisitos documentados (o no en
algunos casos).

Incluye actividades que

aseguren la identificacin de
bugs/errores/defectos en el
software.

Se centra en los procesos y

procedimientos en lugar de la
realizacin de pruebas reales en
el sistema.

Se centra en las pruebas reales

ejecutando el software con el
objetivo de identificar bug/defecto a
travs de la implementacin de los
procedimientos y procesos.

Se centra en las pruebas

reales.

Actividades orientadas a los

procesos.

Actividades orientadas al producto.

Actividades orientadas al
producto.

Las actividades preventivas.

Es un proceso correctivo.

Es un proceso preventivo.

Es un subconjunto del Ciclo de

Vida de Pruebas del
software(CVPS).

Se puede considerado como

subconjunto de Aseguramiento de la
Calidad.

Es un subconjunto del Control

de Calidad.

Auditora e Inspeccin
Auditora: Es un proceso sistemtico para determinar cmo se lleva a cabo el proceso de prueba
real dentro de una organizacin o un equipo.
En general, es un examen independiente de los procesos que intervienen durante la prueba de
un software.
Segn IEEE, es una revisin de los procesos documentados que las organizaciones implementen
y siguen.
Tipos de auditora incluyen a Auditora de Cumplimiento Legal , Auditora Interna y Auditora del
sistema.

Inspeccin: Es una tcnica formal que implica revisiones tcnicas formales o informales de
cualquier artefacto mediante la identificacin de cualquier error o hueco.
Segn IEEE94, inspeccin es una tcnica de evaluacin formal en el que se examinan los
requisitos de software, diseos o cdigos en detalle por una persona o un grupo que no sea el
autor para detectar fallas, violaciones de las normas de desarrollo y otros problemas.
Las Reuniones formales de inspeccin pueden incluir los siguientes procesos : Planificacin,
Informacin general de Preparacin, Reunin de inspeccin, revisiones y seguimiento.

Pruebas y depuracin
Pruebas: Se trata de identificar bug/error/defecto en un software sin corregirlo.

Normalmente profesionales con experiencia en aseguramiento de la calidad estn involucrados

en la identificacin errores.
Las pruebas se realizan en la fase de pruebas.

Depuracin: Se trata de identificar, aislar, y corregir los problemas/errores.

Los desarrolladores que codifican el software llevan a cabo la depuracin al encontrarse con un
error en el cdigo.
La depuracin es una parte de Pruebas de Caja Blanca o pruebas unitarias.
La depuracin se puede realizar en la fase de desarrollo, mientras que la realizacin de pruebas
unitarias o en fases, mientras se corrigen los errores reportados.

Resumen
Testing: Un proceso de anlisis de un elemento de software para detectar las diferencias entre
las condiciones existentes y las requeridas.
Quin hace las Pruebas?: segn la dimensin: Tester, Desarrollador, Lder de Proyecto /
Gerente, Usuario final
Cundo se inicia el testing de software?: Mientras ms temprano es mejor. Se hace testing
desde la captura de requerimientos.
Cundo finalizan las pruebas?: nunca hay software probado al 100%, segn el proyecto podra
ser: Plazos de pruebas, finalizacin de los casos de pruebas, finalizacin de la cobertura
funcional, reduccin de la tasa de Bugs a cierto nivel, decisiones de gestin.
Verificacin y validacin: la validacin se hace posterior a la verificacin.

Mitos en el testing de software: existen muchas presunciones sobre las pruebas de software que
van desde la parte operacional, los costes del proyectos y las funciones, papeles y
responsabilidades de los testers de software.
QA, QC y Testing: el Aseguramiento de la Calidad engloba al Control de Calidad y ste al Testing.
Auditora: Es un proceso sistemtico para determinar cmo se lleva a cabo el proceso de prueba
real dentro de una organizacin o un equipo.
Inspeccin: Es una tcnica formal que implica revisiones tcnicas formales o informales de
cualquier artefacto mediante la identificacin de cualquier error o hueco.
Pruebas: Se trata de identificar bug/error/defecto en un software sin corregirlo.

Depuracin: Se trata de identificar, aislar, y corregir los problemas/errores.