Es a lo que le llamo usabilidad :) YouTu

Es a lo que le llamo usabilidad
YouTube – Microsoft Surface Demo @ CES 2008 http://ow.ly/15izq

Lindos avances que ya son una realidad..

Lindos avances que ya son una realidad…
YouTube – Microsoft: No more keyboards http://ow.ly/15isR

Microsoft’s long-term productivity visi

Microsoft’s long-term productivity vision explores how we will create and share content; collaborate across teams, organizations and networks.
Lo que me más me gusta es como el idioma dejará de ser una barrera y que existirán los post-it, algo que no he podido dejar de usar aún…
YouTube – Office Labs: Productivity Vision Video http://ow.ly/15ic6

Perhaps the clearest sign of the mainstr

Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations.

Forrester Research http://ow.ly/127ME
Pensar que lo digo desde el 2007.
Después de esto vale la pena una siesta con alevosía.

Córdoba Clima – Condiciones actuales, pr

Córdoba Clima – Condiciones actuales, pronósticos y mapas http://ow.ly/125aX
Les deseo un lindo fin de semana a todos

Transform QA and Enable Business Agility

Transform QA and Enable Business Agility
Businesses today are looking at IT and QA functions as drivers of change in enabling business agility. IT organizations need to realign themselves to steer this agility by establishing a synergy between business, IT, and QA teams. http://ow.ly/Yjtd

Embedding QA: Cuando las planning fallan

Embedding QA: Cuando las planning fallan en las metodologías Agile. http://ow.ly/Y2Fx

Junior JAVA Developer | Oferta de trabaj

Junior JAVA Developer | Oferta de trabajo en THE PINNACLE CORPORATION
http://ow.ly/WGT5

Tips para no ser un jefe OGT. http://ow.

Tips para no ser un jefe OGT.
http://ow.ly/WvAw

Embedding QA: ¿Consultoría profesional p

Embedding QA: ¿Consultoría profesional para implantar prácticas SQA? http://ow.ly/WvoW

Quien estima mejor? participa en esta en

Quien estima mejor? participa en esta encuesta. http://ow.ly/WbAg

Gestión de requisitos con Agiles http://

Gestión de requisitos con Agiles http://ow.ly/W9EC

Editing my new personal blog. Be patient

Editing my new personal blog. Be patient and please, participate with your comments. http://ow.ly/W6ZN

Virtualización en QA Testing

Recientemente tuve que utilizar varias máquinas virtuales para ejecutar pruebas y resulta que la única alternativa que tuve a mano fue la utilización de Virtual PC (Microsoft). Luego de haber finalizado las pruebas, emití un informe resumido donde también explico los problemas que tuve y que solución podría aplicarse para esos problemas.

Los problemas básicamente tuvieron que ver con que más del 35% del tiempo fue utilizado en generación de Upgrades de los sistemas que estuve utilizando, como también procesos de desinstalación, limpiezas de registros y otras cosas tradicionales. Este porcentaje se vio agrabado, ya que al no disponer de un servidor dedicado de máquinas virtuales, fue necesario mover archivos de un PC a otro, cuidando espacios de discos, rendimientos de PC anfitrionas y por supuesto, el preciado tiempo del que dispongo para cumplir mis objetivos.

Dado esta última restricción, tiempo, es que decidí lisa y llanamente, realizar los procesos de instalación / desinstalación / upgrades, etc. utilizando solo dos equipos anfitriones donde correrían 4 máquinas virtuales en total.

Las respuestas a mi informe no se hicieron esperar y ahora estoy en la tarea de una comparación para determinar que tecnología podría ser mejor para aplicar en un entorno de testing dedicado, de manera virtualizada.
Por suerte ya tuve la experiencia de trabajar en entornos especializados, virtuales, para testing y puedo contar al menos como fue con VMWare.

Pero lejos de contar esto, solo quiero destacar que la discusión actual se centra en que hardware es necesario para dar soporte a la virtualización y es así que llegué a observar un lindo cuadro comparativo que hizo un tal “Termik”, usuario del lejendario sitio Softonic.

