Calidad del Software

Equipo QA – El recurso oculto

Posted on 4 marzo 2009. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Recursos Humanos, Roles, Trabajo en Equipo, Waterfall |

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera, ya sea utilizando procesos de desarrollos tradicionales o Agiles.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no. Sin embargo con este pensamiento se deja de lado la naturaleza destructiva de las actividades de Testing y el no centrarse en el funcionamiento correcto, sino en los aspectos fallidos del software.

También se está asumiendo que el aseguramiento de calidad es solo cumplir con actividades de Testing. Nada más lejos de la realidad.

En las metodologías tradicionales de desarrollo de software, se tiene especial cuidado con la planificación de las pruebas, de modo tal que esta sea acorde a la definición temprana de los requerimientos (obviando las verificaciones y validaciones QA) y en base a un aprendizaje oportuno de como debería funcionar el sistema, de modo tal que según lo planificado, en ciclos de pruebas de sistemas se valide la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida, se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos.

En la vereda del frente estarían las metodologías Agiles, donde la planificación del Testing debe ser adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema, lo cual puede presumir una mayor participación de los miembros QA en etapas tempranas del proceso de desarrollo, inclusive en la misma formación de los requisitos, su analisis y estimaciones, lo cual comprensiblemente podría ser deseable.

Esto es en resumen como se comporta el Testing en metodologías no Agiles.

De este modo, conceptualmente la participación del QA cambia de un rol de “full-control” a “full-partner” del resto de los miembros del equipo.

Esta concepción permite revalorizar los roles QA debido al uso petenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers, podrían ser utilizados a su máxima potencia, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias tempranas.

A su vez los miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto.

Pero no confundamos esta revalorización del personal QA tratando de abarrotarla detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile”. Inclusive muchos “pseudoagilístas” consideran a un Tester como a cualquier otro recurso QA, un recurso de menos rango y hasta despreciable para la organización.

QA se da cuenta de la evolución por la misma adaptación que debió sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Anuncios
Leer entrada completa | Make a Comment ( Comentarios desactivados en Equipo QA – El recurso oculto )

Tres factores que influyen positivamente en los proyectos exitosos

Posted on 23 febrero 2009. Filed under: Calidad del Software, Gestión de Proyectos de Software, Métricas, Project Management | Etiquetas: , , , , |

Según una revisión realizada por SDTime a cerca del Chaos-Report,  , los proyectos iniciados en el año 2006 han culminado exitosamente en un 35%, comparado con el 16% reportado en el año 1994.

Considerando como exitoso a aquellos proyectos que culminaron a término, dentro del presupuesto y satisfaciendo las necesidades de los usuarios, se conoció que se redujo de casi 53% al 46% la tasa de proyectos que no cumplían con alguno de estos tres atributos de éxito.

Según la revisión existen tres factores que fundamentan esta mejoría:

  1. El estilo de gerenciamiento, los conocimientos en técnicas y métodos como la evolución de las estrategias y la aplicación de todo el conjunto en contextos dinámicos, permite que los proyectos inicien de un modo mucho más favorable, lo cual directamente impacta en su desarrollo y culminación.
  2. La nueva infraestructura Web juega un papel significativo para la producción de mejores proyectos, por cuanto permite que una idea pueda ser mostrada, aprender de ella y obtenerse un importante volumen de retroalimentación que genera experiencias dinámicas únicas.
  3. Pero podría decirse que el principal factor que favorece a que los proyectos sean exitosos, es la creciente inclusión del aseguramiento de la calidad, lo cual ha permitido que las organizaciones desde un principio se planteen aspectos de sus productos y servicios que antes no consideraban, incluyendo la relación con sus clientes y usuarios finales de quienes requieren cada vez más devolución para el perfeccionamiento de todo el proceso.

Un elemento central del aporte QA son las métricas organizacionales y quienes a medir su rendimiento, lograron tomar partido de sus fracasos y éxitos, revirtiendo los aspectos negativos de los proyectos para conseguir un fuerte sesgo a la culminación exitosa de sus proyectos.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Tres factores que influyen positivamente en los proyectos exitosos )

Actitudes y Aptitudes – 2

Posted on 20 febrero 2009. Filed under: Actitudes, Aptitudes, Capacitación, Habilidades Personales, IT Management, Opinión, Pruebas de Campo, Recursos Humanos | Etiquetas: , , , , |

Agustín, ¿que esperabas obtener de las respuestas de los entrevistados?

sería importante que nos contaras eso para saber si no pecaste de lo que la mayoría de los entrevistadores pecan, que quieren innovar en las entrevistas siguiendo un proceso que en definitiva es clasisista. 

Es muy interesante ver cuando los entrevistadores hablan mal de los entrevistados adusiendo que no pueden resolver tal o cual “asunto simple” que uno mismo está acostumbrado a resolver a diario, o no responden de acuerdo a las espectativas.

Sin embargo, la mayoría de las veces no se explica el contexto de la entrevista, por ejemplo indicando que no se esperan respuestas tradicionales y que se busca que los interesados en el trabajo puedan responder innovativamente, hasta con un toque de “infantilismo” si se quiere aceptar el término.
Así mismo no se plantean las dinámicas que le permita al entrevistado adaptarse rápidamente al proceso de selección y logre participar de juegos, actividades de grupo y cosas por el estilo que ayuden al mismo entrevistador ir detectando líderes, planificadores, operarios, según la participación y su modo de resolver los aspectos de las dinámicas.

Luego hay que tener en cuenta que muchos recruiters intentan innovar en la forma de encontrar nueva gente, pero en cuanto ven un talento, inmediatamente le buscan el “pero”, y lo tildan de excéntrico o viciado, dado a que gente de esta naturaleza es un poco excentrica y hasta demasiado exigente. Allí mismo comienza el proceso de truncar el caracter innovador del prospecto.

También se debe tener autocrítica
Analizar si se está dispuesto a que la gente sea proactiva, auto resolutiva, extrovertida y motivada como motivadora, por que aunque son atributos deseables en las personas, son aplacables en la mayoría de los entornos de trabajo.

¿Se está dispuesto a detectar los talentos con potencial pero sin las habilidades técnicas maduras?
creo fuertemente que esta es la principal razón que evita que las personas talentozas estén ahora mismo trabajando y no pasa lo mismo con quienes mañana mismo puede iniciar una actividad técnica que aporte valor técnico y operativo inmediato, pero que a la larga su curva de aprendizaje en el resto de los ámbitos, es plana.

Buscar talentos es un proceso de maduración organizacional
fortalecido por un aprendizaje por parte de los RRHH, en estrategias, métodos y técnicas específicas y hasta comprendiendo aspectos psicológicos y neurofisiológicos de los que ni si quieran oyeron hablar y mucho menos entienden de buenas a primeras.
Lleva mucho tiempo comprender esto y mucho más aplicarlo y mucho más aún ver los resultados reales.

“Extreme Interviewing”
es un metodo reciente de entrevistas basadas en dinámicas de grupo y trabajo específicos que ayudan a detectar talentos, basados no netamente en habilidades técnicas, sino más bien en actitudes correctas que permitan la absorsión de nuevas habilidades según el curso de los negocios actuales.
Se pretende detectar a las personas que podrán sostener una curva de aprendizaje constante dentro de la organización.
Intenta validarse en contraposición con las “Entrevistas Tradicionales”, pero lo malo es que ya se le dió una orientación que la liga con las metodologías Ágile.

¿Malo por que?
Por que ya antes, con mucho sentido común, muchos se dieron cuenta que la búsqueda y reclutamiento tradicional de personal IT (o de cualquier otro tipo), son obsoletas o comenzaban a serlo y mientras estas buscaban “robots tecnificados”, las personas comenzaron a estar más lejos de estas habilidades requeridas, por la velocidad del cambio tecnológico, por los desmanes psicológicos que propinan seguir estos rítmos de aprendizaje contínuos, por la mala calidad de vida que genera en si mismo tratar de estar al corriente, sobre todo los que sientes estar siempre al borde del avismo para permanecer en sus puestos de trabajos o conseguir uno mejor.

En artículos de opinión personal, yo mismo ya había hablado de este tema y muchos foros había preguntado cual es la preferencia en una organización “¿un elevado perfil técnico o una mejor actitud?”. Un ejemplo puede leerse aqui: “Actitudes y Aptitudes – 1”

Sin embargo este tipo de “entrevistas extremas” tiene una connotación importante, pues todos los posibles candidatos son convocados a trabajar juntos en sesiones de trabajo por pares, donde se les asigna una tarea a realizar, con la premisa de resolver un problema, sin embargo, los recruiters no observan solo las capacidades de resolución, sino el desembolvimiento del prospecto como un ser humano que interactuará en una sociedad de trabajo colaborativo y con objetivos comunes, tal es así que la resolución del problema pasa a ser un elemento secundario y se valor mucho la capacidad de “hacer sentir bien a tu socio colaborador”.

La respuesta siempre apunta al equilibrio
pero los reclutadores parecen no entenderlo, ni las organizaciones cuando inician el proceso de búsqueda para cubrir vacantes. Es en ese punto cuando quieren al “genio de la bola de cristal”. Ah!!! también debe ser proactivo, autogestionado, colaborador y resolutivo con un alto sentido de la urgencia, con un caracter apacible pero fuertemente decidido, con amplia orientación al cliente y a los servicios.

Hacer sentir bien a tu socio colaborador
Lo que se debe intentar buscar, es evidencia de las personas con verdaderas capacidades de ayudar a sus pares, colaborar con ellos sin importar el inconveniente, ni las diferencias de habilidades técnicas. Quizás la idea es siempre “nivelar hacia arriba”.
Lo que se destaca, es que las personas que finalmente serán seleccionadas, en realidad comenzaron con su entrenamiento en el preciso momento en que iniciaron el proceso de evaluación y selección.

El diseño de un ambiente propicio para el aprendizaje
es el aspecto fundamental para este cambio de paradigma, ya que no es posible promover el reclutamiento de talentos sobre el reclutamiento de habilidades si organizacionalmente solo nos interezan los aspectos de resolución técnica inmediata y no contamos con la estructura de capacitación y transferencia de conocimientos técnicos.
Nuevamente la capacitación es un ítem de importancia, pero fijémonos que aquí no comentamos los mismos errores.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Actitudes y Aptitudes – 2 )

QA & Testing en SCRUM

Posted on 24 enero 2009. Filed under: Actitudes, Aptitudes, Calidad del Software, Comunicación, Entorno de Pruebas, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Organización del Trabajo Personal, Procesos Ágile, Project Management, Soporte Colaborativo, Testing, Trabajo en Equipo | Etiquetas: , , , , , , |

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3) serán de desarrollo y una (1) de testing? ¿como se gestionan los defectos? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuan codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros estos últimos dos años. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y me arriesgo a decirte que en SCRUM no está bien estipulado como es el proceso de testing y calidad.
Leí varios libro sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos, como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos.
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando el requerimiento es expuesto al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible. Debes contar con los recursos necesarios y adecuados. El problema aquí nuevamente es la planificación del testing y la calidad.
    ¿tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional.
  • Mientras se hace testing los desarrolladores codifican. Para eso están, salvo que también sean testers, ya que aunque está mal visto en los paradígmas tradicionales, puedo asegurar que visto con un pensamiento lateral es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo QA.
    También adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
    La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos. Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar, ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Saludos,
