tag:blogger.com,1999:blog-91499711680631217292024-02-20T10:55:25.208-03:00Tengo una ideaEl blog de Germán BraunGermanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.comBlogger58125tag:blogger.com,1999:blog-9149971168063121729.post-20398692983908977062014-04-07T08:00:00.000-03:002014-04-07T08:00:12.220-03:00Power of Three<div style="text-align: justify;">
Algo que tienen que empezar a suceder para que los testers se involucren en el software desde el principio, es participar en las discusiones entre los desarrolladores y <i>product owner</i>. Para darle impulso a esto se puede aplicar la regla denominada <b>Power of Three</b>. Básicamente, significa que todas las discusiones sobre una nueva funcionalidad necesitan de un desarrollador, un tester y el <i>product owner</i>. Es responsabilidad del equipo que siempre haya un representante en este grupo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="font-size: x-small;">ref:</span> <a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468" style="background-color: white; border: 0px; color: #ea5546; font-family: 'Open sans', sans-serif; font-size: x-small; line-height: 15px; margin: 0px; outline: 0px; padding: 0px; text-align: start; text-decoration: none; vertical-align: baseline;">Agile Testing: A Practical Guide for Testers and Agile Teams</a></div>
<div style="text-align: justify;">
<br /></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2tag:blogger.com,1999:blog-9149971168063121729.post-40292228429273747852014-03-31T08:00:00.001-03:002014-03-31T10:05:23.611-03:00Principio #3 - Enable face-to-face communication<b>Principio de Testing Agile #3 </b>[1]<br />
<br />
<div style="text-align: justify;">
Ningún equipo puede trabajar bien sin una buena comunicación. Principalmente en estos tiempos en los cuales se tiende al trabajo distribuido. Aquí la comunicación es aún más importante y más desafiante.</div>
<div style="text-align: justify;">
Para un tester ágil, la comunicación es crítica. En todo momento, el tester se hace preguntas (es parte de su esencia) sobre cómo una funcionalidad debe trabajar o cómo una interface debe ser mostrada. Entonces, se deben habilitar canales con los desarrolladores y los expertos del negocio. Los testers deben hablar en estos dos idiomas y deben colaborar para que todos compartan un lenguaje común.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Finalmente, si bien la comunicación "cara a cara" nunca podrá sustituirse, hay que buscar formas "creativas" en caso que nuestro equipo esté distribuido.</div>
<br />
Germán<br />
<br />
<span style="font-size: x-small;">[1]</span> <a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468" style="background-color: white; border: 0px; color: #ea5546; font-family: 'Open sans', sans-serif; font-size: x-small; line-height: 15px; margin: 0px; outline: 0px; padding: 0px; text-decoration: none; vertical-align: baseline;">Agile Testing: A Practical Guide for Testers and Agile Teams</a><br />
<br />Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-82627323370583713222014-03-26T08:00:00.000-03:002014-03-26T08:00:02.425-03:00PrincipiosMe gustó esta lista de principios del libro <a href="http://www.amazon.com/The-Peoples-Scrum-Revolutionary-Transformation-ebook/dp/B00CO8CRDY">"The People's Scrum"</a> de <a href="https://twitter.com/tobiasmayer">@tobiasmayer</a>.<br />
<br />
<div style="text-align: justify;">
<b>Framework</b>: nos comprometemos a seguir los principios ágiles utilizando Scrum.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>Calidad</b>: nos comprometemos a construir calidad en nuestros productos en todos los estados de su desarrollo. Así como también, revisar continuamente y mejorar nuestras técnicas para alcanzarla.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>Personas</b>: somos profesionales y tenemos la responsabilidad de respetar a los otros, actuar honestamente, comunicar abiertamente, y buscar y dar ayuda cuando sea necesario.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>Proceso</b>: nos comprometemos a trabajar con la organización para definir a proceso mínimo para guiar nuestras actividades durante la duración de una iteración, apoyando al equipo para lograr completar su trabajo.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>Crecimiento</b>: como individuos, nos comprometemos a mejorar y compartir nuestro conocimiento (en la compañía), cuando sea apropiado.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-11535393860486061272014-03-24T08:00:00.000-03:002014-03-24T08:00:08.239-03:00Bugs should be about behaviour enhancements<div style="text-align: justify;">
Hace un tiempo que venimos hablando de que hacer testing es <a href="http://germanbraun.blogspot.com.ar/2013/08/hacer-testing-es-tambien-capturar.html">capturar conocimiento y que una de las formas operativas de obtener este conocimiento, es a través de los <i>bugs</i></a>. Esto me lleva a pensar que, en realidad, los <i>bugs</i> no son algo negativo, para nada. Es verdad que tienen "mala fama" pero tanto para el que los encuentra como para el que los arregla, debería ser algo positivo y atractivo, además de habilitar nuevas discusiones sobre lo que realmente se espera del producto (en muchas ocasiones esto puede no aplicar para los incidentes productivos, pero el usuario también debería comprometerse con el software).</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Dicho esto y basándome en el artículo de <a href="https://twitter.com/gojkoadzic">@gojkoadzic</a> <a href="http://gojko.net/2014/02/12/user-stories-should-be-about-behaviour-changes/">"User stories should be about behaviour changes"</a>, es que los <b>"Bugs should be about behaviour enhancements"</b>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-43775709859952866232014-03-19T08:00:00.000-03:002014-03-19T08:00:05.365-03:00Primera persona del singular<div style="text-align: justify;">
Llevo un tiempo trabajando con equipos y, pensando retrospectivamente, me doy cuenta que muchas veces me encuentro/nos encontramos dialogando con compañeros o clientes, anteponiendo el pronombre '<b>yo'</b> o usando verbos en <b>primera persona singular</b>. Este hecho marca el <b>sentido de no pertenencia a nuestro equipo </b>y atenta contra los ambientes colaborativos<b>. </b>Creo que una de las maneras de mejorar la comunicación y la colaboración, y que debería ser trabajada en retrospectivas, es la erradicación de este tipo de pronombres y verbos cuando hablamos en nombre del grupo. Potenciará el sentido de equipo, la pertenencia y el compromiso hacia él.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
<br />Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com1Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-57690225149576215822014-02-26T08:30:00.000-03:002014-02-26T08:30:03.446-03:00Vacaciones<div style="text-align: justify;">
En la entrada anterior hablamos sobre la pausa. Aquella que nos predispone al pensamiento crítico. Esta pausa es sólo de unos segundos, para tomarnos un respiro, pensar en la información que tenemos y usarla racionalmente.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hoy quiero hablar, brevemente, sobre otra pausa: <b>las vacaciones</b>. Es el tiempo en el cual deberíamos dejar de pensar en el trabajo. Tratar de no revisar mails (despreocuparse por el <i>inbox zero</i>) y dedicarse al ocio y al esparcimiento. Es el momento para viajar y retomar esos <i>hobbies</i> o actividades que tenemos relegados. Debería ser nuestra obligación.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
<div style="text-align: justify;">
<br /></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-81232712218055377502014-02-24T08:00:00.000-03:002014-02-24T08:00:09.076-03:00Pausa<div style="text-align: justify;">
<a href="https://twitter.com/michaelbolton">@michaelbolton</a>, en su <a href="http://www.developsense.com/blog/2014/01/the-pause/">blog</a> propone una nueva herramienta para los testers. Aunque también quiero hacerlo extensivo a desarrolladores y analistas. Dicha herramienta es <b>la pausa.</b></div>
<div style="text-align: justify;">
<b><br /></b></div>
<div style="text-align: justify;">
El desarrollo de software es una actividad compleja y, cómo toda profesión que requiere de un despliegue intelectual diario, necesita de una pausa. Según Bolton, una pausa es el efecto de aplicar las siguientes cuatro palabras: <b>Huh?, Really?, And? y So? </b>Cada una de ellas da un respiro y predispone al pensamiento crítico.</div>
<div style="text-align: justify;">
<br /></div>
<i><div style="text-align: justify;">
<i>Wait…<b>huh?</b> Did I hear that properly? </i></div>
<div style="text-align: justify;">
<i>Um…<b>Really?</b> Does that match with my experience and understanding of the world as it is, or how it might be? </i></div>
<div style="text-align: justify;">
<i>…<b>And?</b> What additional information might be missing?</i></div>
<div style="text-align: justify;">
<i>Okay…<b>So?</b> What are some consequences or ramifications of those interpretations?</i></div>
</i><div style="text-align: justify;">
<span style="font-family: inherit;"><span style="color: #333333; line-height: 25px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-family: inherit;"><span style="color: #333333; line-height: 25px;">Germán</span></span></div>
<br />Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-85694469890570153452014-02-19T08:00:00.000-03:002014-02-19T08:00:02.049-03:00Principio #2 - Entregar valor<b>Principio de Testing Agile #2</b> [1]<br />
<br />
<div style="text-align: justify;">
Como sabemos, <a href="http://agilemanifesto.org/principles.html">una de las prioridades del desarrollo ágil es entregar valor al cliente en pequeñas iteraciones</a>. Este valor es software funcionando y compuesto por las funcionalidades que se han priorizado recientemente. En este contexto, es fácil ceder ante los deseos del cliente para ciertas <i>features</i> y, si bien cualquiera en el equipo puede cuestionar estos puntos, es el tester ágil quién debe reconocer los impactos dentro de las <i>stories,</i> debido que debe pensar sobre las repercusiones del testing.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Los testers ágiles deben <a href="http://germanbraun.blogspot.com.ar/2013/12/we-dont-know-exactly-where-well-go-but.html">ver el todo</a> al momento de analizar las <i>stories</i> para identificar los caminos críticos. Las funcionalidades entregadas pueden crecer entre iteraciones y, si se pierde de vista la funcionalidad <i>core</i> sobre el "camino feliz", se corre el riesgo de no entregar nada. Si bien una de las habilidades de un tester es identificar casos más allá de este "camino feliz", es NECESARIO asegurarse que el camino funcione correctamente. SIEMPRE considerando lo que agrega más valor al cliente y entendiendo su contexto.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Por último, y no menos importante, es el tiempo de testing. Tiene que ser considerado durante el proceso de estimación para asegurarse que haya suficiente espacio en la iteración para entregar una funcionalidad correcta.</div>
<br />
Germán<br />
<br />
<span style="font-size: x-small;">[1] </span><span style="color: black; font-size: x-small;"><a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468">Agile Testing: A Practical Guide for Testers and Agile Teams</a></span><br />
<br />
<br />Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-37243656362258144152014-02-17T08:00:00.000-03:002014-02-17T08:00:04.488-03:00Testing y Scrum en el libro "The People's Scrum"<div style="text-align: justify;">
Leyendo el libro de <a href="https://twitter.com/tobiasmayer">Tobias Mayer</a>, me topé con un par de párrafos que relacionan al testing con la cultura de Scrum. Me pareció interesante para compartir. </div>
<br />
<div style="text-align: justify;">
<i>"The discipline of testing requires a lot more humility than the discipline of development. Testers tend to be more humble than developers; it is the nature of the role. There are different energies at play: development is characterized by the energy of creation, testing by the energy of service".</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>"The mission of scrum is to change the way we work. This is not process change, this is cultural change. People inside a scrum/agile process (we hope) behave differently. We now have test-infected developers. That's great. We have developers who see the value in testing, and do it. They don't push it off to QA people at the end of process"</i></div>
<div style="text-align: justify;">
<i><br /></i></div>
<div style="text-align: justify;">
<i>"I want to see testers passionate about create new software, no just validating someone else's software. I want to see testers weave themselves into the creative process from requirements all the way through to release"</i></div>
<br />
Yo quiero lo mismo!<br />
<br />
Germán<br />
<br />
<br />Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-73549277606770901412014-02-12T08:00:00.000-03:002014-02-12T08:00:05.451-03:00Hasta dónde hemos llegado...<div style="text-align: justify;">
Hace unas semanas, una persona me contacto por <a href="http://www.linkedin.com/">LinkedIn</a> para que le comente sobre testing (en general). Aquí dejo algunas reflexiones de mi respuesta.</div>
<div style="text-align: justify;">
<br /></div>
<div>
<div style="text-align: justify;">
Recuerdo que <a class="g-profile" href="http://plus.google.com/110288085067434958046" target="_blank">+Ernesto Kiszkurno</a> (socio de la consultora en la cual trabajo), siempre me decía que cuando empezaron a trabajar en testing, a ofrecer y vender servicios, los miraban como "personas extrañas". Nadie entendía lo que querían hacer y, obviamente, había una resistencia importante. Esto hace ya unos 15 años. Esta resistencia, era normal. Alguien te venía a decir que tu software "estaba mal". ¿Cómo es esto?</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hoy en día, el testing ya está totalmente aceptado y es indispensable para el desarrollo de un producto. Como consecuencia, la responsabilidad de los testers también se ha potenciado. Deben dar soporte a la <a href="http://germanbraun.blogspot.com.ar/2013/07/hacer-testing-es-tambien-capturar.html">captura del conocimiento</a> y gestionarlo. No sólo deben detectar ciertos desvíos funcionales o errores triviales que pueden tener cualquier software, sino hay que involucrarse mucho más en el dominio. Las prácticas ágiles (TDD, ATDD, BDD, DDD) que involucran desarrollo basado en pruebas, son también un punto de encuentro entre developers y testers que potencia su relación y realza la necesidad de trabajar con foco en la calidad.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Finalmente, creo que el próximo paso es aceptar y dejar de lado (definitivamente) el famoso <a href="http://germanbraun.blogspot.com.ar/2013/09/basta-de-dev-vs-qa.html">"developers vs testers"</a> para pasar a ser un grupo homogéneo de profesionales trabajando en pos de entregar valor. Un equipo multidisciplinario que tiene como único objetivo, construir software de calidad. La gente depende cada vez más del software y se debe dar soporte a esto. Superar este obstáculo dará impulso para concretar e imponer un meta-enfoque que podríamos llamarlo algo así como <b>Quality-Driven Development (QDD)</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
En resumen, enumero algunos hitos que se fueron sucediendo y otros, que espero, puedan concretarse y aceptarse definitivamente. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1. Resistencia al testing.</div>
<div style="text-align: justify;">
2. Aceptación como la última etapa de un proceso de desarrollo cascada (waterfall)</div>
<div style="text-align: justify;">
3. Necesidad de incluir prácticas de calidad más temprano en el ciclo.</div>
<div style="text-align: justify;">
4. Surgimiento de testing agile (TDD, BDD, ATDD) para trabajar sobre el desarrollo gestionado con pruebas.</div>
<div style="text-align: justify;">
5. Testing como actividad que retroalimenta la captura del conocimiento del software.</div>
<div style="text-align: justify;">
6. Fin de la rivalidad <a href="http://germanbraun.blogspot.com.ar/2013/09/basta-de-dev-vs-qa.html">"developers vs testers"</a><br />
7. Imposición de un nuevo concepto <b>QDD (Quality-Driven Development)</b></div>
<div style="text-align: justify;">
<br /></div>
</div>
<div style="text-align: justify;">
Germán</div>
<div style="text-align: justify;">
<br /></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-83277238074471768262014-02-10T08:00:00.000-03:002014-02-10T08:00:06.214-03:00Principio #1 - Dar feedback continuo<div style="text-align: justify;">
<b>Principio de Testing Agile #1</b> [1]<br />
<br />
En el contexto de un equipo ágil, el tester está involucrado en el producto desde los inicios. Desde bien temprano, en la primer iteración. Muchos proyectos ágiles están "manejados" por <i>tests </i>y, en consecuencia, el <i>feedback</i> juega un rol importante en ellos. En principio, el <i>feedback</i> comienza trabajando con el <i>product owner</i> o cliente para articular las <i>stories</i> mediante ejemplos y <i>tests</i>. Luego, los testers trabajan junto con sus otros miembros del equipo para generar escenarios ejecutables a partir de los requerimientos relevados. La ejecución de estos <i>tests</i> es otra fuente continua de <i>feedback</i>. Por último, los testers pueden mostrar su progreso dando una vista global de <i>tests</i> creados/ejecutados/OK así como del cubrimiento funcional de sus pruebas.<br />
<br />
En cualquiera de estas situaciones, el <i>feedback</i> es una manera de ayudar a remover obstáculos y promover la cultura del trabajo colaborativo.</div>
<br />
Germán<br />
<br />
<span style="font-size: x-small;">[1] <span style="color: black;"><a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468">Agile Testing: A Practical Guide for Testers and Agile Teams</a></span></span><br />
<span style="font-size: x-small;"><br /></span>Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-49315825665044203782014-02-05T08:00:00.000-03:002014-02-05T14:05:44.812-03:00Never lose a BUG againSabios consejos <b><a href="http://go.cloudshare.com/LinkedinAds_QA.html?source=Linkedin&camp=QA&medium=CPC&term=NeverLoose&content=&term=">[1]</a></b><br />
<div>
<br />
<ul>
<li style="text-align: justify;">Controlá tus tests.</li>
<li style="text-align: justify;">Compartí tus <i>bugs</i> tal cómo los encontrás.</li>
<li style="text-align: justify;">Capturá tu pantalla, adjuntá al incidente y seguí trabajando. Los <i>developers</i> verán la aplicación exactamente como estaba cuando encontraste el <i>bug</i>.</li>
<li style="text-align: justify;">Eliminá las excusas: no digas más "Funciona en mi PC".</li>
</ul>
<br />
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-30806334107492281842014-02-03T09:03:00.000-03:002014-02-03T10:17:57.065-03:00Principios esenciales para Automatización de Pruebas Funcionales<div style="text-align: justify;">
La última <a href="http://www.testingexperience.com/">Testing Experience</a> tiene un interesante artículo sobre principios para tener en cuenta al momento de automatizar tests funcionales. Los quería compartir aquí ya que me parece importante tenerlos bien presentes.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<b>1. Primero, diseñar los tests. </b>Evitar la creación de tests <i>on the fly</i>. Nuestra <i>suite</i> de tests debe crecer orgánicamente.</div>
<div style="text-align: justify;">
<b>2. No automatizar todo. </b>Ciertos tests pueden ser fácilmente ejecutados en forma manual, evitando así el alto costo de automatización.</div>
<div style="text-align: justify;">
<b>3. Escribir tests cortos. </b>En situaciones en las que uno o más tests fallen, cualquier miembro del equipo debe ser capaz de <i>trackear</i> la causa del error. Es recomendable usar <a href="http://dannorth.net/introducing-bdd/">BDD (Behaviour-Driven Development) </a></div>
<div style="text-align: justify;">
<b>4. Crear tests independientes. </b>Evitar el acomplamiento y aumentar la cohesión de los tests.</div>
<div style="text-align: justify;">
<b>5. Enfocarse sobre su </b><i style="font-weight: bold;">readability. </i>El código fuente de cada test debería estar <i>self-documenting</i>. Comentarios en el código deben ser evitados.</div>
<div style="text-align: justify;">
<b>6. Tests deben ser rápidos. </b>El testing funcional automatizado debe ser un indicador rápido de la calidad de la aplicación. Además, en un ambiente de <a href="http://www.amazon.com/dp/0321601912?tag=contindelive-20">continuous delivery</a>, el tiempo de ejecución debe ser de unos pocos minutos.</div>
<div style="text-align: justify;">
<b>7. Crear tests resistentes al cambio. </b>Quizás esta es una de las principales desventajas de los tests funcionales automatizados. Los tests debería verificar sólo funcionalidad. Dependiendo del contexto también puede ser posible aplicar <a href="http://en.wikipedia.org/wiki/Data-driven_testing">DDT (Data-Driven Testing)</a></div>
<div style="text-align: justify;">
<b>8. Los tests automatizados no pueden reemplazar a los humanos. </b>Este no debe ser el único testing que se ejecuta. Otras técnicas, con la intervención de los testers humanos, deben ser aplicadas sobre el software en pos de generar más conocimiento.</div>
<br />
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-88507333554223311712014-01-29T08:00:00.000-03:002014-01-29T18:15:30.492-03:00What’s a Tester without a QA Team? (hacia un entorno ágil)<div style="text-align: left;">
<span style="text-align: justify;">Luego de escribir sobre </span><a href="http://germanbraun.blogspot.com.ar/2013/12/asi-comienza-el-camino.html" style="text-align: justify;">"Así comienza el camino..."</a><span style="text-align: justify;">, encontré un interesante artículo escrito por Lisa Crispin y Janet Gregory, titulado </span><b style="text-align: justify;"><a href="http://www.agileconnection.com/article/what%E2%80%99s-tester-without-qa-team">"What's a Tester without a QA Team?"</a>. </b><span style="text-align: justify;">Quería remarcar una serie de <i>bullets</i> que me parecen interesantes para llevar a la práctica cuando un equipo de testing transiciona de un esquema tradicional a uno ágil.</span></div>
<div>
<br />
<ul>
<li style="text-align: justify;"><b>Preparándose para el éxito</b>. Inducir y dar soporte para que la persona no se aísle. Ahora, en este nuevo enfoque, se debe reportar a otras personas, otros roles y los testers deben aprender a colaborar con otros miembros del equipo.</li>
<li style="text-align: justify;"><b>El enfoque "Whole Team"</b>. En los equipo ágiles exitosos, todos sus miembros tienen un claro enfoque en la calidad y son responsables de ella. <i>La buena noticia para los testers es que ahora ellos van a estar involucrados en el proyecto desde el principio. Su tarea comienza con los clientes o </i>product owner<i> definiendo los </i>tests<i> de aceptación y continúa con la revisión de </i>user stories<i> junto con los </i>developers<i>.</i></li>
<li style="text-align: justify;"><b>Comunidad de Práctica de Testing</b>. Construir comunidades de práctica que faciliten la integración del equipo. El fin principal es compartir conocimientos y experiencias. Esta comunidad puede tener un <i>test manager</i> (responsable del equipo de testing en el enfoque tradicional) quien sea el encargado de asegurar la inducción y el soporte a los testers. El equipo debe también estar orientado a <b>hacer comunidad.</b></li>
<li style="text-align: justify;"><b>Compartir Conocimiento</b>. Cuando el equipo tiene el sentido de comunidad, se genera un núcleo de conocimiento muy poderoso que favorece el intercambio. Proactivamente, los integrantes comienzan a intercambiar conocimiento de manera desinteresada y totalmente natural.</li>
<li style="text-align: justify;"><b>Ampliar tus horizontes.</b> Todos los <i><a href="http://germanbraun.blogspot.com.ar/2013/09/basta-de-dev-vs-qa.html">software makers</a></i> deben estar enfocados en el <a href="http://germanbraun.blogspot.com.ar/2013/12/por-que-los-testers-necesitan-aprender.html">aprendizaje continuo</a>. Cada vez que una nueva funcionalidad es pensada y desarrollada, se produce una explosión de nuevo conocimiento que involucra y retroalimenta a todo el equipo.</li>
</ul>
<br />
Germán<br />
<br /></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2tag:blogger.com,1999:blog-9149971168063121729.post-30577378952039249682014-01-27T08:00:00.000-03:002014-01-27T08:00:04.842-03:00Equivocarse<div style="text-align: justify;">
Ayer leí este interesante <a href="http://gbonalde.blogspot.com.ar/2014/01/siempre-debemos-fallar-para-lograr-algo.html">artículo</a> de <a href="http://about.me/gbonalde">Gustavo Bonalde</a>, titulado <b>¿Siempre debemos fallar para lograr algo?</b></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Transcribo aquí una frase que me parece interesante:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<i><span style="font-family: inherit;"><span style="background-color: white; line-height: 20px;">"Es muy cierto que en cada falla tenemos una oportunidad de mejora, de aprendizaje, pero hay ocasiones donde no hay espacio para fallar.</span>"</span></i></div>
<br />
<div style="text-align: justify;">
Y es verdad. Además, en aquellas ocasiones en las cuales no podemos fallar, y lo hacemos, seguro el "golpe" será más grande. Pero, a pesar de ellos, <b>seguimos aprendiendo</b>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Para concluir, en cualquier profesión, trabajo, carrera, <b>el aprendizaje es continuo y eso es lo mágico</b>. Sólo hay que estar predispuesto.</div>
<br />
<br />
<div>
<span style="font-family: inherit; text-align: justify;">Germán</span></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0tag:blogger.com,1999:blog-9149971168063121729.post-53561994005005222302014-01-22T08:00:00.000-03:002014-01-22T08:00:05.422-03:00Tengo un problema (2)<div style="text-align: justify;">
Luego del éxito sin precedentes del <a href="http://germanbraun.blogspot.com.ar/2014/01/tengo-un-problema.html">post sobre el patito de goma</a> (¿?) y de algunos de los comentarios que me llegaron, quise hacer una <i>remasterización</i> del algoritmo de la técnica con el feedback que obtuve.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;">Si tenés un problema que no podés resolver y te está bloqueando, entonces:</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"> Si trabajás remoto:</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"> 1. Buscá un compañero en el chat para contárselo;</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"> Sino:</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"> 2. Contáselo a un compañero en persona;</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="font-family: inherit;"><span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b>Si no tenés más remedio y no tenés un compañero a mano:</b></span><br /><span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b> 3. Buscá un Patito de Goma y/o cualquier otro;</b></span></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;">En otro caso:</span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"> 4. Googlealo :)</span></b></span></div>
<div style="background-color: white; border: 0px; color: #888888; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="font-family: inherit;"><br /></span></div>
<div style="background-color: white; border: 0px; color: #888888; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><span style="font-family: inherit;"><br /></span></b></span></div>
<div style="background-color: white; border: 0px; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-style: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><span style="font-family: inherit;">Germán</span></span></div>
<div style="background-color: white; border: 0px; color: #888888; font-family: 'Open sans', sans-serif; line-height: 19px; margin: 0px; outline: 0px; padding: 0px; text-align: justify; vertical-align: baseline;">
<span style="border: 0px; font-family: inherit; font-style: inherit; font-weight: inherit; line-height: 20px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"><b><br /></b></span></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-58512749855962038522014-01-20T08:00:00.000-03:002014-01-20T08:00:11.515-03:00No escribirás con errores ortográficos<div style="text-align: justify;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4OY9IXmGSqbAKougRRmTD-CZjJUN0Jiw-O2uNEK0xVQIkGzlWqa7CFdROtq0YlBiXdgBMno6zM9jT9ifk2aOcjip3pKdtaEnPnTtvfKsuSWTyC-v0XhUt8GBOCTSig7ymwpkiAJW8nVq3/s1600/ortograf%C3%ADa4.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4OY9IXmGSqbAKougRRmTD-CZjJUN0Jiw-O2uNEK0xVQIkGzlWqa7CFdROtq0YlBiXdgBMno6zM9jT9ifk2aOcjip3pKdtaEnPnTtvfKsuSWTyC-v0XhUt8GBOCTSig7ymwpkiAJW8nVq3/s1600/ortograf%C3%ADa4.jpg" height="150" width="200" /></a></div>
Recuerdo que cuando estaba en la escuela primaria (6to grado), tenía una maestra que en una de las clases semanales de Lengua, nos tomaba un dictado. La dinámica era la siguiente: te dictaba 20 palabras elegidas al azar y, si tenías menos de 6 o 7 errores ortográficos, aprobabas. A medida que iba pasando el tiempo, la complejidad de las palabras se incrementaba y, para la calificación final de la materia, se ponderaba también cuántos dictados habías aprobado. Si bien era un examen y tenía un cierto nivel de <i>stress, </i>hoy en día, agradezco haber tenido la posibilidad de entrenar mi ortografía desde chico.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Esta anécdota es para introducir un tema que me parece muy importante, por no decir <b>crítico</b>. Digamos que podríamos seguir hablando sobre <a href="http://germanbraun.blogspot.com.ar/2013/02/habilidades-de-un-tester-el-quid-de-la.html"><i>skills</i> blandas, duras</a>, etc. de un profesional (en este caso, informático, tester, developer, no viene al caso). Sin embargo, pienso que antes de entrenar cualquiera de estas habilidades (que obviamente son también importantes), tenemos que estar seguros de escribir <b>sin errores de ortografía</b>. En resumen, <b>antes de entrenar cualquier otra habilidad, procura escribir sin errores de ortografía</b>.</div>
<div>
<br /></div>
<div>
Les dejo algunos tips que me ayudan a mejorar mi redacción:</div>
<div>
<br /></div>
<div>
<b>- Leer, leer, leer.</b></div>
<div>
<b><br /></b></div>
<div>
<b>- Consultar la <a href="http://www.rae.es/">RAE</a> o un diccionario físico.</b></div>
<div>
<b><br /></b></div>
<div>
<b>- Tener a mano reglas de ortografía y gramática básicas.</b></div>
<div>
<b><br /></b></div>
<div>
<b>- Usar sinónimos.</b></div>
<div>
<b><br /></b></div>
<div>
<b>- Ejercitar la escritura.</b><br />
<b><br /></b>
<b>- Seguir en <a href="https://twitter.com/" style="text-align: justify;">Twitter</a> <span style="text-align: justify;">a </span><a href="https://twitter.com/DelCorrector" style="text-align: justify;">@DelCorrector</a><span style="text-align: justify;"> (leer también su blog </span><a href="http://elsantodelapluma.blogspot.com.ar/" style="text-align: justify;">El Santo de la Pluma</a><span style="text-align: justify;">)</span></b></div>
<div style="text-align: justify;">
<br /></div>
<div>
<div style="text-align: justify;">
Por último, no sé si a ustedes les pasa, pero me molesta leer un texto que tiene errores. Además, tiene consecuencias varias. Por ejemplo:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
- Si es un informe, pierde toda seriedad al momento de localizar el primer acento mal puesto.</div>
<div style="text-align: justify;">
- Si es un <i>bug</i>, tu reputación de buen tester está en duda.</div>
<div style="text-align: justify;">
- Si es un chat, sms o mail informal, puede zafar pero, de vez en cuando, una corrección no viene mal.</div>
<div style="text-align: justify;">
- Si es un CV, estás out.</div>
<div style="text-align: justify;">
- Si es una chica que tiene problemas con su ortografía, pierde inmediatamente todo su encanto.</div>
<div style="text-align: justify;">
- Si es este post, por favor, dejar un comentario. Gracias!</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
¿Es mucho?</div>
<br />
Germán</div>
<div>
<br />
<span style="font-size: x-small;">[1] Imagen <a href="http://escribo-miguel.blogspot.com.ar/2013/02/avisos-ortograficos-cuidado.html">http://escribo-miguel.blogspot.com.ar/2013/02/avisos-ortograficos-cuidado.html</a></span></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com13tag:blogger.com,1999:blog-9149971168063121729.post-66763819129259355772014-01-15T10:12:00.003-03:002014-01-15T10:12:37.641-03:00Publicación en el blog de PetroVR<div style="text-align: justify;">
Colaboré como autor, junto a mis compañeros de equipo de <a href="http://pragmaconsultores.com/Paginas/Home.aspx">Pragma</a>, en una entrada sobre Testing en el blog de <a href="http://www.caesarsystems.com/petrovr/">PetroVR</a>. En el post, hablamos un poco sobre una propiedad que me parece interesante para desarrollar y que es la <b>"self-testability"</b> de un producto software. Los invito a leerlo <a href="http://www.caesarsystems.com/blog/testing-petrovr-done-self-testability-petrovr/#.UtaI7dLuJdM">How is the Testing of PetroVR done? The self-testability of PetroVR</a></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Gracias <a href="http://www.caesarsystems.com/">Caesar Systems</a> por la invitación a participar y a <a class="g-profile" href="http://plus.google.com/113622131200072499744" target="_blank">+Leandro Caniglia</a> y <a class="g-profile" href="http://plus.google.com/108688683714102694833" target="_blank">+Carlos Ferro</a> por el feedback.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-79500835366533423312014-01-12T09:55:00.000-03:002014-01-12T09:55:04.758-03:00Tengo un problema<div style="text-align: justify;">
La técnica del patito de goma <b>[1]</b> (reformulada)<br />
<br /></div>
<div style="text-align: justify;">
<span style="font-family: inherit;"><span style="line-height: 20px;">Muchas veces nos pasa que nos bloqueamos cuando tenemos que resolver un problema (en este caso, laboral). No podemos avanzar, nos volvemos menos productivos, </span></span><span style="line-height: 20px;">incómodos</span><span style="font-family: inherit;"><span style="line-height: 20px;"> y no disfrutamos de nuestro trabajo. Para evitar esto, lo que la técnica propone es, simplemente, contarle a alguien lo que nos pasa. Luego, en medio del proceso, nos daremos cuenta de lo que está fallando (eventualmente) y nos ayudará a resolver el tema que nos aqueja. Pero tiene un problema, hay que molestar a otra persona para que nos atienda. Es aquí dónde aparece el </span></span><b style="font-family: inherit; line-height: 20px;">Patito de Goma</b><span style="font-family: inherit;"><span style="line-height: 20px;">. Cuando estés bloqueado usá el patito, contale lo que te ocurre y verás cómo, en muchas ocasiones, te ayudará.</span></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="line-height: 20px;">Contado de esta manera, tiene algo que me hace ruido y que contradice el "espíritu" de este blog: <b>atenta contra los ambientes colaborativos</b>. Por lo tanto, mi propuesta es:</span><br />
<span style="line-height: 20px;"><br /></span>
<span style="line-height: 20px;"><b>- Si tenés un problema que no podés resolver y te está bloqueando:</b></span></div>
<div style="text-align: justify;">
<span style="line-height: 20px;"><b> 1. Buscá un compañero para contárselo.</b></span></div>
<div style="text-align: justify;">
<span style="line-height: 20px;"><b>- Si no tenés más remedio y no tenés un compañero a mano:</b></span><br />
<span style="line-height: 20px;"><b> 2. Buscá una Patito de Goma.</b></span></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<span style="line-height: 20px;">Germán</span><br />
<span style="line-height: 20px;"><br /></span>
<span style="line-height: 20px;"><b>[1]</b> <a href="http://developerscookbook.blogspot.com.ar/2010_11_01_archive.html">http://developerscookbook.blogspot.com.ar/2010_11_01_archive.html</a></span></div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com4tag:blogger.com,1999:blog-9149971168063121729.post-17072468314071252102014-01-05T21:50:00.002-03:002014-01-05T21:50:40.910-03:00Mis razones para escribir<div style="text-align: justify;">
Este blog está cumpliendo un año desde que comencé a escribirlo. Cuando me dí cuenta de la fecha, me puse a pensar ¿por qué estoy escribiendo?, ¿cuáles son las razones? Entonces identifiqué las siguientes (más representativas):</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1. <b>Investigar</b>: me gusta hacerlo y el blog ayuda a plasmarlo. La gente que trabaja en Informática debe investigar todo el tiempo. El constante avance en materia de Ciencia y Tecnología requiere que todo profesional esté actualizado para intentar llegar a la "cresta de la ola".</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
2. <b>Aprender</b>: El blog nos permite aprender sobre los temas que nos interesan, gestionarlo, escribirlo y compartirlo. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
3. <b>Hacer Comunidad</b>: contactar gente con la que tengamos temas en común, que quiera compartir su conocimiento y que haga comunidad.<br />
<br />
Cualquier motivación es válida para escribir. Sin embargo, creo que lo más importante y, lo que me motiva a seguir haciéndolo, es el feedback que se obtiene de los lectores (cualquiera sea la cantidad)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
¡Gracias por leer!</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-4668573366856251902013-12-31T11:56:00.002-03:002014-01-02T08:36:05.439-03:00¿Por qué los testers necesitan aprender continuamente?<div style="text-align: justify;">
Últimamente estoy leyendo mucho a Lisa Crispin y Janet Gregory. Esta vez, encontré el artículo <a href="http://www.agileconnection.com/article/why-testers-and-qa-engineers-need-learn-continuously">"Why Testers and QA Engineers Need to Learn Continuously?"</a>. Me parece atinado verter aquí algunos de sus conceptos ya que hacer un tiempo venimos diciendo que los testers trabajan con <a href="http://germanbraun.blogspot.com.ar/2013/07/hacer-testing-es-tambien-capturar.html">conocimiento</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
1) Expandir tu conocimiento y tus capacidades te posibilitará incrementar tus oportunidades, tanto dentro como fuera de tu organización.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
2) Testers quienes eligen aprender, abrir su mente y probar nuevas cosas, son más valiosos para sus equipos. Los buenos testers entienden tanto el negocio como los aspectos técnicos de su producto.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
3) El aprendizaje reduce el stress. Invertir tiempo en adquirir nuevo conocimiento permite aumentar la confianza en cómo hacer tu trabajo y, además, hacerlo correctamente.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
4) Cuando tu compartes nuevo conocimiento con tu equipo, "desafías" a tus compañeros a pensar nuevas y mejores maneras de hacer las cosas.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
5) La sabiduría que da la experiencia combinada con el aprendizaje, el perfeccionamiento de tus <i>skills </i>y la constante actualización sobre las nuevas ideas que surgen desde la industria (y la academia), no sólo te vuelven más "vendible" sino que también te hacen más valorable dentro del equipo en el que trabajas.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
6) El aprendizaje continuo te da la posibilidad de formar parte de una comunidad de pensadores que comparten experiencias e ideas que pueden crecer orgánicamente.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Más allá de todos estos puntos, debe existir una motivación intrínseca orientada a comprender las <a href="http://germanbraun.blogspot.com.ar/2013/02/mi-responsabilidad-como-tester.html">responsabilidades del tester</a> y sus <a href="http://germanbraun.blogspot.com.ar/search?updated-max=2013-04-05T19:42:00-03:00&max-results=7&start=14&by-date=false">habilidades</a> y a desafiar el <a href="http://germanbraun.blogspot.com.ar/2013/03/responsabilidad-cambios-y-motivacion-mi.html">status quo</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Germán</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2Neuquén, Argentina-38.9524444 -68.064138899999989-39.0512484 -68.225500399999987 -38.853640399999996 -67.902777399999991tag:blogger.com,1999:blog-9149971168063121729.post-3901587712719907512013-12-30T15:21:00.000-03:002013-12-30T15:22:53.386-03:00Hacer, Equivocarse, Aprender<div class="" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgI6jlRU-5qa0noqEwDwhJYH9TwbABvNi35Wrf6WB1s4WSpX4gFhki0wJPbAGu79MpSfHcOVsuh1SDROY4g5AllgcuyTiUfP1hSIXm4WO5AIwCuSfdJMJLOcLU5BHIzObevOdgR0lxfOrAl/s1600/hacer-equiv-aprender.jpg" imageanchor="1" style="clear: right; display: inline !important; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><br /><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgI6jlRU-5qa0noqEwDwhJYH9TwbABvNi35Wrf6WB1s4WSpX4gFhki0wJPbAGu79MpSfHcOVsuh1SDROY4g5AllgcuyTiUfP1hSIXm4WO5AIwCuSfdJMJLOcLU5BHIzObevOdgR0lxfOrAl/s320/hacer-equiv-aprender.jpg" width="256" /><i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"></span></i></a></div>
<div class="" style="clear: both; display: inline !important; text-align: center;">
<i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"></span></i></div>
<div>
<div class="" style="clear: both; display: inline !important; text-align: center;">
<i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"><i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"><br /></span></i></span></i></div>
</div>
<div>
<div class="" style="clear: both; display: inline !important; text-align: center;">
<i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"><i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"><br /></span></i></span></i></div>
</div>
<div style="text-align: right;">
<i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;"><i style="font-family: inherit; line-height: 1.1;"><span style="font-size: large;">"Si no te equivocás de vez en cuando, quiere decir que no estás aprovechando todas tus oportunidades."</span></i></span></i></div>
<br />
<div style="text-align: right;">
<span style="font-family: inherit;"><br /></span></div>
<div style="text-align: right;">
<span style="font-family: inherit;">— <span style="box-sizing: border-box;">Woody Allen</span></span></div>
<br />
<br />
Esta podría ser nuestra motivación para el nuevo año que comienza.<br />
<br />
<br />
¡Felicidades!<br />
<br />
GermánGermanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0tag:blogger.com,1999:blog-9149971168063121729.post-19505487690368756542013-12-26T18:09:00.001-03:002013-12-27T08:38:38.205-03:00"We don't know exactly where we'll go but small steps ensure we do not fall down" [1]<div style="text-align: justify;">
Ver el todo de un proyecto es algo que puede parecer simple, pero que necesita de sus herramientas y recursos para poder hacerlo de manera controlada y efectiva.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Hasta aquí, hemos estado hablando mucho sobre agilidad y sus bondades. Sin embargo, aparece el siguiente efecto colateral: perdemos de vista "el todo" del proyecto. Es decir, ¿estamos haciendo lo que realmente debemos hacer?, ¿hacia dónde vamos? ¿dónde estamos parados actualmente luego de finalizar determinadas tareas? Si lo trasladamos a un proyecto de testing, ¿todas las funcionalidades están cubiertas por nuestras pruebas? ¿dónde nos está faltando testing? ¿cómo está el semáforo del proyecto?</div>
<br />
<div style="text-align: justify;">
<a href="https://twitter.com/gojkoadzic">Gojko Adzic</a>, en su libro <a href="http://www.impactmapping.org/book.php">"Impact Mapping: Making a big impact with software product and projects"</a>, se encarga de tratar este tema usando los mapas mentales. Adzic, nota que una causa común de la desconexión entre el negocio y el <i>delivery</i> es que los equipos que trabajan en un esquema iterativo, lo hacen sobre pequeñas funcionalidades que tienden a ir por un <i>pipeline</i> sin tener en cuenta su valor para el negocio. Con el foco puesto principalmente en el <i>delivery</i>, l<span style="text-align: justify;">os <a href="http://germanbraun.blogspot.com.ar/2013/07/mapas-de-impacto.html">mapas de impacto</a> facilitan esta vista tanto para el negocio como para el equipo técnico y se adaptan bien a los modelos iterativos. Usando mapas de impacto podemos reportar progreso, comprometernos sobre impactos a ser logrados, dar visibilidad y permitir una implementación más flexible.</span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjf4s4BJklipmpU0lyl9SOh5t0vj6cjZKLuH2XbnTRV-uprJpQfsbu9bmgcMvg0eyUKkjDBwCguXKVziW7oTHbow4eG19oHiVfag956FvzS-VS3XEEA1ewE9NnHaTnRJ7PyIwPbemkMg-uu/s1600/map-diagram.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="271" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjf4s4BJklipmpU0lyl9SOh5t0vj6cjZKLuH2XbnTRV-uprJpQfsbu9bmgcMvg0eyUKkjDBwCguXKVziW7oTHbow4eG19oHiVfag956FvzS-VS3XEEA1ewE9NnHaTnRJ7PyIwPbemkMg-uu/s400/map-diagram.png" width="400" /></a></div>
<br />
<i style="text-align: justify;"><br /></i>
<br />
<div style="text-align: justify;">
Para <a href="http://ca.linkedin.com/in/janetgregory">Janet Gregory</a> y <a href="http://www.linkedin.com/pub/lisa-crispin/0/20a/884/">Lisa Crispin</a>, <i>"look at the big picture"</i> es uno de los factores claves de éxito según definen en su libro <a href="http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468"> "Agile Testing: A Practical Guide for Testers and Agile Teams"</a>. Para ellas, todos los <i><a href="http://germanbraun.blogspot.com.ar/2013/09/basta-de-dev-vs-qa.html">software makers</a></i> deben mirar el todo del proyecto y usualmente desde el punto de vista del cliente. ¿Qué sucede si una nueva funcionalidad causa que otras no relacionadas rompan? Es necesario considerar el impacto sobre el sistema completo y llamar la atención del equipo sobre esto. Enfocándose puntualmente en testing, Crispin y Gregory proponen evaluar cómo las actuales <i>stories </i>se insertan en el esquema del negocio y preguntarnos a nosotros mismos cómo podemos hacer un mejor trabajo para poder entregar valor real. Usar el <a href="http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/">cuadrante de <i>testing agile</i></a>, guiar el desarrollo con tests, hacer testing exploratorio para aprender sobre el negocio, hacer un ambiente de pruebas tan similar al productivo como sea posible, usando datos reales y recrear situaciones en producción, tales como el testing de carga, son algunas de las herramientas que se proponen en el libro.</div>
<br />
<div style="text-align: justify;">
Personalmente, he puesto en práctica varias de estas herramientas y consejos en mis proyectos. Algunas ya las hemos charlado en el blog y otras las vamos a ir desarrollando en entradas posteriores. Sin embargo, antes de seguir avanzando, creo que es necesario ponernos a pensar si estamos viendo el todo de nuestros proyectos.</div>
<div style="text-align: justify;">
<br /></div>
¿Ustedes lo están haciendo?<br />
<br />
Germán<br />
<br />
[1] Frase extraída del libro <a href="http://www.impactmapping.org/book.php" style="text-align: justify;">"Impact Mapping: Making a big impact with software product and projects"</a><br />
[2] Imagen de <a href="http://blog.pablojimeno.com/blog/2013/03/13/london-2013-experience-part-i-impact-mapping-with-gojko-adzic/">http://blog.pablojimeno.com/blog/2013/03/13/london-2013-experience-part-i-impact-mapping-with-gojko-adzic/</a>Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com2tag:blogger.com,1999:blog-9149971168063121729.post-80687376226866891902013-12-09T15:14:00.000-03:002013-12-09T15:14:37.402-03:00Scrum is a Platonic Ideal<blockquote class="twitter-tweet" lang="en">
Beginning to see that Scrum is a Platonic ideal. It cannot exist in its perfect form in the real world.<br />
— Tobias Mayer (@tobiasmayer) <a href="https://twitter.com/tobiasmayer/statuses/407669943711191041">December 3, 2013</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0tag:blogger.com,1999:blog-9149971168063121729.post-28034411244708335102013-12-07T11:40:00.002-03:002014-01-14T09:38:48.532-03:00Así comienza el camino...<div class="gmail_default" style="background-color: white; color: #222222;">
<div style="text-align: justify;">
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;">"<b>Scrum</b>: learn from a new start. <b>Kanban</b>: learn from where we are now". </span></span><br />
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;"><br /></span></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhERLhRg2L_NPWEgZPWscKBR2X7DeqY9Dv-ssAxreHOSI5ypyvQsQwY8syY0gK10L-1ibB_d5aNIG2Xi6jnF7wU1PKR0IToMMC46kh7pUlMxeQxViHffnbLc2xhkSkJQIw9mWzSkoBKtNnh/s1600/Kanban+Blog.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="241" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhERLhRg2L_NPWEgZPWscKBR2X7DeqY9Dv-ssAxreHOSI5ypyvQsQwY8syY0gK10L-1ibB_d5aNIG2Xi6jnF7wU1PKR0IToMMC46kh7pUlMxeQxViHffnbLc2xhkSkJQIw9mWzSkoBKtNnh/s320/Kanban+Blog.png" width="320" /></a></div>
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;">Si queremos transicionar de una esquema "más Waterfall" a un entorno ágil y no estamos del todo preparados, es recomendable empezar por Kanban. </span></span><span style="color: #333333; line-height: 18px; white-space: pre-wrap;">Si bien ya he hablado de esta herramienta en varias ocasiones, me parece importante definir qué debemos tener en cuenta a la hora de aventurarnos en la agilidad desde cero.</span></div>
<div style="text-align: justify;">
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;">¿Se puede combinar Kanban con mi proceso actual? </span></span><br />
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;"><br /></span></span>
<span style="color: #333333; line-height: 18px; white-space: pre-wrap;"><span style="font-family: inherit;">Si, y podemos empezar de la siguiente manera.</span></span></div>
<br />
<ul>
<li style="text-align: justify;"><span style="font-family: inherit;"><b>Tablero</b>: comenzamos visualizando nuestro trabajo. ¿Dónde están nuestros cuellos de botella?</span></li>
</ul>
<ul>
<li style="text-align: justify;"><span style="font-family: inherit;"><b>WIP (Work in Progress)</b>: ¿cuánto trabajo podemos tomar en cada etapa de nuestro proceso?</span></li>
</ul>
</div>
<div class="gmail_default">
<div style="background-color: white; color: #222222; text-align: justify;">
<br /></div>
<div style="background-color: white; color: #222222; text-align: justify;">
<span style="font-family: inherit;">Así comienza el camino...</span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRifNr18_CGA2n9O57ItE3yTWHYYkScuyoMpwWBNgkFXWcpPEfzbbgjHzk9Vkrgy-euvQvLuqW7q4u270jlEeV7GTZTm3oiNhlFCm_GEa211a0gLIBQCjIVdpUWeZloy7sXGlxE9qa4iz4/s1600/Kanban+Taskboard.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="255" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRifNr18_CGA2n9O57ItE3yTWHYYkScuyoMpwWBNgkFXWcpPEfzbbgjHzk9Vkrgy-euvQvLuqW7q4u270jlEeV7GTZTm3oiNhlFCm_GEa211a0gLIBQCjIVdpUWeZloy7sXGlxE9qa4iz4/s400/Kanban+Taskboard.png" width="400" /></a></div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<div style="background-color: white; color: #222222;">
<b>[Entradas relacionadas]</b></div>
<div style="background-color: white; color: #222222;">
<br /></div>
<div style="background-color: white; color: #222222;">
- <a href="http://germanbraun.blogspot.com.ar/2013/05/una-experiencia-aplicando-kanban-en.html">Una experiencia aplicando Kanban en Testing</a></div>
<div style="background-color: white; color: #222222;">
- <a href="http://germanbraun.blogspot.com.ar/2013/11/lean.html">Lean</a></div>
<div style="background-color: white; color: #222222;">
- <a href="http://germanbraun.blogspot.com.ar/2013/12/kanban-maturity-chart.html">Kanban Maturity Chart</a></div>
<div style="background-color: white; color: #222222;">
<br /></div>
<div style="background-color: white; color: #222222;">
<b>[Referencias]</b></div>
<div style="background-color: white; color: #222222;">
<br /></div>
- <a href="http://www.crisp.se/gratis-material-och-guider/kanban">http://www.crisp.se/gratis-material-och-guider/kanban</a><br />
- <a href="http://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402">Kanban: Successful Evolutionary Change for Your Technology Business</a><br />
<div style="background-color: white; color: #222222;">
<br /></div>
</div>
<div style="background-color: white; color: #222222; text-align: justify;">
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Germán</span></div>
</div>
Germanhttp://www.blogger.com/profile/15949153736153987789noreply@blogger.com0