Termik compara el rendimiento de Virtual PC, VirtualBox y VMware, con “Host”, que es el rendimiento de su sistema operativo. Así se pueden ver de maravilla las diferencias de hacer una misma acción en una máquina virtual y hacerlo directamente en el sistema operativo instalado. De verdad, con opiniones así da gusto.

Comparativa de rendimiento software virtualización

Las pruebas han sido realizadas utilizando como equipo host un portátil Pentium M 1.6 GHz con 752 Mb de RAM.

Las máquinas virtuales han sido Windows XP SP2 Profesional con 320 Mb de RAM y disco duro de expansión dinámica. Para que la comparativa de rendimiento sea más precisa todas las instalaciones han sido nuevas, instalándose como único software: PC Mark 2005, 7-Zip, Direct-X 9 y los drivers exclusivos para virtualización.

PC Mark 2005 es una referencia en la industria para evaluar el rendimiento de un PC, pero en este caso debido a las peculiaridades de una máquina virtual (no admite aceleración gráfica por hardware y el disco duro es virtual) nos hemos ceñido solo en realizar los test de rendimiento CPU y Memoria.

7-Zip es una excelente herramienta de compresión que admite la ultra-compresión, consiguiendo unos ratios de compresión mejores que Zip, Rar y Ace. El método de compresión Ultra necesita de unos altos requerimientos de RAM y de CPU siendo un método formidable para evaluar el rendimiento de una máquina. Podíamos haber utilizado también algún compresor de vídeo, pero con 7-Zip ya nos basta.

El software de virtualización evaluado ha sido Virtual PC 2007, VirtualBox 1.5.2 y VMware 6.02.

Debido a que la velocidad de reloj de las máquinas virtuales se descontrola un poco ante pruebas de estrés el resultado obtenido por PC Mark 2005 no ha sido todo lo preciso que pudiera ser, para el resto de pruebas hemos utilizado un cronómetro externo. La realización de cada una de las pruebas ha sido ejecutada previo reinicio de la máquina virtual y ha sido realizada tres veces, el resultado mostrado es la media de las tres, solo para PC Mark 2005 – CPU hemos necesitado de 12 reinicios (4 x 3).

Puntuación PC Mark 2005 – CPU:

• Host: 2807
• Virtual PC: 2704
• VirtualBox: 2742
• VMware: 2730

Puntuación PC Mark 2005 – RAM:

• Host: 2345
• Virtual PC: 2333
• VirtualBox: 2245
• VMware: 2087

Tiempo empleado en copiar 345 Mb de archivos del Host a la máquina virtual:

• Virtual PC: 2 min. 35 seg.
• VirtualBox: 2 min. 37 seg.
• VMware: 1 min. 24 seg.
Tiempo empleado en comprimir con 7-Zip:

(345 Mb de archivos método Ultra, tamaño de diccionario 16 Mb y de palabra 256)

• Host: 7 min. 21 seg.
• Virtual PC: 8 min. 19 seg.
• VirtualBox: 12 min. 30 seg.
• VMware: 7 min. 52 seg.

Tiempo empleado en iniciar la máquina:

• Host: 40 seg.
• Virtual PC: 41 seg.
• VirtualBox: 14 seg.
• VMware: 42 seg.

Consumo de RAM con la máquina virtual en ejecución:

• Virtual PC: 348 MB
• VirtualBox: 355 MB
• VMware: 397 MB

Tamaño de la instalación:

• Virtual PC: 36 MB
• VirtualBox: 33 MB
• VMware: 733 MB

A lo largo de los últimos años hemos visto como han ido mejorando cada vez más el rendimiento de estas máquinas virtuales, acercándose cada vez más al ordenador que las aloja (host), en el caso de Virtual PC 2007 por ejemplo se ha conseguido triplicar el rendimiento de la versión 2004. En el caso de VMware el rendimiento es de un 93% del host!!! Si nuestro procesador soporta virtualización puede mejorarse aún más.

