En metodologías Ágil, ¿Quiénes son los tres amigos?

En metodologías ágil, esta técnica ayuda a encausar el incremento de producto desde 3 perspectivas distintas.

Advertisements

Los tres amigos se refieren a las tres perspectivas principales al examinar el incremento de producto antes, durante y después del desarrollo. Estas perspectivas son:

 

  • Línea de negocio – ¿Qué problema intentamos resolver?
  • Desarrollo – ¿Cómo vamos a crear la solución que resuelva ese problema?
  • Testing – Si hacemos ésto, ¿Qué es lo que pueda ocurrir?

 

Las personas responsables de tener estas perspectivas deben de colaborar en definir las acciones a realizar, y acordar cuando es que estas acciones estarán hechas correctamente. El resultado final de esta colaboración es una descripción clara del incremento de producto, generalmente en forma de ejemplos, y termina siendo un entendimiento compartido con el resto del equipo.

 

También resulta una buena práctica que estas personas también revisen los incrementos del producto que ya haya sido implementado, para asegurar que es lo correcto desde estas perspectivas distintas.

 

El concepto de los tres amigos busca balancear la colaboración entre personas con distintas perspectivas e involucrar al equipo entero a la discusión de los detalles en cada incremento de trabajo.

 

Beneficios esperados:

  • Construir un entendimiento compartido sobre los incrementos de producto
  • Identifica confusiones pronto y permite que las lecciones aprendidas ocurran en una etapa temprana del incremento de producto
  • Limita el número de personas que deberían de involucrarse en las discusiones de cualquier incremento de producto

 

Obstaculos comunes:

  • Limitar estas reuniones a sólo tres personas; si hay cualquier otro tomador de decisiones que pueda enriquecer la visión de un incremento de producto específico, es necesario incluirlo en la conversación
  • Terminar de incluir a todo el equipo en estas reuniones; la idea de esta practica es incluir sólo las perspectivas necesarias y mantener el grupo lo más reducido posible
  • Las reuniones de los tres amigos se vuelven juntas programadas y empiezan a manejarse como cualquier otra ceremonia, en lugar de servir de guía basada en las perspectivas que deberían ser incluidas en la conversación de un incremento de producto en particular

 

Kent McDonald

 

El rol de un tester en metodologías Ágil – Un resúmen

Revisemos rápidamente cuales son las actividades que debería realizar cada tester en un proyecto Ágil.

Iniciemos desde un nivel muy alto, en un proyecto idealizado que corra sobre metodologías Ágil, y con un rol idealizado de testing, un rol que generalmente se cataloga como QA.

 

El Kick Off

Este es una junta donde se reunen todos los involucrados en el proyecto y pueden estar incluídos representantes de distintos departamentos como marketing o ventas, así como mánagers de proyecto, dueños del producto, desarrolladores, arquitectos, diseñadores de experiencia de usuario y, por supuesto, testers. La razón porque alguien con el rol de tester participe, ya que el objetivo de esta junta es que todos tengan la idea de no sólo lo que harán, sino que compartan la idea del porqué realizarán el proyecto. Se revisan los objetivos del negocio que condujeron a las decisiones que se han tomado respecto al proyecto; una vez que se entienden los objetivos del negocio, se puede tener una idea más clara de que signfica calidad en este proyecto.

Una vez definido el concepto de calidad dentro del proyecto, se puede trabajar en conjunto con el resto del equipo para que Calidad ocurra.

Si este es un proyecto en curso, sería benéfico tener juntas regulares con el mismo propósito de alinear objetivos ya que es esperado que el negocio enfrente cambios a medida que el mercado cambie.

 

La definición de “Hecho”

Es importante que los equipos definan que aceptarán como Hecho, cuándo es que considerarán una historia como “hecha” o “terminada”, dicha definición deberá ser acordada y aceptada aún antes de que empiecen la construcción de su producto. Sin embargo, esta definición puede ser actualizada si el equipo decide que es necesario. Una definición de hecho(DOD por sus siglas en ingles), se debería basar en los siguientes puntos:

 

  • Todas las solicitudes conjuntas fueron aprobadas por dos desarrolladores antes de hacer el despliegue al ambiente de QA
  • Las pruebas unitarias pasaron
  • Los criterios de aceptación se alcanzaron
  • Las pruebas funcionales se aprobaron
  • Los bugs encontrados fueron solucionados(a menos que el dueño del producto hubiera decidido otra acción)
  • El dueño del producto aceptó la historia de usuario

 

Hay muchas y distintas versiones de lo que es una Definición de Hecho, pero lo que considero extremadamente importante es que una historia de usuario no puede considerarse terminada hasta que haya sido probada y los bugs encontrados estén debidamente reportados. Hacer que el equipo esté de acuerdo que la Definición de Hecho incluya sesiones de pruebas y remediación de defectos, significa que el equipo ha aceptado compartir la responsabilidad de crear un producto de calidad.

 

Planeación de Sprint

Esta debería ser siempre una actividad de equipo, y puede ser complicada para quien tenga el rol de tester. Aquí sucede un cambio de paradigma, los miembros del equipo se enfrentan a la responsabilidad de decir qué actividades realizarán y dejan de lado el sólo recibir instrucciones a realizar; esta transición puede ser complicada para cualquiera.

 

