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

Conclusión de la lista que iniciamos aquí:

 

  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

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