lunes, 8 de noviembre de 2010

VI Jornadas de Software Libre en Junín



El sábado estuve en Junín, invitado por los organizadores, la Rama Estudiantil del IEEE de la UNNOBA. El evento, ya en su sexta edición estuvo muy bueno (lamentablemente solo estuve en una parte del mismo)

Una buena noticia, los videos de las sesiones van a estar disponibles. Además, se difundieron en vivo!

Aún así, va un breve resumen de lo que escuché.

El amigo Andés Riancho presentó una visión de la seguridad en ambientes web de una manera muy entretenida.

Planteó un escenario (acceso pago a Internet en un hotel), y nos mostró como cuatro perfiles de atacantes distintos se comportarían, y en todo loos casos lograría acceso.

El primero, alguien que conoce mucho de sistemas operativos y networking (Charly García)
Usa un CD (BackTrack), una distro basada en Ubuntu, con herramietas de seguridad. Booteando desde el CD se tienen todas las herramientas para el ataque, ya configuradas (listas para usar)
En este caso, el ataque fue tcpdump y luego fakeo de la mac (ifconfig) de algún usuario con acceso.

El segundo, sabe de todo (Sheldon Cooper)
El objetivo es tomar control del servidor que tiene el proxy
- Nmap: info de los puertos abierto
- OpenVas: scanner de vulnerabilidades
- MSF: permite hacer exploits
En el ejemplo se encontro una vulnerabilidad, y se pudo usar un exploit que permite correr comandos en el servidor. Luego hay que trabajar para lograr un usuario de mayor nivel, ya que se entró por un servicio, cuyo usario tenía pocos privilegios.

El tercero sabe mucho seguridad informática (Paris Hilton)
Utiliza la herramienta de la que Andrés es creador (w3af), no encuentra nada obvio inicialmente, pero luego aplica una estrategia de Man in the Middle (MITM proxy provisto por la herramienta), y con eso falsea un post y consigue acceso gratuito.

El cuarto no sabe nada de Internet ni servidores ni seguridad informática (Chaqueño Palavecino)
¡Pero no es ningún tonto! Mira la página, y encuentra un fallo en el procedimiento. ¡Hace que le carguen el costo a otro huesped del hotel!

Esperen el video, un maestro Andrés!, como hacer que una charla de seguridad sea divertida.

Python y las aplicaciones extensibles, por Roberto Alsina

Roberto usó Qt (GUI multiplataforma), como una manera de hacer una aplicación rápidamente, para luego dedicarse a hacerla extensible.

Usó Qt Designer para hacer en 15 min un buscador de twitter (kwrite como editor, creo que lo usó solo para zoomerar)
Luego de tener la aplicación andando, la hizo extensible usando un framework (yapsy) para manejo de plugin. En poco tiempo tuvo una aplicación extensible!. Las extensiones son clases
Python con un método actual (un patrón command) y un pequeño archivo de configuración. Muy elegante.

Juan Pedro Fisanotti y Django

Fisa presentó Django y implemento un sitio sencillo.
Entre algunas de las cosas que resaltó estuvierno:
- Aplicaciones desacopladas (reusables), un plus de Django
- MVC: la forma de programar Web en estos días
- ORM: el mejor amigo del programador que usa datos en DB relacionales
- Plantillas: simplicidad (y posibilidad de no usarlo si uno no quiere!)
- Admin: el argumento de venta de Django, no vuelvas a escribir este código, chabón.


lunes, 1 de noviembre de 2010

¿Existe la “mejor” forma de probar?

¿La prueba manual de software es necesaria? ¿Es suficiente? ¿Y la prueba automatizada?
Es tentador pensar que si estudiamos el problema (prueba de software) lo suficiente y somos buenos profesionales, podremos encontrar “la mejor manera” de hacerlo. Si conocemos “la mejor manera”, los que realizan la prueba de otra manera están equivocados.
Alguna vez pensé conocer cual era “la mejor manera”. Luego, aprendí o cambié de contexto, y “la mejor manera” cambió.
A partir de estas experiencias soy algo escéptico cada vez que escucho (de otros, o de mí!) afirmaciones en este sentido. Esta nueva “mejor manera”, ¿que problemas viejos resuelve? ¿que problemas nuevos crea? ¿en que contexto está siendo usada?
Voy a comentar mi experiencia personal con diferentes formas y contextos de prueba. En cada contexto, analizaré los problemas comunes y cultura, y también si ese contexto es un estado final o sólo un paso hacia otro estado. Este texto se basa en la presentación que realicé en Ágiles 2010 – Lima.
No trato el problema más general de la calidad de software, sino solamente sobre la prueba.
El modelo