La definición de hecho debe de incluir las actividades de testing como parte de la estimación de toda la historia de usuario, esto significa QA/Testing necesita ser parte de la conversación. Necesitan preguntar sobre los criterios de aceptación y dar retroalimentación si algo no puede probarse, o si algo parece no ajustarse a las reglas de negocio.

Los desarrolladores tienden a discutir sobre la dificultad de implementar una funcionalidad y eso es algo importante de saber, es necesario tomar notas de estas preocupaciones y hablar con ellos para entender el porqué de su preocupación. Podría significar que será necesario realizar más pruebas o que habrá que hacer mancuerna con los desarrolladores desde las etapas tempranas del proceso para brindar la ayuda necesaria.

 

Algunas cosas son fáciles de codificar pero difíciles de probar, y viceversa. Es importante que el equipo conozca el nivel de esfuerzo sin perder el propósito de las juntas diarias; será complicado encontrar un balance, más si el tester siente que alguna historia de usuario no tiene tiempo suficiente para probar, sin embargo el resultado será peor si estas inquietudes no quedan resueltas. Los equipos que no estiman esfuerzos de testing, son equipos que generalmente terminan con una deuda técnica ya que dejan pasar historias con bugs, casi siempre por tener presiones de tiempo, o simplemente por no poder completar las historias dentro de los límites del sprint.

Algo que también es recomendable es que los equipos elijan historias que de distintos tamaños a fin de escalonar el avance de las historias hacia testing y dueños de productos. Esto ayuda a mitigar los cuellos de botella al final del sprint, cuando todas las historias necesitan ser probadas y aceptadas, generalmente, un día antes que el sprint termine. Entre mejor trabaje un equipo en conjunto, estarán estimando mejor en conjunto, así que una buena dinámica de equipo y buena comunicación son esenciales para todos los roles.

 

Durante el Sprint

 

Seguimiento

Parte de trabajar en equipo es que cada miembro use la misma herramienta con toda la información en un solo lugar, muchas veces Jira o una herramienta similar; también es provechoso usar una pizarra(ya sea en línea o física) que registre los estatus de cada historia de usuario. Las tres columnas básicas serán:

 

Por Hacer | En Progreso | Hecho

 

Sin embargo, aunque no es muy generalizado, también puede ser provechoso incluir otras columnas que ayuden a clarificar el estatus de las historias. Además que ayuda a determinar los cuellos de botella que ocurren durante el sprint. La pizarra completa se vería así:

 

Por Hacer | En Progreso | En Pruebas | Probado y con bugs | Hecho | Aceptado

 

Por Hacer – Historias que están en el sprint pero que todavía no son trabajadas

En Progreso – Historias que se están trabajando

En Pruebas – Historias que se están probando

Probado y con bugs – Historias que han sido probadas pero que reportaron bugs

Hecho – Historias que han sido probadas y los bugs han sido reportados y asignados

Aceptado – Historias que han sido aprobadas por el dueño del producto y están listas para salir a producción

 

Los primeros días del Sprint

Sería fácil pensar que los primeros días del sprint son tranquilos para los testers ya que no hay historias completadas que haya que probar. Sin embargo hay varias actividades que un tester puede realizar.

 

Kick off de las historias(Los tres amigos)

Aunque esta técnica necesita una explicación más detallada, aquí va una versión resumida. Justo antes que el desarrollador empiece a trabajar con su historia, debe reunirse con el tester y el dueño del producto; debe ser una conversación rápida donde se revisen los criterios de aceptación y hablar de los detalles de como debería ser probada. La historia debe de actualizarse con la información obtenida en esta reunión; además el desarrollador debería ya tener una idea de que temas serán probados y ver la manera en que estas pasen mientras desarrolla sus historias.

 

Revisiones de diseño

Los diseñadores visuales y de experiencia de usuario deberían reunirse a discutir diseños futuros y solicitar retroalimentación. Por supuesto, será necesario que los testers asistan a estas reuniones y enterarse como es que el producto irá evolucionando; además que será una oportunidad para dar sus opiniones basadas en experiencias previas y así ayudar a evitar problemas futuros.

 

Regresiones manuales priorizadas

Otro tema que merece ser explicado a detalle, pero eso será en otra ocasión. A grandes rasgos; se trata de un crear una lista, y se actualice, dependiendo de como se comporte el producto que se está desarrollando. Enlista una serie de funcionalidades clave que ya estén creadas, prioriza cada una, y al inicio de cada sprint realiza pruebas exploratorias en cada una de estas áreas, ya que al final del sprint será complicado realizarlas.

 

Preparación de pruebas

Algunas historias requieren de cierta preparación, incluso documentación. Es necesario que los testers revisen las historias de usuario en el sprint y se aseguren de estar preparados una vez que el desarrollo termine.

 

Actualización de automatización

El objetivo es mantener actualizados los scripts o crear nuevos. También resulta valioso incluir revisiones de ejecuciones y actuar en consecuencia en las falladas.

 

Historias de testing

