Pruebas automatizadas para aplicaciones móviles: Calabash for dummies (2/2). Calabash y BDD

Si utilizamos BDD (entendiendo qué es BDD), el uso de Calabash nos va a resultar de gran utilidad. Esto es así, debido a que hace uso de Gherkin el cual nos permite escribir especificaciones en un lenguaje natural y comprensible por todo el mundo, tanto negocio como desarrollo como QA.

Una vez que tengamos instalado Calabash, accediendo a la carpeta (en mi caso es la siguiente ruta C:\Ruby193\lib\ruby\gems\1.9.1\gems\calabash-android-0.5.14) podemos ver una carpeta que contiene el esqueleto de Calabash (features-skeleton).

El archivo .feature que se crea por defecto contiene lo siguiente:

La carpeta step_definitions contendrá un archivo con extensión .rb llamado “calabash_steps.rb” donde se añadirán los pasos a seguir de nuestro escenario. Además hay que añadir “require ‘calabash-android/calabash_steps’” para poder hacer uso y todos los pasos/usos que proporciona Calabash . Aquí puedes ver ejemplos de pasos que se pueden hacer o aquí.

En la carpeta support uno de los archivos que nos encontramos es “env.rb” donde se le indica a Cucumber qué librerías tiene que cargar. En este archivo hay que añadir en ese archivo la línea de código “require ‘calabash-android/cucumber’”.

A continuación os dejo un ejemplo de una feature (ya sabéis, uno o más escenarios, que corresponde más o menos a los posibles resultados de los casos de uso) y el código para pasar los casos de pruebas (step_definitions) usando Cucumber y Calabash.

Como ya he comentado, la primera imagen de arriba es un archivo .feature de Cucumber y Calabash. Un archivo .feature describe el comportamiento previsto de la aplicación. En el ejemplo tenemos una función que describe la funcionalidad de registrarse en una página.

 Cada línea después de “Scenario” corresponde a un paso. En Calabash, se puede hacer una de las siguientes cosas:

• Hacer una acción del usuario (como un toque en la pantalla, deslizar el dedo, desplazamiento, etc.),
• Hacer una afirmación (como “Then I should see details for…”)
• O tomar una captura de pantalla.

En la segunda imagen vemos el código para que pase esos casos de prueba, añadiendo en la primera línea de código “require ‘calabash-android/calabash_steps’” como decía anteriormente.

Funcionalidades como por ejemplo screen-shot hace una captura de cómo la aplicación se ve en un momento determinado durante la prueba. Las imágenes pueden ser revisadas debido a errores gráficos, algo difícil de hacer mediante afirmaciones, además comparar las capturas de cientos de dispositivos de diferentes sistemas operativos puede ser realmente útil. Este tipo de informe de pruebas visuales, es parte de lo que ofrece el Servicio LessPainful.

¿Por qué Calabash?

A día de hoy, existen muchos frameworks, para la automatización de pruebas de aceptación, como son robotium, appium… no obstante a continuación, os voy a resumir algunas ventajas de usar Calabash:

• Como ya he mencionado antes, es multiplataforma (Android e iOS)

• Se puede configurar para ejecutarse en cientos de diferentes dispositivos.
• Permite el testing sobre aplicaciones nativas, ya sabes aquellas que se programan teniendo en cuenta las particularidades de cada plataforma, e híbridas.
• Como ya he dicho, independiente del lenguaje utilizado en el desarrollo.
• Open source.

 Terminando…

A pesar de haber diferentes opciones para automatizar pruebas de aceptación para apps móviles como por ejemplo los ya mencionados appium o robotium, usar Calabash es la mejor opción para BDD, sobre todo gracias a Gherkin, ya que representa la forma en la que se escriben estas pruebas en texto plano, (igual en un futuro escribo comparando todas estas opciones). Desde luego, con todo lo que nos aporta esta buena práctica, merece la pena llevarla a cabo.

Fuente: http://www.javiergarzas.com/2015/08/pruebas-automatizadas-para-aplicaciones-moviles-calabash-for-dummies-22-calabash-y-bdd.html