fuente: Softonic

En lo personal creo que este tópico solo tiene sentido discutirlo y analizarlo, si los problemas por trabajar con equipos anfitriones comunes, son superiores a las soluciones que actualmente podemos brindar.

Por lo pronto voy identificando que para Testing es dramático la pérdida del 50% del tiempo asignado, solo para generación de ambiente.

Thinking a Test Case – Generic example

<TC.03.06>
‘DataPush packet’ without ‘Assigned Locations’ is not exported
<Summary>
Normal behavior
Is not possible to export a DataPush packet without assign a ‘Location’
<Steps>
1, Follow the path (Setting/Location/Inventory/DataPush)
2, Press the ‘New’ button in the DataPush screen
3, Select the ‘General’ tab
4, Enter a description in the ‘Description’
5, Select the ‘Packet Content’ tab
6, Press the ‘Add’ button
7, Choose a date using the drop down list in the left superior corner into the ‘Item Type Of’ section.
Example: (Initial Set Up/All)
8, Select one ‘Item Type’ in an individual way or pressing the ‘Select All’ button (recommended)
9, Press the ‘Accept’ button
10, Select the ‘General’ tab
11, Press the ‘Export Packet’ button
<Expected results>
A, the DataPush packet is not delivered
B, a clear alert message pop up notifies that there are no locations defined

Main concept

Subject
Subject + Condition+ Event (Wanted / Unwanted)
Summary
Brief description indicating the current situation. (The behavior actually produced when the object is tested under specified conditions)
Steps
Specific sequence of activities to follow to reproduce de event
Expected results
Brief explicit description of the expected behavior after complete the Steps. (The behavior predicted by the specification of an object under specified conditions)

Agile facilita la separacion de areas

Agile nos facilita un marco para las rapidas adaptaciones, no solo cuando hablamos de “artefactos de desarrollo” o “productos”, sino especialmente cuando hablamos de modelos de negocios.
Los distintos formatos organizacionales vienen migrando hacia modelos mas colaborativos, con menor foco en la separacion de areas y de disminucion de roles y mayor volumen de compromiso con los clientes, trabajando con empe;o en los cumplimientos de los acuerdos de servicios, mejorando la cadena de valor y todo esto haciendo foco en la calidad.
He comenzado a notar cada vez mas, que mientras una corriente de pensamiento del agilismo sostiene que los equipos deben trabajar sin separaciones (inclusive fisicas) y abordar los asuntos basandonos en equipos consolidados y con experiencia en lo que se trata, otra corriente trabaja bajo el concepto de que AGILE permite, apoya y facilita la separacion de areas, ayuda en el sosten de la independencia y asi las proyecta convirtiendolas en mas utiles por si mismas al colaborar con otras areas brindando un aporte exquisitos en pos de los mismos objetivos.
Este segundo marco de trabajo, a mi entender, permite pensar en Agile como una valiosa herramienta de aprovechamiento de recursos, ayudando a que los equipos puedan estar conformados por personas fisicamente separadas, tener una formacion conceptual y metodologica plenamente diferente y hasta modos de gestion diversos.
Agile puede ser observado desde las entra;as de un equipo operativo o desde las ventanas reducidas del managment y la direccion. A cada nivel le sera util de distintas maneras y el modo de gestion a mi entender solo terminaria siendo una herramienta que ayuda a enmarcar mejor lo que cada organizacion comprende como Agile.

Use Repro to test applications while Repro runs silently in the background

http://www.reprosoftware.com/index.htm

• No changes to the application source code are required. Simply add the application(s) to be instrumented through a menu option.

Create a Repro when a bug occurs by simply clicking on the Repro tray icon and selecting ‘Found a bug.’

Preview the Repro file and trim the bug to the appropriate time frame.

Estas son las actividades básicas que QA/Testing realizan a diario o periódicamente.

QA/Testing common activities