Una vez que el desarrollador ha asignado una historia a Testing, se tiene que verificar que los criterios de aceptación se han alcanzado, y será responsabilidad de cada tester averiguar como verificar que se cumplen. En este punto es indispensable entender las necesidades del negocio, además de haber revisado la historia con el dueño del producto y el desarrollador, ellos deberían tener la información necesaria para realizar las pruebas necesarias. Otro punto relevante es que el tester no sólo debe enfocarse en alcanzar los criterios de aceptación, las pruebas exploratorias son esenciales y el equipo debe estar consciente que se reportarán bugs de funcionalidades o procesos que no estén definidas en las historias; habrá algunos errores que serán necesarios discutir primero con el desarrollador, o el dueño del producto, o ambos, antes de de reportar un defecto y así poder discutir el impacto que tendrá en el sprint; o tal vez, simplemente, no sea un error como tal y no haya necesidad de documentarlo; así como también puede ser un error tan pequeño e irrelevante, como un error ortográfico, que pueda ser solucionado al vuelo.

 

El objetivo de testing no debería ser encontrar y reportar la mayor cantidad de defectos; el objetivo debe ser proveer retroalimentación enfocada al negocio rápidamente, los bugs son sólo una manera de dar esa retroalimentación, o también mantener conversaciones constantes con el resto del equipo. Documentar temas relevantes al proyecto resulta de gran ayuda para clarificar temas que haya acordado el equipo; hasta comentarios agregados a las historias son tan provechosos como reportar defectos, en algunos casos.

 

Todo bug reportado y documentado debe ser asociado a una historia de usuario de alguna manera u otra, pensemos que la historia es la madre de ese bug, al igual que lo es de comentarios y sub tareas. De esta manera, cada que el resto del equipo voltee a ver la historia, encontrará toda la información asociada con ella.

 

Si no se encontraron problemas con la historia, es momento de enviarla a Aceptación con el dueño del producto. Los bugs documentados deben ser asignado al desarrollador que trabajó con la historia, una vez arreglados, se reasignan a la persona que lo reportó, así se verificará que el bug se arregló y procederá a cerrarlo; ningún defecto debería ser reabierto más de una vez. Testers y desarrolladores deben trabajar juntos para resolver un bug engañoso en vez de jugar al ping pong con los tickets.

 

Esto se repite cuantas veces sea necesario.

 

Por Kate Falanga

View story at Medium.com

Diez ideas equivocadas sobre testing que creen muchas personas que no son testers. 1era parte.

Las pruebas de software es un oficio que muchas personas fuera del área malinterpretan; y que dañan el propósito de este proceso, propiciando una mala comunicación, culpa y resentimientos.

  1. Los testers descomponen las aplicaciones

Está es una falacia muy común que puede ser refutada con un poco de lógica. Los testers no tenemos ninguna herramienta mágica, escondida entre la computadora del desarrollador y el ambiente de pruebas, que inserta defectos a la aplicación, pero de alguna manera, la aplicación siempre funciona bien en la computadora del desarrollador.

La razón no es que el tester lo haya descompuesto. La razón es que el tester hizo algo que el desarrollador no tenía contemplado. Eso podría ser “Correr el software en el ambiente de pruebas sin antes haber instalado todos los prerrequisitos”. También podría ser que se buscaron exhaustivamente las fallas. De aquí podría venir la frase “Pero es que en mi computadora sí funciona”; en el equipo del desarrollador todo lo necesario para que un software se ejecute ya está instalado, toda la configuración está hecha, además de que sabe que está haciendo, así que sus pruebas generalmente se centran en las cosas que deberían ocurrir.

También puede suceder que la nueva funcionalidad que el desarrollador acaba de implementar, interactúa con otra funcionalidad que se acaba de actualizar y que olvidó ligar, así que la cobertura de las pruebas unitarias no fueron tan completas como el desarrollador pensó.

El punto es, hay muchísimas maneras en que una aplicación compleja pueda fallar, en mi experiencia cualquier equipo encontrará al menos una vez con esta situación en alguna etapa de sus carreras.

 

La verdad: Los testers no lo escribieron, así que no pudieron haberlo descompuesto

A diferencia de un objeto físico que puede romperse al dejarlo caer o al usarse de una manera inesperada, el software sólo puede ser estropeado por quien lo escribió. Los testers sólo encuentran donde es que está estropeado y lo reportan. A veces ni siquiera es un falla como tal y es simplemente que lo construido no funciona como los usuarios esperan que funcionara.

 

  1. Los testers no tienen habilidades técnicas

Esta es una idea que hace que rechine los dientes. He conocido algunos muy buenos testers que no podrían codificar y no tienen habilidades técnicas particularmente avanzadas. He conocido también algunos muy buenos testers que podrían sobrepasar las habilidades de cualquier otro programador en su empresa. Tener habilidades técnicas no se trata solamente de programar, sino también de reproducir y rastrear un defecto complicado de reproducir, ser capaz de leer o entender un error de código, poder preparar una aplicación en distintas configuraciones para probarla, poder explicar tanto a un programador como a alguien con nulo conocimiento técnico, que es lo que el software está haciendo y porque ese comportamiento es un problema.

Ser capaz de comunicar los hallazgos del producto, o reproducir un evento extraño, o poder encontrar esas situaciones en que las suposiciones del desarrollador no cumplen con las expectativas del cliente aún antes de que el cliente pueda ver el software funcionando, esas son el tipo de habilidades que importan. Son muchísimo más difíciles de definir y mucho más difíciles de cuantificar que un “puede programar tan bien como un desarrollador”.

