Manual (Exploratory) Tester is not dead at all…

“My team (Pivotal Tracker) is looking for an exploratory tester. We are based in Denver, and I think we have about 25 people total on the team. It’s a really nice environment with great people. As with the rest of Pivotal Labs, we use XP practices such as pairing, TDD, and automating tests at all levels. We’re doing some exciting experiments to improve our ability to build quality in. For example, we’re automating all of our build and deployment processes, moving towards continuous delivery. We’re also starting to use story workshops and BDD (automated with Cucumber and Capybara) to guide development at the acceptance test level.”

Así es como inicia uno de sus post la muy famosa Lisa Crispin en el grupo público de Yahoo “Agile Software Tester”.

En ésta porción de texto nos muestra lo grandioso de su entorno de trabajo, donde lo más destacado es el “gran grupo de profesionales” que conforma su equipo de aproximadamente veinticinco (25) profesionales.
También nos cuenta que mayormente sus prácticas, como las del resto de la empresa, son del estilo XP (Extreme Programing) entre las que destaca trabajo en pares, TDD (Desarrollo Dirigido Por Pruebas, según siglas en inglés), automatización en todos los niveles :O lo que incluye la generación de sus paquetes de software (builds) en un esquema de Entregas Continuas (Continuous Delivery).

Además al parecer han encarado algunos “experimentos” con el objeto de mejorar la calidad en el proceso de desarrollo, aunque le anteceden técnicas para mejorar los contenidos y comprensión de las Historias de Usuarios, tales como “story workshops”. Inclusive han incorporado Desarrollo Dirigido Por El Negocio (BDD) utilizando algunas conocidas herramientas de automatización como Cucumber y Capybara, para conseguir un desarrollo orientado por Testing de Aceptación (AUT).

Como podrán ver, es un entorno ideal de trabajo donde las técnicas están “en la ola de la cresta” y no dudo de que se encuentren al mismo nivel las prácticas agilistas.  Los productos que desarrollan detrás de Pivotal Tracker son sin dudas innovadores y están entre los mas requeridos al rededor del mundo, así que no puedo menos que imaginar que la fuerza de conocimientos tecnológicos y el grado operativo están también en una máxima expresión.

El artículo de la señora Crispi continua diciendo:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills. The developer pairs are trying to do some exploring before they mark a story finished, but there are so many of them and only two testers right now. Our goal is that with BDD/ATDD, and the developers doing some exploring too, there will be more time for testers to do exploring at a more end-to-end level.”

En éste pedido en particular, no están buscando un nuevo desarrollador con habilidades única en un lenguaje o framework, ni un arquitecto de software eximio que establezca las bases tecnológicas, ni un experto consultor (ellos deben serlo todos) que determine los lineamientos de un proceso para trabajo Agile. No han mencionado tampoco  a un experto analista de negocios (BA) o dueño de producto (PO) para fortalecer la cadena de valor de ideación o gestación del producto, como tampoco se habla de un experto automatizador de pruebas.

Si ya sé, la página de ofertas laborales de Pivotal seguramente están todos o algunos de esos pedidos, de acuerdo, pero eso al menos lo podemos suponer todos, verdad? Lo realmente interesante es que en una de las empresas más conocidas del planeta están pidiendo un Exploratory Tester, algo a lo que en nuestra industria realmente no estamos acostumbrados.

Si son observadores en el posteo de Crispi, el pedido además de ser cordial y convincente, también es muy claro en varios aspectos a los cuales no debemos dejarlos pasar por alto:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills.”

Esta persona en particular tendrá un interesante y duro desafío al intentar explicar el enfoque del Testing Exploratorio a desarrolladores. Aunque ella (Lisa) lo expone como algo simple, liviano y muy “al paso” … “…to teach others SOME exploratory testing skills”, estoy seguro que quien tome este empleo, deberá extender sus conocimientos y habilidades a escala empresarial.
Seguramente Lisa sabe a que se enfrenta este postulante, por cuanto éste enfoque no es algo simple ni liviano, ni se aprende sin esfuerzo de la noche a la mañana, muy por el contrario tiene un sin número de particularidades que lo hacen complejo y difícil de implementar con éxito. Por un lado requiere de “practicantes” con una base conceptual importante “fuera de los estándares del testing tradicional”, pero también es necesario un absoluto apoyo de la empresa en todos los niveles.

“The developer pairs are trying to do some exploring before they mark a story finished”

Quien no ha notado que las Historias de Usuario usualmente son entregadas con un estado de “hecho” (done) dudoso, y que finalmente el ciclo de desarrollo se extiende hasta el final de Sprint tratando de resolver los defectos y errores que solo se detectaron en las pruebas de sistema?
Claramente la señora Crispi transparenta aquí una de las debilidades de casi todas los equipos que juegan a XP delimitando la participación de los Testers a fases tardías como en Waterfall.

 but there are so many of them and only two testers right now

