Certificado del curso Agilidad y Lean. Gestionando los proyectos y negocios del s XXI Francisco Javier Cervigon Ruckauer

Certificado del curso Agilidad y Lean pdf

Certificado

Certificado

Certificado
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:
Etiquetas:

Módulos del curso Agilidad y Lean en la tecnología, Scrum, XP, Kanban, ágil, Agile. Francisco Javier Cervigon Ruckauer

Francisco Javier Cervigon Ruckauer
. en No hay comentarios:
Etiquetas:

Archivo del curso Agilidad y Lean en la tecnología, Scrum, XP, Kanban, ágil, Agile. Francisco Javier Cervigon Ruckauer

Archivo del curso Agilidad y Lean en la tecnología

. en No hay comentarios:
Etiquetas:

Índice del curso Agilidad y Lean en la tecnología, Scrum, XP, Kanban, ágil, Agile. Francisco Javier Cervigon Ruckauer

Índice del curso Agilidad y Lean en la tecnología

  • Lección 0. Introducción

    • Objetivos del curso
    • Modalidad de evaluación
    • Normas en los foros
    • Fuentes, referencias y agradecimientos
  • Lección 1: Construir software no es como construir coches o casas

    • Ágil vs. Tradicional
    • Frente a la predicción… adaptación, o el ciclo de vida iterativo e incremental
    • Ciclo de vida ágil
    • El proyecto ágil
    • El Manifiesto Ágil
    • Los Principios Ágiles
    • Comparativa resumen de agilidad vs tradicional
    • Unión los modelos de procesos y metodologías ágiles
    • Enlaces y lecturas recomendadas
    • Test Lección 1
  • Lección 2: Peopleware

    • Trabajar en más de un proyecto a la vez genera pérdida de tiempo y disminuye la productividad
    • Interrumpir a quién programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga
    • Los equipos con mucha gente son menos productivos
    • Hay un límite en el que no puedes recortar más el tiempo de un proyecto añadiendo más gente
    • Quemar y saturar de trabajo al equipo no se traduce en mayores resultados
    • Añadir gente a un proyecto retrasado… hace que se retrase aún mas
    • Programar con música hace que seas menos productivo
    • La organización de la sala y las mesas de un equipo de desarrollo software influye en la productividad
    • Entornos físicos y productividad
    • #MobProgramming
    • Motivación en los equipos
    • Test Lección 2
  • Lección 3: El “Product Owner” y las historias de usuario

    • Historias de usuario
    • Qué información contiene una historia de usuario
    • Malas interpretaciones del concepto de historia de usuario I
    • Malas interpretaciones del concepto de historia de usuario II
    • Creando buenas historias de usuario
    • Asignar valor a una historia de usuario
    • Lecturas y enlaces recomendados
    • Taller de historias de usuario
    • Test Lección 3
  • Lección 4: Scrum

    • El equipo en Scrum
    • El Product Backlog
    • El Sprint
    • Reuniones
    • Medir el progreso del proyecto
    • Acordar una buena definición de "done"
    • Beneficios de Scrum
    • Animación de despedida
    • No olvides las buenas prácticas técnicas
    • Lecturas y enlaces recomendados
    • Test Lección 4
  • Lección 5: La planificación ágil

    • La unidad de estimación: Puntos historia
    • Planning Poker
    • Un ejemplo de convergencia en Planning Poker
    • Planning Poker II
    • Peligros al estimar
    • La velocidad
    • Histórico del equipo
    • La experiencia de un año automatizando estimaciones con Puntos Historia
    • Cuánto debe durar una iteración
    • ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates
    • Lecturas y enlaces recomendados
    • Test Lección 5
  • Lección 6: Lean y Kanban

    • Lean software development
    • Agilidad y lean no son exactamente lo mismo
    • Desperdicios de Lean I
    • Desperdicios de Lean II
    • Kanban
    • Ejemplo I: Flujo de Kanban
    • Ejemplo II: Kanban y un Sprint Backlog
    • Ejemplo III: Kanban con elementos de Scrum
    • Midiendo el flujo de trabajo en Kanban
    • Los cuellos de botella y el WIP
    • Una pizarra más compleja
    • Enlaces y lecturas recomendadas
    • Test Lección 6
  • Lección 7: Deuda Técnica y Testing Ágil

    • Deuda Técnica
    • Testing Ágil
    • Behaviour Driven Development
    • Cucumber
    • Automatización de pruebas web con Capybara
    • Automatización de pruebas móviles con Calabash I. Calabash y BDD
    • Automatización de pruebas móviles con Calabash II. Calabash y BDD
    • Calidad Software
    • Test Lección 7
  • Examen
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:
Etiquetas:

Calidad Software Francisco Javier Cervigon Ruckauer

Calidad Software

No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO

En el mundo del software, cuando nos referirnos al amplio concepto de “calidad software” hemos de ser muy conscientes de que en realidad ese “etéreo” concepto de calidad se subdivide, principalmente, en tres tipos de calidad: la del proceso, la del producto y la de las personas/equipos.
No se vosotros, pero yo demasiadas veces me encuentro con que este tema, aun siendo tan antiguo, en el mundo empresarial no está tan claro y maduro. Y, a la hora de la verdad, cuando se entrega el software, aquello que en la oferta / contrato parecía tan claro resulta que produce enormes desengaños. “¿Pero cómo puede ser qué la empresa X con CMMI nivel Y nos entregue este producto tan malo?” “¿Pero no usaban la metodología Z?”
Sin pretender, ni poder, resolver el mundo, dejáme que haga un breve resumen de estas tres tan diferentes y determinantes áreas de la calidad software:

La calidad del proceso

La calidad vista desde el mundo de los PROCESOS nos dice que la calidad del PRODUCTO software está determinada por la calidad del PROCESO. No me voy a perder en definiciones de libro, pero por proceso se entiende las actividades, tareas, entrada, salida, procedimientos, etc., para desarrollar y mantener software.
Modelos, normas y metodologías típicas aquí son los CMMI, ISO 15504 / ISO 12207, el ciclo de vida usado, e incluso las metodologías ágiles entran aquí (aunque en el mundo ágil la palabra proceso no guste nada, no entiendo muy bien porque, aunque creo que es porque hay quien aún piensa que proceso = a ciclo de vida en cascada, lo cual no es nada cierto, véase este post para más detalle)
Un buen proceso sin duda asegura un buen producto, pero, claro, también podemos seguir un modelo de procesos famoso, y que no sea el más adecuado para nuestra organización y que por ello el producto no acabe siendo el mejor. Por ello, una mala, algunas veces perversa, interpretación es asumir que cumpliendo cierto modelo, nivel de madurez, norma, metodología, ciclo de vida, o cualquier otra cosa relacionada con el proceso… se ASEGURA por ello directamente productos de calidad. ¿Realmente es garantía suficiente? ¿Una certificación sobre la calidad del proceso garantiza un producto de calidad?…

La calidad del producto

Comentaban en IEEE software que hay poca evidencia en que cumplir un modelo de procesos (CMMI, ISO 12207, una metodología ágil o no, etc.) asegure la calidad del producto. Y en Computer, que las evaluaciones de calidad deberían estar basadas en evidencias del producto (auditando el software), y no en evidencias circunstanciales o suposiciones.
Y es por ello que existen los modelos de calidad de producto, destacando entre ellos la ISO 9126, o la nueva serie ISO 25000, que especifica diferentes dimensiones de la calidad de producto. Aunque aquí la dura tarea de evaluación recae en el uso de métricas software, amplio mundo que no voy a tratar porque excedería el objetivo de esta lección.
Sí una empresa que desarrolla software debe preocuparse de la calidad del PROCESO y del PRODUCTO que desarrolla y entrega, una empresa que solo compra software (el típico cliente) debería, principalmente, preocuparse de la calidad del PRODUCTO que compra. Aunque vemos que en la realidad, las empresas que compran software lo hacen al revés, se preocupan por el proceso que usa su proveedor (CMMI, ISO, etc.) y apenas del producto que les llega. Cosas de la industria.