Probablemente la forma más sencilla de describir ésto es que testers y desarrolladores tienen habilidades complementarias. Apresurar que un desarrollador tenga las habilidades para hacer cosas de tester toma tiempo que lo alejaría de sus actividades principales, de la misma forma que a un tester aprende a hacer cosas de desarrollador. Ambos perfiles son necesario y cada uno complementa al otro.

 

La verdad: Testing no es desarrollo

Testing es un campo distinto que tiene sus propias demandas. Algunas de esas demandas podrán involucrar desarrollo mientras que otra no.

Los desarrolladores usan sus habilidades para construir soluciones a problemas expresados en requerimientos de usuario. Antes de escribir una sola línea de código revisan casos de uso, o la petición de características, o el ticket de help desk o cualquier otra documentación que llegaran a necesitar, y toman decisiones en base a la mejor manera de ayudar a la persona que hizo el requerimiento. Después, mientras programan, toman decisiones sobre la mejor manera de manejar los distintos retos que encuentren mientras construyen la solución al problema o necesidad de alguien más. Son habilidades orientadas a la solución de problemas.

Los testers usan sus habilidades para analizar la usabilidad de la solución que se les presenta. Compararán el software con el problema en el caso de uso o la petición de características y buscarán los huecos o áreas que no encajen con el problema o la solución. Después usarán cualquier herramienta en su control para buscar posibles riesgos o sorpresas. Donde los desarrolladores se dedican principalmente a resolver problemas, los testers se dedican a encontrar problemas.

No importa si los testers tienen menos (o más) habilidades técnicas que los desarrolladores. Lo que importa es que sus habilidades sean lo suficientemente buena para cumplir con las tareas que necesitan desempeñar o que puedan hacerse de cualquier habilidad para hacer su trabajo a su mejor capacidad.

 

  1. Testing sólo se trata de escribir casos de prueba para luego ejecutarlos

Sólo hay que voltear a ver las ofertas de trabajo para ver como esta idea es comúnmente concebida. Cada posición tendrá una descripción similar: escribir casos de prueba y/o ejecutarlos. Los testers seniors los escriben y los junior los ejecutan. Eso es suficiente para soltar un pequeño gruñido de desdén.

Esta, como tantas otras ideas erróneas, vienen del modelo de fábrica de desarrollo de software, y de la creencia que el testing puede ser hecho por cualquiera con dos pulgares, además creer que cualquier software puede estar tan correctamente documentado que es posible escribir casos de pruebas exhaustivos y cien por ciento detallados mucho antes que el software esté terminado. Esa preconcepción es tan del modelo de cascada y no sobrevive para nada a las prácticas AGIL; y para casos prácticos, tampoco sobrevive a muchos proyectos de cascada.

Ésto es porque son pocos los proyectos que inician conociendo, y entendiendo, a detalle los requerimientos; así que habrá retrabajo y mantenimiento constante de los casos de prueba, no importa que tanto esfuerzo se haga para mantenerlos siempre vigentes. Dicen que el diablo se esconde en los detalles, o en los huecos de los requerimientos.

Como es relativamente sencillo medir el número de casos de prueba escritos y ejecutados, hay una tendencia a perpetuar esta práctica tan ineficiente. Ésto también ocurre seguido si hay un desdén a reducir la documentación requerida. Existen lugares donde tener una documentación detallada es necesaria; software que podría matar a alguien si llegara a fallar, o software para empresas que son muy reguladas, para esas situaciones sus requerimientos exigen que las pruebas sean realizadas profundamente documentadas e incluir evidencia de que fueron realizadas.

 

La verdad: Los casos de prueba son mucho menos importantes en testing a diferencia de la creatividad, la comunicación y la curiosidad

Creatividad, comunicación y curiosidad. Esas cualidades son esenciales para testing. Los casos de pruebas no son cualidades de un buen tester. Un equipo ÁGIL no tendría problemas de producir un código de alta calidad y bien probado mientras haya documentación sobre lo que fue probado, lo que no y el porqué.

Aún en industrias altamente reguladas con una necesidad de una documentación extremadamente detallada, un tester listo puede montar un proceso automatizado que incluya screenshots y así lidiar con la mayoría de las auditorías y requerimientos regulatorios, además de poder usar herramientas de captura para documentar sesiones exploratorias.

Es muchísimo más difícil medir esas habilidades a medir casos de prueba creados y ejecutados, lo cual justo explica la persistencia tan arraigada a los casos de prueba detallados dentro de la comunidad de testing.

 

  1. No funcionó en producción, así que los testers fallaron

Ésto resulta irritante en extremo. Si algo va mal en producción quiere decir que los testers fallaron. Si los testers no escribieron el código que está fallando, ¿porqué culparlos?

No me gusta culpar a testers o desarrolladores por problemas surgidos en producción. Los desarrolladores escriben código, pero cada release malo que he visto fue malo por factores fuera del control de desarrolladores o testers. Los problemas fueron causados por factores que ni los desarrolladores o testers pudieron prever, por ejemplo huecos en la comunicación, dependencias con otros equipos, o escalamiento de problemas que no pudieron resolverse dentro del equipo.

El software es instalado en servidores que no controlamos, usado por usuarios que no controlamos y en circunstancias que no controlamos. He visto a usuarios culpar a los testers por bugs documentados en navegadores así como también por sus propios errores ortográficos.

