Criterios de clasificacin

Usualmente clasificamos para agrupar elementos con caractersticas comunes,

simplificando la realidad y analizando un conjunto de elementos desde distintos
puntos de vista.
Sobre un mismo conjunto podemos definir distintos criterios de clasificacin, y los
elementos pueden reagruparse segn cada uno de stos.
Por ejemplo podemos clasificar a las personas segn su estatura (alto, mediano, bajo)
o su edad (nio, joven, adulto, anciano) y adems podemos clasificar a un nio segn
su estatura.
Cuando entramos en el mundo del testing comenzamos a or y leer trminos que
refieren a distintos tipos de pruebas.
Algunos de estos tipos de prueba son:

En el mbito del testing podemos distinguir tambin varios criterios de clasificacin,

algunos relativos a las pruebas, o tros al contexto.
Podemos clasificar las pruebas segn los siguientes criterios:

-->El conocimiento del cdigo

-->La etapa de desarrollo del software

-->El aspecto a evaluar del software

A continuacin se definen y clasifican distintos tipos de testing.

Clasificacin segn el conocimiento del cdigo

Pruebas de caja negra
Se trata al sistema como una caja negra, de la que no se conoce ni su contenido ni su
estructura interna.
Para la ejecucin de pruebas de caja negra, se suministran datos de entrada al sistema,
se observa la salida obtenida y se compara con la salida esperada. Si bien no
conocemos la estructura interna del sistema, sabemos cmo se espera que se
comporte.

Pruebas de caja blanca

En las pruebas de caja blanca se piensan y disean casos de prueba conociendoel
cdigo del software. Se seleccionan los caminos del programa y el flujo de datos a
ejercitar durante las pruebas.
Comnmente se conoce con el nombre de testing de caja blanca para contrastar con
el testing de caja negra, pero sera ms apropiado el nombre caja transparente, ya
que a travs de una caja blanca tampoco podemos ver lo que tiene adentro. Este tipo
de testing tambin se denomina estructural.

En general, el testing de caja transparente es realizado por el desarrollador que

escribi el cdigo o por otro desarrollador, ya que las pruebas estn fuertemente
ligadas al cdigo. Sin embargo, puede darse el caso de que un equipo de testing
interno o externo deba hacer este tipo de pruebas, por ejemplo para un mdulo
crtico.
Es importante destacar que las pruebas de caja blanca estn enfocadas a identificar
debilidades en el diseo del cdigo y no a detectar discrepancias entre los
requerimientos y su implementacin.
En las pruebas de caja blanca los programas son vistos en trminos de unidades de
cdigo que interactan entre s.

Pruebas de caja gris

En las pruebas de caja gris se tiene un conocimiento limitado del cdigo y la estructura
interna del software. Se establece un dilogo programador-tester o bien se estudia la
documentacin tcnica para conocer sobre la estructura interna del sistema.
Por ejemplo, podemos ejecutar pruebas de cada gris si tenemos acceso a la base de
datos del sistema, aunque no conozcamos el cdigo.

Clasificacin segn el conocimiento del cdigo

Segn este criterio, dependiendo del grado de conocimiento que se tenga del cdigo y
la estructura interna del software, las pruebas se clasifican en: pruebas de caja negra,
caja blanca o caja gris.

Clasificacin segn la etapa de desarrollo

Pruebas unitarias
En este tipo de pruebas, se prueban de forma aislada las unidades o conjunto de
unidades relacionadas de un software.

Podemos considerar una unidad como una clase, un mtodo,un componente o un

subsistema. Las pruebas unitarias intentan detectar discrepancias entre los
requerimientos y el comportamiento real de la unidad. Se pone nfasis en verificar la
especificacin de la interfaz de las unidades.
Estas pruebas pueden ser manuales, o automatizadas, pueden ser ejecutadas por
quien desarroll el software o por un tercero y pueden ser de caja negra, blanca o gris.

Pruebas de integracin
La integracin es el proceso en el cual los componentes son agregados para crear
componentes ms grandes. En las pruebas integracin componentes de software y
hardware son combinados para evaluar su interaccin.

Uno de los objetivos de este tipo de prueba es identificar problemas cuando se

combinan los componentes.
Las pruebas de integracin pueden ser de caja negra, caja blanca o transparente o caja
gris y pueden ser ejecutadas por distintos actores. En general requieren de la
participacin de los desarrolladores, que conocen los detalles de la integracin:
interfaces, tablas, servicios, mensajes, por ejemplo.
Hay varias estrategias para las pruebas de integracin, en las que ahora no entraremos
en detalle.

Pruebas del sistema

Estas pruebas tienen como objetivo evaluar el comportamiento del sistema en su
conjunto, verificando el cumplimiento de los requerimientos explcitos e implcitos.
Son pruebas sobre la aplicacin integrada.
En estas pruebas se considera el hardware y el software definido, similar al de
produccin,y se tienen en cuenta las interfaces externas, los dispositivos de hardware,
y el ambiente de ejecucin.

