Clasificación de Pruebas

Existen distintas clasificaciones para las pruebas de software. Desde el punto de vista de cómo se ejecutan, podemos clasificar las pruebas en manuales o automatizadas.

 

Por otro lado, desde el punto de vista de qué es lo que prueban, yo suelo clasificarlas en primera instancia en unitarias o no-unitarias.

 

La prueba unitaria prueba un componente en concreto. Esto implica aislar al componente bajo prueba de sus dependencias. Pues si no lo aislamos y la prueba falla, no tendremos la certeza de si la falla se debió a un error en el componente bajo prueba o si se debió a un problema en una de sus dependencias. Es aquí, donde entran en juego los llamados Test Doubles que no ayudan a aislar el componente bajo prueba.

 

Por su parte, dentro de lo suelo llamar pruebas no-unitarias, entran todos los demás tipos de pruebas, las cuales implican probar la interacción entre distintos componentes. En este tipo de pruebas los componentes ya no están aislados y por ello algunas personas las llama pruebas de integración. En este grupo están tanto las pruebas de aceptación, como las de stress y cualquier otra prueba que implique la interacción en distintos componentes. Dado que hay mucho que decir sobre este tipo de pruebas, dedicaré otro post exclusivo.

Agile Open Buenos Aires Educación 2013

La cita es el próximo sábado 10 de Agosto en las instalaciones que tiene la UNTref en el Centro Cultural Borges (arriba de las Galerías Pacífico en la ciudad de Buenos Aires)

Es un evento totalmente gratuito que se realiza con formato Open Space, lo cual permite que todos seamos tanto oyentes como oradores ;-).

Para más información pueden ver aquí y aquí.

Si bien el evento es gratuito es requerida registración previa para estimar la cantidad de asistentes y así simplificar algunas cuestiones de logística, este el link para registrarse.

¡Nos vemos!

Webinar: Técnicas de versionado para Entrega Contínua

El próximo miércoles (mañana), voy a estar dando un webinar sobre este tema. La idea es ver los conceptos básicos de la práctica Continuous Delivery y enfocarnos en cómo manejar nuestro repositorio de código para facilitar la entrega continua. Presentaremos algunos conceptos y estrategias, y veremos como llevarlos a la práctica utilizando la herramienta Git.

En página de registración encontrarás más detalles sobre este webinar.