Javo.

Leer entrada completa | Make a Comment ( 2 so far )

LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

Posted on 2 enero 2009. Filed under: Calidad del Software, Entorno de Pruebas, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Resolución de Problemas y Gestión de Incidentes, Soporte de Aplicaciones, Testing | Etiquetas: , , , , , , |

Algunas estrategias de detección de errores en nuestras aplicaciones pueden parecer demasiado sencillas o desactualizadas, sobre todo con el auge y advenimiento de herramientas potentes, con cientos de reportes, gráficas y métricas para analizar.

Sin embargo prácticamente ninguna herramienta permite a desarrolladores, analistas funcionales y testers de aplicaciones, reconocer la causa raíz de los problemas que aquejan a nuestros desarrollos.

Una técnica sencilla y pronta a aplicar, es la generación de logs de errores en formato TXT. A partir de allí mejorar el proceso de construcción en base a información obtenida del núcleo de funcionamiento de nuestras aplicaciones, es cuestión de solo dejar volar la imaginación.

Aunque un conjunto de nuevas herramientas podrían ser la solución para el ahorro de tiempo y dinero en la resolución de defectos, estas herramientas principalmente deben tener la capacidad de generar reportes que permitan aislar los problemas raíces, haciendo mucho más sencillo el diagnóstico y resolución, sin tener que invertir en costosos ambientes de aislamiento ni tiempos de reproducción.

Estas soluciones no están del todo presente en las actuales herramientas disponibles, ni diseñadas para el comportamiento dinámico de los defectos y solo se permite un análisis estático basado en la mayoría de los casos, en pruebas orientadas de “caja negra”.

Pero tal vez la productividad se vería acelerada exponencialmente si no solo pudiéramos introducir herramientas con estas características dinámicas, sino que a su vez tuviéramos la capacidad de darle a nuestras aplicaciones la capacidad de resguardo y notificación de errores.

Desde el análisis y diseño y bajo un planteo de pruebas que orienten la construcción de los componentes, es posible introducir ciertos niveles de detalles que serían plasmados en “logs de errores”, los cuales pudieran ser de gran utilidad para el diagnóstico de problemas raíces y resolución temprana, es decir en fases de pruebas tempranas.

Al finalizar cada ciclo de prueba, testers y desarrolladores pueden interactuar con mejor foco en las causas raíces de los bugs, errores de construcción e inclusive errores de interpretación de requisitos o detección de requisitos mal formados.

La verdadera potencia de tales “logs de errores” se manifestarán solo si esta solución es diseñada y aplicada en forma armonizadas para que no se entorpezca el trabajo y los resultados sean positivos y bien significativos.

Un beneficio central es que los “tiempo ventana” demasiados cortos para la resolución de defectos, sean mejor aprovechados y el proceso se optimice significativamente.

Hay quienes opinan que se deben modificar significativamente los requerimientos para incorporar estos elementos a los procesos de desarrollo, pero yo creo que el esfuerzo no es tan grande como para evitarlo y los beneficios son tremendos como para dejar de hacerlo.

No piensen en tecnificar demasiado ni en agregar complejidad, orienten esta solución a la simplicidad y facilidad de lectura y comprensión y bastará con utilizar un notepad o archivo tabulado para comenzar a obtener resultados que mejoren la visibilidad del comportamiento erróneo de nuestras aplicaciones.

Potenciar la solución  es cuestión de imaginación.

Leer entrada completa | Make a Comment ( Comentarios desactivados en LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones )

CMMI/Agile. Un híbrido que se viene – I

Posted on 23 diciembre 2008. Filed under: Calidad del Software, CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Testing, Trabajo en Equipo | Etiquetas: , , , |

He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI.

Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un híbrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles.

Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfocan en uno u otro modelo.

Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto.

Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes.

Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

Otro precepto que aleja CMMI de ágile (keep it simple).

Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero… ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear, …?

Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

Leer entrada completa | Make a Comment ( 4 so far )

El desarrollo de software Ágile y la automatización

Posted on 11 diciembre 2008. Filed under: Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas Unitarias | Etiquetas: , , , |

todo lo que he leído hasta el momento da claros inidicios de que la automatización es un hecho en los entornos de desarrollo Ágiles. Tal es así que pareciera que no existe programación sin Pruebas Unitarias o sin Intengración Contínua, ni pruebas de sistemas sin automatización, inclusive si las mismas fueran manuales.
También se está hablando a pleno de los ambientes colaborativos y automáticos para la generación de requerimientos.
Por experiencia puedo decir que en muchas fabricas de software no se utilizan tales herramientas y se utilizan procedimientos y técnicas “artesanales”.

Inclusive siguiendo metodologías de desarrollo Ágile para la gestión, tal como Scrum, no se ejecutan otras prácticas Ágile. 

Cual es el límite para decir que somos verdaderamente Ágile o que no lo somos?

Mi amigo Juan Carlos Sanchez Miralba, nos da desde XING una respuesta con un punto de vista completo y claro:
Primero debemos diferenciar entre modelo de desarrollo y de gestión. El modelo de gestión puede ser Scrum sin desarrollar utilizando metodologías ágiles.

Si miramos algunos Principios Ágile no forzosamente debemos automatizar todos los procesos. Por lo tanto podríamos aplicar perfectamente el manifesto agile a un proceso de desarrollo cascada iterativo en el que cada iteración sea de una o do semanas como mucho.

No obstante la metodología de programación extrema XP involucran prácticas y herramientas de test unitario e integración continua, las cuales son excelentes para dar soporte a un verdadero proceso de desarrollo Ágile. 
Aquí la automatización de las pruebas y la integración contínua son inobjetables.

Otras Metodologías Ágile no hacen referencias directas a la automatización.

Básicamente aplicando dos principios:
1- Encontrar errores antes en el ciclo de vida es más barato –> Inspección de código y test unitario.
2- Cuantos menos cambios antes del test fácil es la solución –> Integración continua / test automatico de integración.

podemos decir que son dos buenos pilares en los que asentar un desarrollo ágil.

Gracias Juan Carlos
https://www.xing.com/app/forum?op=showarticles;id=16233872;articleid=16254918#16254918

Leer entrada completa | Make a Comment ( Comentarios desactivados en El desarrollo de software Ágile y la automatización )

¿Que es lo que significa un entorno de pruebas inconsistente?

Posted on 5 diciembre 2008. Filed under: Calidad del Software, Entorno de Pruebas, Gestión de Proyectos de Software, Ingeniería del Software, Juegos de Datos, Pruebas de Campo, Pruebas de Sistemas, Testing | Etiquetas: , , , , , , |

Se conoce como “entorno de pruebas inconsistente”, al entorno de ejecución de pruebas que no cumple con los requerimientos del Plan QA y/o del Plan de Testing. Estos documentos formales de los procesos de desarrollo, definen cuales son las necesidades de Recursos IT, Recursos Humanos, Juegos de Datos, entre otros ítems a cumplir, previo a la ejecución de un ciclo de Testing. Estos elementos serán requeridos, presentados y revisados para los diferentes ciclos planificados a lo largo de todo el ciclo de vida del proyecto.

Hay quienes pueden pensar que un entorno incompatible, está relacionado a la diferencia de entornos entre el ambiente de laboratorio y el ambiente de producción (donde se desenvuelve el usuario final), sin embargo esto no es real puesto a que en la mayoría de los casos, los entornos de producción son absolutamente irreproducibles, principalmente por su costo.

Por ende un ambiente de pruebas no debe ser necesariamente un espejo de los ambientes de producción y mucho menos utilizar el juego de datos que en producción se utilizan, sino que solo es factible simular en una variedad de grados de aproximación, y definir las características del sistema bajo prueba para tratar de inferir el comportamiento del mismo en un ambiente real.

Esta es la misma razón por la cual existen y se planifican las “Pruebas de Campo” de los productos desplegados. El nuevo sistema corre posiblemente en paralelo al sistema actual, con el objeto de determinar y reconocer la estabilidad y robustez del mismo, como también los niveles de cumplimiento respecto a los requerimientos.

Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿Que es lo que significa un entorno de pruebas inconsistente? )

El 85 por ciento de las empresas españolas de software tiene menos de diez empleados

Posted on 4 diciembre 2008. Filed under: Artículos sueltos, Calidad del Software, Mercado Tecnológico |

El sector del software en España está formado por 32.023 empresas, de las cuales el 99,6% son pymes y un 85%, micro empresas (menos de 10 empleados). A pesar de sus reducidas dimensiones, las micro empresas generan un 60% del valor del sector y dan empleo a un 70% de los trabajadores. Es el retrato inicial esbozado por el responsable de Calidad del Instituto Nacional de Tecnologías de la Comunicación (INTECO), Ignacio Caño, en el marco de las V Jornadas de Calidad de Software EXPO:QA, organizadas por SOGETI ESPAÑA.
Caño tomó estos datos como punto de partida para resaltar el valor estratégico de la calidad en el sector del software, y añadió que la certificación de la calidad del software es una de las vías clave para impulsar el sector en España. Durante su ponencia en EXPO:QA, el representante de INTECO destacó algunos datos de estudios elaborados por la institución oficial, como por ejemplo que sólo un 0,67% de las pymes españolas poseen alguna de estas certificaciones. De hecho, según estos mismos estudios, el 86% desconoce los modelos de mejora y un 79% ignora los beneficios económicos que comporta aplicar metodologías de calidad.
Caño se refirió también al desconocimiento de las metodologías de calidad, que alcanza el 65,8% en el caso de las micro empresas.
En el caso de las grandes compañías (las que tienen más de 250 empleados), destaca que un 33,9% tiene intención de implantar a corto plazo metodologías de calidad. En el otro extremo, sólo un 5,6% de las micro empresas se decidirá a corto plazo a dar este paso por la mejora de su metodología de calidad.
Durante su ponencia en EXPO:QA Caño destacó también  algunos aspectos negativos que pueden lastrar el despegue del sector. Por ejemplo, el hecho de que sólo un 26% de las organizaciones participe en eventos que les permitan relacionarse o darse a conocer, por un 74% que no lo hacen. Además, el 90% desconoce las ayudas y programas públicos de formación en calidad de software.
Además de Ignacio Caño, EXPO:QA 2008 ha contado con la intervención de otros muchos expertos. Uno de ellos es Eric Pugh, que aportó su visión sobre los sistemas de Integración Continua (IC), no sólo desde el punto de vista técnico, sino también social. Por su parte, Edgardo Greising compartió la metodología usada en el Laboratorio de Ensayos de Plataformas del CES, mientras que Susan Windsor habló de los pros y contras de las recientes certificaciones de Software Testing. Por su parte, Luis Rodríguez Berzosa habló sobre la externalización de proyectos, apuntando como pista que “cuando mejor se reconoce la falta de calidad es cuando se sufre”.
En otra línea, Karen N. Johnson abordó la importancia del Story Telling, incidiendo especialmente en la dificultad de “pintar imágenes verbales” y en el uso de filtros que ayuden a adecuar el lenguaje en función del tipo de audiencia. En una vertiente más técnica, Fran O’Hara disertó sobre las estrategias de Testing basadas en Agile.
Obtenido de Cibersur.com