En las pruebas del sistema se evala:

<!--[if !supportLists]--><!--[endif]-->Funcionalidad: se evala si las

funcionalidades definidas para el software se comportan como es
esperado.

<!--[if !supportLists]--><!--[endif]-->Seguridad: se evala si el sistema

protege los datos manipulados, maneja autenticacin y autorizacin.

<!--[if !supportLists]--><!--[endif]-->Usabilidad: se evala la facilidad con

la que un usuario puede aprender a manejar, preparar las entradas e
interpretar las salidas de un sistema o componente de software.

<!--[if !supportLists]--><!--[endif]-->Configuracin e instalacin: se

evala que una versin del producto pueda ser instalada y configurada
por el usuario.

<!--[if !supportLists]--><!--[endif]-->Escalabilidad: se estudian los

cambios a nivel de hardware y de software.

<!--[if !supportLists]--><!--[endif]-->Desempeo: se evala el rendimiento

o performance del sistema.

<!--[if !supportLists]--><!--[endif]-->Volumen: se evala el sistema

funcionado con un gran volumen de datos.

<!--[if !supportLists]--><!--[endif]-->Carga: se evala el sistema con la

mxima cantidad definida de usuarios concurrentes.

<!--[if !supportLists]--><!--[endif]-->Stress: Se evala el sistema ms all

de los lmites para los que fue diseado, considerando volumen y carga
simultneamente.

<!--[if !supportLists]--><!--[endif]-->Y ms..

Por ejemplo, las pruebas de un sistema web pueden incluir pruebas con
diferentes navegadores, adems de pruebas de desempeo en los servidores
donde correr la aplicacin.
Tambin se prueban interfaces con otros sistemas, como por ejemplo la interaccin
entre Gmail y Google Docs

Prueba de aceptacin
Las pruebas de aceptacin son efectuadas por el cliente o una entidad que lo
represente, para dar su conformidad con el producto liberado.

El objetivo de estas pruebas es evaluar si el software puede ser utilizado por el usuario
final para realizar las funciones y tareas para las que fue construido o adquirido.
Ejemplos de pruebas de aceptacin pueden ser pruebas que hacen usuarios que
trabajan en la empresa cliente, o pruebas de humo que ejecutan testers (en este caso
los testers son los clientes del producto)
Este tipo de prueba se encuentra ms ligado a la validacin que a la verificacin, ya
que se trabaja ms cerca de los requerimientos.
La prueba de aceptacin puede ser:

<!--[if !supportLists]-->Formal : extensin de la prueba del sistema.

<!--[if !supportLists]--><!--[endif]-->Informal: se identifican las funciones

pero no hay casos de prueba a seguir. El usuario final determina qu
hacer.

<!--[if !supportLists]--><!--[endif]-->Alfa: Pruebas realizadas por el

usuario final en la organizacin de desarrollo.

<!--[if !supportLists]--><!--[endif]-->Beta: El usuario final es responsable

de crear el ambiente, seleccionar sus datos y decidir qu funciones
explorar. Es responsable por identificar su propio criterio de aceptacin.

Pueden participar testers y usuarios. Segn Michel Bolton, las distintas organizaciones
consideran las pruebas de aceptacin de formas diversas, por ejemplo como:

<!--[if !supportLists]-->Una ceremonia, en la que no hay testing real...

sino ms bien, un paso protocolar que hay que cumplir para que se haga
efectivo un cobro o un cierre de contrato.

<!--[if !supportLists]--><!--[endif]-->Una demostracin, donde no se

quiere que aparezcan errores, para convencer o capacitar a cierto
auditorio.

<!--[if !supportLists]--><!--[endif]-->Un ejercicio suave, con pruebas

simples, mediante las cuales se procura salir airoso del paso.

<!--[if !supportLists]--><!--[endif]-->La bsqueda de un chivo

expiatorio procurando detectar el error que provoque la no

aceptacin. Este caso se da generalmente, cuando hay problemas entre

las empresas y no se quiere aceptar el producto.

Puede darse tambin como:

<!--[if !supportLists]-->pruebas de sondeo

<!--[if !supportLists]--><!--[endif]-->desafiando al software, buscando

romperlo y al no hacerlo confirmar que ste funciona

<!--[if !supportLists]--><!--[endif]-->investigacin imparcial, crtica y de

apoyo

<!--[if !supportLists]--><!--[endif]-->buscando un software de alta calidad

Diferentes formas podran ser correctas segn el contexto. Es fundamental entender la

misin y adecuar el enfoque, la estrategia y las tcnicas a utilizar.

Las pruebas de aceptacin entraan un riesgo para un proyecto de software. Pueden

surgir mltiples obstculos, entre los cuales:

Foco en detalles insignificantes en lugar de las funcionalidades y ciclos

funcionales ms significativos.

Usuarios no adecuados o preparados para la tarea.

Reaccin negativa frente al cambio y no frente al software.