La comparación de los contextos está organizada utilizando el modelo de prueba comentado en el libro “Agile testing”, de Lisa Crispin y Janet Gregory, a su vez basado en las propuestas Mike Cohn y Brian Marick. En este modelo, tenemos 4 tipos de prueba (de arriba hacia abajo):
  • Pruebas Manuales
  • Pruebas de Interfase Usuaria (automatizada)
  • Pruebas de Aceptación o API (automatizada)
  • Pruebas técnicas o unitarias y de componentes (automatizada)
El costo de ejecución es menor en las Pruebas técnicas y va creciendo hasta el máximo costo, que es la ejecución de pruebas manuales. El costo de mantenimiento de las pruebas automáticas también es creciente, desde el mínimo en las pruebas técnicas, hasta el máximo en las pruebas de Interfase Usuaria. El mantenimiento de las pruebas manuales es equivalente o menor que el caso de pruebas técnicas automatizadas. En todos los casos, el costo y mantenimiento de las pruebas automatizadas requiere una inversión importante en experiencia e infraestructura. Pero esa inversión se puede llevar en muchos casos de un proyecto a otro. Los costos consideran esa inversión amortizada o distribuida en gran cantidad de pruebas.
La relación entre los costos lleva a sugerir que la forma más eficiente de dedicar esfuerzo tiene la forma de una pirámide, con las pruebas técnicas (unitarias y de componentes) en la base, las de aceptación (o API) luego, y finalmente las pruebas de UI en el vértice de la pirámide.
Contexto: Prueba Ad hoc
Durante los primeros 10 años de mi carrera, trabajé en grupos de 5 personas o menos, trabajando en desarrollo de software en áreas tan variadas como aplicaciones administrativas (ERP), adquisición y procesamiento de imágenes médicas (de medicina nuclear), y sitios de Internet que brindan información bursátil en tiempo real.
En estos equipos, no había separación de roles, todos hacíamos un poco de todo. En particular, las pruebas las hacíamos entre todos, intercambiábamos roles, probando la funcionalidad realizada por otro. La prueba final la hacían los jefes, usuarios o, si existían, las personas de servicio a cliente.
Al no haber responsables definidos la prueba solía quedar huérfana, sin mejora. En este contexto es un problema realizar pruebas de regresión, una tarea poco atractiva y compleja.
La evolución de este contexto suele ser incorporar un tester o área de testing para Prueba Manual (camino tradicional) o que los programadores empiecen a desarrollar Pruebas Técnicas o incluso TDD (camino del desarrollo ágil).
Cualquier camino de evolución pasar por un cambio cultural, ya que en estos grupos la prueba no suele ser valorada lo suficiente. Se suele escuchar “si los programadores hacen bien su trabajo, ¿por qué senecesitaría probar?”
Los problemas se hacen más notorios cuando el grupo debe crecer, tiene mucha rotación o debe mantener muchos productos.
Caso: en una importante compañía de fondos de pensión y seguros de retiro pidieron presupuesto para mantenimiento de muchas aplicaciones existentes (legacy: sin pruebas automatizadas). El cliente no aceptó una propuesta de equipo con cuatro personas, en la que una cumplía el rol de tester; sin embargo, aceptó un equipo de 4 personas con 3 programadores. Internamente el equipo se manejó con uno de los 'programadores' actuando como tester, con buenos resultados.
Motto: ¡No vale la pena probar!
Problemas: baja calidad, baja previsibilidad, regresiones
Cobertura: no hay métricas.