Sí, los testers cometen errores, pero también los demás. Nunca he conocido a un tester que no se moleste al saber que dejo pasar algo, aún y cuando no tenían manera de predecir que ese problema pudiera ocurrir.

 

La verdad: Nada puede ser probado en su totalidad

Es ingenuo pensar que un tester podría encontrar cada cosa que está mal con un programa. Tomemos por ejemplo una aplicación de una calculadora básica, con o sin funciones avanzadas. Ahora consideremos la función de sumar, para probar solamente el sumar dos números enteros en su totalidad, sería necesario usar cada número que la calculadora puede producir y sumarselo a todo otro número que la calculadora pudiera producir, y después asegurarse que el resultado es el correcto como lo muestre en pantalla.

Aún con una calculadora simple que no muestre notación exponencial y que sólo muestre números entre -999,999 y 999,999, eso son 1,999,998 posibles números enteros, si consideramos que en promedio tarda 5 segundos para hacer el cálculo y revisarlo, se estaría tardando más de 300,000 años en probar cada posible suma de dos números(trabajando 24 horas por 365 días). Nadie tiene tanto tiempo.

Supongamos que automatizamos el proceso y reducimos el tiempo de cálculo a 0.1 segundos, seguíamos tomando miles de años, o miles de computadoras, para poder probar cada posible combinación. Además que, sólo se ha probado sumar dos enteros. ¿Qué pasará cuando se sumen decimales? ¿Otras operaciones? ¿Más de dos números? Y así podemos seguirnos hasta el infinito.

Teniendo en cuenta todo lo anterior, el error de división de pentium se vuelve más razonable, ¿no lo creen? https://es.wikipedia.org/wiki/Error_de_divisi%C3%B3n_del_Intel_Pentium

 

  1. Los testers pueden encontrar todos los bugs

Para empezar, vuelve a mirar el título de este punto. Estoy seguro que con un presupuesto ilimitado y un lapso de tiempo ilimitado (recuerden lo de los miles de años) sería posible encontrar todos los bugs en un software dado. El único problema es que para cuando todo eso termine, los clientes habrán avanzado y el software que fue probado por miles y miles de años, ahora es obsoleto.

Más allá de la diversión que es el incremento de combinaciones matemáticas, hay que agregar que el tiempo de pruebas deberá de aumentar exponencialmente cada que un nuevo sistema operativo, hardware o funcionalidad se agregue a al alcance del software que se esté desarrollando; también hay que mencionar que muchas de las cosas reportadas como defectos en realidad no lo son… técnicamente hablando. En esos casos el software funciona exactamente como fue diseñado y construido, pero su funcionamiento y diseño no cumple del todo las necesidades y expectativas del cliente. Ésto es común, muy común.

 

La verdad: Los testers no pueden hacerlo todo y tampoco pueden leer la mente

No sólo es físicamente imposible probar cada particularidad que el software pueda realizar en cada pieza de hardware que pueda ejecutarlo, a menos que no importe que siga siendo probado después de que tu vida expire. Los testers no son telépatas; lo intentamos, y aún dando lo mejor, no podemos asegurar que es lo que el cliente quiere o necesita. Es por eso que hacemos nuestro mejor esfuerzo en probar lo que realmente importa, hacemos medidas de riesgo e intentamos asegurarnos que las funcionalidades principales del software trabajen de la mejor manera de acuerdo a nuestro conocimiento y habilidad.

 

Diseñar mejores pruebas de software usando taxonomía de bugs

La taxonomía de bugs ayuda a los testers novatos a tomar puntos de referencia en sus pruebas y a los experimentados a evaluar el alcance total de sus pruebas.

Sumario: En testing, la taxonomía de bugs tiene que ver con definir categorías de funcionalidades y listar todos los posibles bugs en cada categoría. Esas listas pueden ser usadas por testers inexpertos como puntos de referencia, y para ayudar a testers experimentados para iniciar una lluvia de ideas y evaluar la totalidad de un caso de prueba. Usar una taxonomía de bugs existente puede ser provechoso, pero crear una por tu cuenta es aún mejor.

 

Como parte del equipo de investigación y desarrollo, mi equipo desarrolla nuevos productos. R&D tiene un halo de innovación y descubrimiento, pero como estoy seguro que cualquiera que trabaje en R&D sabe que, parte del trabajo donde hacemos cosas nuevas, es bastante escaso. Aún y cuando desarrollamos algo nuevo, una vez que el trabajo inicia, la mayoría de las veces es rehacer cosas que ya estaban hechas.

Algunos ejemplos: Desarrollas una nueva maravilla embebida que resuelve el hambre en el mundo. El producto final debe ser actualizable para que en su versión 2.0 pueda resolver el problema de la disminución de la capa de ozono, así que también se necesitaría una funcionalidad para actualizar el firmware; ¿Qué no habíamos hecho esto antes? ¡Por supuesto que lo hicimos! Cualquier sistema embebido lo tiene, así que nuevamente nos enfrentamos a los mismos retos y, por añadidura, a los mismos bugs. Es la misma situación que instalar un programa, un módulo de base de datos, etc. Si no fue nuestro equipo el desarrollo algo así antes, entonces fue otro equipo haciendo algo similar y hecho sus respectivos casos de prueba. Así que llegamos al mismo punto, reinventando la rueda una vez más.