Leer entrada completa | Make a Comment ( Comentarios desactivados en El 85 por ciento de las empresas españolas de software tiene menos de diez empleados )

Demanda laboral IT en Argentina – Acumulado Anual

Posted on 29 noviembre 2008. Filed under: Artículos sueltos, Calidad del Software, Gestión de Proyectos de Software, Opinión, Recursos Humanos |

Recientemente en el sitio Universo Bit se publicó la lista de demanda laboral IT, actualizada hasta el 22 del mes de noviembre del año 2008.

La imagen muestra cuales son las herramientas IT más requeridas en el mercado en todo el año y cuales son los perfiles de mayor demanda.

Demanda Laboral IT - Noviembre 08

Queda muy a las claras que la inversión en calidad aún no es demandante, o quienes cubren puestos QA tienen mayor estabilidad y perduran en sus posiciones, o un bajo porcentaje de profesionales involucrados en QA es suficiente para el control, seguimiento y aseguramiento de la calidad de todos los procesos, prácticas, productos, servicios y derivados de todas las áreas.

De cualquier manera algo no me huele bien respecto a la demanda de profesionales QA.-

Leer entrada completa | Make a Comment ( Comentarios desactivados en Demanda laboral IT en Argentina – Acumulado Anual )

¿Que hace un SQA?

Posted on 22 noviembre 2008. Filed under: Calidad del Software, Gestión de Proyectos de Software, Habilidades Personales, Ingeniería del Software, Project Management | Etiquetas: , , , , |

Es responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado. Para asegurar la calidad debe revisar la calidad de los entregables de planificación del proyecto y los entregables de valoración del proyecto. Además revisa el nivel de apego al modelo de proceso de desarrollo de software y a los planes de Verificación, Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones encontradas.

Debe conocer los conceptos y técnicas de Gestión de Calidad del Software. Debe identificar las propiedades de calidad que deben cumplir los productos del proyecto.

Centralizar y revisar las entregas que se realizan durante el ciclo de vida del proyecto.

Realiza las Revisiones Técnicas Formales con los responsables de los productos a revisar.

El Responsable de SQA debe:

  • Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo

  • Asegurarse de que se realicen estudios de factibilidad

  • Realizar mediciones para comprobar la calidad del proyecto

  • Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos

  • Evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto

  • Registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el Cliente.

Perfil del rol

  • Debe conocer los requerimientos del sistema.

  • Debe conocer los estándares o lineamientos del proyecto para asegurar la calidad.

Actividades que son responsabilidad del rol

  • Planificar la Calidad

  • Revisión Técnica Formal (RTF)

  • Revisar las Entregas

  • Revisar el Ajuste al Proceso

  • Evaluar la Calidad de los Productos

  • Realizar el Informe Final de Calidad

Entregables que son responsabilidad del rol

  • Plan de Calidad

  • Informe de RTF

  • Entrega Semanal de SQA

  • Informe de Revisión de SQA

  • Informe Final de Calidad

Actividades en las que está involucrado el rol

  • Relevar los Requerimientos

  • Especificar los Requerimientos

  • Priorizar los Requerimientos

  • Validar los Requerimientos

  • Validar con Prototipo

  • Definir el Alcance del Sistema

  • Definir la Línea Base del Proyecto

  • Planificar el Proyecto

  • Describir la Versión

  • Planificar la Transición

  • Seguimiento de Satisfacción del Cliente

  • Gestión de Riesgos

  • Registrar Esfuerzo

  • Auto estudio

  • Reunión de Equipo

  • Preparar Cierre del Proyecto

  • Reunión Conmemorativa


Obtenido de MUM

Leer entrada completa | Make a Comment ( 1 so far )

Desempolvando Bases de Datos

Posted on 21 noviembre 2008. Filed under: +, Juegos de Datos, Soporte de Aplicaciones, Testing |

Generación de Juegos de Datos para Pruebas de Performance

¿Puede ser que me haya olvidado de como realizar una simple conexión a una base de datos? Si, puede ser. Sobre todo luego de 700 días sin esos menesteres.

¿Imaginas cuantas cosas olvidaste con el transcurso del tiempo?

Sucede que mi pasaje del Testing al SQA implicó una merma sustancial de actividades técnicas relacionadas a aquellos operaciones que antes eran comunes. No me resulta tan simple generar por mi propia cuenta un entorno de base de datos para ser utilizado como juego principal de datos, ahora relego y quizás demasiado.

No es que no tenga la capacidad, pero tengo que desempolvar mis conocimientos para ponerme a tono con el ejercicio que ello implica.

Les cuento. Hoy quise generar varios miles de actividades para un sistema de sincronización de datos al estilo P2P, las cuales serían utilizadas en pruebas de rendimiento. La base de datos no es compleja pero tiene sus aristas, como casi todas las cosas, así que tuve que analizar todos los esquemas para saber que me serviría. Así fui separando las tablas que me servirían de las que no.
Luego vi que había un buen grado de relación entre algunas de las tablas que necesitaba y una tabla en particular sería la de mayor utilidad.

Ahora, luego identificado todo esto, debí pasar a lo tangible, entenderme con PostgresSQL 8.1 y su PLPGSQL.
Como supe que no nos llevaríamos bien y necesitaba lo antes posible los datos, decidí pasar a la acción bajando el nivel de mis acciones (¿la simplicidad ante todo?) y utilizar ACCESS para obtener los datos, hacer las modificaciones y luego migrar los resultados a Postgress.

Al principio no recordaba como realizar una conexión a la base, aquí comienza mi historia:

Javier dice:
Martín, tirame unos tips para conectarme a la base de datos Postgres
Martín dice:
1 – hace un odbc a una bd postgres
2 – Importar la tabla actividades y todas las que comiencen con actividades_******
3 – Y ahí podes ver como es el tema y empezar a toquetear
Martín dice:
al paso 2 lo haces desde un MDB
Javier dice:
donde está ubicada la base de datos?
Martín dice:
server: xxxdesaxx (192.168.105.4)
puerto: xxxx
usuario: postgres
psw: xxxxx
Javier dice:
el nombre de la base es CRM?
Martin dice:
DRM_TST

Imagen 1 – Mis primeras acciones para crear el conector a la baseimage

 

 

 

 

 

 

 

 

 

 

 

Imagen 2 – Ingreso los parámetros de la base

image

 

 

 

 

 

 

 

Imagen 3 – Genero la base . MDB que importará las tablas Postgres
image

 

Imagen 4 – Gestiono la importación image 

 

 

 

 

 

 

 

 

 

 

 

Imagen 5 – Indico el tipo de conector considerando que cree anteriormente un conector ODBC
image 

 

 

 

 

 

 

 

 

 

Imagen 6 – Localizo el conector creado
image 

 

 

 

 

 

 

 

 

 

 

 

 

 

Imagen 7 – Selecciono las tablas a importar
image

De aquí en más ya es abrir las bases, generar las consultas SQL, exportar Excel si fuera necesario. En pocas palabras a trabajar la base.

Lo difícil de alguna manera, es pasar los cambios para la nueva base al Postgres y peor aún si debo hacerlo a un ambiente virtualizado. ¿Será realmente más complejo?

Leer entrada completa | Make a Comment ( Comentarios desactivados en Desempolvando Bases de Datos )

4 Tips para mejorar la calidad del Testing

Posted on 18 noviembre 2008. Filed under: Calidad del Software, Opinión, Testing |

En Testing no todo es Casos de Pruebas y cobertura en base a los mismos. Existe un sin número de factores que alteran notablemente los resultados y la calidad de las pruebas.

Aquí me atrevo a idear 4 TIPS para tener en mente a la hora de hacer nuestro plan de calidad y Testing:

  1. Reutilización de todos sus datos existentes.
    Es lógico y necesario guardar los datos de prueba en un lugar seguro y a su vez accesible para que se pueden utilizar y re usar por todos los Testers.
    Esto permite ahorrar mucho tiempo y encontrar más errores.
  2. Dejar de hacer copias de la producción.
    Hay quienes dicen que más del 90% de los datos en producción son similares, por lo que trabajar únicamente con ellos creyendo que así tendremos mejor cobertura, es un engaño.
    Es mejor utilizar un 10% de los datos de producción, manteniendo en foco que aquellos datos serán los verdaderamente significativos para las pruebas. El 90 % restante debemos generarlos nosotros para garantizar de esta manera la cobertura y la calidad de las pruebas, ya que así estaremos mucho más seguros de cumplir con más caminos del grafo de pruebas.
  3. Evitar que la mayor parte de nuestra generación de datos de pruebas sea manual.
    Es un trámite muy laborioso que se consume gran parte de nuestro tiempo asignado a pruebas del proyecto. También es muy propenso a errores.
  4. Mantener el foco en la calidad de los datos, asegurando que los mismos es una buena representación de la realidad y que la misma puede ser modificada para configurar varios escenarios posibles.
    Cuanto más alta es la calidad de los datos que utilizamos como juego principal para las pruebas, mayor cantidad de defectos se detectan y se evita que los mismos lleguen a producción.

Quien pueda aportar un poco más, bienvenido sea..

Leer entrada completa | Make a Comment ( 4 so far )

Está hecho y lo voy a comprobar

Posted on 18 noviembre 2008. Filed under: Comunicación, Metodologías de Desarrollo, Testing, Trabajo en Equipo |

No confundir los hitos de pruebas

La revisión par de componentes intenta validar la completitud y correctitud de los componentes generados, es decir marcar el hito de finalización de la construcción por componentes. De ninguna manera representa una integración de los mismos con otras unidades, esto lo sabemos por la experiencia del momento, por que cada uno supo el alcance y los límites de su caso de uso y aunque hubo cierta integración necesaria con otros componentes, los fallos imputados solo atañen al componente en revisión.

Todos defienden sus implementaciones.

Es por eso importante finalizar y avisar al par revisor tanto como al líder de desarrollo. Este aviso implica principalmente a los conceptos de, “está hecho” (el famoso “done”) y “lo voy a comprobar”. Pasado este hito, ya estamos asegurados para muchas cosas más como, cambios de funcionalidad, mejoras de funcionalidad, acoplamientos exitosos, seguir con otras cosas diferentes, etc. pero todo estará dentro de un “marco de generación de valor agregado”.

Continuar sin haber validado el componente implica un riesgo importante para la integración y normalmente debemos volver atrás con un cúmulo importante de retrabajo. También implica que la prueba deja de ser de componente y presentaría un sesgo hacia pruebas de sistemas, el decir con una versión del aplicativo el cual ya sin dudas tendría N cantidad de fallos indeseados.

Es bueno saber para que sirve cada cosa y no confundir los hitos, sabiendo que un momento se desea asegurar los componentes, en otro momento la integración modular y en otro el sistema.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Está hecho y lo voy a comprobar )

Fishbowl – Parte 1 (Desarrollo de Juegos)