O bien puede ser que el tan alto y preciado nivel de aplicación tecnológica les hace pensar que se necesitan menos personas en el proceso de desarrollo y por ello “recortaremos Testers”

Our goal is that with BDD/ATDD, and the developers doing some exploring too..

y “eventualmente sumaremos a algún tester”, pero esperamos que desarrollo tenga tiempo de hacer sus propias pruebas de integración garantizando algún flujo mínimo que de cierta cobertura antes de hacer “committ”.

…there will be more time for testers to do exploring at a more end-to-end level.”

porque actualmente no estamos llegando a hacer pruebas punto-a-punto y nuestros testers no logran hacer pruebas completas en los distintos flujos de negocio, ya que deben hacer sus pruebas en los puntos intermedios, revisar los datos para múltiples tipos de usuarios y sus accesos, más sus acciones posibles según los roles, analizar datos en las bases, chequear cambios de estados y trabajar contra servicios web de terceros.
La Hiper-super-archi automatización de las pruebas no son suficientes y el cliente se ha quejado tantas veces de que nuestro producto falla en algunas acciones complejas, o en los resultados mostrados, que exige que seamos mucho más cuidadosos en el análisis y en las pruebas.

Finalmente todo esto por supuesto y como es costumbre, es percibido como un “Issue de calidad” (de la vieja y nunca bien amada “área QA”), pero no asumiremos que necesitamos más testers analistas (los famosos “manual testers”) insertos en el proceso y menos herramientas intentando suplantar la inteligencia del ser humano.

You have a passion for customer-focused web & mobile apps, and discovering interesting interactions and side effects. You know good testing isn’t about quality gates that hold back releases, but about sharing information and helping to release faster and with more confidence. Whether you know how to code or not, you find you have the most fun testing. You are sharp, curious and enjoy exploring the dark corners of complex software. You judge your success by customer feedback and the success of your team, not how many problems you find. You enjoy collaborating closely with other team members.

Claro, los grandes volúmenes de datos dan una sensación de velocidad y cobertura y las enormes cantidades de horas insumidas en generación de estos frameworks de automatización y su mantenimiento, sumado a las horas de generación de las pruebas automáticas, nos dan la idea de que lo estamos haciendo bien y así muchas cosas menos podrían fallar.

Lo cierto es que haciendo cierto tipos de lecturas (totalmente sesgadas por supuesto) de éste pedido de Pivotal Tracker, podremos deducir que el Tester analista debe ser un practicante del Testing Exploratorio, que el Testing no puede ser ejecutado por herramientas o robots, que no cualquiera puede hacer Testing… pero lo que más me agrada de haber leído éste pedido en particular, es que puedo concluir que simplemente el Tester no ha muerto.

Advertisements

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

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!

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.

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í.

Dependiendo del entorno de trabajo, la suspicacia de las personas, los objetivos personales de cada integrante del equipo de Testers entre otros elementos, 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.

Quizás es bueno tener ciertas métricas como, cantidades de defectos detectados por Tester, pero no podríamos evitar entrar en comparaciones odiosas y 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.
Tal vez este tipo de mediciones solo servirían 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. Pero que aporta a la calidad en si mismo? tal vez poco o nada.


A las buenas del Tester?

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.

Me gusta mucho la idea de incentivar, pero sin generar competencias sino creando ambientes colaborativos (inclusive para eso estamos aquí nosotros) y cada uno en su puesto de trabajo debe elevar al máximo su responsabilidad (habilidad de respuesta).

Por lo tanto considero que 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.
Así, si se considera la existencia de Testers en un equipo de desarrollo de software, tal como sucede actualmente en los equipos Scrum, no debería quizás quedar fuera de la supervisión de Responsables QA y permitir que la carga de gestión recaiga 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, técnicas, modelos y patrones de calidad, invirtiendo en el aprendizaje de conceptos avanzados y modelando nuevos modos de hacer testing y demás elementos que existen para sumir al equipo de desarrollo entero en un estándar que desde el llano y como punto de partida sea muy alto.

Entonces, presumiendo un equipo maduro, consciente y capaz, presumiremos que todos los defectos del producto fueron eliminados y en relación directa, un producto de alta calidad. Ahora a generar retorno de inversión.

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.

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í.