La calidad del equipo y/o personas

Ya lo decíamos… ¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto (o para el producto software)? Las personas. Lo más determinante, complejo, y sobre lo que menos “guías”, “maneras de puntuar” o “métodos” hay. Tema complejo donde los haya.
Aquí podemos encontrar decenas de aproximaciones para mejorar, que van desde el tan de moda coaching, a la filosofía ágil de lograr la auto-organización de los equipos, estrategias de motivación, combinaciones de los anteriores, etc. e incluso hasta hay modelos, como son los TSP y PSP.

Alguna conclusión…

Si quieres calidad, vas a necesitar los tres anteriores. Aunque depende del rol que juegues te puede importar más uno u otro, y esto es muy importante saberlo. Si eres un cliente que solo compra software no puedes perder la prioridad, procesos, productos y personas son importantes, pero la calidad del producto es para ti determinante. Si eres fabricante de software, vas a necesitar los tres y no puedes olvidar ninguno.
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:

Automatización de pruebas móviles con Calabash II. Calabash y BDD. Francisco Javier Cervigon Ruckauer

Automatización de pruebas móviles con Calabash II. 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.
A continuación os dejamos un vídeo demo en la que automatizamos la preueba de login en una aplicación móvil:
https://www.youtube.com/watch?v=EyhyGmXPbAs
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:

Automatización de pruebas móviles con Calabash I. Calabash y BDD. Francisco Javier Cervigon Ruckauer