Posted on 16 noviembre 2008. Filed under: Calidad del Software, Capacitación, Comunicación, Herramientas Colaborativas, Pruebas de Integración, Pruebas de Sistemas, Pruebas Unitarias, Testing |

Recientemente participé del primer Fish Bowl de la provincia de Córdoba, organizado por la gente de Pregunta al Experto, en la Universidad Nacional de Córdoba.

El evento aunque poco concurrido, fue de gran utilidad para mí, puesto que me permitió salir de mi esquema de trabajo unitario y de comunicación unidireccional y participar de un método de exposición y retorno inmediato.

Se trataron varios temas en los que yo me anoté para participar siguiendo la modalidad propuesta y aunque en algunas temáticas no haya tenido ni la menor idea, puede realizar preguntas que fueron bien respondidas y me permitieron tomar alguna postura, pero no necesariamente una conclusión .

La primer actividad fue al rededor de la temática “Desarrollo de Juegos”, donde quien hizo el planteo inicial nos introdujo en conceptos básicos de las plataformas existentes. Se mencionaron otras plataformas de desarrollo tales como Torque, Ogre, Genesis, Allegro, Fenix, Blitz y Jade, pero mencionó DXNA de Microsoft, como la de su preferencia para desarrollo en entorno Windows y consola XBOX.

El expositor del momento indicó “el por que” de su preferencia, mostrando un entendimiento y alineación con las estrategias de expansión del gigante del software en el rubro y explicando que los pilares fundamentales son la facilidad de creación, prueba y distribución  de desarrollo de juegos, hasta el punto de permitir a desarrolladores individuales, lograr ser considerados casos de éxito mundial.

Otros expositores indicaron que la plataforma JAVA para el desarrollo de juego de consolas, fue un verdadero fracaso quedando relegado a la expresión de juegos para celulares, lo cual pronto también evolucionarán como ya se puede percibir.

Nos explicaron también que el lenguaje fuerte para la generación de juegos de consola es y seguirá siendo por mucho tiempo más, el legendario C++ y en respuesta a si existen juegos desarrollados para la plataforma Silverlight, se explicó que no se conocen tales desarrollos, pero que no consideran que sea una limitación del todo importante y que solo habría que esperar que Silverlight tome una orientación más definida a la que tiene en la actualidad o incluya a este rubro.

Por mi parte, durante las exposiciones y el debate, había oído hablar de los términos, Xploit, bucles finitos, estructuras de datos y objetos, como también la frase “moderar el trabajo a bajo nivel y a alto nivel para manejar adecuadamente las funciones de control y evitar que este sea excesivo o poco en su defecto”. Entonces las preguntas obvias fueron:

¿como se establecen los niveles mínimos de calidad requeridos para los juegos y como se los alcanza?¿cómo se organiza el TEAM de desarrollo?¿cómo se testean los juegos?

Las respuestas fueron poco satisfactorias para ser honesto. En primer lugar indicaron que no existe cosa tal como “Testing Unitario” dentro de sus procesos de construcción. Luego explicaron que el software es testeado de manera regresiva al 100% y que no son admitidos los errores en los juegos, por lo tanto es necesario que los testers recurran a probar todo el paquete cada vez que se introduce un cambio o una mejora. Las pruebas a su vez son todas del tipo funcional de caja negra, es decir que se prueba jugando.

Sin lugar a dudas, no se conocen métricas de Testing, ni el costo de la calidad o si los programadores están abocados a las mejores prácticas efectivamente. Por lo tanto no es conocido el “costo de la no calidad”.

Lo satisfactorio fue saber que existen empresas que trabajan en emprendimientos muchos más grandes (juegos categoría Triple A) y que deben contar con procesos formales donde aspectos como el Testing Unitario, de Integración, Pruebas Automatizadas y Métricas, son una necesidad más que nada por la envergadura de los proyectos.

En muchos aspectos el Fish Bowl de esta temática fue interesante, pero lo que más rescato fue el juicio experto de quienes participaron exponiendo y respondieron las inquietudes en el entorno abierto.

Un saludo para ellos.

Leer entrada completa | Make a Comment ( 1 so far )

Como codificar Software que sea fácil de mantener?

Posted on 27 septiembre 2008. Filed under: Calidad del Software, Patrones de diseño, Programación | Etiquetas: , , , , , , |

Hay que diferenciar entre software fácil de mantener (mantenibilidad) y fácilidad en la codificación del software.
La facilidad para la codificación de software hoy en día son bien sostenidas por los nuevos IDEs y herramientas existentes y mucho más si se considera la relativa facilidad de obtención, aprendizaje e implementación de tales herramientas.
A su vez cada lenguaje tiene su particularidad y cada programador es particular en su forma de codificar y tal vez ese sea el motivo por el cual las organizaciones podrían necesitar establecer estándares de codificación y patrones de soluciones, proponiendo un método de trabajo homogéneo para toda la empresa. Esto sin lugar a dudas (de mi parte) ahorra muchos problemas y mejora la productividad.
Por cierto que tiene costos iniciales y me atrevo a decir que tienen más que ver con el cambio que implica en la metodología de trabajo que con el costo monetario.
Ahora bien, tener todas estas facilidades de ninguna manera garantiza que logremos genera software fácil de mantener ya que este aspecto de mantenibilidad, tiene que ver con la concepción misma del sistema.
Muchos dicen que es competencia exclusiva del Diseño y Arquitectura del software, pero yo me atrevo a decir que esto se trata mucho antes, cuando se plantean los alcances y se reconocen las limitaciones a nivel de herramientas tecnológicas, conocimientos del equipo del proyecto, cuestiones políticas, legales y hasta culturales.
La arquitectura y el diseño del sistema brindarán las propiedades de mantenibilidad necesarias y atributos como  testeabilidad, flexibilidad, escalabilidad, fiabilidad entre otros, pero siempre tendrán de limitantes los ítemes que antes mencioné.

Sin embargo, para no dejar colgado a aquellos que quieren alguna respuesta relacionada a la codificación y tanto a otros aspectos, comparto con ustedes este artículo de Martín Fowler “Código como documentación”

Leer entrada completa | Make a Comment ( Comentarios desactivados en Como codificar Software que sea fácil de mantener? )

La importancia de diagramar los Procesos de Negocios

Posted on 23 septiembre 2008. Filed under: Ingeniería del Software, Modelado de Negocio, Modelado de Sistemas, Pruebas de Integración, Pruebas de Sistemas, Testing, Trabajo en Equipo |

Contar con un lenguaje común para que las partes involucradas puedan comunicar los procesos de forma clara, completa y eficiente, resulta en extremo importante, y esto se nota particularmente cuando un equipo de pruebas necesita definir planes de Calidad y/o Pruebas . De esta forma es bueno y necesaria la existencia de definiciones en las notaciones y semántica de un Diagrama de Procesos de Negocio.

Existe un sin número de herramientas que nos ayudan en estas definiciones, pero en forma genérica, lo que necesitamos es previamente definir ese lenguaje común entre colaboradores de los proyectos.

image

La imagen arriba mostrada corresponde a un ejemplo de la aplicación BIZAGI donde se podrá apreciar una explicación del diagrama modelo. 

Personalmente lo utilizo para modelar los procesos importantes y críticos donde debo hacer foco para verificaciones de funcionalidad. Debajo muestro un ejemplo sencillo:

image 

Con este diagrama, que no fue realizado en etapas anteriores en mi equipo de trabajo del proyecto, espero que los analistas de pruebas entiendan el por que de las verificaciones y validaciones planteadas en el Plan de Pruebas del Proyecto.

Por lo que se, ya es también de gran ayuda a los desarrolladores.

Leer entrada completa | Make a Comment ( 1 so far )

Calidad como Cuarta Restricción en Gestión de Proyectos?

Posted on 17 septiembre 2008. Filed under: Calidad del Software, Project Management, Uncategorized | Etiquetas: , , , , , , , , |

La calidad tiene cinco (5) vistas conocidas:

  1. TRASCENDENTAL (calidad = excelencia innata)
  2. BASADA EN USUARIO (adecuación al propósito)
  3. BASADA EN FABRICANTE (conformidad con requisitos)
  4. BASADA EN PRODUCTO (económica)
  5. BASADA EN VALOR (precio asequible)

Es posible que dependiendo de cual sea el enfoque (vista) mandatorio respecto a la calidad para el proyecto en cuestión, será el alcance del mismo e impactará directamente en el alcance del proyecto en general y en toda la planificación.

Ejemplo:
La Gerencia general solo habilita 800 horas (tiempo) en función de los costos-beneficios (costo) para cumplir con un proyecto que naturalmente llevaría el doble de tiempo para lograr los objetivos máximos (alcance).
Según este ejemplo, existen un fuerte enfoque orientado a la conservación del coste (vista “basada en valor”), pero los alcances serían prácticamente imposibles de lograr en el tiempo habilitado. Esta imposibilidad surge por que se asume que el producto debe contar con una calidad mínima esperada, quizás considerando los enfoques inadecuados, es decir “trascendental”, “basada en usuario” o “basada en los requisitos”, pero no se observa que las restricciones de tiempo y coste impactan directamente en el alcance.
En conclusión, es posible que la calidad sea un atributo muy arraigado con la restricción ALCANCE y no se la deba considerar como una cuarta restricción, sino que se la debe tangibilizar dentro de uno de los elementos de la triangulación Alcance-Tiempo-Costos.

Ver The triple constraint of the Customer versus the PM’s

Leer entrada completa | Make a Comment ( Comentarios desactivados en Calidad como Cuarta Restricción en Gestión de Proyectos? )

The Chaos Report

Posted on 16 septiembre 2008. Filed under: Calidad del Software, Gestión de Proyectos de Software, Metodologías de Desarrollo, Project Management | Etiquetas: , , , , , , |

“Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único, con restricciones de plazo y de costo”


Sobre la base de los resultados de la dirección de proyectos en compañías de informática se realizo el estudio “The Chaos Report” (Standish Group) que observa de todos los proyectos estudiados, qué cantidad fueron finalizados exitosamente y cuántos no llegaron a cumplir con algunos o todos los objetivos. Y lo más interesante es que hace un análisis de los motivos que originaron esos “fracasos”, permitiéndonos poner foco en ellos al dirigir nuevos proyectos.

Según este estudio del total de proyectos evaluados:
El 16% son completados con el alcance esperado, en el tiempo planificado y dentro del presupuesto asignado.
El 53% de los proyectos son completados con menor alcance, y/o sobrecosto y/o fuera de término.
El 31% de los proyectos son cancelados antes de terminar.

Del total de proyectos que se completan:
El 70% de los proyectos terminan fuera de plazo.
El 54% de los proyectos sufren sobrecostos.
El 66% de los proyectos no son considerados exitosos.
El 30% de los proyectos son cancelados antes de terminar

Principales factores de éxito:
1 – Involucramiento del usuario 15.9 %
2 – Apoyo de la Gerencia 13.0 %
3 – Enunciado claro de los requerimientos 9.6 %
4 – Planeamiento adecuado 8.2 %
5 – Expectativas realistas 7.7 %
6 – Hitos intermedios 7.7 %
7 – RRHH competentes 7.2 %

