Midiendo la calidad del software: Una guía práctica.

Una guía breve y práctica para medir eficazmente la calidad del software.

Advertisements

Si trabajas para una organización que produce software, la calidad del software que produces puede determinar algunas cosas importantes:

 

  • Las ganancias de la compañía para la que trabajas
  • La prioridad del proyecto o producto para el que trabajas dentro de la compañía
  • La oportunidad subir dentro de la compañía o el riesgo de ser despedido
  • Tu salario

 

Así que, la calidad importa. Sin embargo ¿Qué es calidad? En este artículo describiremos algunos aspectos de la calidad de software. Los primeros cuatro aspectos(Confiabilidad, Eficiencia, Seguridad y Mantenibilidad) son tomados del modelo CISQ; además presentamos algunas métricas incluidas en ambientes de desarrollo ágil.

Por cada aspecto de calidad de software, daremos una breve guía de como implementar esta medición en tu empresa, y así saber si tu software es de alta calidad, de otra manera tener la base para mejorarlo.

 

Aspecto # 1 de Calidad de software: Confiabilidad

Confiabilidad se refiere al nivel inherente de riesgo en un producto de software y como es que fallaría. También hace referencia a la “Estabilidad”, como la define ISO: verifica si el sistema puede mantener su funcionamiento a pesar de realizar cambios.

Un término relacionado, acuñado en años recientes, es “Resiliencia”. Este término observa el problema desde un ángulo distinto, ya que pregunta ¿Cuál es la habilidad para lidiar con un fallo?, ya que eso, el fallo, es un hecho inevitable. Por ejemplo, muchas aplicaciones hoy en día que están basadas, o contenidas, en microservicios pueden volver a ser desplegadas fácilmente, o automáticamente, en caso de un fallo, haciéndolas altamente resilientes.

¿Porqué medimos la confiabilidad? Para reducir y prevenir un mal funcionamiento o caída, además de errores que puedan afectar a los usuarios y que hagan decrecer su satisfacción. El software es mejor si no falla con frecuencia, y si un error llega a suceder, se pueda recuperar fácilmente.

¿Cómo medir la confiabilidad?

Incidencias en producción – Una buena medida de la confiabilidad de un sistema es el número de bugs con prioridad alta en producción.

Testing de confiabilidad – Pruebas comunes para confiabilidad son las de carga, qué revisa como trabaja el software cuando carga cantidades altas de información o solicitudes, y pruebas de regresión, que revisa cuantos bugs nuevos aparecieron después de realizar cambios al software. Los resultados agregados a esas pruebas, con el tiempo, pueden ser la medida para la resiliencia del software.

Evaluación de confiabilidad – Una prueba a profundidad realizada por expertos, que construyan un ambiente operacional que simule el ambiente real en el que el software trabjará. En este ambiente simulado, se probará como trabaja en una versión estable, y se esperará que crezca su contenido, por ejemplo, que aumente su número de usuarios o las entradas.

Nivel promedio de fallas – Mide el promedio de fallas por periodo entre liberaciones (o despliegues).

El tiempo medio entre fallas – Una métrica usada para medir el total de tiempo que se espera que el software esté funcionando óptimamente, hasta la siguiente gran falla.

 

Aspecto # 2 de Calidad de software: Desempeño

En el modelo CISQ, este aspecto es conocido como “Eficiencia”. Generalmente, los elementos más importantes que contribuyen al desempeño de una aplicación son: como está escrito el código, su arquitectura, y los componentes dentro de esa arquitectura (bases de datos, servidores, etc). La escalabilidad también es fundamental para el desempeño, ya que los sistemas que pueden escalar o desescalar pueden adaptarse a diferentes niveles requeridos de desempeño.

El desempeño es un punto importante en campos como el procesamiento transaccional o algorítmico, donde cantidades masivas de información necesitan ser procesadas rápidamente, y la más mínima latencia puede causar fallas significativas. Sin embargo, hoy por hoy, el desempeño se está volviendo un tema universalmente importante, ya que usuarios de aplicaciones web y móviles demandan un alto desempeño y pueden frustrarse rápidamente si un sistema no responde con la velocidad que ellos esperan.