Es redundante e ineficiente. Debe haber una manera de converger el conocimiento acumulado entre proyectos, entre ingenieros veteranos y novatos, entre los equipos que hay dentro de tu organización, aún entre distintas empresas.

 

Iniciando con la taxonomía de bugs

Una manera de compartir conocimiento sobre testing, es a través de la taxonomía de bugs. Como el término sugiere, la idea general es definir las funcionalidades por categoría y enlistar los posibles bugs en cada categoría.

Estas listas pueden ser usadas para ayudar a los testers experimentados dandoles ideas sobre que probar, y para darle a los inexpertos una lista de las cosas que deben ser probadas y darles a conocer aspectos del producto que tal vez no habían visto que debían de probar, como aspectos específicos de desempeño o usabilidad, y evaluar la totalidad de un caso de prueba seleccionando los ítems de la lista de taxonomía y revisando si ese aspecto ya fue cubierto.

 

Por ejemplo, usando un extracto del libro “Testing computer software” de Cem Kaner, Hung Q. Nguyen y Jack Falk; aquí una lista de aspectos a probar:

 

Desempeño:

  • Baja optimización
  • Pobre respuesta de echo
  • Pobre respuesta de comunicación
  • Ausencia de funcionalidad de Tecleo Anticipado
  • Falta de alertas si una operación tomará mucho tiempo en ejecutarse
  • Falta de reportes de progreso
  • Problemas de tiempo excedido

 

Algunos de esos ítems son funcionalidades más o menos obvias a probar, y otras deberían detonar ideas para pruebas que quizá estén faltando.

 

Por ejemplo, el bug “Falta de alertas si una operación tomará mucho tiempo en ejecutarse”, debería traer a discusión varias validaciones: ¿Hay funciones en el producto que tomen mucho tiempo en ejecutarse?, ¿Bajo qué condiciones?, ¿Habrá registro de avance?, ¿Ese registro es preciso?; Además que debería plantear preguntas sobre funcionalidades redundantes: ¿Daremos soporte al registro de progreso para cosas que tomen poco tiempo?, si lo hacemos ¿Saltará una ventana de avance en la pantalla y desaparecerá en segundos?, de ser así, el usuario podría confundirse por lo que acaba de pasar.

 

Algo más que es interesante de resaltar es que algunas de estas ideas ya son obsoletas. Por ejemplo, la funcionalidad de tecleo anticipado era un requerimiento para aplicaciones de la primer generación de computadoras, cuando una persona podía teclear tan rápido que sobrepasaba la capacidad del sistema para mostrar caracteres en pantalla. Con el tiempo, y el aumento en las capacidades de nuestros sistemas y equipos, ésto dejó de ser un problema.

 

Crear tu propia taxonomía de bugs

Aún y cuando estoy familiarizado con cierto número de listas de taxonomías, realmente nunca he usado ninguna. Lo he intentado, pero debo admitir que no lo he intentado mucho. Por un lado, estoy seguro que las listas de taxonomía de bugs funcionan, pero por otro, usarlas puede ser un inconveniente.

La forma de pensar y el proceso de análisis que siguió la persona que haya escrito la lista, no necesariamente puede coincidir con los tuyos. De esta manera, muchos ítems que esperas encontrar en cierta categoría, terminan en otra que no te hace sentido. Tomemos por ejemplo la lista pasada, en esa lista pusieron “Falta de reportes de progreso” dentro la categoría de “Desempeño”, yo la habría listado dentro “Experiencia de usuario”; otro punto a resaltar es el lenguaje, que en estas listas debería ser breve y conciso, a veces puede ser complicado de entender.

Para poder beneficiarse de una lista de taxonomía de bugs, para un aspecto específico del producto, es necesario leer muchas partes de la lista, filtrar resultados que puedan ser irrelevantes al producto que estás por probar, además que habrá que aceptar que hay muchas cosas que pudieras no entender debido a tu experiencia.

Así que, tenemos una buena idea, pero fue implementada de una manera que resulta ser muy complicada de usar; ¿deberíamos descartarla?

Claro que no, una opción que he aprendido por experiencia, es crear tus propias listas con cosas que he encontrado en repetidas ocasiones; gracias a que tu escribiste esa lista, su organización te hará sentido y el lenguaje te será claro; de esta manera te familiarizaras con su uso en los proyectos en que trabajes.

 

Tengo una lista similar, creada hace mucho tiempo y que enlista aspectos de testing de APIs; la reviso continuamente, y en cada ocasión que descubro una manera de aproximárme a las pruebas de APIs, lo agrego a esa lista. No compartiré esta lista por lo descrito anteriormente: Está escrita de una manera que yo entiendo, pero no sería sencillo de entender para otras personas; cuando la he compartido, lo he hecho estando a lado de las personas que la usarán, explicando cada aspecto descrito y resolviendo sus dudas para asegurarme que la entienden. Para mi, esta lista es muy valiosa y la he usado en innumerables ocasiones; también sé que hay otras listas creadas por colegas de mi empresa, que cubren sus propias necesidades.

Toda esta evidencia anecdótica no califica, de ninguna manera, como un estudio riguroso; sin embargo todo se enfoca en ejemplificar que una lista de taxonomía de defectos funciona en las actividades del día a día, y funciona mucho mejor si esa lista la creaste tú.