Automatización de pruebas móviles con Calabash I. Calabash y BDD

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, y así ejecutar y validar las aplicaciones en Android e iOS:
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.

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 función (por ejemplo touch(“button text:’Accept'”))
  • O se puede almacenar el resultado de una consulta pasado en una variable: bin = query(“button text:’Accept'”)  y luego touch(bin).
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 querrás.
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:

Automatización de pruebas web con Capybara. Francisco Javier Cervigon Ruckauer

Automatización de pruebas web con Capybara

Nos podemos preguntar, ¿y si tengo una aplicación web, como puedo utilizar las ideas de BDD y cómo puedo realizar las pruebas?
Pues bien, necesitamos de algo que nos dé un vocabulario especifico para realizar las pruebas en la web, alguna herramienta que interactúe con el sitio web de la forma en la que lo haría un humano. Esta herramienta es Capybara y se utiliza, como decía, para emular el flujo de un usuario en un sitio web.
Además, Capybara va a permitir ocultar los detalles del navegador para que se puedan realizar las pruebas de una forma más sencilla. Para ello, utiliza un driver, un controlador, alguien que se comunique con el navegador web. Existen varios drives muy conocidos que se pueden utilizar con Capybara, aquí te pongo algunos con sus pros y contras:
Rack-test: es el driver que Capybara utiliza por defecto. Con este driver es rápido realizar las pruebas, pero tiene algunas limitaciones, ya que no soporta JavaScript, no está disponible para acceder a recursos HTTP fuera de la aplicación Rack y solo se puede utilizar con aplicaciones escritas en Ruby.
Selenium: Utiliza la ventana real del navegador y se puede ver la prueba en la realidad, viendo como se hace la prueba en cada momento (el texto que está introduciendo, cuando da a los botones, etc) y utiliza el motor JavaScript real del navegador. Esto hace que sea muy visual pero si se tiene una aplicación muy grande o se realizan muchas pruebas, puede llevarte mucho tiempo para pasarlas todas, ya que es muy lento.
Poltergeist: es un driver para Capybara que nos permite la conexión entre Capybara y un navegador sin interfaz gráfica. El navegador sin interfaz gráfica está basado en WebKit. Gracias a esto, se pueden lanzar scripts que carguen páginas e interactúen con ellas. Que permita utilizar un navegador sin interfaz gráfica va a permitir que las pruebas sean mucho más rápidas de ejecutar.

El lenguaje de dominio específico

Se puede utilizar el método visit para navegar entre las diferentes páginas:

Se puede hacer click en botones y enlaces:

También podemos interactuar con los elementos de un formulario, por ejemplo con lo que aparece en la siguiente imagen busca un área de texto con  nombre, id o texto con la etiqueta ‘Nombre’ y lo rellena con “Natalia”:

Se pueden consultar más métodos en la documentación oficial de Capybara.

Instalando Capybara y el driver

Para instalar Capybara, es necesario tener instalado Ruby 1.9.3 o posterior y poner por línea de comando gem install ‘capybara’. Además, si se va a utilizar el driver Poltergeist es necesario instalárselo con gym instala ‘poltergeist’o si se va a utilizar el de Selenium se instala poniendo el comando gym instala ‘seleniuv-webdriver

Configurando Capybara con el driver

En el fichero de la prueba hay que añadir que se va a utilizar la librería capybara poniendo require ‘capybara’.
Si se quiere cambiar el driver por defecto Rack-test que utiliza Capybara por otro driver en TODA la aplicación se debe poner en el fichero de configuración capybara.default_driver = :selenium o si se quiere utilizar Poltergueist cambiaría a capybara.default_driver = :poltergeist.
Pero también se puede dar el caso de que queramos ejecutar todas las pruebas con el driver por defecto race-test y solo algunas de ellas con otro driver. Entonces lo que pondríamos sería:
before(:all) do
Capybara.current_driver = :selenium
end
Y después de lo que se quiera ejecutar habría que poner
after(:all) do
Capybara.use_default_driver
end

Ejemplo con Cucumber y Capybara utilizando el driver Selenium.

Veamos un ejemplo de cómo poder utilizar todo esto. En este caso vamos a hacer un ejemplo sencillo entrando en google y buscando “cucumber”. Entonces una vez hecho esto, debemos poder entrar en la página oficial de Cucumber y buscar su documentación.
En primer lugar, vamos a crearnos la estructura de las carpetas con sus archivos correspondientes:
1. Nos creamos una carpeta llamada “capybara”
2. Dentro de ella, nos creamos una carpeta llamada “features” para guardar nuestras características, por lo que en ella nos creamos un fichero llamado “busqueda.feature”
3. Dentro de “features” nos creamos dos carpetas: una llamada “step_definitions” y otra llamada “support”
4. Dentro de “step_definitions” nos creamos un fichero llamado “step_busqueda.rb”
5. Dentro de “support” nos creamos un archivo llamado “env.rb” donde vamos a decirle a Cucumber qué librerías tiene que cargar y cuál va a ser la configuración que vamos a utilizar con Capybara, poniendo lo siguiente:

A continuación expresamos el caso de prueba con Gherkin en el fichero .feature para que Cucumber lo pueda utilizar:

Por último, empezaremos a escribir el código que pase esos casos de prueba.
1. El caso de prueba del dado se encarga de entrar en Google utilizando el método visit.

2. El caso de prueba del cuando se encarga de buscar lo que se le pase. Utilizamos el método fill_in para buscar el campo de texto donde poder introducir nuestra consulta.

3. En el caso de prueba del entonces buscamos todos los resultados obtenidos y vemos si está la web que se le pasa como argumento. En ese caso no dará fallo y lo visitamos.

4. Y si todo fue bien deberíamos poder buscar la documentación, haciendo click en el link “Docs”.

Si ejecutamos, vemos como Capybara con Selenium lanza el navegador,  pone Cucumber en el buscador, accede a la página oficial de Cucumber y por último, accede al apartado Docs del menú.
El DSL de Capybara nos ha proporcionado ese vocabulario para que podamos especificar las pruebas en la web y simplemente indicándole qué driver queremos que utilice, el driver se encargará de comunicarse con el navegador para que podamos realizar las pruebas en la web.
A continuación dejamos un video demo de todo lo que hemos explicado
Francisco Javier Cervigon Ruckauer
. en No hay comentarios:
Suscribirse a: Entradas (Atom)