Control de Versiones

                     

¿Qué es el control de versiones, y por qué debería ser importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que el usuario pueda recuperar versiones específicas más adelante. A pesar de que los ejemplos de este informe muestran código fuente como archivos bajo control de versiones, en realidad cualquier tipo de archivo que se encuentre en un ordenador puede ponerse bajo control de versiones.[1]

Una herramienta de la que muchas personas, sean diseñadores gráficos o web pueden hacer uso y es de muy buena calidad es la llamada Version Control System (VCS). Con esta herramienta es posible  revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.

Sistemas de control de versiones locales

Un método de control de versiones usado por mucha gente es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son avispados). Este enfoque es muy común porque es muy simple, pero también está propenso a errores. Es fácil olvidar en qué directorio se encuentra en el momento en que se encuentra trabajando, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no se estaba pensado hacer.

Para hacer frente al problema anterior, los programadores desarrollaron VCSs locales que contenían una simple base de datos en la que se llevaba registro de todos los cambios realizados sobre los archivos como se muestra en la siguiente imagen.

Sistemas de control de versiones centralizados

El siguiente gran problema en el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas diferentes. Para resolver este problema, se desarrollaron los Centralized Version Control Systems (CVCSs). Estos sistemas, como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central. Para que la idea quede un poco más clara se muestra la siguiente imagen.



Esta configuración ofrece muchas ventajas, especialmente frente a VCSs locales. Por ejemplo, cualquier persona puede saber (hasta cierto punto) en qué están trabajando los otros colaboradores del proyecto. Los administradores tienen control detallado de qué puede hacer cada uno; y es mucho más fácil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene serias desventajas. La más obvia es el punto único de fallo que representa el servidor centralizado. Si ese servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que están trabajando. [1]

Sistemas de control de versiones distribuidos

Es aquí donde entran los Distributed Version Control Systems (DVCSs). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos como se puede visualizar en la siguiente imagen.

Referencias:

[1] Git-scm.com. (2017). Git - Acerca del control de versiones. [online] Available at: https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones [Accessed 13 Nov. 2017].

V&V

Verificación y Validación

La importancia de este tema se viene dando desde hace ya más de 30 años por Michael S.Deutsch [DEUT79] en su estudio de "Verification and Validation" dice que:

"El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y de desarrollo. Debido a la imposibilidad humana de trabajar y comunicar de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice la calidad."[1]

Los proyectos de desarrollo de software han padecido tradicionalmente problemas de calidad, tanto en el propio proceso de desarrollo como en los productos de entrega. Esta problemática tiene su origen en las habituales desviaciones sobre los plazos y esfuerzos previstos y en la frecuente aparición durante la implantación y operaciones de los productos resultantes.

El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas que tenga el mismo. Para poder alcanzar dichos objetivos se han desarrollado distintos modelos de ciclo de vida, pero en cualquiera de ellos será necesario un proceso que asegure la calidad del producto durante su desarrollo. Para ello, al final de cada fase del ciclo de vida debería comprobarse que el trabajo realizado hasta ese momento cumple con los objetivos previstos. Este es el punto clave, en el que tiene lugar la evaluación del producto, donde se decide si está o no preparado para pasar a la siguiente fase. De esta forma, si hay errores y son detectados, será más eficiente corregirlos que si se descubriesen en etapas avanzadas.[2]

El objetivo final del proceso de verificación y validación es comprobar que el sistema está hecho para un propósito, al cual intenta llegar aplicando técnicas específicas conocidas como: las pruebas y las revisiones.

El proceso de Verificación y Validación es un conjunto de procedimientos, actividades, técnicas y herramientas que se utilizan paralelamente al desarrollo de software, con el fin de asegurar que un producto resuelve el problema inicialmente planteado.

La Verificación
La verificación comprueba la consistencia del software con respecto a especificaciones y requisitos, es decir, si responde a la pregunta: ¿Se ha construido correctamente el software?

• El proceso determina si los productos resultantes de una fase del ciclo de vida del software cumple los requisitos establecidos en la fase anterior. 
• El proceso determina si el producto resultante es completo, consistente y correcto para comenzar la siguiente fase.

La Validación

La validación comprueba si lo que se ha especificado e implementado es lo que el usuario realmente desea, es decir, si responde a la pregunta: ¿Se ha construido el software correcto?

• El proceso determina si el software cumple su especificación.
• El proceso asegura que el software fabricado se comporta como se espera y de acuerdo a las expectativas del cliente.