Responsable: todos y ninguno. Pruebas por el usuario.
Organización: generalmente chicas y con poca estructura
Contexto: Prueba Manual
En mi siguiente reencarnación, estuve 8 años en una compañía que trataba de convencer y ayudar a empresas de contexto Ad hoc a que la prueba es algo útil y necesario.
Este cambio cultural es difícil, y con riesgo de involuciones. Por eso se busca separar en un grupo autónomo a los responsables de probar. La separación y la función de probar, que a veces se desvirtúa como prueba de la persona en vez de prueba del producto, provoca enfrentamientos y fricciones con los programadores.
El diseño de las pruebas es divertido, pero ejecutarlas una y otra vez es terriblemente aburrido, lo que lleva a que pocas personas quieran quedarse mucho tiempo haciendo esto. Resultado: muchas personas capaces se van a otras áreas, más divertidas (como desarrollo), y por el recambio hay mayoría de novatos en los roles de prueba. Los que se mantienen en el rol suelen ser personas con poca inclinación a lo técnico. Para crecer profesionalmente, los testers se dedican a tareas de QA (procesos) o de Analistas de negocio, que son más valoradas en el mercado.
En este contexto, los problemas son que la prueba de regresión de productos medianos y grandes se hace muy costosa, lo que lleva a ciclos de desarrollo muy largos (para ejecutar pocas veces las pruebas de regresión) o disminución de las pruebas realizadas durante la regresión (lo que lleva a baja calidad).
La salida parece ser la automatización, pero lamentablemente no es una salida fácil, ya que las personas que están en el grupo de prueba no tienen conocimientos técnicos, y la relación con el grupo de programación, que puede aportar el conocimiento técnico, no es la mejor.
En algunos casos se pasa a Prueba Manual Optimizada.
Motto: ¡No vale la pena automatizar las pruebas!
Problemas: costo de ejecución, que a su vez lleva a seleccionar las pruebas, que baja la confianza y lleva a pocos releases
Cobertura: requerimientos, casos de uso
Responsable: Testers / QA.

