Siguenos en:

martes, 5 de noviembre de 2013

¿Cualquiera puede ser un tester?


Cocinar, como cualquier actividad requiere de habilidades, experiencia y talento. La película Ratatouille relata la historia de cómo una rata se convierte en chef, y una de las frases más recurrentes de la película es: “Cualquiera puede cocinar”.
A continuación una cita de la película donde un conocido crítico opina sobre la idea de una rata cocinando:
 “Una extraordinaria cena de una fuente singular e inesperada, decir solo que la comida y su creador han desafiado mis prejuicios sobre la buena comida, subestimaría la realidad. . . . .Al fin me doy cuenta de lo que quiso decir en realidad. No cualquiera puede convertirse en un gran artista, pero un gran artista puede provenir de cualquier lado”.
Volviendo a la idea, me pregunto: ¿Cualquiera puede ser un tester?
Personalmente, veo al testing como una actividad similar a la cocina, con requisitos de habilidades, experiencia, conocimiento y talento, sin embargo, mientras que las competencias, conocimiento podrán irse adquiriendo mientras una persona se desenvuelve en el rol, creo que existen ciertas habilidades que cualquier persona (sin importar su formación académica) puede tener para convertirse en un gran tester. Habilidades como la curiosidad, creatividad y el pensamiento lateral deberán ser fundamentales para el rol.
De esta manera creo que efectivamente cualquiera puede ser un tester, pero al igual que para cocinar, “No cualquiera puede convertirse en un tester, pero un tester puede provenir de cualquier lado
¿Tú qué opinas?

jueves, 24 de octubre de 2013

El testing solo da problemas

Es cierto, ¿o no? Alguna vez, como tester, ¿te has preguntado o has pensado cuál es tu función en su sentido más básico? Algunos dirían romper software (que personalmente creo que ya está roto desde el principio, en mayor o menor medida), otros dirían que nuestro trabajo es romper ilusiones (demostrar que no funciona, cuando se supondría que sí), acerca del producto que se prueba. ¿No es cierto también que parte de nuestro trabajo es encontrar problemas?, problemas que podrían afectar a nuestros usuarios o hacer que disminuya el valor del producto que se prueba.

Una de las definiciones de la palabra problema, la cual creo encaja muy bien en este contexto, es: Conjunto de hechos o circunstancias que dificultan la consecución de algún fin.Así pues ¿de qué sirven los problemas que encuentra un equipo de pruebas? ¿No son esos problemas revelados con el fin de evitar que los usuarios enfrenten esas dificultades para lograr sus fines? En ese sentido me gusta pensar acerca del tester como una especie de héroe de los usuarios, salvándolos de los problemas, al menos de tantos como nos sea posible.

Pero los problemas o bugs que se revelan en algún proyecto, no solo representan un problema al que un usuario podría enfrentarse. También pueden representar un problema para el desarrollo de dicho proyecto. No siempre es así ya que se puede contemplar una parte del desarrollo del proyecto a corregir bugs. Pero ¿qué pasa cuando los problemas descubiertos en el código sobrepasan el tiempo calculado? Cuando el proyecto se retrasa y las fechas de entrega se acercan. Si consideramos que un proyecto en retraso es un problema, y que los problemas que el equipo de pruebas encuentra están retrasando el proyecto, entonces podemos decir que el testing da problemas al proyecto. Lo interesante de esta situación es que si los bugs o problemas revelados no hubieran sido descubiertos por el equipo de pruebas, seguramente los usuarios los descubrirían, lo cual impactaría negativamente en la reputación y valor de cualquier producto de software y no solo de un producto sino hasta de una organización. Es aquí donde se evalúa qué representa más riesgo, si entregar el producto como está o invertir más tiempo desarrollándolo para mantener al mínimo posible los errores y retrasar más su salida.


Entonces, ¿es malo para un equipo de pruebas solo generar problemas? Más que generar problemas yo lo veo como ayudar a que los problemas se resuelvan. Para solucionar un problema el primer paso es reconocerlo o identificarlo y creo que esa es una de las aportaciones más importantes que un equipo de pruebas hace, al contribuir como parte de un equipo más grande, al desarrollo de un proyecto.

miércoles, 16 de octubre de 2013

Pensamiento crítico en tres palabras: Huh? Really?? So???