Las tareas V&V no solo se aplican a productos de software, sino que también a los resultantes del proceso de desarrollo, como el análisis y a la especificación de requisitos, por ejemplo. De esta forma, se comprueba que el proyecto es viable y que las especificaciones documentadas son completas, correctas, precisas, legibles, evaluables, y que, en general, responden a las expectativas del cliente. La V&V del diseño debe garantizar que los requisitos no se encuentran incompletos o incorrectamente diseñados. En el caso de la implementación y la codificación, la V&V del software es comúnmente conocida como las pruebas de software. 

Técnicas de verificación y validación

Existen dos paradigmas principales que permiten la aplicación de estas en un proyecto, las cuales son el análisis estático y el análisis dinámico.

El análisis estático necesita de la ayuda de una herramienta que analice la representación estática del sistema con el propósito de descubrir errores. Trata de la verificación de "productos" obtenidos durante el desarrollo del software.

Por lo contrario, el análisis dinámico implica normalmente la ejecución del código fuente del software con los datos de prueba, con el fin de evaluar en tiempo real los diferentes escenarios soportados por el programa. [2]

Las técnicas son las siguientes:

• Técnicas estáticas: comprende de las revisiones informales que son:
• Revisión del código.
• Programación en parejas.

y revisiones formales:

• Planificación.
• Familiarización.
• Preparación.
• Examen.
• Rehacer.
• Seguimiento.
• Técnicas dinámicas.
• Caja Negra y Caja Blanca.
• Las pruebas del sistema:
• Pruebas de integración.
• Pruebas de entregas.
• Pruebas de rendimiento.
• Las pruebas de componentes:
• Métodos o funciones individuales.
• Clases de objeto.

Referencias

[1] Ton van Schijndel, Dré Robben, “TPI, CMMI and Testing”, Sogeti Nederland B.V.

[2] Hernández, J. Z. (2011). Análisis de los procesos de verificación y validación en las organizaciones software.

Automatización

En las pruebas de software, la automatización de pruebas es una de las actividades que presentan una mayor expectativa. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones deshagan sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.

Sin embargo, poner en marcha la automatización no es una tarea sencilla. Es necesario salvar numerosas dificultades para poder llevar a cabo una automatización eficiente y que permita retornar la inversión realizada. Es importante fijar un conjunto de prácticas que agilicen las tareas de mantenimiento y construcción que aporten una cierta metodología a nuestro proceso de automatización.

Buenas Prácticas:
Los productos de la Automatización deben mantenerse organizados. Los Scripts, ficheros de datos, aplicaciones de soporte, documentación, ficheros de configuración, etc... Deben almacenarse en un sistema de directorios y carpetas que permitan su direccionamiento rápido.
La organización puede depender de los objetivos. Podemos organizar nuestra infraestructura de directorios por aplicación, por plan de pruebas, por sistema y demás.

En la sección de modularización los casos de prueba automatizados pueden modularizarse en base a librerías que realicen funcionalidades más sencillas, de esa forma se agilizará el mantenimiento de los casos.
También es posible construir librerías de propósito general que apliquen a todos nuestros casos automatizados con indepencia de la aplicación o proceso. Ejemplos de librerías de propósito general son:
* Control de errores.
* Escritura/lectura de ficheros de datos.

Ahora bien, tenemos también el aspecto de robustez que en casi de que se produzca un error no controlado durante la ejecución, la lógica del caso de prueba debe ser capaz de finalizar y dejar el estado del equipo de ejecución estable y listo para continuar con un nuevo caso de prueba.
Una posibilidad es comprobar el estado de la maqueta al comenzar una ejecución, forzando el cierre de aquellas aplicaciones que se encuentren abiertas o elevar para los servicios necesarios.

Para el sistema de trazas la información que debe aportar un caso de prueba debe ser fiable. En caso de fallo debe informar de manera concreta de lo que ha ocurrido.
Completar la construcción de los casos de prueba con un sistema de trazas que aportan toda la información o suministrar la captura de la pantalla en el momento del error, pueden ayudar a ganar confianza en los casos automatizados.

En la flexibilidad los casos de prueba automatizados se deben preparar teniendo en cuenta posibles cambios.
Una opción es parametrizar aquellos datos susceptibles de cambios: rutas de acceso, identificadores de usuarios...

En el mantenimiento de los equipos de ejecución la ejecución de casos automáticos suele ser una tarea estresante para los equipos donde corren los casos. Es recomendable programar tareas de mantenimiento como reinicios periódicos, eliminación de ficheros temporales, desfragmentación de discos, entre otros.




Referencias:
[1] González, J. (2017). Buenas Prácticas en la Automatización de Pruebas. [online] Qatecnico.blogspot.com. Available at: http://qatecnico.blogspot.com/2011/08/buenas-practicas-en-la-automatizacion.html [Accessed 25 Oct. 2017].