Organización: testing separado
Prácticas: casos de prueba manuales, checklist
Contexto: Prueba Manual Optimizada
Luego de 6 años en Prueba Manual, reencarné en Prueba Manual Optimizada. Algo bueno habré hecho en mi vida anterior, porque un cliente exigió en un proyecto que automaticemos.
¿Por qué automatizar? Por criticidad del negocio o cuando se logra volumen suficiente en el área de prueba como para justificar la inversión.
¿Cómo hacerlo? Se suele incorporando programadores al grupo de prueba con el rol de Automatizadores de la Prueba.
Con gran esfuerzo se mantiene un conjunto de pruebas automatizadas, que permiten hacer pruebas de regresión en forma rápida, lo que permite mejorar la calidad, confianza y tiempo de respuesta. Pero por otro lado, debido a la separación entre los grupos de programación y los de prueba, es frecuente que cambios realizados en forma inconsulta en el producto rompan las pruebas automatizadas. Ysi sumamos el hecho que estas pruebas suelen ser de caja negra a través de la UI, el costo de mantenimiento de las pruebas automatizadas es alto.
Es una situación extraña, ya que en muchos casos nos damos cuenta que podríamos ser mucho más eficiente si algunas pruebas fueran de caja blanca y las hicieran los programadores, o si los testers pudieran participar en la toma de decisiones sobre cambios al producto. Pero no podemos influir en la forma en que se programa, es otro grupo.
Esta tensión puede resolverse cuando los grupos de programación y prueba empiezan a trabajar juntos y se pasa al contexto Técnico++ o al Nirvana.
Motto: No podemos mejorar la producción del código.
Problemas: mantenimiento de las pruebas
Cobertura: requerimientos, riesgos
Responsable: Testers, Testers automatizadores, QA.
Organización: organizaciones grandes, grupos de homologación separado
Prácticas: pruebas automatizadas de interfase de usuario
Contexto: Prueba Técnicas
Algunos equipos en los que trabajé (entre 2 y 40 desarrolladores) tenían la cultura de calidad incorporada con fuerte influencia de XP, por ejemplo con prácticas de Integración Continua, TDD y Pair programming incorporadas.
En estos equipos la calidad es alta comparada con los contextos de Prueba Manual. Se suele utilizar cobertura de código como métrica relevante. Los problemas que suelen presentarse son: mantener el tiempo total de ejecución de las pruebas bajo (<10 min)
La evolución natural es hacia Pruebas Técnicas++, ya que en este contexto ante los problemas la primera solución que se piensa es agregar pruebas automatizadas.
Caso: en un proyecto Ruby on Rails comenzamos con una funcionalidad de CMS sencillo para seguir luego con funcionalidad más compleja. Se trabajaba con coberturas de código por arriba del 80%. A los dos meses del proyecto, el usuario vuelve a utilizar la funcionalidad de CMS sólo para encontrarla rota, debido a un cambio en las vistas que pasó desapercibida por mucho tiempo. El análisis del problema llevó al equipo a agregar pruebas automatizadas con Cucumber y Selenium (API y UI).
Motto: Sólo vale la pena las pruebas automatizadas
Problemas: usabilidad, cumplimiento de requerimientos y regresiones en cuanto a requerimientos
Cobertura: líneas de código
Responsable: programador
Organización: equipo de programadores
Prácticas: TDD, CI
Contexto: Prueba Técnicas++
Los equipos en este contexto vienen de la Prueba Técnica, agregando prueba de APIs y quizás de UI, o de la Prueba Manual Optimizada, agregando prueba unitaria y quizás de API. En ambos casos, tienen des-balanceada la pirámide de prueba. En el caso de los que vienen desde Prueba Manual Optimizada, puede ocurrir que pierdan la prueba manual o la prueba de UI automatizada, dado que el esfuerzo por incorporar pruebas unitarias es grande, y se detecta duplicación de esfuerzo entre las pruebas existentes (manuales o automáticas a nivel UI).
Luego de lograr el balance en la pruebas automatizadas, el problema remanente son las pruebas de difícil automatización (¡ningún programador las quiere hacer!) y la falta de prueba exploratoria. Esto último puede llevar a productos que son correctos desde el punto de vista funcional y de robustez, pero que no son sobresalientes, ya que no se detectaron puntos a mejorar en forma temprana.
Motto: Sólo vale la pena las pruebas en automatizadas
Problemas: usabilidad, cumplimiento de requerimientos
Cobertura: líneas de código y requerimientos
Responsable: usuario y programador
Organización: equipo de programadores
Prácticas: ATDD, BDD, TDD, CI
Contexto: Nirvana
Aunque no he llegado aún al Nirvana. Pero estoy atento a los reporte de gente que estuvo, como Lisa Crispin.
Estos equipos han incorporado todas las prácticas de XP. Están en continuo aprendizaje sobre como complementar los distintos tipos de pruebas, la automatización a diferentes niveles y la exploración, para lograr la combinación óptima. Están en un equilibrio dinámico, siempre cambiante, atentos a cambios en el negocio, la organización, el producto y nuevos desarrollos de prácticas en el equipo y la comunidad. Se preocupan por la cadena de valor completa.
Motto: Optimizamos el todo
Problemas: buscar el balance óptimo
Cobertura: líneas de código y requerimientos, riesgos
Responsable: equipo completo (whole team)
Organización: Lean
Prácticas: ATDD, BDD, TDD, CI
Re-visitando
Las descripciones dadas en cada contexto plantean la visión que tenía de lo 'correcto' cuando estuve en ellos, aunque algunas cosas me hacían ruido. Mirando ahora hacia atrás, tengo una visión distinta, que comento a continuación.
Re-visitando: Nirvana
Hay quienes quieren ir más allá de las prácticas de XP.
Los usuarios se equivocan tanto como los desarrolladores, ¿podemos hacer algo para ayudarlos? Hace 5 años Sebastián Elbaum nos comentaba sobre las pruebas para los usuarios finales. Actualmente Excel indica (subraya) las fórmulas que considera “raras” y co posibles errores del usuario, como el caso de una columna con fórmulas que totalizan filas, excepto en una celda que tiene un valor (no una fórmula).
Soporte a la prueba exploratoria: Brian Marick nos comentaba el año pasado sobre experimentos que estaba haciendo para potenciar el mecanismo de UNDO de una aplicación, de manera de poder volver atrás en una prueba para tomar otro camino en la exploración de la misma.
Re-visitando: Ad hoc
¿Qué pasa cuando la solución implica poco o nada de programación en el sentido estricto, sino más bien configurar soluciones existentes o crear contenido?
Caso: hace un año, poniendo en marcha nuestro primer evento usando Open Space (Agile Open Bs As 2009), teníamos que decidir como hacer la registración de los participantes. Luego de evaluar un par de alternativas, incluyendo desarrollar, decidimos realizar la registración utilizando la funcionalidad de Formularios que brinda Google Docs. Una de las personas se quejó del formulario de registración, la pregunta “¿Le interesaría un evento de dos días?”, tenía sólo alternativas de dos días (dos días de semana, viernes y sábado, sábado y domingo) y era obligatoria. Hasta ahí, entendible. Pero la sugerencia que nos hacia era que deberíamos tener pruebas automatizadas. Probablemente esta persona se imaginaba que eramos un equipo de desarrollo en el contexto de Prueba Manual o Ad hoc, y nos sugería que deberíamos estar en Prueba Manual Optimizada o Técnica. ¡Pero la realidad fue que una sola persona configuró el formulario en media hora! Y el problema no tenía que ver con funcionalidad implementada, sino con la semántica del texto y la consistencia del mismo con el tipo de control utilizando. Este problema semántico pasó desapercibido por los revisores. Automatizar la prueba del formulario no hubiera encontrado el problema, y hubiera sido más costosa que el 'desarrollo'.
En algunas situaciones, la prueba Ad hoc podría ser lo mejor: desarrollo de sitios sencillos usando CMS, creando contenido y configuración.