Principales factores de fracaso:
1 – Requerimientos incompletos 13.1 %
2 – Falta de involucramiento del usuario 12.4 %
3 – Falta de recursos 10.6 %
4 – Expectativas no realistas 9.9 %
5 – Expectativas realistas 9.3 %
6 – Falta de apoyo de la Gerencia 8.7 %
7 – Requerimientos cambiantes 8.1 %

Leer entrada completa | Make a Comment ( 4 so far )

Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución

Posted on 16 septiembre 2008. Filed under: Calidad del Software, Ingeniería del Software, Procesos Ágile, Pruebas de Integración, Pruebas Unitarias, Resolución de problemas, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo |

Las verificaciones funcionales tuvieron una tónica un poco desagradable el día de hoy, ya que para la ejecución de las pruebas de sistemas requirieron mucho esfuerzo en el levantamiento de elementos que me permitan formar un concepto de cómo realizar el Testing y que resultados esperar.

La mayoría de las verificaciones no pudieron ser ejecutados por aspectos relacionados a elementos faltantes del despliegue, los cuales no son mencionados en ninguna de las evidencias de resolución. Sin embargo, al revisar la evidencia de cada una de las resoluciones encuentro que tales evidencias no tienen elementos que permitan formar con cierta normalidad los conceptos de Testing Funcional.

De esta manera solo se consigue dilatar los tiempos de Testing, se tienen más rechazos de soluciones (inclusive por desentendimiento), no cumplir con la entrega planificada y el re trabajo que implica en todas las áreas involucradas. Ni hablar si se aprueba un resolución y luego la rechazan en Despliegue al detectarla como fallida.

Creo que las evidencias tienen que tener el foco funcional que hace falta, principalmente por que en situaciones como la de hoy, se hace “testing forzado”, sin planificación, sin anticipación.
Las evidencias no deberían simplemente tener las sentencias SQL que se usan o los valores booleanos que adoptan las variables o los nombres de formularios ocultos, entre otros elementos de bajo nivel, que muchas veces es interpretable y sirve solo en el contexto adecuado, pero fuera de el no es de utilidad.

Tal como mencioné varias veces, estoy convencido que para ciertos artefactos, no es necesario intentar recurrir a prácticas de Pruebas Unitarias sin el framework adecuado, pero se pueden plantear juegos de pruebas de caja negra, en la cual es posible definir aspectos relacionado a las interfaces, totalizadores, los comandos de acción, etc.

Dicho de otra manera, las pruebas del desarrollador tal vez deberían declarar el juego mínimo de pruebas de funcionales (caja negra) que indiquen un estado previo, el proceso ejecutado y el estado posterior del juego de datos.

O en su defecto hay que darnos el tiempo para que luego de notificada la resolución, se asuma “un tiempo de estudio” para generar los conceptos de pruebas funcionales, pero así no se garantiza nada.

Por otro lado, el día de hoy se vio una debilidad en el traspaso al darnos cuenta que falta la especificación de la corrida de agentes y también el momento de la corrida, lo cual parece ser estratégico para que no se presenten los fallos que se presentaron en Testing.

En definitiva me doy cuenta de la debilidad que hay en los traspasos y posiblemente tenga que ver con la estrategia que se deba plantear antes de iniciar las resoluciones.

A mi me sigue costando enterarme con anticipación de que bloques serán entregados y según la experiencia que tengo en nuestra interacción cotidiana (Desarrollo – Testing / Testing – Desarrollo), aún las correcciones más sencillas nos cuesta un esfuerzo muy importante tanto a Desarrollo como a Testing y las verificaciones se demoran de manera no convenientemente, como es lógico.

Si estos elementos se siguen presentando con tanta dificultad, las estimaciones del esfuerzo de Testing van a quedar subestimadas por la necesidad de estudio de los Testers para cada uno de los artefactos de software, siempre que se efectúen pruebas exploratorias.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución )

Realmente necesario y suficiente – Backlog, Sprint, Metricas, Gráficas

Posted on 15 septiembre 2008. Filed under: Calidad del Software, Trabajo en Equipo | Etiquetas: , , , , |

En mi intento de mejorar mis gestiones personales y organizacionales, suelo perder el foco los elementos que son realmente necesarios y suficientes. Muchas veces esos ítemes de perfeccionamiento no encuentran eco dentro de las organizaciones mismas aunque bien las aprovechan, es por eso que me atrevo a proponerles que vean y usen este Template Excel, al cual yo particularmente modifiqué para mi gestión de Sprint para Testing.
Hice lo que pude en este entorno WEB y dejo para el resto que desee participar, todas las mejoras que sean posibles. Por favor no pierdan el foco en lo “realmente necesario y suficiente”.
Por favor, compartan las nuevas versiones que puedan surgir y aquello nuevo y ocurrente que pueda nacer.


Leer entrada completa | Make a Comment ( Comentarios desactivados en Realmente necesario y suficiente – Backlog, Sprint, Metricas, Gráficas )

La importancia de las Certificaciones y evaluaciones de los SSI

Posted on 31 agosto 2008. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile | Etiquetas: , , , , |

Desde siempre los profesionales que prestamos servicios informáticos nos vimos en la necesidad de constante evolución y así cada vez más, se presentan situaciones en las que un estudiante universitario o terciario o idóneo, logra una certificación que lo acerca a una mejor posición a la hora de prestar sus servicios, mucho antes de finalizar su educación formalista.
En vista del auge que tienen las empresas dedicadas al SSI (Software y Servicios Informáticos) no es sorpresa que se coticen mejor aquellos RRHH que suman certificaciones y otras capacitaciones año a año. Tampoco es sorpresa que las empresas necesiten certificar sus procesos y/o productos y de esa manera acceder a mejores oportunidades de negocio en el mundo globalizado.
Muchas empresas accedieron a importantes logros a nivel de evaluaciones CMMI o certificaciones ISO, entre otras calificaciones y debo decir que ya es notable la escalada de proyectos internacionales que recaudan sus agendas de trabajo y la cartera de cliente se globaliza aún más.
El movimiento agilísta no a presentado ninguna restricción al respecto de que certificaciones y/o evaluaciones son requeridas para dar un formato cerrado de empresa SSI de calidad y garantías de satisfacción. Estos procesos y metodologóas propuestos por los movimientos Ágiles parecerieran ser solamente aditivos para mejorar en ciertos aspectos la productividad, sin representar necesariamente calidad certificada.
Entonces ¿Por que los clientes deben confiar sus requisitos a empresas que no tienen interés en certificar una norma de calidad de productos finales como ISO o ser evaluados en CMMI para sus procesos de construcción y prestación de servicios informáticos?

Leer entrada completa | Make a Comment ( Comentarios desactivados en La importancia de las Certificaciones y evaluaciones de los SSI )

De ArgTIgentina al mundo

Posted on 25 agosto 2008. Filed under: Argentina tecnológica, Calidad del Software, IT, Mercado Tecnológico, Plan de Acción | Etiquetas: , , , , , |

Se modifica la realidad del Software y la prestación de Servicios Informáticos en Argentina a partir de la generación de políticas para iniciar, acompañar y fortalecer el crecimiento de las actividades relacionadas con la proveeduría de software y servicios informáticos.
Se realizan estudios y análisis de modelos a considerar por su éxito en Irlanda, India e Israel y se trata de definir el modelo propio a ser utilizado en Argentina por considerarse el nuevo Polo Informático de “países no centrales”.

El objetivo marcado en lo que se conoce como “Plan de Acción 2004-2014” es llevar a Argentina a liderar los mercados de Tecnología de la Información, dentro de los países conocidos como “países no centrales”.
Este plan estratégico apunta a detectar e implementar las medidas correctas y necesarias para accionar a favor del objetivo, con el apoyo y consenso de políticas de estado para lograr continuidad.

Si bien las expectativas generales apuntan a tener una posición clara y dominante en el mercado tecnológico en 2014, se considera de gran importancia entender el marco conceptual para los próximos cuatro años considerando a 2008 como el primer año de marcado crecimiento y cambios significativos. Tal es así que se adosa al Plan de Acción 2004-2014, el Plan de Acción 2008-2011.

Indicadores utilizados para evaluar objetivamente las posibilidades de crecimiento real

  1. Crecimiento sostenido de las TICs a nivel mundial, zonal y regional
    • 20% anual según indicadores nacionales
    • Mayor generación de empleo de calidad
    • Generación de competitividad sistémica
  2. Amplitud de créditos para sostener el crecimiento continuo
    • Pendiente de políticas claras y eficaces
    • Muy pocas experiencias de éxito manifiesto
    • Oferta muy reducida
  3. Demanda creciente RRHH calificados en todo el mundo
  4. Políticas de capacitación para sostener la demanda creciente de RRHH
    • Los puntos 2 y 3 orientados a regular los salarios, evitar fugas de conocimiento por absorción de recursos desde otros países en crecimiento de TICs y garantizar calidad en las prestaciones
    • Existe solo un 4% de alumnado inscripto en carreras universitarias afines al sector
    • Población económicamente activa de menos de 0,3% es un factor de retraso muy importante para este plan de crecimiento
    • El sistema educativo actual no sabe como articular acciones para dar soluciones a las demandas de capacitación especializada
  5. Recuperación de capacidad de ejecución del Mercado Corporativo proveedor de TICs (grandes empresas)
  6. Crecimiento sostenido y “aceleramiento pronosticable de las PyMEs proveedoras de TICs”
  7. Reversión de pautas culturales inconexas en el sector público para lograr una normal inserción en el sector TIC
    • “Presiones” importantes en el sector público para lograr la aceptación y masificación de las tecnologías para facilitar y mejorar gestiones de los ciudadanos.
    • Participación de nuevos perfiles de gestión en las gobernaciones nacionales, provinciales y municipales
  8. Tercerización de servicios TICs a empresas de capitales privados para brindar soluciones al sector público
  9. Ceración de nuevos polos tecnológicos y clusters informáticos regionales fortaleciendo los ya existentes y generando valor agregado a la competitividad, nuevos empleos y riqueza distribuida en todo el país.

Proyecciones para el periodo 2008-2011 en cinco sectores

Se hace foco para el análisis:

  1. Corporativo (grandes empresas)
  2. PyMEs
  3. Exportaciones
  4. Gobierno
  5. Masivo

Todos los sectores crecerán de manera diferente y esto provocará una redistribución de la participación de cada uno de ellos.
Se estiman los siguientes valores a considerar a futuro dentro del periodo mencionado:

2006 2011 Crecimiento Anual
Ventas (Millones $) 4850 9340 93% 19%
Exportaciones (Millones $) 900 1970 119% 24%
Empleo 40000 70400 76% 15%

Fortalezas

  • Infraestructura física
  • Nivel educativo de la población
  • Costos competitivos
  • Actitud abierta a negocios en todo el mundo
  • Entidades empresariales sólidas
  • Políticas públicas específicas
  • Interés en la “Clusterización”
  • Asociativismo empresario en crecimiento
  • Fuerte participación en el negocios de Internet de habla hispana
  • Importante crecimiento de empresas certificadas en calidad