Plan de Pruebas en el Desarrollo del Software

Plan de Pruebas

El propósito del plan de pruebas es desarrollar el alcance, el enfoque, los recursos requeridos, calendarios, responsables y el manejo de riesgos de un proceso de pruebas. Es posible manejar un plan global que abarque los distintos tipos de pruebas como lo son la verificación e integración.

El módulo del plan de pruebas es un instrumento muy útil para dar estructura tanto al proceso de pruebas como a la documentación de las mismas es el plan de pruebas.[2]

Algunos aspectos que se deben contemplar para un plan de pruebas son los siguientes:

1) Identificar el plan: se debe permitir relacionar con el alcance. Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicional-mente la versión y fecha del plan.

2) Alcance: Indica el tipo de prueba y las propiedades o elementos del software a ser probado.

3) Items por probar: Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es difícil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4) Estrategia: Describe la técnica, patrón o herramienta que se pueda utilizar en el diseño de los casos de prueba. Como por ejemplo en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la pre-condición". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar. La estrategia también explica el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.

5) Caracterización de la configuración: Hace de forna explícita las condiciones bajo las cuales, el plan debe ser suspendido-repetido-culminado.
En algunas circunstancias el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicarse a partir de qué punto, ya que puede ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.

6) Tangibles: En este caso los documentos a entregarse al culminar el proceso previsto por el plan deben estar de la mayor forma posible bien estructurados.

7) Procedimientos especiales: Identifica el grado de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8) Recursos: Se deben identificar las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas. Cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar.

9) Calendarios: Esta parte describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. Se puede realizar con diagramas como el diagrama de Gantt.

10) Manejo de riesgos: Identifica los riesgos en el plan, las acciones que lo solucionan y la contingencia de estos.

11) Responsables: Especifica quién es el responsable de cada una de las tareas previstas en el plan.[1]

Plan de Pruebas - IEEE 829
La estructura de un plan de pruebas en este tipo de estándar es el siguiente:

1- Introducción
2-Items de pruebas
3-Supuestos
4-Características sujetas a pruebas
5-Características No sujetas a pruebas
6-Estrategia de prueba
7-Criterios de éxito/fracaso
8-Criterios de suspensión/devolución
9-Entregables de las pruebas
10-Tareas de la etapa de prueba
11-Recursos:
        Recursos hardware
       Recursos software
       Herramientas de soporte
12) Roles y responsabilidades
13) Riesgos del proyecto de pruebas
14) Dotación de personal y formación
15)Cronograma/Calendario.
16)Aprobación




Referencias:

[1] Obtenido de: http://www.calidadysoftware.com/testing.php
[2] Obtenido de: http://www.pruebasdesoftware.com/plandeprueba.htm

Cero Defectos del Software

En esta nueva entrada les estaré comentado acerca del "Cero Defectos" del software. Todo sobre este.

El Cero Defectos es un programa de la mejora de la calidad que tiene como objetivo principal que las cosas se hagan bien desde la primera vez. Este toma en cuanta la participación del operador, así como la forma de involucrarse con el producto y el proceso, y mediante una evaluación comprender las consecuencias que puede traer algún error.

Philip Crosby nació en Wheeling, Virginia Occidental el 18 de junio de 1926. Fue un empresario estadounidense, autor que contribuyó a la Teoría Gerencial y a las prácticas de la gestión de la calidad. Hasta su muerte se dedicó a la calidad.
Un dato muy importante es que fundó Philip Crosby Associates (PCA) con sede en Winter Park, Florida, y durante los diez años seguidos la convirtió en una organización con 300 empleados alrededor del mundo y con $80 millones con ganancias. P.C.A. enseñó a la gerencia cómo establecer una cultura preventiva para lograr realizar las cosas bien y a la primera. GM, Chrysler, Motorola, Xerox, muchos hospitales, y cientos de corporaciones alrededor del mundo vinieron a P.C.A. para entender la Administración de la calidad. Todavía enseña en 16 lenguajes alrededor del mundo.[1]

Componentes Básicos para la resolución de problemas y mejoramiento de la calidad:

1. Cuatro Fundamentos:
1. Pleno involucra-miento de la dirección.
2. Administración profesional de la calidad.
3. Programas originales.
4. Reconocimiento.
2. Los 5 principios de la dirección de calidad.
1. La calidad significa cumplir los requisitos del funcionamiento del producto.
2. No existen problemas de calidad.
3. No existen ahorros al sacrificar la calidad.
4. La calidad medida de desempeño es el costo de la calidad. 
5. El único estándar de desempeño es el cero defectos.
3. Los 14 pasos de Crosby los cuales son:
1. Asegúrese de que la dirección esté comprometida con la calidad.
2. Forme equipos para el mejoramiento de la calidad con representantes de cada departamento.
3. Determine como analizar dónde se presentan los problemas de calidad actuales y potenciales.
4. Evalúe el coste de la calidad y explique su utilización como una herramienta de administración.
5. Incremente la información acerca de la calidad y el interés personal de todos los empleados.
6. Tome medidas formales para corregir los problemas identificados a lo largo de los pasos previos.
7. Instituya una comisión para el programa "Cero Defectos".
8. Instruya a todos los empleados para que cumplan con su parte en el programa de mejoramiento de la calidad.
9. Organice una "jornada de los Cero Defectos" para que todos los empleados se den cuenta de que ha habido un cambio.
10. Aliente a los individuos para que se fijen metas de mejoramiento para sí mismos y para sus grupos.
11. Aliente al personal para que comunique a la dirección los obstáculos que enfrenta en la persecución de sus metas de mejoramiento.
12. Reconozca y valore a aquellos que participan activamente en el programa.
13. Establezca consejos de calidad a fin de mantener informado al personal en forma regular.
14. Repita todo para enfatizar que el programa de mejoramiento de la calidad no finaliza jamás. 

Ventajas: 

• Se concentra el esfuerzo en ámbitos administrativos y de procedimientos competitivos.
• Consiguen mejoras en un corto plazo y resultados meramente visibles.
• Si existe reducción de productos defectuosos por consecuencia hay una reducción de los costos.
• Incrementa la productividad y dirige a la organización hacia la hacia la competitividad.
• Contribuye a la adaptación en los procesos a los avances tecnológicos y permite alinear procesos repetitivos.

Desventajas:

• Se pierde la perspectiva de la interdependencia entre los miembros de la empresa. 
• El mejoramiento continuo se hace a un proceso muy largo.
• Requiere de un cambio en toda la organización y hay que hacer inversiones importantes

Una aplicación es el sistema "jidoka", que es la automatización  con la mano humana de que el sistema permita tener su propio auto-control de oportunidad.

Referencias:

[1] Obtenido de: http://www.pablogiugni.com.ar/httpwwwpablogiugnicomarp106/ 

Cobertura de Pruebas

En este blog les estaré brindando información acerca de la cobertura de las pruebas de software, tema sumamente interesante con respecto al aseguramiento de la calidad del software. 

Para iniciar, debemos tener claro el termino de cobertura, la cual es un concepto relacionado con la medición de la relación entre factores, y se la define como el grado en el cual un elemento específico es sometido a una batería de pruebas, donde el "elemento" de la cobertura puede ser cualquier cosa que debamos cubrir durante las pruebas.[1]

Es decir, se debe determinar cómo se vincula lo que se esta probando con el pedido del cliente y expresado en el requerimiento original, convertido tal vez en especificación funcional.

Es por esto que, de la medición que se realice, resultará el grado de cobertura en la que las pruebas están dando respuesta a todo lo que se necesita cubrir.

Un primer análisis que resulta de esta medición es conocer en qué área hace falta agregar más cobertura, como por ejemplo:

• Para las pruebas basadas en requisitos, se debe planificar medir contra las especificaciones.
• Para las pruebas basadas en riesgos, debemos planificar medir contra aquellos eventos de amenazas que podamos detectar.
• Para las pruebas basadas en ínter-operabilidad, se debe planificar medir la cobertura de las configuraciones y las interfaces. 

Si se logra alcanzar una cobertura de caja negra del 100%, y una cobertura de sentencias del 100%, por lo tanto podemos pasar a la siguiente fase: la cual es prueba de condiciones.

Otra forma de que pueda suceder es de que partes del código no hayan sido ejecutadas jamás (cobertura de sentencias inferior al 100%), por lo que para estos casos habrá que realizar más pruebas buscando que se ejecuten todas y cada una de las sentencias del programa. En este sentido, puede que hayamos conseguido una cobertura elevada de sentencias. pero tal ves nos estemos contemplando las ramas condicionales.

ramas condicionales: x=0; if(y<100){x++}

Si se considera durante las pruebas un valor de "y" inferior a 100, se habrán ejecutado todas las líneas; pero nunca la variante de que x no se incremente.

Se habla de una cobertura de ramas al 100% cuando se ha ejercido todas y cada una de las posibles vías de ejecución controladas por condiciones.

La cobertura de ramas es indiscutiblemente deseable; pero habitualmente es un objetivo excesivamente costoso de alcanzar en su plenitud, salvo que se haga con herramientas de automatización.