Pruebas automatizadas para aplicaciones móviles: Calabash for dummies (1/2)

Si ya conoces Calabash, y trabajas regularmente con ello, u otros frameworks para la automatización de pruebas de aceptación para aplicaciones móviles, ahórrate este post.

Siguiendo la línea de los post ¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conoceno Simplifica drásticamente la administración de sistemas: Puppet en 10 min., este post está pensado para aquellos que no van a trabajar directamente con Calabash, pero están interesados en conocer este mundillo, y también para aquellos que sí que puede que algún día quieran implantar la automatización de pruebas de aceptación para aplicaciones móviles, y quieren empezar por aquí el camino que les queda por recorrer para conocer realmente esta práctica, y que en 10 min quieran quedarse con la idea principal. Así que ¡vamos allá!

Nota, si no estás familiarizado con BDD te recomiendo leer antes estos post:

• Entendiendo qué es BDD (I),

• Entendiendo qué es BDD (II). Los escenarios

• Entendiendo qué es BDD (III). Cucumber Gherkin

• ¿ATDD? ¿BDD?… ¿Cómo? Aclarando el lío de siglas en Testing

¿Qué es Calabash?  

Calabash, traducido en español como calabaza, es un framework de software libre (mantenido aquí) que te permite escribir y ejecutar pruebas funcionales automatizadas contra la interfaz de usuario de una aplicación móvil, tanto en Android como en iOS (ya sea en dispositivos o en emuladores).

Resumidamente, Calabash funciona lanzando de manera automatizada interacciones de interfaz de usuario,como presionar botones, introducir texto, la validación de las respuestas, etc.

En la siguiente imagen se puede ver la estructura de cómo se integra Calabash, con los casos de prueba usando Cucumber (te recomiendo aquí, si no conoces Cucumber leer este post primero), y así ejecutar y validar las aplicaciones en Android e iOS:

Las “queris” en Calabash

A día de hoy, se ha implementado un lenguaje de consulta para Calabash, Calabash Query Language (y se sigue trabajando en ello). La API de Calabash Android Ruby API y Calabash iOS Ruby API tienen métodos de consulta que seleccionan objetos visibles en la pantalla en tu aplicación. Los métodos de consulta cogen un argumento de tipo string que describe los objetos que se “consultan”. La sintaxis de las consultas se basa en UIScript (aquí te dejo información sobre UIScript). Si quieres saber más sobre las consultas y las sintaxis de Calabash te dejo un link.

En la siguiente imagen, podemos ver una consulta, en la que  hay dos botones: una con el texto “Aceptar” para el botón con id  “Button1″, y el otro con el texto “Rechazar” e id “button2″. Además contiene la posición de cada uno de los botones, si están o no habilitados para su uso, etc.

Acciones como tocar (u otros gestos) se puede hacer de dos maneras:  