Oportunidades

  • Mercado global TI creciente y con proyecciones positivas
  • Visión de Argentina como un proveedor calificado
  • Mayor competitividad y crecimiento en segmentos específicos de la economía
  • Mayor receptividad por miembros del sector político y económico en desarrollar la industria
  • Debilidades de algunos proveedores:
    • Países centrales: Costos elevados y falta de talento
    • India: problemas de estructura física, costos crecientes y diferencias culturales muy marcadas
    • China: diferencias culturales fuertemente marcadas
    • Brasil: falta de actitud exportadora/idioma
    • México: fuerte presencia americana, fuerte tendencias a idiosincrasias “yankies”/ falta de RRHH
    • España: socio natural de Argentina y en crecimiento

Debilidades

  • Pocas empresas en el sector SSI a nivel regional y/o global
  • La marca país no nos identifica aún
  • Poca masa crítica en el consumo interno de SSI
  • Escasa vinculación con las cadenas productivas
  • Bajo nivel de uso I+D+T en los productos
  • Poca articulación con el sistema científico
  • Mínima articulación del sector SSI con el gobierno para aprovechar su poder de compra
  • Ausencia de capitales de mercados aplicables
  • Sistema financiero poco proclives a estos emprendimientos
  • Limitaciones de crecimiento ligadas a las tasas de capacitación RRHH

Amenazas

  • Posibilidad de absorción de RRHH por parte de capitales extranjeros
  • Menor tasa de crecimiento de RRHH en relación a las demandas de la industria
  • Desaliento al empuje exportador
  • Readecuación de las estructuras empresarias a los nuevos escenarios de crecimiento

En lo personal me resulta notable como la realidad actual contrasta contra los planes estratégicos de crecimiento, al menos en los aspectos educativos o de capacitación, ya que hoy por hoy cualquier persona puede acceder a capacitaciones privadas que presentan las mejores ofertas para dar valor agregado de calidad en la prestación de servicios de los RRHH, sea que los mismos estén recibidos o no, sean de niveles terciarios, secundarios técnicos o universitarios.
Esta es una solución inmediata y a mano, y en algunas empresas es el principal recurso estratégico para hacerse de mano de obra calificada en corto plazo y con un gran retorno de la inversión. Ete aqui que las empresas que pueden llevar a cabo tales calificaciones de su personal son justamente las corporaciones SSI que inclusive cuentan con departamentos própios de capacitación y autogeneran el “plus”.
PyMEs y microempresas no pueden acceder en forma fluida a tales capacitaciones sin que implique una inversión sensible y un riesgo importante si no se logra que tales capacitaciones sean aplicadas a soluciones inmediatas, necesarias para la organización.
Los educadores privados tienen costos muy altos y es entendible que así sea, pero de este modo se frena fuertemente el crecimiento propuesto.
Queda ver que proponen las entidades gubernamentales para solucionar estas falencias.

Mas información puede ser consultada en el sitio http://www.cessi.org.ar/index.htm
Vea

Ver más sobre ArgenTIna

Leer entrada completa | Make a Comment ( Comentarios desactivados en De ArgTIgentina al mundo )

Olfato e intuición amplificada

Posted on 5 agosto 2008. Filed under: Calidad del Software, Procesos Ágile, Testing, Trabajo en Equipo | Etiquetas: , , , |

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para este tipo de verificaciones y validaciones son necesarios ciertos elementos del lado del QA y Testing:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Este es un formato simple de ideación de prueba exploratoria y aquí les muestro un breve ejemplo:

“Se hizo el planteo de ir cambiando fechas del servidor para que las Presentaciones venzan con la regularidad que precisamos y los avisos visuales se evidencien en cada vencimiento, según la parametrización establecida para cada Etapa del Circuito de Aprobación. Con esto tendremos la cobertura necesaria para verificar las funcionalidades relacionadas con el establecimiento de fechas luego de haberse aceptado una Presentación para que ingrese al Circuito de Aprobaciones.
Será necesario realizar verificaciones también un paso adelante, es decir desde el Circuito de Aprobaciones, para lo cual preparamos el siguiente juego de datos sencillos:
Se prepararon a nivel de juego de datos para Testing, 16 presentaciones vencidas donde existe al menos una presentación vencida para cada Etapa.
Se definen seis (6) usuario donde cinco (5) tienen el rol de Aprobador de Circuito, más su rol principal y un (1) usuario tiene el rol de Administrador.
Se define una cuenta de Test para cada aprobador y se la configura con alias en ThunderBird.
Cada vez que se cierra una etapa se notifica vía mailing tanto al Administrador como al Aprobador de cada etapa del circuito.
Cuando una Presentación se encuentre vencida en la Etapa Actual, según los parámetros definidos para la etapa, se notificará vía mailing al Administrador y al Aprobador”

Hay que considerar que para el éxito de esta verificación se utilizarán las definiciones que se hacen a nivel de requerimiento (por eso es importante la completitud y correctitud del Req.) para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas según criterio de SQA, para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente los requerimientos definidos son los Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar en la fase de construcción e integración, más no pretender que las pruebas funcionales indiquen que el sistema funciona correctamente, sino entender que el concepto es la detección de fallos y errores.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Olfato e intuición amplificada )

¿Cual es la importancia de contar con un proceso bien definido?

Posted on 28 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo | Etiquetas: , , , |

En la actualidad existen  cientos de Software Factory que no tienen prácticas definidas en casi ninguna área de procesos y aún sin definir puntos de control formalistas como lo demandan los procesos más conocidos (existen muchos y variados), realizan actividades que son las que en escencia la definen como una Software Factory.

Conocen de requerimientos, análisis y diseño, implementación y testing, tienen definidos sus objetivos para cada proyecto y trabajan contra un “end line”, con un presupuesto limitado, con recursos asignados y todo esto se gestiona de alguna manera, aunque no está claro como. El no tener claro “el como” o ser variable de un proyecto a otro, puede considerarse como un proceso indefinido.

Estoy de acuerdo que cualquier empresa que trabaja con algún tipo de organización funcional, tiene un proceso que le permite llegar desde un principio hasta un fin. Esta organización funcional no define necesariamente a un proceso.

Sin embargo no podemos excluir a estas empresas del rubro software factory por el de no tener prácticas moderadas. Inclusive las podemos criticar y comparar pero no podemos ponderar en forma generalizada el grado de éxito o fracaso que estas entidades tienen.
Puedo afirmar que existen organizaciones pequeñas que no conocen los verdaderos preceptos de calidad (la gran mayoría) y ni siquiera están interezados en los procedimientos formales de verificación, ni en documentación ni en el testing tradicional, ni en métricas y para cada proyecto varía el método de trabajo, el modo de comprobación y sus certificación internas y externas.

Y aún sin definiciones formales logran entregar sus productos en muy buenos términos, pero con aspectos pocos deseados como son:

  • resultados poco predecibles
  • resultados poco repetitivos
  • alto desgaste de los recursos
  • métricas endebles o inexistentes
  • calidad dudosa o no garantizada

Nuevamente me pregunto: ¿cual es la importancia de contar con un proceso bien definido?

Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿Cual es la importancia de contar con un proceso bien definido? )

Aplicaciones completamente personalizables

Posted on 23 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Soporte Colaborativo, Soporte de Aplicaciones | Etiquetas: , , , , , , , , |

Las aplicaciones WEB están marcando la tendencia inexorable de las UI (User Interface) que pronto deberán ser aplicadas en nuestras aplicaciones de escritorio.

La riqueza de funcionalidades que actualmente se ofrece en la WEB abarca factores de total personalización desde la primera interacción del usuario con su aplicación. El LOGIN puede hacerse ni bien se abre el SITE pero es posible previamente seleccionar el idioma de preferencia, el esquema de colores y hasta alternativas de gestión basadas en perfiles que el usuario definió en ingresos previos.

Por ejemplo un SITE puede validar solamente el “nombre de usuario” sin que el mismo haya ingresado aún su “clave privada” y en una especie de juego tienta al usuario identificado a seleccionar algunas opciones de accesibilidad y usabilidad, las cuales solo estarán disponibles si se valida la “clave privada” y en algunos casos un tercer nivel de seguridad como puede ser un “código de validación” que recibe en su cuenta de correo diariamente.

De esta manera los propietarios de SITE pueden hacer gala de estas potencias mostrando valores agregados de diseño, arquitectura y funcionalidades, mucho antes de brindarles el servicio real para el cual el sistema fue creado. Con estos “Mock-Ups” se logra un alto factor de fidelización y atracción para potenciales nuevos usuarios y clientes.

Una vez “adentro” continúan las opciones de personalización hasta niveles antes desconocidos:

  • El usuario puede, mediante “Drag & Drop” cambiar el orden de visualización del contenido usando la potencia de lo que se conoce como “Portlets”, mientras que puede determinar que contenidos estarán bloqueados para que no se pueda reemplazar su posición o la visualización de su información interna.
    Bajo el mismo esquema de personalización mientras el usuario mueve su contenido con “Drag & Drop” el SITE propone generar nuevas columnas o nuevas filas o ambas cosas, según disposiciones posibles de orden.
    Esto es posible mientras tiene garantizado que siempre su contenido estará activo y actualizado.
  • El usuario puede ejecutar en pasos muy sencillos “uploads inline” realizando selecciones múltiples de archivos y en el mismo proceso de carga, pausar una o varias cargas planificadas, cancelar una o varias cargas planificadas, visualizar el avance individual de cada carga y a su vez visualizar el avance general de la carga, pausar todo el lote de carga y en esa pausa quitar archivos que aún no fueron cargados y definir otros archivos de su interés y finalmente reiniciar el proceso de Upload.
  • En lo que respecta a catálogo de imágenes es posible realizar operaciones de “Drag & Drop” con el teclado mismo utilizando teclas que el mismo usuario configura para la navegación.
    El teclado pasa a ser una herramienta de uso contemporáneo en las aplicaciones WEB tanto como el mouse.
  • Los “ToolTips” están a la orden del día y es posible que el mismo usuario los genere del mismo modo que en Excel se genera un comentario en una celda.
    Hay que sumarle que los ToolTips son personalizables en color, fuente, el mismo contenido, retardo antes de mostrarse y si además de mostrar la información ingresada por el usuario también mostrará información técnicas del objeto del catálogo.
  • Los “chekboxes” no se limitan a solo permitir la selección sino que ya muestran una variedad de estilos que el mismo usuario puede definir y se combina con la nueva potencia del texto que se puede modificar “inline”. Nuevamente el teclado es fundamental para interactuar con estos elementos.
  • Los “Tabs” aumentan potencia al permitir interacción con el teclado y utilizar las teclas que el usuario mismo define, estableciendo el orden saltos, las teclas de navegación, reordenamiento y un poco más al definir los estilos de foco.
  • Las listas verticales ahora son totalmente ordenables y permiten que el usuario mueva grupos enteros de una lista desde un lugar a otro o bien redefina la posición de un único elemento de la lista, cambiándolo a un nuevo grupo.
    También se pueden mover varios grupos a una nueva posición de orden y la aplicación enumera automáticamente las posiciones según un orden establecido inicialmente o configurable también.
  • Los formularios editables muestran toda las funcionalidades ricas de aplicaciones como Word

image