¿Porqué medir el desempeño? Para entender el nivel de desempeño experimentado por los usuarios y como es impactado mientras lo usan, el software tiene que alcanzar y superar las expectativas.

¿Cómo medir el desempeño?

Pruebas de carga – Realizadas para entender el comportamiento del sistema bajo una cierta carga, por ejemplo, con mil usuarios concurrentes.

Pruebas de estrés – Entender la capacidad máxima del sistema.

Pruebas de estabilidad – Revisar si el sistema puede soportar cierta carga por un periodo prolongado de tiempo, y cuando es que el desempeño empieza a degradarse.

Monitoreo de desempeño de la aplicación – Es una nueva categoría de software que puede proveer métricas detalladas de desempeño desde la perspectiva del usuario.

 

Aspecto # 3 de Calidad de software: Seguridad

Seguridad, en el contexto de calidad de software, aborda el tema de como los ataques pueden vulnerar la integridad del software, irrumpiendo en su actividad o apoderándose de información sensible, ya sea por una mala codificación o una pobre arquitectura. Uno de los temas principales en seguridad son las “Vulnerabilidades”, problemas conocidos que pueden terminar en la irrupción del sistema. El número, y la severidad, de vulnerabilidades descubiertas en un sistema es un indicador importante del nivel de seguridad.

¿Porqué medir la seguridad? Cada vez más, los usuarios usan distintas aplicaciones de software para desempeñar operaciones críticas relacionadas a sus vidas personales y/o negocios. El software es mejor si es menos vulnerable a las fallas de seguridad, en realidad, es mejor si no sufre de vulnerabilidades de seguridad.

¿Cómo medir la seguridad?

Número de vulnerabilidades – Es posible escanear aplicaciones de software para identificar vulnerabilidades conocidas. El número de vulnerabilidades encontradas es una buena medida(negativa) para medir la seguridad.

Tiempo de resolución – ¿Cuánto tiempo desde que la vulnerabilidad fue encontrada en el software hasta que la solución fue liberada?

Despliegue de actualizaciones de seguridad – Para software desplegado en los equipos de los usuarios, ¿Cuántos usuarios realmente instalaron el parche o actualización de seguridad?

Incidentes reales de seguridad, severidad y tiempo total del ataque – ¿Cuántas veces el sistema fue vulnerado? ¿Qué tanto afectó a los usuarios el ataque? ¿Y por cuánto tiempo?

 

Aspecto # 4 de Calidad de software: Mantenibilidad y Calidad de código

Mantenibilidad de software se refiere a la facilidad con que el software puede ser adaptado a otros propósitos, que tan portable es entre ambientes, y si es transportable de un equipo de desarrollo a otro. Mantenibilidad está íntimamente relacionado con calidad de código, si el código es de alta calidad, el software será más fácil de mantener.

La calidad de código es difícil de definir, pero la mayoría de los expertos están de acuerdo que la calidad de código reside en los siguientes puntos: seguimiento de convenciones de codificación, legibilidad y que esté bien documentado; que sea reusable y evite la duplicación; que maneje los errores diligentemente, que sea eficiente en el uso de recursos, incluya pruebas unitarias, y se adhiera a las mejores prácticas de seguridad.

¿Porqué medir la mantenibilidad y calidad de código? Este aspecto de la calidad de software es más significante para la empresa que desarrolla el software, e indirectamente afecta a los usuarios. Se produce un mejor software si es mantenible ya que tomará menos tiempo y costo el adaptarlo a los cambiantes requerimientos de los usuarios. El software que es mantenible y tiene una alta calidad de código, es más propicio a mejorar su confiabilidad, desempeño y seguridad.

¿Cómo medir la mantenibilidad y la calidad de código?

