Criterios de clasificación

Transcripción

1 Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre un mismo conjunto podemos definir distintos criterios de clasificación, y los elementos pueden reagruparse según cada uno de éstos. Por ejemplo podemos clasificar a las personas según su estatura (alto, mediano, bajo) o su edad (niño, joven, adulto, anciano) y además podemos clasificar a un niño según su estatura. Cuando entramos en el mundo del testing comenzamos a oír y leer términos que refieren a distintos tipos de pruebas. Algunos de estos tipos de prueba son: En el ámbito del testing podemos distinguir también varios criterios de clasificación, algunos relativos a las pruebas, o tros al contexto. Podemos clasificar las pruebas según los siguientes criterios: -->El conocimiento del código -->La etapa de desarrollo del software -->El aspecto a evaluar del software

2 A continuación se definen y clasifican distintos tipos de testing. Clasificación según el conocimiento del código 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 ejecución 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 cómo se espera que se comporte. Pruebas de caja blanca En las pruebas de caja blanca se piensan y diseñan casos de prueba conociendoel código del software. Se seleccionan los caminos del programa y el flujo de datos a ejercitar durante las pruebas. Comúnmente se conoce con el nombre de testing de caja blanca para contrastar con el testing de caja negra, pero sería más apropiado el nombre caja transparente, ya que a través de una caja blanca tampoco podemos ver lo que tiene adentro. Este tipo de testing también se denomina estructural. En general, el testing de caja transparente es realizado por el desarrollador que escribió el código o por otro desarrollador, ya que las pruebas están fuertemente ligadas al código. 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 módulo crítico. Es importante destacar que las pruebas de caja blanca están enfocadas a identificar debilidades en el diseño del código y no a detectar discrepancias entre los requerimientos y su implementación. En las pruebas de caja blanca los programas son vistos en términos de unidades de código que interactúan entre sí.

3 Pruebas de caja gris En las pruebas de caja gris se tiene un conocimiento limitado del código y la estructura interna del software. Se establece un diálogo programador-tester o bien se estudia la documentación técnica 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 código. Clasificación según el conocimiento del código Según este criterio, dependiendo del grado de conocimiento que se tenga del código y la estructura interna del software, las pruebas se clasifican en: pruebas de caja negra, caja blanca o caja gris. Clasificación según 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.

4 Podemos considerar una unidad como una clase, un método,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 especificación 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 integración La integración es el proceso en el cual los componentes son agregados para crear componentes más grandes. En las pruebas integración componentes de software y hardware son combinados para evaluar su interacción. Uno de los objetivos de este tipo de prueba es identificar problemas cuando se combinan los componentes. Las pruebas de integración pueden ser de caja negra, caja blanca o transparente o caja gris y pueden ser ejecutadas por distintos actores. En general requieren de la participación de los desarrolladores, que conocen los detalles de la integración: interfaces, tablas, servicios, mensajes, por ejemplo. Hay varias estrategias para las pruebas de integración, 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 explícitos e implícitos. Son pruebas sobre la aplicación integrada. En estas pruebas se considera el hardware y el software definido, similar al de producción,y se tienen en cuenta las interfaces externas, los dispositivos de hardware, y el ambiente de ejecución. En las pruebas del sistema se evalúa: <!--[if!supportlists]--><!--[endif]-->funcionalidad: se evalúa si las funcionalidades definidas para el software se comportan como es esperado. <!--[if!supportlists]--><!--[endif]-->seguridad: se evalúa si el sistema protege los datos manipulados, maneja autenticación y autorización.

5 <!--[if!supportlists]--><!--[endif]-->usabilidad: se evalúa 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]-->configuración e instalación: se evalúa que una versión 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]-->desempeño: se evalúa el rendimiento o performance del sistema. <!--[if!supportlists]--><!--[endif]-->volumen: se evalúa el sistema funcionado con un gran volumen de datos. <!--[if!supportlists]--><!--[endif]-->carga: se evalúa el sistema con la máxima cantidad definida de usuarios concurrentes. <!--[if!supportlists]--><!--[endif]-->stress: Se evalúa el sistema más allá de los límites para los que fue diseñado, considerando volumen y carga simultáneamente. <!--[if!supportlists]--><!--[endif]-->y más.. Por ejemplo, las pruebas de un sistema web pueden incluir pruebas con diferentes navegadores, además de pruebas de desempeño en los servidores donde correrá la aplicación. También se prueban interfaces con otros sistemas, como por ejemplo la interacción entre Gmail y Google Docs Prueba de aceptación Las pruebas de aceptación son efectuadas por el cliente o una entidad que lo represente, para dar su conformidad con el producto liberado.