Cada una de ellas es llevada a cabo considerando la participación de roles transversales y responden a una necesidad y/u objetivo de negocio de la organización.
Existen muchas otras actividades comprendidas en estas macro actividades.

No cuentes el tiempo que usas en generar…

No cuentes el tiempo que usas en generar el entorno de testing y prepárate para explicar por que aún el testing no finaliza.
Si por cada vez que debes iniciar una actividad de testing, debes preparar ambientes nuevos o actualizar los existentes, configurando, modificando o cambiando tu juego de dato para hacerlo significativo, entre otras tantas acciones previas al testing efectivo, entonces será mejor que incluyas ese tiempo en tus estimaciones o te verás acorralado contra la línea de tiempo final.
Inclusive si tu actividad de ejecución de las pruebas en si mismo, es corta, es decir si tus casos de pruebas son simples y de un corto tiempo de ejecución, es absolutamente posible que la preparación del entorno para tales ejecuciones pueda consumirte el doble o más tiempo del que usas para hacer las pruebas.
Esto es algo que posiblemente un manager no lo comprenda y suele ocurrir muy seguido. Un síntoma muy claro es cuando se espera que la actividad de testing finalice en tiempo y en forma, aún cuando los desarrollos no finalizaron en término y se consumieron una franja del tiempo de testing.

Agile en los procesos de selección RRHH. Nuevos paradigmas contra nuevos paradigmas?

Durante 5 meses y medios participe en más de 10 entrevistas de trabajo en las consultoras, más de 5 en las empresas en su área de RRHH, tuve más de 15 entrevistas vía telefónica. Me llamaron hasta 7 veces distintas consultoras a nombre de la misma empresa. Me dijeron “solo falta un trámite” en más del 70% de las veces, “la semana que viene te llamamos por que te fue muy bien en los técnicos” en más del 50% y puedo seguir con la lista de “casis” hasta hartarnos.
En las distintas entrevistas en su primera fase, normalmente realizada por las especialistas en RRH, tuve un éxito importante, en las técnicas superé la mayoría de ellas y en otras fracasé hasta por falta de entusiasmo. Pero aún así, la decisión final de darme trabajo siempre fue resuelta por una suspicacia, una duda intrínsica, o una “intuición”, quizás sobre mi perfil, quizás sobre mi personalidad. Entiendo que esta suspicacia podría haber sido solo mis pretenciones económicas, pero jamás negociamos.
Aparentemente todo lo previo a esta etapa no tuvo peso significativo o lo que es peor, siempre hubo un recurso más barato.
Solo en dos oportunidades llegué a conversar con el gerente general. En una nos miramos y no congeniamos. Demás está explicar el resultado. En la otra me quedé esperando su llamado para “comenzar el lunes”. Finalmente muy amablemente pude “hacer mi descargo.”
Recientemente me integré a una empresa norteamericana radicada en la provincia de Córdoba. Estoy muy contento no solo por el grupo que la conforma, sino por el proceso de selección directo asumido por su líder al frente de la organización.
Este proceso directo me pareció especial y bien dirigido, asumiéndose todas las responsabilidades, desde la búsqueda y selección, hasta las entrevistas iniciales, técnicas y negociaciones de salarios y otros términos. Pude observar que fue un proceso libre de vicios, prejuicios, suspicacias y otros metodologías aburridas, perennes e ineficaces. En esto SOS o NO SOS.
Mi actual jefe una tarde terminó su entrevista técnica conmigo, ayudado por su líder técnico y lejos de indicarme que todo estaba a mi favor, dejó que me marchara hasta una nueva oportunidad. Al final de la tarde me pidió que me acercara a la oficina (no su secretaria ni la “chica RRHH”), conversamos unos minutos más e hizo su propuesta laboral, clara, precisa, sin rodeos y cerramos el trato.
De pronto sentí nuevamente tener mucha suerte. Haber pasado por tanto manoseo de pasamano y de pronto estar negociando mi futuro con el “dueño del circo” y cerrar trato muy favorablemente.
Esta no es una empresa pequeña ni mediana, es una gran empresa con un montón de cosas bien aceitadas, un montón de gente trabajando en conceptos absolutamente de puntas, entre los que menciono Agile.
¿Será que Agile ya está embebido en su proceso de selección de recursos? por que los principios del cara-a-cara fueron excelentemente aplicados aquí, no por que yo haya quedado, sino por que me tocó vivirlo y ahora lo estoy disfrutando desde adentro.
Por favor las empresas de Argentina y del resto del mundo, revean sus procesos de selección. Dejen de poner en manos de consultoras externas la definición de sus relaciones con sus colaboradores. No digo que no pidan su participación, pero selecciónenlas a ella previamente, expliquen quien toma la decisión y quienes deben llegar hasta los escritorios de los manager para entablar una relación duradera y de confianza.