Durante el webinar, recibiré consultas a través de Twitter (@kleer_la & #kleerScm).

 

Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino

Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.

La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.

Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.

Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.

Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.

En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.

La clave es educarlos de chiquitos

Hoy compartí el almuerzo con mi colega JuanG y algunos otros profesionales de la informática. En un momento comenzamos a hablar sobre TDD y algunas otras prácticas ágiles. Durante la charla uno de los comensales comentó que le parecía muy difícil pretender que los programadores «junior» utilicen dichas técnicas cuando las mismas ni se mencionan en las universidades. Estuve de acuerdo con el comentario respecto de la complejidad, pero al mismo tiempo agregué que en algunas universidades, estos temas son materia corriente. Para mi : «La clave es educarlos de chiquitos».

Como ocurre en todos los ámbitos de la vida, una vez que algo se hace hábito, cuesta mucho cambiarlo. Es por esto que en las materias que dicto hago mucho énfasis en cuestiones tales TDD y prueba unitaria. Un caso testigo es lo que hacemos en Algo3. En las clases prácticas resolvemos ejercicios y en todos los casos lo hacemos usando TDD. Luego, en los dos trabajos prácticos individuales que los almnos deben resolver, les recomendamos una y otra vez que los resuelvan utilizando TDD. Finalmente cuando llegan al último trabajo práctico que implica trabajar el grupo, los alumnos tienen la técnica incorporada. Un detalle importante es que si bien la técnica de TDD la aprenden en nuestra material, ya en la materia anterior los alumnos comienzan a hacer pruebas unitarias automatizadas.

Cierro este post con algunos gráficos de métricas de tests de los grupos que estoy dirigiendo en Algo3 este cuatrimestre. ¡Hermoso!

covertura

Sobre mi sesión virtual de Continuous Delivery en ITSMF

La semana pasada participé de un evento virtual organizado por ITSMF. Fue mi primera vez en un evento de esto tipo.

En un primer momento me sentí un poco incómodo, pues sentía que hablaba sólo y yo estoy a acostumbrado a interactuar con la audiencia en todas mis exposiciones. Pero luego de hablar unos minutos, empecé a percibir la interacción de la audiencia en la plataforma, lo cual me tranquilizó.

La sesión se realizó utilizando una plataforma específica para este tipo de eventos: Brightalk. La misma requería subir el material a exponer, en formato PPT/ODP. Luego loguearse en la plataforma como orador y desde ahi manejar la el avance de los slides. Para el audio, el orador debía conectarse vía telefónica. Al mismo tiempo, la plataforma tenia un espacio de chat y la posibilidad de hacer compulsas, dos herramientas muy útiles para interactuar con la audiencia.

Agradezco a la gente de ITSMF y en particular a Juan José (@PinkFloydF) por la invitación.

La sesión está disponible aquí.

Hay gente que miente, gente que roba y gente que no respeta las convenciones

Esta frase me surgió espontáneamente esta tarde mientras daba clase en Algo3. Sonó un poco extrema, a punto tal que motivó algunas risas, pero a esta altura del cuatrimestre los alumnos ya me conocen lo suficiente y saben que para mi no es chiste.

Con el correr de los años me doy cuenta que gradualmente me he vuelto cada vez más radical en algunos temas. Sin duda las diversas lecturas y prácticas de Extreme Programming han tenido algo que ver en esta cuestión.

Personalmente me he ido convenciendo que si una práctica es beneficiosa entonces llevarla al extremo maximiza los beneficios. Y estoy convencido que esto va mucho más allá del desarrollo de software.

Un modelo de madurez de Entrega Contínua

Hace un tiempo salió publicado un artículo en InfoQ sobre el tema de referencia. Hay algunas cosas del modelo propuesto en el artículo que no me cierran pero más allá de eso creo que hay dos puntos destacados en el planteo:

  1. Explicita las diversas dimensiones de la entrega contínua
  2. Propone un camino razonable para la adopción de la práctica en cada una de las dimensiones

Al mismo tiempo resulta que una empresa con la que estoy trabajando actualmente, ha definido su plan de implementación de Entrega Contínua basado en este modelo. En 6 meses les cuento que tal vamos.

Sesión virtual sobre Continuous Delivery

¿Cuánto tiempo pasa desde que el usuario expresa su necesidad hasta que el software que la satisface llega al ambiente productivo donde puede utilizarlo? ¿Cuánto de ese tiempo se debe a a ejecución de procesos manuales? ¿Cuántos errores introducen esos procesos manuales? Si no tienes las respuestas a estas preguntas, o si las tienen y te gustaria mejorarlas no dejes de asistir a esta ponencia sobre Continuous Delivery.

Este es el resumen de la sesión en la que voy a estar dictando mañana, martes 14 de Mayo. Esto es en el contexto de un evento virtual organizado por  ITSMF . El título de la sesión es: De la idea al ambiente de producción. La intención es presentar la práctica de Continuous Delivery surgida dentro del movimiento ágil.  Voy a comenzar presentando algunas cuestiones «conceptuales» y luego hablaré de algunas experiencias concretas de implementación en las que he participado. Mi intención es mezclar un poco de teoría y poco de mundo real.

Como parte del mismo evento habrá otras dos sesiones:

La primer sesión es las 10 am (hora Argentina) y me sesión en particular es a las 12.

El evento es totalmente gratuito, pueden encontrar más detalles de la presentación y el link para registración aquí.

User Stories vs. Casos de uso

Es común que en una primera aproximación tienda a verse las user stories como análogas a los casos de uso del Proceso Unificado, en el sentido que ambos artefactos describen en cierto modo una funcionalidad del sistema. Personalmente creo que esta analogia no es apropiada, ya que mientras un caso de uso es efectivamente una especificación de un requerimiento, la user story podría a lo sumo el título de dicho requerimiento.

Es más, en un punto podríamos decir que las user stories son en su espíritu contrarias a los casos de uso: mientras que los casos de uso pretenden contemplar los detalles del requerimiento para que el programador pueda realizar una implementación completa y correcta del requerimiento, las user stories son intencionalmente vagas pues lo que buscan es promover el diálogo entre quien debe implementar la funcionalidad y quien la ha requerido.