Criterios de aceptacin inciertos, funcionalidades y ciclos funcionales no

priorizados.

Perfiles de uso del producto no estudiados.

Si se est en un proyecto que involucra pruebas de aceptacin es

recomendable considerarlas lo antes posible.

Pruebas de regresin

Su objetivo es verificar que no ocurri una regresin en la calidad del producto luego
de un cambio. La modificacin puede ser una nueva funcionalidad, la correccin de un
error ya detectado o la actualizacin de uno o ms componentes del software o
hardware. En cualquier caso no es suficiente con probar la modificacin solamente,
porque sta pudo haber tenido un impacto en otras "zonas" del producto.

Las pruebas de regresin implican la reejecucin de alguna o todas las pruebas

ejecutadas anteriormente.

Entre los tipos de pruebas de regresin podemos mencionar:

<!--[if !supportLists]--><!--[endif]-->Regresin de incidentes

recientemente corregidos

<!--[if !supportLists]--><!--[endif]-->Regresin de antiguos incidentes,

corregidos en versiones anteriores

<!--[if !supportLists]--><!--[endif]-->Regresin de efectos secundarios

o

<!--[if !supportLists]--><!--[endif]-->Implica volver a probar una

parte del producto

<!--[if !supportLists]--><!--[endif]-->El objetivo es probar que a raz

del cambio, algo que funcionaba ya no funciona

La pregunta que surge inmediatamente es:

Es posible reejecutar siempre todas las pruebas?
La respuesta no es trivial y es un nuevo desafo para los testers. Existen varias
estrategias para decidir qu casos de prueba reejecutar. Todas tienen ventajas
y desventajas. Por ejemplo, si siempre reejecutamos las pruebas de las
funcionalidades ms crticas, podran quedar funcionalidades que nunca
volveramos a probar. Lo que se recomienda y nosotros aplicamos es que
antes de liberar un producto, se reejecuten todas las pruebas.

La prueba de errores severos corregidos de forma urgente, constituye una

excepcin, ya que es apremiante liberar el producto inmediatamente. Pero lo

que no puede suceder es que esos casos de prueba se pierdan y no sea
incorporados a las sucesivas pruebas de regresin del producto.

Tanto en las pruebas unitarias, de integracin, del sistema, o de aceptacin

pueden ejecutarse pruebas de regresin.
<!--[endif]-->
Ejemplo
Por ejemplo en Gmail, los desarrolladores del mdulo correo prueban el envo de
correos, los desarrolladores de Chat prueban el envo de mensajes, y otro equipo
prueba los filtros de bsqueda y cmo se visualizan. Todos estos son ejemplos de
pruebas unitarias, considerando cada componente como una unidad.
En las pruebas de integracin, se verifica que los mdulos interactan como se
esperaba, por ejemplo, haciendo una bsqueda en las conversaciones almacenadas y
visualizndolas de la misma forma que se visualizan los mails.
Supongamos que durante las pruebas se detecta un defecto en el mdulo de correo y
el defecto es solucionado por el equipo de desarrolladores.
Luego, se ejecutarn pruebas de regresin (se vuelve a probar el mdulo y la
interaccin con los otros mdulos), para comprobar que el defecto fue solucionado y
que no se introdujeron nuevos defectos.
Clasificacin segn la etapa de desarrollo
Segn este criterio, dependiendo de en qu etapa del desarrollo de software se hacen
las pruebas, se clasifican en:pruebas unitarias, de integracin, de sistema, de regresin
y de aceptacin. Es importante destacar que el momento, la forma y la frecuencia con
que se ejecutan estas pruebas depende del proceso de desarrollo que se utilice.

Clasificacin segn el aspecto a evaluar

Pruebas funcionales
Las pruebas funcionales se enfocan en verificar la capacidad del sistema de realizar
ciertas funcionalidades. Se basan en qu hace el sistema y consideran el punto de vista
del usuario y generalmente, se utiliza un enfoque de caja negra.
Pruebas para-funcionales
Las pruebas para-funcionales verifican otros atributos del sistema, enfocndose en
cmo el sistema cumple con las funcionalidades.
Usualmente a este tipo de pruebas se les llama pruebas no-funcionales, sin embargo el
rendimiento y performance del sistema son parte del comportamiento de las
funcionalidades del sistema. Por lo que decidimos llamarle pruebas para-funcionales a
aquellas que tienen por objetivo evaluar aspectos relacionados a la rapidez
(transacciones por seg.), el tamao (KB) y a la fiabilidad (tiempo promedio entre fallas,
recuperacin ante errores), entre otros aspectos.
Por ejemplo las pruebas de usabilidad, escalabilidad, rapidez, seguridad, tamao,
portabilidad (sistemas operativos, navegadores) se consideran pruebas parafuncionales.
Clasificacin segn el aspecto a evaluar

Resumiendo

Trabajamos con 3 criterios de clasificacin, pero siempre podemos barajar y dar de

nuevo. Por ejemplo:

Estos son los nicos criterios posibles?