Líneas de código – Esta es una métrica muy sencilla que impacta en la mantenibilidad del sistema. Entre más líneas tenga de código tenga el software, más difícil será de mantenerlo y más probable a tener problemas de calidad de código.  La siguiente imagen muestra líneas de código de varios frameworks de PHP, usando varias técnicas de medida.

  • LOC Hace un conteo global de las líneas de código y objetos desarrollados, y las enlista por clases, métodos, funciones, constantes, y directorios y archivos
  • CLOC Hace un conteo de líneas de código en el desarrollo, además de dar información de en que lenguaje está escrito, hace un conteo de cuantos archivos están corresponden a cada lenguaje, cuantas líneas están en blanco, cuantas corresponden a comentarios, cuantas son de código
  • NCLOC Determina el total de líneas de código fuente que no son comentadas
  • LLOC Es el número de declaraciones lógicas en el código, también se le conoce como Líneas de código efectivas

Análisis estático de código – La examinación automática de código identifica y asegura que el código se adhiera a los estándares de la industria. El análisis estático es hecho directamente en el código sin siquiera haber ejecutado el software.

Métricas de complejidad de software – Hay distintas maneras de medir que tan complejo es el software, tales como Complejidad ciclomática y complejidad algorítmica. Entre más complejo sea el código, más complejo será su mantenibilidad.

 

Aspecto # 5 de Calidad de software: Ritmo de entrega

En desarrollos ágil, las nuevas iteraciones de software se entregan más rápido a los usuarios. Muchas organizaciones liberan nuevas versiones de su software cada semana, día o incluso varias veces en un mismo día, este proceso es conocido como “Integración Continua”, o en su versión extrema “Desarrollo Continuo”, donde cada cambio hecho al software es enviado inmediatamente a producción.

El ritmo de entrega de software está relacionado a la calidad porque se espere que una nueva versión de software contiene mejoras que pueden impactar al usuario. Entre mayor sea la frecuencia de liberaciones al usuario, debería, en teoría, significar que el usuario obtiene mejor software más rápidamente.

¿Cómo medir el ritmo de liberación de software?

Número de salidas a producción – Esta es una medida básica que determina que tan frecuentemente el software es entregado a los usuarios.

El número de historias de usuario que son terminadas cada cierto tiempo – Contando el número de historias, o requerimientos, que son enviados a producción, provee un medida granular del ritmo de entrega.

Consumo de releases por los usuarios – Por ejemplo, medir el número de usuarios que descargan o instalan un nuevo parche o actualización de software.

Publicado por Sealights

 

“Testing nos está retrasando”, pasar de la culpa al involucramiento y compromiso

¿Realmente los esfuerzos de testing están restrasado el avance del proyecto?, ¿Sabemos detectar las causas reales?

“Testing nos está retrasando”

“¿Porqué están apareciendo todos esos defectos al final del proyecto?”

“Los testers deberían estar probando casos extremos siempre”

 

No conozco a muchos testers experimentados que no hayan escuchado alguno de los reclamos citados anteriormente, tal vez todos.

Este post reúne lo que resultaron ser las causas de raíz cuando la parte de negocios o administración creyeron que testing retrasaba el proyecto; además de las tácticas que se usaron para cambiar esa narrativa.

 

Las causas pudieron ser:

  • Que las estimaciones del proyecto no tomaron en cuenta los riesgos de testing mientras se planeaban las actividades
  • Que en la planeación del proyecto se desestimó el impacto de la integración con componentes de terceros
  • Que algunos de los riesgos están ocurriendo y la planeación debe ser inspeccionada y adaptada
  • Que testers y desarrolladores no trabajan bajo una estructura multifuncional
  • Que aún y en una estructura multifuncional, los desarrolladores no ayudan en los cuellos de botella de testing, y usualmente terminan tomando otro ítem del backlog
  • Qué el código está padeciendo por una deuda técnica
  • Que no se evaluó la deuda técnica y se culpó a los errores encontrados
  • Que no se tienen pruebas automatizadas para realizar regresiones puntuales
  • Que se antepone la cobertura de las pruebas automatizadas sobre la estabilidad
  • Que se tienen dependencias con IT Ops para poder completar las definiciones de Hecho
  • Que los testers no tienen permitido interactuar directamente con los tomadores de decisiones o usuarios finales
  • Que los testers no pueden articular su enfoque de pruebas

 