Si algo se me ha quedado muy grabado de lo que he leído de James Bach (mi gurú del testing favorito), y que quisiera compartir aquí, es una forma muy peculiar, breve y efectiva para aplicar el pensamiento crítico en el testing del día con día, y que no solamente funciona para los testers sino para cualquier persona que no quiera dejarse engañar. Su método consiste en realizar tres simples preguntas: Huh???  Really???   So??? (algo que traduje burdamente a "¿Qué? ¿En serio? ¿Entonces?")

Supongamos que uno va caminando tranquilo por la calle, rumbo al trabajo, pensando en todos esos bugs que están pidiendo a gritos ser reportados. De repente, entre los arbustos se escuchan unos ruidos extraños y de la nada salta encima un vendedor de herramientas de automatización de pruebas, tratando de vender su producto y proclamando que la automatización es la mejor práctica en el testing, y que además ayuda a ahorrar mucho dinero y esfuerzo. Gracias a James Bach, podría hacerle un alto a esa persona y preguntar:

¿¿Qué??


"Huh?/¿Qué?" me ayuda a recordar que probablemente no comprendo por completo la premisa que se me presenta, y que debo buscar más información respecto a lo que voy a cuestionar hasta entender lo que la otra persona realmente quiso decir. ¿A qué se refiere al decir "automatización de pruebas"? ¿Se refiere al uso de herramientas que ejecutan pruebas unitarias de forma automatizada? ¿Al uso de scripts/addons que facilitan el rellenado de datos de prueba en formularios? ¿Quiere decir la automatización de todos y cada uno de los flujos del sistema de inicio a fin o sólo ciertos módulos seleccionados bajo algún criterio? ¿Sugiere que la automatización por sí sola es la mejor práctica, sin necesidad de otros tipos de pruebas apoyándola? 

¿¿En serio?? 

"Really?/¿En serio?" me ayuda a recordar (una vez que entendí la premisa) que incluso los argumentos mencionados pudieran estar aún en disputa. ¿En serio la automatización es la mejor práctica? ¿Cómo sabe esa persona que realmente es la mejor práctica en el testing? ¿Qué hechos/estudios/experiencias/argumentos tiene para respaldar que es la solución a los problemas del testing y que además representa un ahorro de esfuerzo y dinero? ¿Qué validez tienen los argumentos que lo respaldan?

¿¿Entonces?


"So?/¿Entonces?" me recuerda que a pesar de entender lo que la otra persona quiso decir y de comprender los argumentos que según su criterio dan certeza a su premisa, puede que ni siquiera sea de relevancia en mi contexto o que dichos argumentos no apliquen de igual manera para mi caso. ¿Entonces en qué me beneficia considerar que la automatización es la mejor práctica? ¿Cómo sabe si en mi contexto también pudiera ser la mejor práctica? Tal vez para esa persona sea así debido al tipo de aplicaciones que desarrollan en su empresa. Puede que en mi caso sea mayor el costo de implementarla debido a la cantidad y complejidad de los flujos de mi producto, o que ni siquiera valga la pena el costo de implementación dado que el enfoque del producto requiere más de pruebas exploratorias y de la experiencia del tester, y automatizar flujos no ayude a encontrar los riegos más críticos. También puede ser que de manera general la automatización realmente sea más costosa  en comparación con los beneficios que parece traer con ella.

Con esas tres preguntas me será más fácil aplicar el pensamiento crítico y no dejarme engañar por la primera persona que se me ponga enfrente diciendo que todo saldrá bien.

En lo personal, estas tres preguntas me han ayudado bastante en varias situaciones (no solamente en el trabajo, sino en la vida cotidiana) en las que las cosas parecen ir sospechosamente bien cuando la realidad (o al menos la percepción de la realidad de distintas personas) es otra. Espero que les sea de ayuda este pequeño truco.




martes, 8 de octubre de 2013

Lo que Buda tiene para enseñar a los testers

Hace poco tiempo encontré una presentación de Dawn Haynes donde se habla sobre como el Testing es acerca de “querer aprender y perseguir ese aprendizaje de manera continua” a continuación trataré de explicar un poco de lo que trata la presentación.

En su libro: “El universo en un solo átomo” el Dalai Lama menciona:
“Mi confiada incursión por la ciencia se debe a mi convicción fundamental de que tanto la ciencia como el budismo se proponen comprender la realidad por medio de la investigación crítica: si el análisis científico pudiera demostrar sin lugar a dudas que determinados postulados del budismo son falsos, deberíamos aceptar los hallazgos de la ciencia y abandonar dichos postulados.”