QA-Testing en SCRUM

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), o dos (1), serán mitad de desarrollo y mitad de testing? ¿como se gestionan los defectos en tiempos tan acotados? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuar 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 en tantos años de vida de Agile. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y te aseguro que en SCRUM no está estipulado como es el proceso de testing y calidad. Pero eso está bien por cuanto Scrum no es prescriptivo hasta el punto de definir “cómo hacer el trabajo” del equipo.

Leí varios libros 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 por adelantado. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos (la cual es mayormente deseada en los negocios actuales), como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos (inclusive dentro del Sprint en curso).
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando la historia del usuario es expuesta 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, pero es mejor dejar de pensar en fases tan marcadas. Que opinas de colaborar todo el tiempo con lo que sabes, con lo que entiendes? Seguramente será más beneficioso para todos en términos de “descubrimiento de la feature” y/o “descubrimiento del product”, si te involucras y con tus opiniones generas mínimamente dudas.
    No considerarías a esto mismo TESTING?
  • ¿Tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional. Lo que puedes hacer sabiendo que cuentas con los recursos necesarios y adecuados (interación plena, coordinación y colaboración, pero principalmente la involucración), es gestionar de un modo colaborativo, es decir con la opinión de todos a tus sugerencias y propuestas de planificación, así probablemente ya no existirán más los clásicos problemas de “responsabilidad de un rol”, porque el resultado será algo funcional a todos y generado por todos.
  • Mientras se hace testing los desarrolladores codifican y mientras reportas fallos, ellos corrigen, al rato lo verificas. Para eso está el trabajo en equipo, solo hay que consensuarlo y organizarlo.
    Aunque está mal visto en los paradígmas tradicionales, los desarrolladores serán eventualmente los mejores testers; puedo asegurar que visto que es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo en general, no solo a QAs.
    En el mismo iterín, los desarrolladores 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.

Para que esto no quede con un amargo sabor, te paso este enlace que podrá al menos darte una idea de como iniciar, pero te repito, aprende por tu cuenta pues no hay recetas.

A mejor Testing, peor calidad de Software?

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.

    A las mejores prácticas debemos diseñarla “Ad-Hoc”

    Como sabrás,  no dispongo de un plan genérico tipo “receta de cocina” para que puedas implementar mejores prácticas para el aseguramiento de calidad, control y Testing. De hecho para poder diseñar un plan lo óptimo es que formes un proyecto inicialmente, tal cual como lo haría un Líder de Proyectos para construir un sistema.

    Tal vez sería provechoso Iniciar con observaciones de las prácticas actuales tratando de comprender sus ciclo de vida completo, teniendo en cuenta para esto cuales son los elementos de entrada y salida para poder definir en concreto que es lo que se hace con esas prácticas en particular.

    Luego tomar un mes, dos o tres para analizar las prácticas relevadas, sus contextos operacionales, sus entradas y salidas, sus procesos. Hacer esto mientras se aprende cada vez más del procesos de desarrollo completo en el que opera el equipo equipo.

    Esta actividad seguramente la realizarás en forma cíclica, es decir que nunca terminarás de relevar y analizar, pero debes al fin de cada fase del proyecto, determinar que elementos son útiles, cuales se pueden despreciar y cuales se pueden mejorar.

    Es importante tener en mente la simpleza, sencillez y considerar que los que ejecutan esas actividades son personas, no máquinas.

    Siempre pensar en el inicio y fin dentro del horario normal de trabajo y con esto estimar mejor los costos de las actividades de cada práctica y serás realista al ponderar los proyectos de calidad.

    Si aún no existe un modelo de calidad al que la organización se haya adherido , es posible que solo tengan un proceso informal o semi formal, pero no es necesario que sigas al pie de la letra otros procesos conocidos, como CMMI o ISO, aunque es muy bueno comprenderlo. Lo más importante es que no hay recetas de cocina y no se debe exigir que el equipo de trabajo se amolde directamente a un modelo o una norma y todos los procesos que implican.

    Las mejores prácticas debemos diseñarla.

    Dada mi experiencia, puedo sugerir que esta labor nunca se haga como un trabajo en solitario, por que nadie comprenderá el trabajo y su objetivo.
    Inicialmente se debe buscas el consenso de las personas más importantes, es decir la Gerencia, luego pedir el apoyo de los líderes de los equipos, por ejemplo Líder de Proyecto y Líder de Desarrollo como también y fundamentalmente el del Líder de Testing, salvo que cumplas ese rol al mismo tiempo.
    Siempre se debe recalcar que el objetivo de cualquier Software Factory, empresa IT o prestadora de servicios, es brindar productos y servicios dentro de los plazos establecidos, cada día más cortos, a los costos pactados, y con la mejor calidad posible a tal punto que se perciba tanto dentro como fuera de tu organización.

    LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

    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.

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

    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.