¿Cómo podemos cambiar este panorama?

La narrativa debe de cambiar de “Culpa” a “Involucramiento”

Es necesario involucrar a los testers al juego, a actividades en las que usualmente no están involucrados, escuchar su retroalimentación y apoyarlos en cumplir con sus objetivos e implementar sus ideas.

 

Es necesario involucrar (más) a los testers en:

  • Las discusiones para elegir proveedores(de software, herramientas, servicios, etc)
  • Las discusiones al elegir una solución
  • Las discusiones al diseñar la solución de una arquitectura
  • Administrar ambientes de prueba
  • En ejecutar las pruebas en producción
  • Definir el alcance de la planeación del proyecto
  • Hablar directamente con los usuarios finales
  • Ampliando las responsabilidades del equipo para la automatización de pruebas
  • Determinar estándares de código con el resto del equipo
  • Diseñar las revisiones técnicas

 

 

Comprometerse e interactuar (más) con los testers en

  • Diseñar pruebas
  • Dar retroalimentación sobre la cobertura de pruebas y el enfoque
  • Revisar el código de las pruebas automatizadas
  • Dar seguimiento al enfoque de pruebas
  • Dar retroalimentación de como pueden mejorarse las pruebas
  • Responsabilizarse de la calidad
  • Apremiar al resto del equipo en seguir los estándares de calidad propuestos por el equipo de pruebas

 

Por thereluctanttester

 

Seis temas que terminan mal cuando se discute sobre testing

Discutir sobre testing no es sencillo y pueden resultar peor cuando se abordan ciertos temas.

No es sencillo hablar sobre pruebas de software. No es natural, testing es una actividad “meta”; no es sólo una tarea, pero genera muchas tareas(al encontrar bugs que deben ser solucionados o al encontrar nuevos riesgos que deben ser examinados). Es una tarea que nunca podrá ser “completada”, y aún así debe “acabarse”.

