Testing

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.

Anuncios
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 )

¿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? )

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 )

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 )

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 )

¿”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? )

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