Podcast: Personas, equipos, talento y gestión ágil

Software Testing Advice for Novice Testers

Algunos me han preguntado que cosas tener en cuenta cuando se es un principiante en materia de Testing del Software. Mis respuestas particulares ya las di­, pero en viajes por Internet encontre un interesante sitio y un arti­culo muy bueno para tener en cuenta, aun cuando se es un experto.
Algunos conceptos solo son posibles de entender cuando los has vivido.

Software Testing Advice for Novice Testers

Próxima compra de servicios de desarrollo. El tamaño no importa…

Según tu experiencia como comprador de servicios de desarrollo de software, ¿te sientes satisfecho o aún estás intentando decidir con cual otro proveedor reemplazar los servicios actuales?

Pero en esta oportunidad ¿indagarás sobre aspectos internos del proveedor o volverás a limitarte a las cuestiones contractuales y de costos?

Algunos de los profesionales con los que he conversado en este sentido me han indicado que en el 90% de los casos basta con entregar las funcionalidades principales dentro de unos límites de tiempo, costos y calidad. Inclusive dejando una gran deuda de funcionalidad, los clientes desean evitar confrontaciones y amplian sobradamente los tiempos, habilitan un incremento del presupuesto y son los que por lo general absorven los costos.

Esto quizás solo es la consecuencia de los síntomas enquistados en la mayoría de los proveedores de desarrollo de software, normalmente PyMEs.

Pero “no hay peor ciego que el que no quiere ver” y si tu gestión de proveedores es buena, no puedes evitar indagar profundamente sobre algunos aspectos que influyen no solo en la calidad de tus productos solicitados, sino en la calidad de los proyectos que compras. Ten en cuenta que en definitiva, lo que compras es un proceso de desarrollo y una gestión que afecta a personas y sería muy bueno que tu proveedor pudiera acreditar calidad en la vida de las personas al ejecutar proyectos para tus productos.

Estas son algunas de mis sugerencias sobre ítems a exigir a tus proveedores:

• Metodologías de desarrollo
• Existencia de técnicas de integración continua
• Patrones de desarrollo
• Procedimientos de pruebas unitarias
• Repositorio, seguridad de datos y respaldo
• Procedimientos de Testing por terceros (Independencia de QA)
• Pruebas de rendimiento
• Pruebas de funcionalidad
• Pruebas de usabilidad
• Pruebas de aceptación
• Gestión de defectos y métricas
• Gestión de proyectos
• Gestión de documentación en entornos colaborativos
• Entorno de trabajo y estilos de liderazgo

Parece exagerado? solo piensa que una empresa que no invierte en estos aspectos, no invierte en la calidad de sus servicios y si logras un producto de calidad, seguramente el proyecto habrá sido de una calidad dudosa o pésima y quienes sufren el impacto son los recursos humanos.

La proxima compra de servicios de desarrollo de software, hazlo con una empresa seria. No importa su tamaño.

Testing Unitario y Automatizado (lecturas recomendadas)