La confusión que provoca testing, lleva a conversaciones nada efectivas que terminan enfocándose en temas sin importancia mientras se ignoran las cosas que realmente importan. Aquí hay unos ejemplos específicos de como estas conversaciones fallan.

  1. Cuando las personas se interesan más en cuantos casos de prueba de ejecutaron en vez de que es lo que hace la prueba. El número de casos de prueba(500, 1000 76135768941) no le dice a nadie nada sobre “cuanto testing” estás haciendo. La razón de porque los desarrolladores no presumen cuantos archivos crearon, es porque todo mundo sabe que es ridículo contar archivos, o líneas de código, o cualquier otra cosa relacionada; por esa misma razón es ridículo contar los casos de prueba. La misma actividad de una prueba puede representarse tanto en un caso de prueba como en mil. Si un tester desarrolla una aplicación que genere 100,000 variaciones de un sólo caso de uso, ¿son realmente 100,000 casos de prueba?, ¿sólo uno muy grande? o tal vez no es un caso de prueba como tal. La próxima vez que alguien te de la cuenta del total de casos de prueba, practica diciendo “Eso no me dice absolutamente nada”. Después haz las preguntas que importan: ¿qué cubren esos casos de prueba? ¿qué defectos pueden detectar? ¿cuáles fueron los riesgos que tratan de cubrir?
  1. Cuando las personas se refieren a las pruebas como un objeto en vez de un evento. Una prueba no es un objeto físico, aún y cuando haya cosas físicas como documentación, datos, o código como parte de las pruebas. Una prueba es ejecución, una actividad, es algo que haces. Cuando se habla de pruebas como un objeto en lugar de una ejecución, se olvidan las partes más importantes de una prueba: la atención, motivación, integridad y habilidad del tester. Dos testers distintos no podrán realizar “la misma prueba” de “la misma manera” de ninguna forma. Tecnicamente, no puedes entregar un caso de prueba a alguien más sin que el resultado de la prueba cambie de alguna manera(así como un jugador no podría hacer la misma jugada de la misma manera dos veces), aún y cuando los cambios no sean necesariamente importantes.
  1. Cuando las personas no pueden describir su estrategia de pruebas a medida que evoluciona. La estrategia de pruebas es un conjunto de ideas que guian tus opciones sobre que pruebas diseñar y que pruebas ejecutar en cualquier situación. La estrategia de pruebas también puede ser llamado el razonamiento detras de las acciones que forman cada prueba. La estrategia de pruebas es la respuesta a preguntas tales como ¿cuál es el valor de hacer esas pruebas?, ¿porqué no hacemos otras pruebas?, ¿qué debemos cambiar si queremos hacer pruebas más profundas?, ¿qué debemos cambiar si queremos hacer pruebas más rápido?, ¿porqué estamos haciendo pruebas de esta manera?, esas preguntas no surgen justo después de probar, sino al mismo tiempo que inicia el proceso. La habilidad para diseñar y discutir una estrategia de pruebas, es el sello de unas pruebas profesionales, de otra manera, testing sólo sería una cuestión de hábitos e intuición.
  1. Cuando las personas hablan como si automatización hace pruebas como si fuera un humano. Si los desarrolladores hablaran de desarrollo de la misma manera en que muchas personas hablan de testing, se diría que es el compilador el que hace todo el trabajo, y su único trabajo fuera operar el compilador. Dirían que el producto fue creado “automáticamente” en vez de hablar de la gente que trabajo arduamente en escribir el código, siguiendo esa línea, la administración se obsesionaría con “automatizar desarrollo” y empezaría a conseguir mejores herramientas en lugar de contratar y entrenar excelentes desarrolladores. Una mejor manera de hablar de testing, es hablar como hablamos de desarrollo: “Es algo que realizan las personas, no las herramientas; las herramientas ayudan, pero las herramientas no hacen pruebas”. No hay tal cosa como testing automatizado, lo más que puede hacer una herramienta es operar un producto tal como se lo dicta un script y revisar puntos específicos. Eso no sería una prueba, sino una revisión del producto. Las herramientas son excelentes para hacer revisiones, pero testing es mucho más que revisar, los testers deben usar un juicio técnico a la vez que muestran un poco de ingenuidad para crear esas revisiones, para luego ser evaluadas, actualizadas y mejoradas. El nombre para todo ese proceso humano(apoyado por herramientas) es testing. Cuando te enfocas en “pruebas automatizadas” dejas de enfocarte en las habilidades de juicio, de resolución de problemas, y de motivación que son las que realmente controlan la calidad de testing. Como resultado dejas de prestar importancia a los factores que realmente controlan la calidad de testing.
  1. Cuando se habla como si sólo hubiera un tipo de cobertura de pruebas. Hay muchas maneras de cubrir un producto cuando se prueba. Cada método es diferente y tiene sus propias dinámicas, no hay manera que usando sólo uno (por ejemplo, cobertura de código) nos de un panorama completo de la historia. Tomemos el siguiente ejemplo, si estás probando una página que arroje resultados de búsqueda, acabas de hacer una cobertura de funcionalidad, y acabas de cubrirla usando cierto tipo de datos(cobertura de datos); si cambias los parámetros de búsqueda por otros, acabas de realizar una nueva cobertura funcional, lo mismo pasa si cambias los datos, y de cualquier forma podrás encontrar un nuevo bug con cada cobertura. Las funcionalidades interactúan con los datos, así que un buen testing involucra cobertura no de una manera u otra, sino que también con diferentes combinaciones.
  1. Cuando las personas hablan de testing como si fuera una tarea estática que puede ser formalizada facilmente. Testing es una tarea de aprendizaje, que es fundamental aprender. Si me dices que estás realizando pruebas, pero que no estás aprendiendo nada, entonces te diré que no estás probando nada. La naturaleza de cualquier aprendizaje es que nunca sabrás que es lo que vas a descubrir, es una empresa exploratoria; de la misma manera que sucede con muchas otras cosas de la vida, desde manejar un carro hasta administrar una compañía. Hay cosas que podemos predecir que podrían ocurrir y patrones que podemos usar para organizar nuestras acciones, pero nada de eso significa que podamos guiarnos ciegamente siguiendo los pasos que dictan un script. Realizar pruebas significa cuestionar continuamente lo que hacemos y lo que vemos. El proceso del testing profesional no es diseñar casos de prueba y luego seguirlos; no hay tester responsable que trabaje de esta manera, el testing responsable es un proceso constante de investigación y de experimentar diseños. Esto podría involucrar el diseño de procedimientos y automatización que sistemáticamente recolecte datos sobre el producto, todo eso debe ser hecho con el entendimiento de que respondemos a como se vayan presentando las situaciones. Frecuentemente nos desviamos de los procedimientos que establecemos porque el software es complicado y sorpresivo; y porque nuestras empresas tienen necesidades de entrega que debemos satisfacer; y porque aprendemos mejores métodos de testing a medida que avanzamos.

 