• Se puede hacer una consulta mediante touch function (por ejemplo touch(“button text:’Accept'”))
• O se puede almacenar el resultado de una consulta pasado en una variable: btn = query(“button text:’Accept'”)  y luego touch(btn).

Además se puede navegar por la jerarquía de vistas, desplazarse de arriba a abajo, y también  se puede extraer propiedades por ejemplo texto de esta manera text(), getText() o isText().

Si quieres ver todos los comandos puedes usar query(“*”). Aquí puedes encontrar más información sobre las querys.

Terminando

Calabash fue desarrollado por LessPainful y comprado por Xamarin. Está basado en Cucumber y desarrollado en Ruby, no obstante, se pueden usar otros lenguajes, ya que Calabash es independiente del lenguaje utilizado para el desarrollo.

A parte de para ejecutar y validar pruebas de aceptación, otra de las grandes utilidades de Calabash es que al estar vinculado con Xamarín Test Cloud, los casos de prueba con Calabash se pueden configurar para ejecutarse en cientos dispositivos móviles proporcionando información en tiempo real entre otras cosas, permitiendo así comparar y validar fácilmente los resultados de las pruebas y el aspecto visual de su aplicación a través de diferentes dispositivos y diferentes Sistemas Operativos.

Calabash está pensado para ser usado en un modelo de Testing BDD, de esto ya hemos hablado mucho, si es necesario puedes leer los enlaces al principio de este post. En la segunda parte de este post, que saldrá el lunes que viene, trataré específicamente Calabash y BDD

Fuente: http://www.javiergarzas.com/2015/08/pruebas-automatizadas-para-aplicaciones-moviles-calabash-for-dummies-12.html

Entendiendo qué es BDD (Behavior-Driven Development) (III). Cucumber y herramientas que entienden el lenguaje Gherkin

Como algun@ recordareis, hace unos seis meses me propuse hacer una serie completa de post sobre BDD. De hecho, escribí los dos primeros. Los que me conocen y ven como últimamente no tengo un minuto libre, que a su vez son muchos de aquellos que no daban un duro porque realmente terminara esa serie de post de BDD… acertaron, maldita sea, acertaron. Pero a medias, je, sólo a medias has acertado.

A medias porque Natalia Carretero, que va camino de convertirse en la experta killer en BDD, ha dado un paso al frente para solucionar la injusticia de dejar la serie de BDD incompleta. Ha tomado el testigo y aquí nos deja la parte III de la serie sobre BDD (y confiamos en que haya una 4 o las que hagan falta) 

—

Como explicaba Javier en el primer post de esta serie Entendiendo qué es BDD (Behavior-Driven Development) (I), Gherkin es de gran ayuda para los stakeholders (negocio, comerciales, etc.), para product owners y testers, proporcionando una forma sencilla de escribir test para que puedan ser entendidos por cualquiera.

En el segundo post (aquí te dejo el link),  Javier terminaba diciendo que hay herramientas capaces de entender los escenarios escritos en Gherkin, y ahí retomamos la serie de post, en las herramientas.

Las herramientas que entienden Gherkin

Pues bien, sabiendo esto, en la siguiente tabla te muestro algunas de las herramientas disponibles que entienden Gherkin, son herramientas con las que podrás utilizar BDD. La más conocida es Cucumber pero hay muchas más y disponibles para diferentes lenguajes. Véamos las más destacadas y los lenguajes en los que se suelen utilizar (os señalo los más conocidos en negrita):

Java	JBehave , JDave , Instinct , beanSpec
C	CSpec
C#	NSpec, NBehave
.NET	NSpec , NBehave, SpecFlow
PHP	PHPSpec, Behat
Ruby	RSpec, Cucumber
JavaScript	JSSpec , jspec
Phython	Freshen

Gracias a estas herramientas se pueden ejecutar pruebas automatizadas escritas en texto plano utilizando las ideas de BDD. Estas pruebas interactúan directamente con el código de la aplicación y están escritas en un lenguaje que cualquier persona puede entender, es decir, Gherkin, que representa la forma en la que se escriben estas pruebas en texto plano.

Cucumber marcó un antes y un después en la difusión de BDD y fue justo en este contexto cuando se estandarizó la sintaxis de especificación en texto plano, conocida como Gherkin. Por ello nos fijaremos en Cucumber. Pero que la tabla no os confunda, Cucumber está escrito en Ruby y a menudo las pruebas se realicen en ese lenguaje, pero también se puede utilizar con aplicaciones escritas en otros lenguajes de programación, como Java o .Net.

Sea cual sea el lenguaje en el que se realicen las pruebas, Cucumber ejecuta las pruebas tal y como os enseño a continuación:

Cómo ejecuta Cucumber una prueba

Aunque en otros post veremos un ejemplo de cómo utilizar Cucumber, en este vamos a ver cómo ejecuta Cucumber una prueba, por ser la herramienta más popular. Podemos diferenciar dos partes en una prueba:

– El caso de prueba, está en los archivos .feature (que están en la carpeta features). Son el dado, cuando,entonces, pero e y. Como ya vimos, tienen esta pinta:

Y la definición de un caso de prueba (donde se implementa la prueba, se ubican dentro de la carpeta step_definitions).

Cada escenario en Gherkin contiene una serie de casos de prueba escritos en un lenguaje que entienden todos. Estos también forman la documentación del sistema y necesitan la definición de los caso de pruebapara decir a Cucumber qué es lo que tiene que hacer.

Cuando Cucumber ejecuta un caso de prueba (Dado, Cuando, Entonces, Y, Pero), en un escenario, busca la definición correspondiente de dicho caso de prueba, es decir, la que coincida su texto, y la ejecuta el código que tenga en ella.

Para las imágenes de antes:

1 – Cucumber cogería primero el caso de prueba definido en una carpeta llamada features, un archivo con extensión .features que dice Dado un contexto inicial.

2 – A continuación, busca en una carpeta llamada step_definitions, la definición de caso de prueba que le corresponda. En este caso es:

3 – Ejecuta el código que tenga dentro

4 – Repite el mismo proceso para el resto de los casos de prueba

Y aquí termina este post. En el siguiente os diré como instalar Cucumber en diferentes sistemas operativos y un ejemplo de cómo utilizar Cucumber con Gherkin. Espero que os haya gustado mi primer post en este blog y ya sabéis, a comer mucho Pepino (Cucumber) y pepinillo (Gherkin) este verano  ¡Nos vemos en el siguiente!

Fuente: http://www.javiergarzas.com/2015/06/bdd-behavior-driven-development-3.html

Entendiendo qué es BDD (Behavior-Driven Development) (II). Los escenarios

Si recordáis la parte I de este post, hablamos de las historias de usuario o features (en el mundo BDD, aun con diferencias, puedes encontrar las historias de usuario bajo el término features) y de como, con el objetivo de automatizar el testing, cada historia de usuario se escribía usando un lenguaje llamado Gherkin.

Una “feature” contiene la descripción de la historia de usuario y uno o más escenarios (cada escenario vendrá a ser una prueba). Un escenario describe un ejemplo de comportamiento del sistema, son condiciones de aceptación de una historia de usuario y normalmente las proporcionan los product owner.

Si esto era una feature (historia de usuario):

Feature: Tener un Camion

As a Rockero

I want to a Camion

Because I want to be happy

Un escenario está compuesto de pasos:

• Given, dada (condición previa para el escenario),
• When, cuando (ejecutar una acción en la aplicación bajo prueba) y
• Then, entonces (el resultado deseado)

Por ejemplo…

Scenario: haciendo ruido con mi camión

Given yo soy rockero y tengo un camión

When yo toco el claxon

Then suena un ruido estrepitoso que me hace feliz

Lo siguiente será definir cada paso. Es decir, y tirando de un popular ejemplo en el mundo BDD, para el escenario…

Scenario: Cutting vegetables

Given a cucumber that is 30 cm long

When I cut it in halves

Then I have two cucumbers

And both are 15 cm long

Podría escribir, utilizando expresiones regulares, por ejemplo, la siguiente definición:

#encoding: utf-8

Given /^a cucumber that is (\d+) cm long$/ do |arg1|

pending # express the regexp above with the code you wish you had end

When /^I cut it in havles$/ do

pending # express the regexp above with the code you wish you had end

Then /^I have two Cucumbers$/ do

pending # express the regexp above with the code you wish you had

end

Then /^both are (\d+) cm long$/ do |arg1|

pending # express the regexp above with the code you wish you had

end

No me adelanto más en esta segunda parte, y antes de ver con más detalle esas implementaciones, tenemos que ver antes las herramientas capaces de interpretar los escenarios, más concretamente., y como ejemplo de las mismas, vamos ver Cucumber en las siguientes partes de este post.

Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-2.html

Entendiendo qué es BDD (Behavior-Driven Development) (I)

Debe haber centenares post sobre BDD y sí… este es uno más, con las características especiales de estar en español y estar escrito y pensado para aquellos que desconocíais el tema BDD por completo y queráis en poco tiempo “saber de qué va” esto, de sacar la idea principal de por qué esto del BDD es importante y por qué cada vez se habla más de ello.

En las próximas semanas iré dejando un post sobre BDD y relacionados, este es una primera y básica introducción, el siguiente será probablemente de Cucumber, etc. Me vais a disculpar que no fije un día exacto para esta serie de post “BDD”, pero es que ando demasiado liado para poder comprometerme a un día exacto (de hecho, créeme, este post que lees, y otros restos de la serie, lo empecé en abril y lo he ido terminando a ratos)

Estaría encantado de recibir comentarios, mejoras, detalles, añadidos y demás, sé que entre los lectores del blog hay auténticos expertos en BDD, animaros y me ayudáis a difundir el conocimiento sobre el tema del BDD y de “las buenas pruebas”.

Vamos a ello…

¿Qué es eso de BDD?

Behavior-Driven Development ​​o BDD es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge.

BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.

En BDD, las pruebas de aceptación se escriben usando historias de usuario, ya sabes aquello tan usado en agilidad (sino léete el anterior post)… “Como [rol ] quiero [ característica ] para que [los beneficios].”

Y, siguiendo con lo anterior, posteriormente escribir criterios de aceptación para esas historias de usuario, haciéndolo en términos de escenarios:

Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]

Given [initial context], when [event occurs], then [ensure some outcomes].

Así, simplificadamente, el ciclo básico de BDD sería el siguiente…

1 – Escribir las historias de usuario.

2 – Escribir los escenarios.

3 – Automatizar las pruebas de aceptación.

Ya sabes, con la idea final de tener un mismo “framework” de comunicación y colaboración entre desarrolladores, QA y roles no técnicos, o de negocio, en un proyecto de software. Y para tener ese punto común entre todos esos actores, algo clave es tener un lenguaje común, y ahí es donde aparece Gherkin…

Gherkin

Las historias de usuario que comentamos antes, o features (en el mundo BDD puedes encontrar las historias de usuario bajo el nombre de features, hay quien dice que no son exactamente lo mismo, pero para nosotros por ahora sí lo son), lógicamente, las escribe negocio, es responsabilidad del product owner.

En BDD, lo que haremos será, con el objetivo de automatizar el testing, aparte de tener historias en pósit, como ha sido de toda la vida, cada historia de usuario se escribirá usando un lenguaje “de programación”, llamado Gherkin (la traducción es pepinillo), y se guardarán en un fichero, de extensión .feature (normalmente dentro de un directorio llamado “features”, para más datos).

Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda “negocio”, los usuarios, etc. Su idea es contar como se “comporta” el software sin entrar en detalles de implementación.

Es un lenguaje muy simple. Sólo tienen 5 sentencias:

Feature:

Scenario:

Given

When

Then

Estas features serían historias de usuario. Y como es típico en una historia de usuario, deben tener el “As a / I want to / Because”. Vamos con un ejemplo, la historia de usuario “Tener un Camión”:

Feature: Tener un Camion

As a Rockero

I want to a Camion

Because I want to be happy

Así que Gherkin nos sirve para documentar y para automatizar lo que luego se convertirá en test, haciéndolo con un lenguaje que puede entender negocio, o cualquier product owner, y que además puedes usar en otros idiomas más allá del inglés, hasta la fecha en 40 idiomas.

Luego necesitaremos una herramienta que entienda los .feature, por ejemplo, Cucumber (para Ruby), que cuando lo lanzas genera un informe que verifica si el software se comporta como el fichero Gherkin dice. Para ello, alguien del equipo habrá escrito código que transforma el texto de Gherkin en interacciones con el código a probar, pero antes, para ello, necesitaremos escenarios asociados a cada historia de usuario, que nos den ejemplos de cómo debe comportarse el software implementado para esa historia.

Esos escenarios serán el paso intermedio entre la historia de usuario y la implementación de una prueba automatizada. Pero como este post ya se me a alargado demasiado… los escenarios y herramientas como cucumber… lo dejo para la segunda parte.

Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-1.html

Herramientas para testear tus aplicaciones Android

Si hay un quebradero por encima de todos para los programadores de Android, éste no es más que la fragmentación. Y no hablamos sólo de la fragmentación que hay en Android (donde versiones como Gingerbread siguen teniendo su cuota de mercado), sino de fragmentación en características de los dispositivos como es la pantalla y su resolución.
Pero si somos un programador purista, querremos testearlo en todos los dispositivos para asegurar que funciona perfectamente y que se ve todo perfectamente. ¿Acaso vamos a comprar un dispositivo de cada fabricante? Evidentemente no. Por eso, deberemos utilizar herramientas que nos permitan analizar la aplicación en la mayoría de posibilidades. Aquí van algunas de ellas:

Apkudo

Esta herramienta nos permite analizar de manera online aplicaciones Android en más de 260 dispositivos físicos. Permite además ejecutar Monkey (herramienta para auto testeo) de forma paralela.

Podremos ver el tiempo de ejecución de la aplicación (tiempo en instalar, ejecutar y desinstalar) en el dispositivo más lento. Dispondremos de información como el log de la aplicación, para si falló ver en qué.

App Thwack

Esta aplicación nos permite seleccionar los dispositivos donde ejecutar la aplicación. Al igual que la anterior, ejecuta Monkey, proporcionándonos datos de rendimiento, como el uso de CPU o la memoria.
A continuación podemos ver un ejemplo de los resultados que podemos observar:
Disponemos de 100 minutos gratis, pero después deberemos abonarnos a uno de sus planes:

Samsung Developers Remote Test Lab

Este producto nos permite reservar y usar un dispositivo real de forma remota, para capturar y grabar la pantalla, automatizar pruebas y compartir sesiones.

Para ello deberemos tener cuenta de desarrollador de Samsung y tener un navegador con javascript y JRE (al menos, en su versión 6).
A cada usuario le darán 20 créditos al día, equivaliendo 1 crédito a 15 minutos de prueba, pudiendo hacer uso de los mismos para un mínimo de 30 minutos o máximo de 10 horas al día. Podremos reservar incluso wearables.

TestObject

En este caso, dispondremos de más de 40 dispositivos reales y una serie de emuladores. Podremos conseguir informes de calidad, con la ejecución automática de la aplicación. Luego podremos hacer testeo manual o pruebas automatizadas según convenga. Incluso conectar con Issue Tracker de GitHub.


Disponemos de 30 minutos gratis, a partir de los cuales tendremos que contratar otro plan de minutos:


Como siempre me gusta decir, la lista podría no acabar aquí, pues hay muchos más productos. Y tú, ¿utilizas alguno de ellos?

Extras:

http://calaba.sh/
http://appium.io/

Fuente: http://www.elandroidelibre.com/2014/07/herramientas-para-testear-tus-aplicaciones-android.html

Pomodoro - (Gestión del tiempo bajo tomates)

Como nace esta técnica

Algunas personas en determinado momento de sus vidas han sentido que el tiempo que utilizan en realizar sus tareas no es suficiente,  que lo que hacen carece de sentido o que se encuentran en un estado de desorden que no les permite avanzar en las metas que se proponen, y hablamos respecto a un desorden en el manejo del tiempo, el cual muchas veces lleva situaciones de procastinación o de inclumplimiento de los deberes. Pues esta fue la situación en la se vio envuelto Francessco Cirillo a finales de los 80. Esta situación lo llevo a analizar su forma de trabajo y como empleaba su tiempo de estudio, llevándolo a crear la técnica de pomodoro. Por cierto pomodoro significa tomate en italiano, y es que resulta que el autor se pregunto si en realidad era capaz de mantener la concentración en su tarea durante 10 minutos ininterrumpidamente, por lo cual busco un cronómetro para medir el tiempo y encontro uno en su cocina con forma de tomate, de ahí su nombre.
Cuando empezó a medir su tiempo se dio cuenta que cada vez quería llegar mas lejos, proponiéndose metas y tratando de realizar ejercicios más complejos en el tiempo estipulado. Todo esto lo llevo a darse cuenta de lo poderosa que podría ser esta herramienta y lo mucho que podría ayudar a otros.

Objetivos de la técnica

Esta técnica tiene los siguientes objetivos:

• Aliviar la anciedad producida por el devenir del tiempo.
• Incrementar la concentración reduciendo las interrupciones.
• Incrementar la conciencia que tenemos sobre las decisiones que tomamos.
• Impulsa la motivación y la mantiene constante.
• Refuerza la determinación de alcanzar las metas.
• Mejora el proceso de estimación.
• Mejora el proceso de estudio y de trabajo.
• Refuerza la determinación de aplicar más dedicación en situaciones complejas.

Pasos a seguir

1. Escribir en un listado el conjunto de tareas que debe realizar, este listado debe estar ordenado por importancia de las tareas.
2. Poner un cronometro a 25 minutos, es importante poder ver cuanto tiempo falta y escuchar el sonido del reloj, esto condiciona a la persona para saber que el sonido significa que debe estar concentrado.
3. Empiece a desarrollar las tareas en orden.
4. Cuando finalice el primer pomodoro, marque una x en la tarea en la cual se encontraba realizando la actividad.
5. Descanse 5 minutos, distraigase, tome agua, charle con sus compañeros de trabajo, es importante no realizar tareas que requerirán mucho tiempo como escribir correos importantes o hablar de algún problema del trabajo con los compañeros, estas tareas deben escribirse en otra hoja aparte para realizarlas más adelante.
6. Una vez finalizado el descanso continúe con el siguiente pomodoro. Cada 4 pomodoros realice un descanso más largo de 15 a 30 minutos. Es importante recordar que en el tiempo de descanso debe despejar la mente y olvidarse de lo que esta haciendo, esto le permitirá recobrar fuerzas para continuar.
7. Una vez finalice la tarea que esta realizando táchela. Pueden suceder que realizando la actividad la finalice en medio de un pomodor, puede hacer dos cosas, si termina en los primeros 5 minutos del pomodoro puede darlo por terminado y no lo marque como un pomodoro completado, o si falta poco para finalizar el pomodoro puede utilizar el tiempo restante para hacer una revisión de las labores hechas y de lo que ha aprendido.
8. Al finalizar el día debe registrar: la hora de inicio, la actividad realizada una descripción de la actividad, la cantidad de pomodoros que empleo en esta y notas adicionales sobre la actividad realizada.
9. Por ultimo viene la parte que considero da un gran valor a esta técnica y es el mejoramiento, esta etapa consiste en revisar el registro que se realizo en el paso anterior y observar de que forma se puede reducir la cantidad de pomodoros para lograr realizar una actividad similar en menos tiempo.

¿Como se relaciona con el esfuerzo?

Recordemos que la cantidad de esfuerzo que toma una tarea es usada en scrum como reemplazo del tiempo, ya que por percepción resulta mejor trabajar orientado a logros, cumplir actividades, en vez de trabajar a contra-reloj.  Pero entonces viene la pregunta, como se mide la unidad de esfuerzo, que significa que una tarea me toma 2 esfuerzos.
En principio podemos decir que un pomodoro es una medida del tiempo, pero lo podemos convertir en esfuerzo si lo combinamos con la cantidad de personas, por ejemplo podríamos decir que una actividad puede tomar 3 pomodoros persona o 1 pomodoro pareja (dos personas). De esta forma el pomodoro se convierte en esfuerzo. Se debe tener cuidado con lo siguiente, y es que estas unidades no son aditivas, y no existen formulas que permitan convertir pomodoro persona a pomodoro pareja.
Con este nuevo concepto se abre la posibilidad de calcular mas fácilmente cuanto esfuerzo requiere una actividad determinada, sea que esta actividad de realice individualmente, en parejas o grupos. Para realizar estimaciones con esta medida debemos realizar un listado de actividades y asignarles el esfuerzo que se tomaría en cada una. Se repasa la lista y si existen actividades que requieren mas de una unidad de esfuerzo esta actividad debe ser subdividida.

Bibliografía

• Página oficial http://www.pomodorotechnique.com/
• Guía oficial de la técnica: http://www.pomodorotechnique.com/resources/ThePomodoroTechnique_v1-3.pdf

Fuente: https://codeater.wordpress.com/2012/08/14/pomodoro/