Re-visitando: Prueba Manual
¿Podemos siempre tener un equipo integrado? ¿Podemos siempre confiar en el equipo?
Homologación de plataformas: cuando debemos proteger una plataforma, como en el caso de Microsoft, Apple o el entorno de producción de un banco, nos interesa validar algunos puntos mínimos, y simplemente no podemos confiar en que el equipo que realizó el producto (en muchos casos un tercero), haya realizado bien su trabajo. Pero por otro lado, aunque automaticemos algunas partes de la prueba (preparación de ambientes, comparaciones de antes y después), hay una buena parte de la prueba que es exploratoria, y que no tiene mucho sentido automatizar, ya que es de única vez.
Alto riesgo: aunque podamos ser un sólo equipo, cuando hay en juego mucho dinero o vidas, queremos redundancia. Podemos pagar pruebas manuales para lograr independencia (dos grupos, con dos técnicas distintas)
Productos que no controlamos, open source o no: cuando construimos sobre otros productos, la ecuación que justifica las pruebas automáticas nos juega una trampa, si el dueño del producto decide cambiar la aplicación, él solo evalúa sus costos, pero puede romper nuestras pruebas automáticas. (ej. en los que trabajé: Outlook y Liferay)
En algunas situaciones, la Prueba Manual podría ser lo mejor, buscando el mejor punto en el continuo que hay entre prueba manual totalmente definida y la prueba exploratoria. También debe considerarse tener ayudas automatizadas.
Re-visitando: Prueba Manual Optimizada
Cuando el producto no es sólo software, puede ser factible automatizar parte de la prueba (correspondiente al software) y realizar el resto en forma manual.
Algunos casos de esta situación podrían ser
  • CMS complejos, en los que no sólo se desarrolla contenido, sino también extensiones o aplicaciones.
  • Productos en los que el software acompaña al texto, y probablemente el texto sea lo más importante, como tutoriales
  • Soluciones que incluyan procesos: probar que los procesos se realicen correctamente (por ejemplo que las personas estén entrenadas y sepan qué hacer) es algo que debe probarse con las mismas personas.

Re-visitando: Prueba Técnica/ Técnica++
No encontré situaciones en las que convenga quedarse en estos contextos, siempre me parecieron pasos hacia el Nirvana. ¡Pero creo que es sólo cuestión de tiempo!
Conclusiones
Las metodologías ágiles han logrado una mejora muy importante en la calidad lograda en los desarrollos. Es tentador aplicar siempre las técnicas y prácticas que han permitido estas mejoras, y es tentador pensar que nuestros problemas se resuelven con más y mejor aplicación de las mismas.
Por otro lado, he escrito críticas a algunas prácticas (como el (ab)uso de métricas de cobertura de código), para luego encontrar que personas a las que respeto encuentran estas críticas inconvenientes, ya que se interpretan como un ataque a las técnicas de automatización de la prueba.
Estos contextos me han ayudado a aclarar las discusiones sobre la conveniencia de la utilización o no de las distintas prácticas. Espero que pueda ayudar a otros. ¿Tu que opinas?