Con esas, y tantas otras, conversaciones fallidas sobre testing, muchas personas siguen con la idea de que testing se trata sólo sobre escribir y escribir casos de prueba (sin importar lo que hagan), automatizarlos (sin importar que es lo que no hace automatización), pasarlos de un tester sin experiencia a otro, todo eso mientras los casos de prueba y scripts son fetichizado en lugar de ver que es lo que hacen los testers con ellos cada día.

 

 

Por James Bach

4 estrategias para crear un proceso de QA estructurado

El rol de tester está evolucionando junto con la industria de la tecnología y su adhesión a las metodologías agil. Esta transición abre oportunidades inexploradas, emocionantes y desafiantes para todo tester.

El rol de tester está evolucionando junto con la industria de la tecnología y su adhesión a las metodologías agil. Esta transición abre oportunidades inexploradas, emocionantes y desafiantes para todo tester.

 

Las viejas formas: Sólo encontrar defectos

En mis primeros años como tester poco me preocupaba por el pensamiento crítico. Cada mañana el equipo de testing nos daba una lista de aplicaciones a revisar, el recurso asignado instalaba las aplicaciones e intentaba romper su funcionalidad.

Nuestros análisis de desempeño eran simples: ¡Entre más bugs encontráramos, más inteligentes eramos! Sin análisis, sin estrategia, sin motivación. En nuestros descansos las discusiones giraban en torno al número de bugs encontrados, en lugar de discutir la calidad de estos bugs.

Eso me puso a pensar, ¿Qué valor estamos agregando? ¿Deberíamos probar sólo para encontrar defectos? Tenía muchas preguntas sin respuesta.

 

Desarrollando un proceso de QA

Mi siguiente empleo lo cambió todo. Como parte de las pruebas de una funcionalidad, el equipo de QA también debuggeaba, analizaba el track trace, y proveía la causa raíz del error cuando reportaba a los desarrolladores. Fue vigorizante ver a cada uno de los miembros colaborar como un equipo con un sólo propósito.

Me di cuenta que las tareas de un tester no eran actividades individuales para romper la aplicación, pero más las de un miembro de un equipo contribuyendo al esfuerzo común. A medida que los testers iban cambiando de equipos, empezamos a priorizar la mejora continua de la automatización y el conocimiento profundo de cada componente. Desarrollé una perspectiva totalmente diferente sobre QA, además de un gran respeto por todo el valor que proporcionaba este rol.

Cuando cambié de posición, me emparejaron con un arquitecto de QA. Nunca imaginé que esa mentoría tendría un impacto tan grande y duradero en mi. Me di cuenta de la importancia dar un seguimiento estructurado a QA; con la ayuda de este arquitecto, afiné y perfeccioné cuatro estrategias para mejorar el proceso de QA.

 

  1. Revisa los documentos de diseño y arquitectura