Y es que si lo pensamos un poco, pareciera que se está describiendo el rol que un tester debería tener en una organización, encontrando conjeturas y no conclusiones y estando abierto a que en cualquier momento se podrá encontrar evidencia para abandonar postulados que hasta el momento se toman como hechos.

En su presentación: The Zen of Software Testing, Dawn menciona que Buda invita a no aceptar la validez de sus enseñanzas simplemente sobre la base de respeto a él. Sino que promueve que se pruebe la verdad de sus enseñanzas a través de la evaluación razonada y la experimentación personal.

Es aquí donde podemos encontrar ciertas similitudes que el Budismo y el Dalai Lama tienen para nosotros los testers, buscar la evidencia y evitar caer en suposiciones, en ocasiones es importante cuestionar aquello que pueda parecer obvio con el fin de encontrar nuevos elementos capaces de fortalecer la confianza que tenemos en nuestra visión.

¿Qué opinan?





viernes, 30 de agosto de 2013

Usando nuestro mejor pensamiento en el trabajo

Ya sea que hablemos de pensamiento racional, lateral, crítico o analítico sería genial que nuestros momentos de “mejor” pensamiento sean en el trabajo, sin embargo la realidad es que no es así.
El Dr. David Rock, director ejecutivo del NeuroLeadership Group menciona en una de sus publicaciones un dilema esencial con el que muchos nos podemos identificar.
“Nos regimos bajo reglas que se enfocan al trabajo en una fábrica, en un tiempo donde la mayoría de nuestro trabajo requiere de pensamiento profundo”.
¡Ojo! No se trata de demeritar ningún trabajo o rol, sino que debemos reconocer que existen tareas entre los roles que requieren distintos tipos de pensamiento. Un estudio dirigido por este instituto demostró que solamente el 10% de las personas entrevistadas mencionaron que sus mejores momentos de pensamiento son en el trabajo.
Si el trabajo no es inspirador para pensar, ¿qué lo es? Dentro de los comentarios más concurrentes se encuentran: la regadera, trotar, los minutos previos a dormir, un viaje, entre otros.
Sin embargo, aún podemos hacer algo para que esos momentos sean más frecuentes en el trabajo; las distracciones son sin duda una pieza clave en cualquier tarea que involucre un alto nivel de pensamiento o creatividad. Las pelotas antiestrés, dibujar, la escritura a mano (o en mi caso los malabares), son algunas tareas que apoyan a la actividad cerebral con el propósito de potenciar nuestro pensamiento.
David Creswell, neurocientífico de Carnegie Mellon, encontró  que las personas que se distraen durante periodos cortos de tiempo son quienes mejores resultados obtienen a la hora de resolver problemas complejos.
Incluso se ha buscado comprobar que hasta la ropa que utilizamos puede influir en este tipo de procesos cerebrales; algunos investigadores han descubierto que existe una relación cognitiva ligada a la ropa que utilizamos, así como a lo que esta ropa significa. Durante una prueba cognitiva, los participantes que usaban bata blanca durante este proceso cometieron menos errores que quienes no la usaban y también menos errores que quienes la usaban bajo la idea de que la bata pertenecía a un pintor. Esto sugiere que usar ropa con cierto significado puede también ayudar a potenciar la efectividad de estos procesos cognitivos.
Una vez que entendamos que estas dificultades son simplemente limitaciones inherentes a la forma en que nuestro cerebro trabaja, podremos usar distintas estrategias para compensarlas. Es entonces donde podemos buscar esos distractores que apoyen a sacar nuestro “mejor” pensamiento durante el trabajo con el propósito de obtener mejores resultados de nosotros mismos.
Tú, ¿qué distracciones tienes en tu trabajo para que sea más productivo?






martes, 30 de julio de 2013

El Testing es como en las películas

Dos de mis grandes pasiones son: las películas y el testing, pero hasta ahora me doy cuenta de que es posible que ambas áreas tengan muchas cosas en común. ¿Se han preguntado qué tanto puede parecerse el testing al cine?

Y es que en realidad, tanto en el testing como en el cine, se ve de todo:

Comedias: Donde los personajes principales de la historia terminan haciendo algo distinto a lo que se espera y resulta ser disparatado, todos nos hemos reído tanto de alguna buena película así como de algún bug J.

Western: Donde en ocasiones pareciera que la trama principal está en un épico enfrentamiento entre el tester y el bug para ver quién es el que dispara más rápido.

