Diez ideas equivocadas sobre testing que creen muchas personas que no son testers. 2da parte.

Conclusión de esta lista que busca ayudar a explicar lo que no es el rol del tester en un proyecto,

Advertisements
  1. La actividad de testing se puede automatizar

Esta es una de las ideas más comunes porque es casi, casi, cierta. En teoría, cualquier prueba puede ser automatizada. Sin embargo, el proceso de testing, con sus múltiples combinaciones contextuales y la intuición del tester, no pueden ser automatizados; al menos sin una verdadera inteligencia artificial a la mano, aunque probablemente tampoco se podría. Lo más seguro es que terminaríamos con un equivalente a Marvin, el robot tester paranoico quejándose que su único propósito es realizar cosas nada interesantes.

 

Aún y cuando se pudiera automatizar cada prueba, eso no significa que debiera hacerse. Las computadoras son muy buenas realizando tareas de una misma manera muchas veces y muy rápido. Las pruebas que requieren hacer muchas cosas rápidamente, muchas veces y usando exactamente los mismos pasos una y otra vez, deberían ser automatizados.

Por otro lado, los humanos son muy buenos en reconocer cuando algo no luce bien, ésto gracias al reconocimiento de patrones y razonamiento espacial. Si se intentara realizar esas pruebas con computadoras, sería una inversión de recursos elevada y con el riesgo de que se cometieran muchos errores. Es mucho más fácil y barato dejar a los humanos que hagan esas pruebas y dejarle a la computadora los cálculos basados en múltiples datos o que sigan patrones simples.

 

La verdad: Algunas pruebas pueden automatizarse, el proceso completo no.

Actualmente, podemos probar si un elemento en pantalla es visible o no, pero no podemos automatizar (al menos todavía no) si esos elementos están exactamente donde debieran estar y como es que lucen para el usuario.

En teoría es posible automatizar una prueba donde una impresión contenga la información esperada; sin embargo, requeriría mucho esfuerzo estabilizar ese proceso, a base de prueba y error se necesitaría sanear el proceso cada que la prueba fallara porque la impresora se quedaba sin tinta, sin papel, o que se atorara una hoja, o dejara de estar en línea; eso sin contar que el sistema enviara siempre la información correcta cada vez o en el formato esperado. Cada que uno de esos resultados inesperados ocurriera, la prueba fallaría. Una prueba que tarda menos de un minuto en ejecutarse, tomaría semanas de trabajo en afinarse, para que arrojara resultados confiables.

 

Ninguna automatización podrá reemplazar nunca la reacción de “mhh, eso está raro” de un tester experimentado. Sin esa reacción la gran mayoría de bugs pasarían desapercibidos hasta llegar a producción.

 

  1. Testing ocurre hasta el final

Esta es otra idea errónea y que tiene cierta validez por ser parcialmente cierta. Trabajar con el software es algo que no se puede hacer hasta que la nueva funcionalidad/aplicación/o lo que sea ha sido codificada.

La idea de que esta cosa llamada testing, que ocurre después de que la codificación está hecha y antes de que sea lanzada a producción probablemente nació del modelo de cascada, simple y sencillamente porque así es como luce en ese modelo. Además, que así es como luce en un proceso de fabricación: las cosas no pueden ser verificadas hasta que no existan.

Por supuesto, como se ha mencionado hasta ahora, el desarrollo de software no se parece mucho a un proceso de fábrica. Los desarrolladores no producen miles de cosas más o menos similares, así como los testers no pueden descartar cosas del código que no cumplen con los estándares de fabricación.

 

La verdad: Testing ocurre todo el tiempo

Sólo porque los botones y los links no son presionados significa que el testing no está ocurriendo; testing es a final de cuentas un proceso de comparar los supuestos sobre una cosa(el software que se está probando) contra el desempeño actual de esa cosa. Antes de que la codificación esté terminada, los testers pueden trabajar con el resto del equipo preguntando sobre las cosas que estarán probando. Pueden ir sobre los requerimientos y hacer preguntas incómodas sobre los casos de uso o las historias de usuario, y de ahí ir preparando los prerrequisitos. TODO ESTO ES TESTING.

Aún en un modelo clásico de cascada, los testers no están probando al final. Desde el momento en que empiezan a indagar en las especificaciones de los requerimientos, ya se está probando esos documentos, y aún más importante, se están probando los supuestos con que se crearon esos requerimientos.

 

  1. Cualquier puede hacer pruebas de software

Otra de esas ideas que tiene tanto peso porque es parcialmente cierto. Que también está apoyada por la idea de que testing tiene que ver con seguir una serie de instrucciones detalladas, o casos de prueba, para luego reportar cualquier cosa que no cuadre con esas instrucciones. Por supuesto que cualquier que pueda leer y seguir instrucciones puede hacer eso. Basándote en eso, se contrató gente al azar para probar, en lugar de testers, con la esperanza que puedan seguir instrucciones.

Eso es probar en el más limitado de los casos. El hecho de que este tipo de testing no encuentre problemas relevantes o críticos, tiende a ser ignorado porque este método es más fácil de medir. Se puede evaluar a las personas por los casos de prueba que ejecutó, que hace felices a los gerentes cuenta chicles. A los buenos gerentes no les debería gustar este método porque deberían saber que no están midiendo la habilidad de su gente de encontrar información importante sobre del software.

 

La verdad: Cualquiera puede seguir instrucciones. Testing requiere habilidades y entrenamiento.

Si haces que tus instrucciones sean tan simples que cualquier pueda seguirlas, al final te encontrarás con una tarea que nadie con inteligencia o creativdad va a querer hacer. Mucho peor, desalentarás a la gente que llamas testers a escarbar en la aplicación y encontrar anomalías.