Siempre será una buena idea tener tanto conocimiento como se pueda sobre el producto que está siendo probado, si los documentos de arquitectura y diseño están disponibles para revisarse, dales una leída. Te sorprenderás de cuanto puedes entender del producto sabiendo su arquitectura, los componentes integrados, y del flujo de información que del solo hecho de probar. Toma notas y traza diagramas de como funcionan tus pruebas en paralelo y de cómo interactúa el sistema.

 

  1. Investiga defectos pasados

El pasado informa al presente. Es importante conocer las áreas riesgosas y las funcionalidades más susceptibles a fallar en cada modificación. Ese tipo de información puede provenir de la historia de los defectos.

Lleva a cabo una investigación en tu gestor de defectos y analiza los defectos que han sido reportados anteriormente. Cualquier patrón predecible que provenga de este análisis ayudará a automatizar esas áreas, también incluye los defectos que son reportados por los usuarios o clientes. Este ejercicio te ayudará a tomar decisiones sobre la estrategia a seguir en la mayoría de los releases.

 

  1. Triangula los defectos

QA encuentra un defecto y se reporta, pero el trabajo no termina ahí, hay que ir más allá y hacer algunas otras preguntas importantes. ¿Hay algo más que pudiste haber hecho?, ¿Sabes porqué ocurrió ese defecto?, ¿Qué lo causó?, y ¿Qué cambio en el código pudo haber causado el problema?

Ésto no es trabajo exclusivo de los desarrolladores. Tienes acceso al log, a los releases y al código, así que se puede excavar por información que ayude a resolver esos problemas. Dependiendo en que tan técnico seas, puedes profundizar tanto como puedas. Pero si estás en un alto nivel, mira en las excepciones en el log. ¿Hay un null pointer?, ¿Tiene que ver especificamente con tus datos o con alguna secuencia de pasos?

Delimita el problema y empieza una conversación con el equipo de desarrollo, sabrán apreciar la información detallada y la investigación.

 

  1. Ve más allá del defecto reportado

No te enfoques sólo en las pruebas de funcionalidad. Piensa también en como el back-end y el front-end interactúan con tu aplicación.

Por ejemplo, mientras revisas el log de pruebas, podrás darte cuenta que tal vez la aplicación esté funcionando correctamente, algunos errores están ocurriendo en el back-end. Aquí podrás preguntarte, ¿Son los logs lo suficientemente detallados?, ¿Se están manejando correctamente las excepciones?. Cuando pruebas aplicaciones web, abre las herramientas de desarrollador en el navegador y monitorea los componentes de red, ¿las respuestas están tomando más tiempo del debido? ¿Hay algún request que no está siendo llamado cuando se accede a la aplicación?

Todas esas preguntas permitirán al tester a ir más allá de lo que tiene asignado. También motivará discusiones con el dueño del producto y los desarrolladores al encontrar escenarios que no habían sido pensados.

Es vital tener una mentalidad ágil al momento de buscar y reparar discrepancias en el producto. Una enseñanza clave en testing es ser proactivo. Los bugs que descubres de esta manera pueden volverse historias técnicas, que de no haberse prevenido hubieran pasado desapercibidas y volverse en un error muy serio mucho más adelante.

 

Vuélvete el propietario de la calidad

Ser un tester de software ya no se trata sólo de encontrar defectos y de romper la aplicación; ahora se trata de la mejora continua, de definir una estrategia de pruebas, y de ir un paso más allá para mejorar la calidad.  Seguir un proceso estructurado y consistente de QA te ayudará a adquirir más conocimiento del producto que estás probando, a hacer las preguntas que de otra forma no te hubieras hecho, y al final, volverte en el propietario verdadero de calidad.

 

Por Praveena Ramakrishnan

 

 

 

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,

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

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.