La lista se extiende mucho más de lo que aquí pretendo mostrar y sin duda los diseñadores de aplicaciones WEB utilizan las potencias de las nuevas herramientas que ahora utilizan los estándares más populares y gestores de contenidos para separar justamente el contenido del impacto visual y lograr administraciones mucho más potentes de las aplicaciones.

Es posible que todos esto haya sido ideado inicialmente habiéndose detectado la necesidad de fidelización de usuario y captación de nuevos, pero el desarrollo y evolución es tan acelerado y significativo que este cambio generacional del WEB, ya impacta directamente en el modo de generar la aplicaciones de escritorio.
El contagio no se hace esperar y podremos en muy corta data, observar como los lugares donde trabajamos utilizarán la sinergia de las aplicaciones WEB y las aplicaciones de escritorios, siendo irreconocible la división, si es que la hubiera, en lo que respecta a la implementación y mantenimiento de los “acuerdos de servicios”, obteniendo mayor y mejor soporte para disponer de nuestros datos desde múltiples lugares (remotos o locales), compartirlos con seguridad en un “entorno plenamente colaborativo” y orientado a la generación de información sustancial.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Aplicaciones completamente personalizables )

A mejor Testing, peor calidad de Software?

Posted on 22 julio 2008. Filed under: Calidad del Software, Uncategorized | Etiquetas: , , |

Luego de altas persistencias de fallos, defectos y errores en los sucesivos ciclos de Testing para distintos proyectos y alguna cantidad de detecciones en los clientes, los reclamos con tonos elevados no se hicieron esperar. Hubo así entre dicho entre los Responsables de Despliegues, ataques entre Testers y Desarrolladores, Administradores de Pruebas y Responsables de Desarrollo y finalmente La Gerencia. Luego de planteos fuera de lugar y experiencias que nos pusieron en límites de tolerancias entre las personas, quise analizar por que estamos fracasando tan enfáticamente en lo que a calidad de los productos de software se refiere.

Tengo mis anotaciones frescas en mi cuaderno de proyectos y en mi mente mucho más, sin embargo, luego de leer un poco de blogs que frecuento, encontré una referencia a un artículo muy interesante. El título expresa simplemente lo siguiente: “¿A mejor Testing, peor calidad de Software?”. Automáticamente me llamó la atención esta suerte de contradicción y abrí el PDF directamente desde la WEB.

En cuanto inicié la lectura pude ver un diagrama que me refrescó los conceptos que vengo gestando desde mis análisis de problemas.

Sucede que las metodologías, cualquiera sea, tienen ciertos elementos que si no sabemos tratar con cuidado, convierten todo un proceso en burdo y empantanado.

Observé otra pregunta reveladora:

“¿Cómo sabe que su Software no está en un Espiral Muerto?”