Puedes crear una de estas listas recolectando detalles con el paso del tiempo; puedes crearla para ti o para un grupo, si decides hacerla para un grupo, te recomiendo no sólo invitar a participar a los testers, sino también a los desarrolladores y gerentes a que contribuyan con ideas; también puedes respirar profundamente, buscar en listas publicadas y encontrar ideas que estén relacionadas con tu situación, aún y cuando no encuentres información directamente relacionada, es muy probable que te inspiren de distintas maneras.

 

Eso es un punto de inicio, también puedes apoyarte en el uso de herramientas de mapeos mentales para crear tus listas.

 

Michael Stahl

https://www.stickyminds.com/article/using-bug-taxonomy-design-better-software-tests

 

Mis esperanzas para Testing en 2018…

¿Son las pruebas automatizadas el futuro de testing? La respuesta es no.

 

por Steve Watson

 

Es el uno de enero de 2018, y a las 3 pm la lluvia y las nubes grises empiezan a irse, el cielo azul y unos rayos de sol están apareciendo. Es un pequeño rayo de esperanza en un día gris que me ayuda a pensar en el futuro, y a imaginar donde estaremos como industria en un año.

¿Qué habremos aprendido? ¿Qué haremos diferente? ¿Qué nuevas habilidades y estrategias habremos adoptado? ¿Cómo habrán evolucionado nuestros trabajos?

 

¿Cuál es mi esperanza para la industria de testing este año? Después de considerarlo mucho, pude enfocar mi obsesión en un solo término, en un solo aspecto de las técnicas de testing: “automatización”.

Han habido muchos debates y creo honestamente que es momento de avanzar, es una distracción innecesaria que no nos permite enfocarnos en otros temas que deberíamos estar discutiendo.

Citaré a James Bach: “El problema con “Testing Automatizado” empieza con las mismas palabras. Testing es parte del trabajo creativo y crítico que sucede en la sala de juntas, pero “automatizar” alienta a la gente a creer en un modelo de línea de ensamblaje que se hace en una planta.”

 

Testing es un oficio. Es algo que requiere pensar. Requiere tener la habilidad para identificar que necesita ser probado y como será probado.

Automatizar sólo es “el cómo”, eso está bien, pero enfocándonos mucho en “el como”, parecemos obviar mucho la importancia de “el qué”.

Varios comentarios en LinkedIn, hechos por profesionistas en testing, han sugerido que esto demerita el oficio, y estoy de acuerdo. Cualquiera que no sea tester o no tenga experiencia en testing, tal vez un gerente que lleve control de presupuestos, podría ver las actividades de testing, y asumir que automatización es básicamente codificar algunas pruebas. Ésto no nos ayuda a mostrar los procesos de análisis por los que pasamos para identificar que necesita ser probado, como análisis basados en riesgos, pruebas exploratorias, recorridos de historias y nuestra propia experiencia para planear como romper algo que ni siquiera ha sido construido.

 

Pruebas automáticas se ve muy bien en el papel, ¿Quién no quiere ahorrar tiempo y deshacerse del aburrido trabajo repetitivo?. Es algo muy sencillo de vender, y en teoría, si podemos automatizar un montón de pruebas repetibles tendremos mucho tiempo para hacer cualquier otra cosa. Sin embargo, este no es siempre el caso. Y es que si sólo discutimos sobre automatizar las pruebas, los gerentes, o cualquier persona encargada de tomar decisiones, no podrá ver todas las otras pruebas que necesitan ser agregadas a la ecuación, sin mencionar que ese montón de pruebas automatizadas necesitarán mantenimiento cada que haya cambios o actualizaciones en el producto o aplicación que se esté desarrollando.

Vamos a suponer que estamos probando una página web. Los testers hacen unas pruebas manuales y luego empiezan a escribir unas pruebas automatizadas para cubrir los escenarios encontrados. A menos que otra cosa suceda, el equipo podría asumir que el trabajo está hecho, tenemos pruebas repetibles, así que vayamos a otra cosa. Pero esa automatización de la que tanto se habla sólo está cubriendo UNA PARTE de lo que necesita ser probado: “Regresión”.

Por ejemplo, ¿Qué hay de las pruebas de carga y desempeño? ¿Cuándo entrarían? Hace falta otra herramienta para crear pruebas de carga, pero también es necesario el pensamiento crítico para establecer si los puntos de referencia para el desempeño serán de un usuario, de diez, de cien, de mil, etc. Y luego tiene que venir el entendimiento de como se escalarán esas pruebas de carga, ¿se repetirán los mismos escenarios o trataremos de imitar el comportamiento del usuario? La ejecución es la última parte de un largo proceso de análisis.

 

Y ni siquiera he hablado de los beneficios de las pruebas exploratorias. Las pruebas automatizadas no pueden detenerse en un momento dado de la ejecución y hacer algo diferente(al momento por lo menos), a observar los detalles de la página, a leer el contenido, sin embargo, hoy por hoy, las pruebas automatizadas checan lo mismo una y otra vez.

 

DE ESO NO SE TRATA TESTING.

 