A pedido tuyo amigo mío (Jorge Luís Giménez) ahora que el testing te está exigiendo más conocimientos y reconoces que la calidad del software no es un aspecto que deba ser atendida solo por programadores.
Estos enlaces que te paso son solo el principio. Que bueno sería que pronto nos expliques cosas que aprendiste.
En el mundo somos muchos que buscamos algún tipo de soporte y esto suele no estar al alcance de la mano o no es muy barato que digamos.

Lectura recomendada:
Unit Test Patterns
Advanced Unit Testing, Part I – Overview
Advanced Unit Testing, Part II – Core Implementation
Advanced Unit Testing, Part III – Testing Processes
Advanced Unit Testing, Part IV – Fixture Setup/Teardown, Test Repetition, And Performance Tests
Advanced Unit Testing, Part V – Unit Test Patterns
http://mbunit.tigris.org

Aplicaciones recomendadas para Unit Test Automation :
CSUnit, NUnit, JUnit

Herramienta de diseño de Pruebas Unitarias
MbUnit

Al rescate del 60%

Recientemente leí un artículo interesante en la versión digital de La Nación, el cual en su marco principal trata sobre “qué hacer y cómo tratar a las nuevas generaciones de empleados que nacieron entre 1981 y 2000, y que traen en su ADN una nueva manera de insertarse en el mundo del trabajo”. En este artículo me interesó un concepto particular y es que según estudios recientes, se determinó que el 60% de la fuerza laboral estaría representado por empleados desmotivados cuyo aporte es el mínimo indispensable para la organización y que en lugar de hacer un aporte efectivo estarían generando pérdidas.

Esto me llevó a reflexionar sobre mi participación en distintas empresas de Argentinas y de las cuales finalmente me desvinculé, principalmente por cuestiones de motivación y una falta de misión y compromiso de tales empresas con su empleados, o por el parcialismo que representó su accionar.

Más de una vez me pregunté que ocurre con aquellas personas que por sus características personales y capacidades profesionales o adecuaciones realizadas de su aprendizaje, fueron seleccionadas para pertenecer a un equipo de trabajo para el cual se le brinda inicialmente una apertura y participación amplia, pero con el correr del tiempo, proyecto a proyecto la resultante es un un aporte operativo básico, carente de participación en opinión analítica, crítica constructiva y pensamiento diferenciado.

Creo que las insistentes “conversaciones en pasillos” entre empleados, sobre las malas políticas de RRHH, sueldos bajos, falta de capacitación o el exceso de las mismas, más la poca o nada de relación esfuerzo/compensación, en realidad tienen mucho más que ver con la falta de participación y opinión que se le ofrece a los empleados, que con los ítems negativos.

Es allí donde veo la falta de preparación de las diferentes líneas gerenciales y jefaturas, quienes manifiestan a las claras su falta de liderazgo al no saber declarar una misión, transmitir la visión, conseguir el compromiso y motivar para el cumplimiento de los objetivos.

Creo que gran parte de ese 60% de empleados desmotivados fueron finalmente empujados a esa actitud nociva y destructiva. Es posible que de alguna manera su accionar sea un acto de ajusticiamiento y revancha.

No se debe “tirar a la hoguera” a un soldado que aún vivo huye, sino rescatarlo, curarlo, re reclutarlo y aliarlo bajo un nuevo compromiso. Es importante considerar que, si como líderes y organización no estamos listo para “el rescate”, nuestra vida laboral también será complicada y en camino hacia un valle de desánimo, con un tendal de gente que “no trabaja motivada” y otros que poco a poco planifican su huida.

“Exploratory testing is simultaneous lerning…

“Exploratory testing is simultaneous learning, test design, and test execution”