Si cuentas con testers capacitados y motivados, con la libertad y conocimiento para indagar en instrucciones detalladas y obsoletas, terminarás con un grupo de testers que investigan en internet el porque aquél servidor extrañamente configurado está causándole errores a algunos de tus usuarios. O construyendo pruebas de carga para lidiar con esos molestos errores de desempeño antes de que se vaya a producción. O haciendo cualquier otro número de tareas o actividades que agreguen valor a tu software, en lugar de esas otras personas sin entrenamiento y habilidades necesarias para saber siquiera que eso es posible.

 

  1. Los testers son vigilantes de Calidad

Esta idea en particular implica que los testers pueden controlar la calidad del código que los desarrolladores realizan además de cumplir con las fechas de liberación del software y de cualquier cosa que haya en medio de todo eso. Vayamos por partes, no hay desarrollador que quiera escribir un mal código, usualmente hacen lo mejor que pueden, y al igual que los testers lidian con requerimientos ambiguos, código heredado ilegible, y con cualquier otra cantidad de problemas que impacten con la calidad de su trabajo.

Si eso no fuera suficiente, existen muchas ocasiones en que las decisiones de negocio obligan a que la liberación ocurra antes, sin importar cualquier objeción, sin importar los riesgos o impactos negativos que eso pudiera generar. Si los testers fuéramos vigilantes de calidad, nada iría a producción hasta ser probado correctamente, nunca se presionaría para liberar algo que sabemos tiene problemas graves.

Personalmente creo que llamar a los testers “vigilantes de calidad” es como poner una caseta de cobro en medio de la nada, sin nada que impida que cualquier cosa pueda rodear esta caseta, no hay ninguna reja o pared que pueda detener cualquier tipo de avance, y aún así somos colocados en esa pequeña caseta con la misión de detener cualquier error que ponga en riesgo la calidad del software.

gate

 

La verdad: Los testers no son vigilantes

Los testers no pueden estar en todos lados, conocer todo o hacer todo. No estamos, de ninguna manera, en control de todo desde el inicio hasta el final. Y siendo honestos, ¿quién quisiera serlo?

Hay un número indeterminado de decisiones que hay que tomar sobre liberar o no el software, o si un bug debe ser arreglado o no. Nuestro rol no es pararse frente al código fuente y señalar cualquier línea que no cumpla con nuestros estándares. Nuestro trabajo es reportar que vemos y dar una estimación de los riesgos que podrían ocurrir.

En un mundo ideal estaríamos seguros de cualquier liberación de software, pero la vida rara vez es ideal. Nuestros análisis de riesgos sobre un error encontrado podrían no cuadrar con los de la empresa, siempre serán distintos dependiendo de la naturaleza de sus negocios. Nosotros estamos en una excelente posición para observar y reportar sobre la calidad del software y como podría responder el usuario a éste. Sin embargo, no estamos en una posición para entender la visión completa de las necesidades de la empresa.

 

  1. Testing es Quality Assurance

Esto es parcialmente cierto, la parte en que testing es parte de Quality assurance. Y eso es todo, y esto porque no es posible asegurar la calidad en software. Cada aplicación es diferente, cada funcionalidad es distinta, nunca dos programadores trabajaran en la misma función y no hay dos testers que prueben los mismos cambios.

Asegurar la calidad requiere que se controle la calidad, y cuando hay demasiadas variantes en juego, controlar ese proceso se resume a que cada uno de los involucrados haga su mejor esfuerzo para que el software sea tan bueno como sea posible. Toda la idea de asegurar la calidad de software fue más o menos importada de las mejoras de calidad en fábricas, donde funciona el cambiar procesos para reducir el número de productos defectuosos. Una fábrica produce cantidades enormes de productos más o menos idénticos, así la calidad de un producto puede ser definida por una clara, y medible, cantidad de propiedades. El personal de calidad en una fábrica realiza actividades casi idénticas con la persona en línea 1 y con la persona de la línea 2 y así sucesivamente. Los testers en una fábrica se aseguran que el número de productos defectuosos no exceda el estándar que tenga esa fábrica.

Estoy seguro que para este momento, la idea de aplicar este tipo de lógica al desarrollo de software resulta bastante incómoda. Simplemente no es posible forzar que el desarrollo de software trabaje de esta manera. Además que existen muy pocos lugares donde un tester tengan la posibilidad de cambiar los procesos internos del lugar donde trabajen en pos de mejorar la calidad del código. Con eso, simplemente el tester queda sin posibilidades de asegurar la calidad.

 

La verdad: Quality assurance es mucho más que eso y difiere sobre lo que es testing

Los testers no tienen una manera de inyectar calidad. No tienen manera de inspeccionar pequeños productos de código, descartar los defectuosos y quedarse sólo con los buenos. A lo mucho, lo que podemos hacer es decirle a la gente cuando es que el software no hace lo que la gente de marketing dice que hará, y aun así es poco probable que los altos directivos nos pongan atención.

Hacemos lo mejor que podemos para evaluar la calidad basándonos en requerimientos incompletos, porque queremos darle lo mejor que tenemos tan pronto como lo tenemos, después vamos remodelándolo cuando digan que eso que querían no era realmente lo que necesitaban. Abogamos por la calidad y apuntamos a reducir los riesgos cada que podemos, pero es imposible mitigar todos los riesgos, y francamente, algunas cosas simplemente no pueden preverse.

La finalidad de los testers es más el abogar por la calidad en lugar de asegurarla, no deberíamos tener problemas con ésto.

 

Por Kate Paulk

 

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

 

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