Lo volveré a repetir: “Testing se trata de análizar, investigar, en definir los riesgos, en planear que es lo que vamos a hacer, en buscar cosas que se le hayan escapado a quien haya hecho los requerimientos, algo que nunca haya considerado que pudiera pasar” Después de todo eso, viene “el cómo”, el definir como será la mejor manera de ejecutar esas pruebas, ya sea usando el teclado para navegar en una aplicación web o escribiendo pruebas automatizadas que realicen actividades repetibles por nosotros.

 

Mi deseo para 2018 es que dejemos de hacerle creer a los demás que testing sólo se trata de automatización. No lo es. Somos más que programadores de pruebas, hagamos que nuestro trabajo se trate de añadir valor real a nuestras organizaciones.

 

SOMOS PENSADORES CRÍTICOS, SINTAMONOS ORGULLOSOS DE ELLO.

 

¡Feliz año nuevo!

 

https://stevethedoc.wordpress.com/2018/01/01/my-hope-for-testing-in-2018/

Steve Watson, 01/01/2018

Una prueba es ejecución

Testing es ejecución, no un artefacto.

Los artefactos pueden producirse antes, durante, o después de hacer pruebas. Pero, cualquier cosa que sean, no son pruebas, pueden ser instrucciones para realizar pruebas, resultados de pruebas, o herramientas para pruebas, sin embargoo pueden ser pruebas.
Habré podido decir de manera informal “Creé una prueba”, cuando realmente quise decir es que diseñe una experiencia, o hice un plan para probar algún evento. El plan por si mismo
no es la prueba, tanto como la fotografía de un auto no es un auto. Por esa razón, siendo más estrictos, la única manera de hacer una prueba es ejecutándola.
No siempre hablamos de manera estricta, pero deberíamos saber como y saber porque queremos hacerlo.

¿Porqué una prueba no puede ser un artefacto?
Porque los artefactos no piensan o aprenden en el sentido humano de la palabra, y pensar es fundamental para el proceso de una prueba. Afirmar que una prueba es un
artefacto, es como ponerte un titere en la mano y afirmar que es una personita hablándote, sin embargo eso no sería más que afirmar que estás hablando contigo mismo, obviamente, y si te quitas de la ecuación, el títere ya no será una personita. ¿O si? Sería, en todo caso, un titere adornando el piso. El valor de pruebas en un artefacto dependerá de las habilidades de un tester motivado.
Siguiendo un procedimiento o usando código, podemos hacer un chequeo. Checar es parte del testing, por supuesto. Cualquiera que corra un chequeo y encuentra un falla, sabe que el siguiente paso es averiguar el porqué de esa falla. Un tester también debe evaluar si es que los chequeos están trabajando correctamente y si son suficientes, o muchos, o si están mal.
Todo eso es parte de la ejecución de pruebas.
Cuando la luz de “Check engine” del auto se prende, o cualquier otra alerta extraña aparece, no puedes saber que es lo que está mal hasta ir con el mecánico ya sea que esa alerta sea por una falla grave o pequeña. El chequeo no es la prueba. Las pruebas son mucho más que el chequeo por si mismo.

En el día a día, realizando nuestros trabajos, cuando un tester realiza está probando ¿Has visto realmente eso? Creo que a lo mucho lo que viste fue alguno de estos dos escenarios…
Ya sea:
A un tester que parecía que “sólo” hacía lo que el documento le decía, mientras que constantemente, y quizas, inconscientemente se ajustaba y reaccionaba a lo que pasaba
en el sistema mientras probaba. (Ese tester podría encontrar defectos, pero lo hace interpretando, juzgando, y analizando, ejecutando esa prueba.)

O:

Estás viendo a un tester que necesariamente dejó escapar muchos defectos que pudo haber encontrado, ya fuera porque las instrucciones fueron muy complejas, o muy vagas, o había muy pocas(porque esa documentación costaba mucho dinero) y el tester falló en ejecutar una prueba que compensara todo ésto.
En cualquier caso, ya sea que haya sido detalladamente escrito o meticulosamente codificado, este artefacto de prueba, puede ser un títere en el suelo, o puede ser un títere
animado por la mano de un tester. Es tu elección sufrir sin un tester, o protegerte teniendo a un tester. Al final las cosas caerán por su propio peso.
¿Qué peligro puede haber al ser tan informales al escribir “pruebas”?
No es necesariamente peligroso ser informales al referirse a este tema. Sin embargo, un posible peligro es que los managers que no son testers y los clientes pensarán de nosotros como diseñadores de casos de prueba en lugar de personas que ejecutan el especializado proceso de testing. Esto a su vez causará que se trate a los testers como piezas
intercambiables que crean “pruebas” y que están comprometidas a seguir reglas explícitas.
Esta teoría del testing (A la que llamaremos Escuela de Testing de fabrica) conduce a tener artefactos muy caros que descubren muy pocos bugs. Su valor es mayormente que lucen impresionantes para personas ignorantes.
Si hablas con personas que entienden a fondo que testing es una ejecución, está bien hablar de manera informal. Sólo mantén la guardia cuando oigas a alguien preguntar
“¿Dónde están tus pruebas?, ¿Ya escribiste tus pruebas? o “¿Deberías automatizar esas pruebas?”. Preferiría escuchar “¿Cómo probarás ésto?”, “¿En dónde estás enfocando tus
pruebas?” o ¿”Estás usando herramientas que te ayuden con tus pruebas?”

http://www.satisfice.com/blog/archives/1346
James Bach
6 de enero, 2014