Esta hermosa frase me leventó el ánimo luego de haber ejecutado en forma manual una secuencia de TestCases diseñados en Testlink (una buena herramienta open source). Durante la ejecución no hice más que salirme de los caminos planificados e intentar alternativas que por mi intuición, sabía generarían un fallo.
Lo gracioso del asunto es que ciertamente, cada vez que me salía del plan, detectaba alguna anomalía y comencé a dudar del diseño de TestCases.
Esto tiene cierta lógica, ya que quien diseña un plan de prueba, naturalmente tiende al enfoque conservador orientado a la comprobación del correcto funcionamiento del software, similar a la postura del desarrollador y poco orientado a la “destrucción creativa” que propone un buen testing. Esta actitud nos propone diseñar pruebas en las cercanías de “el camino feliz” y respondiendo al juego de datos que normalmente haría que la aplicación tuviera un desempeño natural y eficiente.
Un enfoque de “destrucción creativa” basado en técnicas exploratorias, podría incluir un juego de datos poco convencional y alternativas de uso no contempladas, ni aún en los planes de testing más abultados.
La debilidad se centra en la mentalidad del diseñador y no en las técnicas formales de registración, que en definitiva solo son un soporte para un proceso repetitivo.
A su vez surgen otros problemas cuando un incorrecto diseño rige el proceso de testing:

. Uno podría ser la merma de creatividad en el acto de ejecución, con su consecuente pérdida de enfoque para la detección de fallos y aumento del enfoque que busca la confirmación del funcionamiento del sistema o aplicación. Aunque garantizo la posibilidad de repetir los casos tantas veces como se desee y aún teniendo la facultad de ampliar el diseño original, si el diseño original es trivial, mal enfocado o demasiado restrictivo, las ampliaciones solo serán una ampliación del error.
. Otro surge cuando se manifiestan los desvío en las ejecuciones de modo tal que una técnica aleatoria se presentan sin consenso y aumenta el riesgo de desviación de los tiempos de ejecución del plan. Aunque pueda detectar mayor cantidad de defectos, se pone en riesgo la naturaleza de los objetivos centrales del plan, la repetitividad y la rastreabilidad. Adiciono también la aparición de la necesidad de análisis por cada defectos detectado, por el solo hecho de explicar el contexto de detección donde se manifiesta el fallo.
En ambos casos la cobertura corre el mayor de los riesgos.
Este enfoque se presenta con tanta frecuencia en planes convencionales que aquí es donde propongo la creación de planes que permitan la aplicación de técnicas exploratorias.
Antes que nada tengamos en cuenta que las técnicas exploratorias, se caracterizan por ser unscripted e improvisadas, por lo que no es posible que cualquiera de los recursos afectados al testing pueda beneficiarse de este contexto, sino aquellos que tienen amplia experiencia en el aprendizaje, una gran intuición y gobiernan el contexto general del sistema y los negocios afectados.
Particularmente, solo me he permitido utilizar testing exploratorio en casos donde tengo la garantía de otros colaboradores ejecutando “testing tradicional” y me asigno tiempo en los planes, para actuar como un satélite que ejecuta “pruebas libres” como motor de ampliación de los caminos diseñados en los planes.
Muchos me han dicho que la ejecución del testing de manera exploratoria la puede ejecutar cualquiera, pero lo interesante es cuando se puede explicar el contexto y el modo de ejecución lo más detalladamente posible. Conseguir que lo intangible se transforme en tangible con solo la explicación verbal, excluye a la mayoría de los testers y managers.
Por esto mismo pienso que lo ideal es cuando se logra pasar a un punto donde las técnicas de diseño tradicional se mezclan con las bases del testing exploratorio y aun cuando ambas parezcan contradictorias, en realidad lo que se establece es un “juego de expectativas” que solo nos indica que tipo de trabajo debemos hacer y como se debe registrar, pero no da más detalles que solo aquellos que proveen la garantía de un excelente marco para el diseño.
Como manager de testing, siempre he querido ser quien más conoce de cada producto, sus características y sus comportamientos, pero no estár restringido a caminos normales y alternativos diseñados en base a otra documentación. Como tester, siempre tuve la intención de ser limpio en mis ejecuciones y facilitar la registración de nuevos caminos posibles. La ambiguedad esta presente en todo pero hay que saber lidiar con ella.
Creo que esta metodología es ideal, pues propone agilidad y creatividad, sin la pérdida de exactitud, repetición y rastreo.

http://www.satisfice.com/sbtm/