Terror: Son aquellas historias que producen inquietud, temor y sobresalto a los involucrados por medio de truculentos y misteriosos dramas a través de morbosos y siniestros elementos :o

Ciencia ficción: Esas historias que solo existen en un mundo fantasioso y giran en torno a personajes fuera de sus cabales y los descubrimientos que ha hecho el cual puede ser un fenómeno poderoso que se transforma en peligro para los hombres (o el proyecto).

Aventuras: De carácter épico, están protagonizadas por algún héroe envuelto en una peripecia. Se prolongan situaciones de máximo peligro suspendiendo o prologando su resolución. Donde en ocasiones el tester (y en otras el bug) recorre ese “camino del héroe” para terminar en un épico final.

Documental: Dejan de lado la fantasía para intentar representar algún hecho real y en ocasiones crítico, promueven la reflexión y pueden hasta causar revuelo entre los involucrados.


¿Cuál creen que falte?

viernes, 26 de julio de 2013

Casos de prueba vs Ideas de prueba

Los Casos de prueba son la descripción detallada de pasos a realizar en un sistema para determinar que un requerimiento está siendo cumplido en su totalidad o no, muchas de las veces y sobre todo en México donde no siempre se sigue un proceso formal de pruebas de software, por lo tanto tener un requerimiento plasmado en un documento donde se pueda basar para generar los casos de prueba es difícil.

Las ideas de prueba sería como la parte informal de un caso de prueba, ya que a diferencia del segundo, no se requiere un detalle extenuante, como ID, descripción, pasos, requerimiento relacionado, etc., donde esto muchas de las veces genera una sobrecarga de trabajo, sino más bien una oración en general que describa lo que se tendría que hacer para determinar el cumplimiento del requerimiento, la cual puede desencadenar no solo un caso de prueba, sino mucho y dar pie a la creatividad al vuelo, es decir, en base a esa idea, generar más ideas de prueba.


Pero aquí lo más importante es determinar que es más útil, que es lo que para ti ha funcionado, yo me inclino hacia las Ideas de prueba, porque es la esencia del tester, es donde entra el proceso creativo, donde puedes utilizar el pensamiento lateral para resolver un problema o buscarlo, donde usas tu ingenio y tu experiencia, pero para ti ¿Cuál es mejor?, ¿Qué beneficios les ves?

http://cartoontester.blogspot.mx/2012/02/curiosity-if-cats-where-testers.html

martes, 2 de julio de 2013

¿Riesgos? ¿Qué es eso?

¿Cuán importante es la administración de riesgos en el Software ?¿Es parte de las responsabilidades de Testing, la administración de riesgos de un producto?


Un riesgo se define como la probabilidad de que ocurra un perjuicio a algo o alguien, el riesgo es parte de toda actividad humana aunque en ocasiones no se considere. ¿Será más seguro viajar en avión que caminando? la respuesta puede parecer lógica, sin embargo según el CFOI del 2010 (Census of Fatal Occupational Injuries) el 3% de las muertes están ligadas a accidentes aéreos mientras que el 14% están ligadas a escalones, tropiezos y peatones ¿Raro? No tanto, si se analizan las medidas de seguridad que se consideran en un vuelo y las que se consideran al caminar, se encontrará que la administración del riesgo juega un papel mucho más importante en la primera mientras que al caminar, esta situación pasa desapercibida. Sin embargo, se debe considerar la administración de riesgo como un factor crítico al momento de realizar cualquier actividad.

Uno de los problemas principales que se tienen en los proyectos de desarrollo de software, no solo en México, sino a nivel global, es sin duda el de la administración de los riesgos, debido a que una mala (o en ocasiones hasta nula) administración del riesgo durante el desarrollo de un producto de software se va a traducir en un fracaso, ya sea en tiempo de entrega, en costo, o en calidad del producto. El Standish Group encontró que de los proyectos relacionados al desarrollo de software en Estados Unidos, solo el 17% se termina adecuadamente lo que sin duda es preocupante ya que otro 50% de los proyectos se encuentran con problemas en costo, alcance o tiempo y el 33% restante termina cancelado, lo cual puede traducirse en unos 140 mil millones de dólares al año desperdiciados en proyectos fracasados o cancelados.

La administración de riesgos no tiene la importancia que debería en estos proyectos, desde esta perspectiva tal vez sea que los avances en un proyecto de desarrollo de software los hacemos con la misma seguridad con la que caminamos.

¿Tú qué opinas?