6 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 aceptación 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 más ligado a la validación que a la verificación, ya que se trabaja más cerca de los requerimientos. La prueba de aceptación puede ser: <!--[if!supportlists]-->formal : extensión 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 organización 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 aceptación. Pueden participar testers y usuarios. Según Michel Bolton, las distintas organizaciones consideran las pruebas de aceptación de formas diversas, por ejemplo como: <!--[if!supportlists]-->una ceremonia, en la que no hay testing real... sino más bien, un paso protocolar que hay que cumplir para que se haga efectivo un cobro o un cierre de contrato. <!--[if!supportlists]--><!--[endif]-->una demostración, 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 búsqueda de un chivo expiatorio procurando detectar el error que provoque la no

7 aceptación. Este caso se da generalmente, cuando hay problemas entre las empresas y no se quiere aceptar el producto. Puede darse también 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]-->investigación imparcial, crítica y de apoyo <!--[if!supportlists]--><!--[endif]-->buscando un software de alta calidad Diferentes formas podrían ser correctas según el contexto. Es fundamental entender la misión y adecuar el enfoque, la estrategia y las técnicas a utilizar. Las pruebas de aceptación entrañan un riesgo para un proyecto de software. Pueden surgir múltiples obstáculos, entre los cuales: Foco en detalles insignificantes en lugar de las funcionalidades y ciclos funcionales más significativos. Usuarios no adecuados o preparados para la tarea. Reacción negativa frente al cambio y no frente al software. Criterios de aceptación inciertos, funcionalidades y ciclos funcionales no priorizados. Perfiles de uso del producto no estudiados. Si se está en un proyecto que involucra pruebas de aceptación es recomendable considerarlas lo antes posible. Pruebas de regresión

8 Su objetivo es verificar que no ocurrió una regresión en la calidad del producto luego de un cambio. La modificación puede ser una nueva funcionalidad, la corrección de un error ya detectado o la actualización de uno o más componentes del software o hardware. En cualquier caso no es suficiente con probar la modificación solamente, porque ésta pudo haber tenido un impacto en otras "zonas" del producto. Las pruebas de regresión implican la reejecución de alguna o todas las pruebas ejecutadas anteriormente. Entre los tipos de pruebas de regresión podemos mencionar: <!--[if!supportlists]--><!--[endif]-->regresión de incidentes recientemente corregidos <!--[if!supportlists]--><!--[endif]-->regresión de antiguos incidentes, corregidos en versiones anteriores <!--[if!supportlists]--><!--[endif]-->regresión de efectos secundarios o <!--[if!supportlists]--><!--[endif]-->implica volver a probar una parte del producto o <!--[if!supportlists]--><!--[endif]-->el objetivo es probar que a raíz 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 desafío 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 más críticas, podrían quedar funcionalidades que nunca volveríamos 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

9 excepción, 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 regresión del producto. Tanto en las pruebas unitarias, de integración, del sistema, o de aceptación pueden ejecutarse pruebas de regresión. <!--[endif]--> Ejemplo Por ejemplo en Gmail, los desarrolladores del módulo correo prueban el envío de correos, los desarrolladores de Chat prueban el envío de mensajes, y otro equipo prueba los filtros de búsqueda y cómo se visualizan. Todos estos son ejemplos de pruebas unitarias, considerando cada componente como una unidad. En las pruebas de integración, se verifica que los módulos interactúan como se esperaba, por ejemplo, haciendo una búsqueda en las conversaciones almacenadas y visualizándolas de la misma forma que se visualizan los mails. Supongamos que durante las pruebas se detecta un defecto en el módulo de correo y el defecto es solucionado por el equipo de desarrolladores. Luego, se ejecutarán pruebas de regresión (se vuelve a probar el módulo y la interacción con los otros módulos), para comprobar que el defecto fue solucionado y que no se introdujeron nuevos defectos. Clasificación según la etapa de desarrollo Según este criterio, dependiendo de en qué etapa del desarrollo de software se hacen las pruebas, se clasifican en:pruebas unitarias, de integración, de sistema, de regresión y de aceptación. 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.

10 Clasificación según 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, enfocándose en cómo 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 tamaño (KB) y a la fiabilidad (tiempo promedio entre fallas, recuperación ante errores), entre otros aspectos. Por ejemplo las pruebas de usabilidad, escalabilidad, rapidez, seguridad, tamaño, portabilidad (sistemas operativos, navegadores) se consideran pruebas parafuncionales. Clasificación según el aspecto a evaluar

11 Resumiendo Trabajamos con 3 criterios de clasificación, pero siempre podemos barajar y dar de nuevo. Por ejemplo: Estos son los únicos criterios posibles?