Por lo tanto, muchas personas recomiendan: 

• Realizar pruebas de caja negra hasta alcanzar una cobertura funcional del 100% (idealmente).
• Inspeccionar código ejecutado y agregar condiciones para someter a prueba a aquellas partes del programa no ejecutadas.
• Inspeccionar condiciones con un cierto grado de complejidad "difíciles" del código para intentar forzar variedad.

La medición de la cobertura es algo muy común en las pruebas de unidad. El objetivo de los desarrolladores es agregar los casos de unidad necesarios para lograr un 100% de cobertura. sin embargo, no es algo muy habitual cuando se hacen pruebas funcionales. Algunos equipos de calidad mantienen un reporte de áreas donde cada probador marca que área probó, pero no hay seguridad de que probaron el 100% de las líneas de código que el desarrollador puso en esa área.[2]

Es por esto que el equipo de calidad requiere manejar un buid que les permita medir la cobertura, de la misma manera que lo hacen los desarrolladores en las pruebas unitarias.

BIBLIOGRAFÍA

[1] Terrera, G. (1 de 09 de 2014). Testing Baires. Obtenido de https://testingbaires.com/sobre-cobertura-en-testing-parte-1/

[2] Guillén, C. (17 de 11 de 2014). Testing Software . Obtenido de http://www.testingsoft.com/espanol/2014/11/17/como-medir-la-cobertura-de-las-pruebas-funcionales-con-jacoco/

Pruebas Exploratorias

En esta nueva entrada les estaré brindando información acerca de las Pruebas Exploratorias, datos realmente interesantes desde quien las dio a conocer hasta como es que realmente funcionan.

El término "Testing Exploratorio" fue dado a conocer por Cem Kaner. Y se tiene que ver con ejecutar las pruebas a en que se va pensando en ellas, sin tener que tener que invertir mucho tiempo en preparar o explicar las pruebas, confiando más que todo en la parte del instinto. Estas pruebas exploratorias se pueden definir como el aprendizaje, el diseño de casos de prueba y la ejecución de de las pruebas de forma simultánea. 

En otras palabras, es una técnica de de pruebas en la cual quien prueba controla activamente el diseño mientras son realizadas, y utiliza la información en la exploración para diseñar nuevas y mejores pruebas.[1]

Una estrategia básica para realizar testing exploratorio es concebir un plan de ataque general, pero que permita desviarse de él por periodos cortos de tiempo e intereses diversos. Cem Kaner lo denomina el principio del "tour bus", las personas bajan del bus y conocen los alrededores con visiones variadas. La clave es no perderse el tour entero[1].

El éxito o el fracaso del testing exploratorio está íntimamente ligado con lo que sucede en la mente del tester. Algunas habilidades deseables en los testers son la capacidad de analizar el producto y evaluar los riesgos, utilizar herramientas y tener un pensamiento crítico acerca de lo que se sabe al momento de diseñar las pruebas. También es importante que los testers tengan la capacidad de distinguir lo observado de lo inferido; ya que las inferencias podrían inducirlos a no realizar pruebas que evidencien vulnerabilidades del producto. El uso de heurísticas desempeña un rol importante en la producción de ideas variadas. Una heurísticaes un mecanismo mental para generar pruebas variadas y acordes a las características del producto que se está probando, por lo que es deseable que los testers las tengan presentes al momento de realizar testing exploratorio [2].

¿Y para qué sirve el testing exploratorio?

Las pruebas exploratorias deben ser como complemento a todas los demás tipos de pruebas existentes.

Es bastante importante para: 

* Profundizar y obtener feedback rápido sobre algo concreto.

* Aprender sobre la aplicación.

* Si ya cubres una parte del testing con automatización, testeo y verificación manual de funcionalidades etc. y quieres buscar bugs más complejos.

* Mejorar la documentación de la aplicación, de los casos de prueba o los scripts de automatización (ya que podemos usar la experiencia adquirida para mejorar la documentación de la aplicación, de los casos de prueba, etc.)[3].

El testing exploratorio requiere su planificación, limitación de tiempo y objetivo, no está reñido con documentar y hacerlo bien es más complicado[3].

Referencias:

[1] J. Bach, “Exploratory Testing Explained”, The Test Practicioner, 2002, Obtenido de: http://www.satisfice.com/articles/et-article.pdf

[2] Pérez, B., Pittier, A., Travieso, M., & Wodzislawski, M. (2007). Testing exploratorio en la práctica. CES.COM, 7.

[3] Garzas, J. (9 de Enero de 2015). javiergarzas.com. Obtenido de http://www.javiergarzas.com/2015/01/testing-exploratorio-10-min.html