A este respecto en el artículo se dan ciertas sugerencias como:

  • Cuenta la cantidad de fallos, errores y defectos
  • Escucha a los Testers
  • Observa los tiempos de Integración
  • Escucha a los desarrolladores
  • Presta atención a la demanda de recursos
  • Recuerda y ten en cuenta ciertos puntos de control
    • Usa una base de conocimiento de los fallos, errores y defectos entregados a producción
    • Aplica técnicas de prevención de fallos
    • Conoce el esfuerzo de implementación
    • Conoce el esfuerzo del Testing
  • Evalúa fallos conocidos
    • Los desarrolles pueden continuar con la tasa de fallos encontrados en su haber?
    • Los Testers están encontrando los fallos más importantes?
    • La Gerencia está tomando buenas decisiones al respecto de los fallos que son encontrados?
    • Los fallos son utilizados para mejorar el proceso de desarrollo en general?
  • Evalúa los Requerimientos
    • Asegúrate de que todo el mundo entiende que estamos construyendo, por que y para que
    • Convierte los requerimientos implícitos en explícitos
    • Permite y promueve que los interesados vean el software periódicamente durante la fase de desarrollo
    • Escucha cuidadosamente y cuestiona las presunciones
  • Los defectos ponen a prueba las aplicaciones
    • Define código estándar
    • Define buenas prácticas de codificación
    • Mantenga las revisiones para ver que las codificaciones siguen los estándares
    • Toma ventaja de las revisiones de código como una oportunidad para compartir sugerencias y técnicas para las pruebas de error en el entorno de desarrollo
  • No permita que un problema se transforme en el problema de alguien más
      • Mantén una cultura donde la idea viva sea la de la RESPONSABILIDAD
      • No dejes de hacer hoy lo que podrías delegar en otra persona del equipo
      • Si un problema tuyo no se convierte en un problema de alguien más, entonces no es un problema
      • Ten en cuenta que el Software es quien sufrirá los resultados
  • Detecta los fallos en forma temprana
    • Como están definidas las Pruebas de Unidad?
    • Quien es el responsable de las Pruebas de Unidad?
    • Se puede testear algunas partes del sistema en forma aislada?
    • El esfuerzo de las Pruebas Unitarias está mejorando?
    • Cuales herramientas está utilizando para ayudar al proceso de Pruebas Unitarias?
    • El sistema es construido e integrado diariamente?
  • Planifica el tiempo para el Desarrollo, Testing y Correcciones de Defectos
    • Incluye en la planificación de los desarrolladores el tiempo suficiente para realizar algunos tipos de pruebas durante la construcción de primera mano
    • Considera en la planificación de los desarrolladores el tiempo suficiente y necesario para la corrección de los defectos detectados durante sus propias pruebas
    • Presta atención a las alarmas de los desarrolladores al respecto de las presiones de tiempo que hacen que se salten etapas
  • Invierte en mayor medida en la prevención de los defectos
    • No planifiques obtener mejora de calidad solo promoviendo la mejora del esfuerzo del “Testing Independiente” (grupo separado de los Desarrolladores)
  • Luego el artículo muestra la conversación entre dos personajes que podrían ser dos actores típicos de una Software Factory, un Responsable de Pruebas y Calidad y una Gerente de Área.
    La conversación muestra con gran simpleza la evolución de la gráfica y va entrelazando los conceptos que indefectiblemente llevan a La Calidad o a la No Calidad del software.

    Queda claro el concepto de que la Calidad Percibida es inversamente proporcional a la cantidad de defectos que se dejan pasar a los entornos operativos del cliente. Es decir que a más defectos del lado del cliente, menos calidad percibida y viceversa.
    De la misma manera a mayor cantidad de defectos detectados en las pruebas de sistemas, el número de defectos posibles a ser pasados al entorno operativo del cliente es menor.
    Esto quiere decir que hay etapas que deben ser respetadas a raja tabla aún a disconformidad de alguna de las partes, como una Líder de Proyecto, Responsable de Despliegue, Comercial o inclusive La Gerencia. Una de esas etapas son las Pruebas de Sistemas. Este es el entorno operativo dentro de la organización, más cercano al entorno operativo del cliente y los resultados generados en este ambiente, se deben tomar indefectiblemente como referente directo de los resultados que se replicarán en los ambientes productivos y su consiguiente Calidad Percibida.

    Aún cuando se incremente el Esfuerzo Independiente que suponen las pruebas de sistemas, hay otras etapas previas conocidas como el “Esfuerzo del Testing del Desarrollo”, que no deben ser omitidas, pues aún estando más lejos del entorno operativo de producción, son la garantía inicial de que el producto construido cumplirá con los requisitos. Directamente estas garantías iniciales impactan en los costos de la organización.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en A mejor Testing, peor calidad de Software? )

    10 Mejores Prácticas para la Generación de Software

    Posted on 18 julio 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Trabajo en Equipo | Etiquetas: , , , , |

    La rapidez con que se construye un edificio es sorprendente, pero detrás de esa aparente facilidad están los siglos de experiencia de la industria de la construcción, y si quisiéremos aplicar los mismos parámetros a los proyectos de software, la desproporción será abismal. A casi tres décadas el desarrollo de software sigue buscando la manera adecuada de desarrollarse para hacerlo más rápido y sin errores.
    Anteriormente las pruebas de software se consideraban sólo una actividad que realizaba el programador para encontrar fallas en sus productos; con el paso de los años se ha determinado la importancia que tienen para garantizar el tiempo, el costo y la calidad del producto, de tal forma que actualmente son un proceso cuyo propósito principal es evaluar en todo momento la generación del software respecto de los requerimientos establecidos al inicio.

    La nueva tendencia consiste en iniciar las pruebas en etapas tempranas dentro del proyecto, y capacitar a especialistas responsables de esta actividad. El primer punto quiere decir que actualmente es una práctica casi generalizada que las especificaciones de pruebas se realicen al mismo tiempo que el diseño de software; la propuesta es iniciar el análisis del testware junto con el análisis del software. Esto habla de pruebas preventivas que ofrecen ventajas como las siguientes:

    a) Se identifica qué se quiere y cuáles son los resultados esperados (criterios de aceptación)
    b) Ejecutar las pruebas tan pronto como el software está listo.
    c) No sólo descubrir errores, sino evitarlos.

    El segundo punto habla de crear conciencia sobre la importancia de las pruebas y tener un equipo de personas dedicadas a esta actividad que puedan integrarse a un proyecto y sean responsables de su calidad. Hoy se tiene ya definida la carrera de ingeniero de pruebas y existen organismos especializados para certificar en esta disciplina.

    Entonces se puede decir que los objetivos actuales de las pruebas no sólo tienen que ver con corregir errores, sino con prevenirlos influyendo y controlando el diseño y desarrollo del software. Las pruebas deben ser empleadas como modelos de los requerimientos de software que se ha de construir; por tanto, en las especificaciones de software deben incluirse especificaciones de pruebas; ambas deberán revisarse en conjunto, y en esta revisión deberá participar un especialista en pruebas.

    La disciplina de pruebas ha evolucionado en una práctica de especialización que puede ser ofrecida como un servicio hacia clientes internos y externos, garantizado que tanto la metodología como las herramientas automatizadas son aprovechadas eficientemente para alinear el desarrollo a las expectativas del cliente.

    Se debe reconocer que las pruebas son una especie de administradores de riesgos; al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor resultado; con esto quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.

    A continuación se sugieren 10 mejores prácticas para la generación de software:

    1. Hacer una evaluación del trabajo de cada integrante del equipo. Concienciar al equipo de la importancia que tienen las pruebas y el valor que tienen para cada miembro del equipo y así generar cooperación y coordinación entre los miembros del mismo.
    2. Establecer un plan maestro integrado. Establecer claramente las funciones y responsabilidades de los equipos de desarrollo y pruebas
    3. Considerar las pruebas preventivas como parte de las especificaciones de trabajo. Diseñar previamente los escenarios de prueba, dentro del desarrollo de software, y realizar revisiones para asegurarse de que lo que se está construyendo cumple con los requerimientos solicitados.
    4. Usar las pruebas como puntos de control y progreso. Realizar pruebas y revisiones formales para verificar y demostrar que todos los productos claves del proyecto han sido realmente terminados.
    5. Inventario de los objetivos de pruebas y diseño para factibilidad. Revisar la factibilidad en la realización de las pruebas.
    6. Probar pronto y frecuentemente. Hay que probar lo antes y más frecuentemente posible; esto permitirá detectar los problemas tan pronto surjan, de esta manera el desarrollador será más eficiente en las correcciones.
    7. Diseñar y desarrollar el testware como el software. Esto implica planear, analizar, diseñar, supervisar, controlar los cambios, administración; en suma, desarrollar el testware con la misma disciplina con que se desarrolla el software.
    8. Proporcionar una herramienta integrada de pruebas, evaluación y de soporte de infraestructura. Proporcionar herramientas que incluyan: Base de datos o repositorio, Administración de pruebas, que permita documentar, ejecutar y clasificar pruebas, Soporte automático, Simuladores, Analizadores de software, Manejadores de pruebas, Herramientas de captura y repetición (playback) y utilerías.
    9. Medir el costo, el alcance, los resultados y la efectividad de las pruebas y evaluación. Coleccionar información que permita conocer el costo, los resultados y los beneficios así como el alcance.
    10. Entrenar y administrar al equipo. Proporcionar el liderazgo y administración al equipo con el fin de que sepa lo que se espera de él para que se tomen las pruebas seriamente. Definir los criterios de “mejores prácticas”.

    La razón principal para implementar esta práctica, es que finalmente todo el tiempo perdido, se convierte en costos que afecta los resultados de un proyecto, pues generalmente se usa más del tiempo planeado para las pruebas. Para los administradores de proyectos, la correcta administración es la que lleva a obtener buenos resultados.

    Publicado por por Elsa Ramírez, Directora de Tecnología y Calidad para Praxis el 6 de marzo de 2008 en http://www.sg.com.mx

    Leer entrada completa | Make a Comment ( Comentarios desactivados en 10 Mejores Prácticas para la Generación de Software )

    ¿”Pay per Defect” o elevar la conciencia creativa del acto verificador?

    Posted on 16 julio 2008. Filed under: Testing, Uncategorized | Etiquetas: , , |

    Un amigo posteó:

    ¿Como creéis que se debe incentivar a los equipos de calidad? ¿Es posible incentivar por defecto encontrado o es contraproducente?

    Imaginemos una compañía que decide incentivar por objetivos, e incentiva el equipo de desarrollo por funcionalidad implementada en el menor tiempo. ¿Como incentivamos al Tester? o dicho de otra manera como sabemos quién realiza mejor labor de verificación?

    Una respuesta de otro amigo:

    Pues yo creo que incentivar la localización de errores está bien.
    Eso sí, debe haber un “juez” que decida si cada caso es digno de contabilizar o no, es decir, que tome la decisión en los casos dudosos (“es que no estaba en los requisitos escritos” … “sí, pero es algo ‘obvio'” … y cosas de ese estilo). Ah! Y añado otra cosa : igual que se incentiva la localización de errores en el testeo creo que se debería “desincentivar” cuando un Cliente localiza el error una vez lanzada la versión.
    Luego se hacen las cuentas de la vieja y se saca balance.
    Ya verías la de errores que se encuentran !!! jejeje

    El aporte de uno más:

    ¿Qué tal un esquema intermedio?

    1) Incentivar a los desarrolladores con relación inversa al número de defectos que “les” encuentren los Testers.
    2) Incentivar a los Testers con relación al número de objetos/unidades/loquesea que pasen a producción validados
    3) E incentivarlos a todos con la “velocidad” del proceso completo, y con relación inversa a los defectos encontrados en producción.

    La “fórmula” no sería sencilla, pero puede que se lograse un resultado adecuado. ¡O que se lograse confundirles a todos!

    ¡¡¡¡me encanta este aporte!!!!

    Pero mi opinión fue la siguiente:

    Me resulta un poco extraña la cuestión de tener que incentivar a un Tester o grupos de Testers por tener que hacer su trabajo bien. Igual para los desarrolladores o cualquier otra persona que cumpla un rol específico dentro de la cadena productiva de software.
    En primer lugar considero que un plan de verificaciones y/o validaciones no puede quedar librado a la buena de un Tester, sino que debe guiar a cada uno de los involucrados en el proceso hacia los resultados esperados, también sus controles y gestiones.

    Si se considera la existencia de Testers en un equipo de producción de software, no debe ser sin la existencia de un responsable QA y la carga de gestión recae sobre los hombros de tal o tales personas. Lo que se puede hacer es “elevar la conciencia creativa del acto verificador” agregando capacitaciones especializadas en herramientas, conceptos avanzados, UML, patrones de calidad y demás elementos que existen para sumir al equipo de calidad en un estándar que desde el llano y como punto de partida sea muy alto.
    Podría agregar que es bueno tener métricas de cantidades de defectos detectados por Tester pero no podríamos dejar de mirar que tipo de defectos detecta cada uno de ellos y como es el impacto de cada uno de esos defectos detectados en los proyectos. Esto serviría para que en caso de necesitar dividir el equipo de Testing, al “mejor Tester” se le asignaría una especie de “jefatura” sobre otros que no tienen el mismo rendimiento.

    Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos RRHH, es bueno aplicar criterios de competencias operativas. Pero en otros casos no. Equipos enteros podrían desintegrarse por generarse ciertas incomodidades. No quiero ni hablar de como impactaría sobre nuestros productos.

    Entonces, pagar por defectos detectados vale para equipos de venta. Ya todos los defectos del producto fueron eliminados o se presumen eliminados y el producto de alta calidad. Ahora a generar retorno de la inversión.

    Me gusta mucho la idea de incentivar, pero sin generar competencias sino ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su conciencia de responsabilidad.
    Los Testers suelen encontrar fallos de severidad Invalidante o Graves a penas inician el Testing. No es mérito del Tester sino de la incompetencia de alguien en fases anteriores. No señalo a nadie, pero desde el Tester para atrás, hay muchas responsabilidades intrínsecas.

    Es cierto también que al principio el Tester se haría de una muy buena suma de dinero extra por la cantidad de detección de fallos y conforme avanzan los ciclos, deberá devolver dinero y hasta poner de su bolsillo por que no encontrará fallos que se sabe por métricas, están allí.

    Cierta oportunidad siendo Líder de Testing al finalizar uno de los proyectos postulados para certificación CMMI-4, mi equipo detectó grandes cantidades de fallos en los productos solo en los primeros ciclos, cuando había planificados 12 ciclos de pruebas. Conforme se comenzaron a resolver los fallos, previo a los ciclos subsiguientes, nuestra tasa de detección cayó significativamente para el resto de los ciclos (considerar PARETO).
    Esto me llevo a analizar la situación, a modificar definitivamente el modo en que manejamos los ciclos. Finalizado el proyecto que menciono, invité a mi equipo a un almuerzo y por supuesto al equipo de Desarrollo. Allí pude explicar lo que habíamos conseguido trabajando en equipo y como unos sin otros no pueden evidenciar su actividad hecha con responsabilidad.
    Gracias a esto pudimos mejorar nuestro proceso en forma significativa.
    Creo en definitiva, que brindar las herramientas adecuadas, la capacitación necesaria y sostener un ambiente colaborativo y ameno, son los mejores incentivos.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿”Pay per Defect” o elevar la conciencia creativa del acto verificador? )

    Algo de Testing Automatizado

    Posted on 1 mayo 2008. Filed under: Calidad del Software, Metodologías de Desarrollo, Procesos Ágile, Pruebas Unitarias |

    Objetivos del Testing Automatizado

    • Tests deben mejorar la calidad
    • Tests deben ayudarnos a entender el sistema bajo pruebas
    • Tests deben reducir riesgos
    • Tests deben requerir mantenimiento mínimo al mismo nivel que el sistema involucrado
    • Tests deben ser ejecutados como parte del proceso de construcción
    • Tests deben ser fácil de ejecutar

    Tipos básicos de Testing donde se puede automatizar

    • Testing Unitario a nivel del código
    • Testing de aceptación de productos/servicios (pruebas del cliente)
    • Testing de interfaces a nivel de prototipos y luego a nivel de integración o preintegración

    Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

    ¿Cuales son los objetivos de nuestro Testing Automatizado?  Estos deben estar alineados con todos los objetivos de Calidad.
    Algunos factores que afectarían a nuestros objetivos:

    • Deseamos automatizar las pruebas regresivas?
    • Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?
    • Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

    Comencemos a Organizarnos

    Elegir una estrategia

    Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización.
    Debería ser una combinación de aproximaciones basadas en:

    • Objetivos
    • Tipo de sistema que queremos probar:
      • Testabilidad: Definir la capacidad del sistema a soportar automatización de pruebas
      • Nivel de automatización actual: Si la base es cero podría ser el peor escenario
    • ¿Podemos modificar el Proceso de Desarrollo y los Requisitos del Sistema para lograr una aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas?
    • ¿Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítemes?
    • Seleccionemos un tipo de Testing Automatizado: Unitario, Integración, Requerimientos, etc.
    Seleccionemos las herramientas basándonos en
    • Estrategia seleccionada
    • Orientación del Testing Automatizado (Aceptación del Cliente, de Componente, GUI)
    • ¿Open Source o Comercial?
    • ¿La aplicación seleccionada se adapta a nuestra aplicación o debemos hacer adaptaciones de la aplicación a la herramienta?
    • Definamos cuales son nuestros costos
    Puntos para facilitar el mantenimiento
    • Definamos las expectativas de la Gestión de las Pruebas
    • Definamos los estándares o patterns para implementar las pruebas automáticas

    Por ejemplo usemos Palabra Clave como patrón que puede utilizarse para reducir los costos de mantenimiento al utilizar la interfaz de usuario basada en la automatización. Algunos de los enfoques de benefician directamente con el trabajo de control de calidad.

    El enfoque que realizamos afectan las acciones

    • Los desarrolladores serán responsables de crear y mantener las Unidades de Pruebas Automatizadas, aunque puede ayudar a QA y su criterio será fundamental
    • SQA puede crear los otros tres tipos de pruebas automatizadas, como siempre lo mejor es integrar directamente en el proceso de desarrollo
    • Debemos asegurarnos de que el Testing Automatizado es realmente parte del proceso y se complementa con el Testing No Automatizado
    Revisemos el Plan de Pruebas Automatizadas

    En todos los casos se debe hacer revisiones de la efectividad del proceso y buscar la forma de mejorarlo. Las siguientes cuestiones podrían ayudarnos:

    • ¿Son lentas las automatizaciones?
    • ¿Son difíciles de mantener?
    • ¿Disminuyen la velocidad del Proceso de Desarrollo?
    • ¿Son eficaces en el logro de nuestros objetivos de calidad?

    Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. También, en algunos casos como en el desarrollo dirigido por pruebas, las pruebas unitarias ayudan a obtener el diseño del código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad asegurando que nada se ha roto cuando cambiamos la lógica interna del software.

    Actualmente las pruebas unitarias se desarrollan con herramientas tipo jUnit [3] y objetos mock [4]. Las herramientas tipo jUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc, son los esperados. Los objetos ficticios o mocks, en cambio, permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar.

    Aquí introduzco conceptos de Testing Driven Development (TDD) tomados de un blog amigo WebTrun:

    SlideShare | View | Upload your own

    Leer entrada completa | Make a Comment ( 1 so far )

    « Entradas anteriores

    Liked it here?
    Why not try sites on the blogroll...