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

 

¿Qué es realmente el happy path testing?

Cuando decimos “Probemos el happy path”, ¿realmente sabemos que debemos probar?

Dependiendo de nuestra posición y entendimiento del proyecto y/o del negocio, el “Happy path” requiere de distintos elementos:

“Happy path”, para el usuario…

  • Entiende perfectamente la funcionalidad
  • Está familiarizado perfectamente con la interfaz
  • Trabaja de la manera en que la aplicación fue diseñada
  • Recuerda perfectamente todo
  • Entiende perfectamente los mensajes enviados por la aplicación (aún y cuando no haya ninguno)
  • Nunca comete errores
  • Nunca se distrae
  • Sólo ingresa información que probó estar correcta

…además “Happy path” del producto…

  • Es usado en una infraestructura y equipo en particular, donde está garantizado que funcionaría de un modo particular (Probado que funcionaría)
  • No tiene ninguna variación o fluctuación
  • Puede entenderse de un sólo modo, un modo perfecto

…creado por equipo “happy path”…

  • Entiende perfectamente el requerimiento de negocio y su propósito
  • Diseñado e implementado de una sola manera, la manera correcta

…Todo eso equivale a un caso sobresaliente
El punto es, hasta que no hayamos aprendido lo suficiente sobre los usuarios, el producto y el ambiente en que se le trabajara, no tendremos idea de cuál será el patrón principal de su uso y cuales serán las funcionalidades o características más importantes a probar. Veamos unos ejemplos

Historia #1
El instructor apunta al botón Guardar y dice “Den clic en Guardar”, veinte usuarios dan clic en el botón salvar desde sus laptops. Veinte usuarios reciben un error de timeout y se bloquean sus sesiones. El ambiente en el entrenamiento de pre-venta se vuelve pesado.

Unas pruebas de carga que incluyeran llamadas simultaneas de HTTP de veinte usuarios a la vez hubiera sido un buen escenario de happy path en este contexto, aún y cuando producto pudiera soportar más de cien usuarios trabajando a la vez(pero no simultaneamente).

 

Historia #2
En un sistema que graba documentos legales -Decisiones legales- cada letra, caracter, signo de puntuación y espacios extra debe ser grabado como en el original, o si no el documento puede ser modificado en la corte. Para horror del dueño del producto, descubieron que en algunos registros electrónicos, algunos datos no se guardaban. Después de una extensa y costosa investigación, algunos casos fueron aislados, lo que resultó fue lo siguiente: Algunas veces “menos que” se abreviava como “<“, desafortunadamente el código interpretaba el “<” como tags de xml abiertos pero no cerrados, truncando de inmediato toda esa sección.

Testing para caracteres especiales e inyecciones de html hubieran sido un escenario para este happy path, aún y cuando los usuarios de este producto(no accesible a todo público) fueran agentes empleados legales experimentados que nunca se esperaría que hicieran mal uso del producto.

 

Historia #3
Un esposo y una esposa ordenan una chequera. Sus nombres deberían aparecer impresos en los cheques como: “Mr. & Mrs. Smith”, sin embargo reciben sus cheques viéndose así:

image1

Pruebas de, por lo menos, algunos caracteres especiales en HTML y PDF hubieran sido un escenario de pruebas en este contexto de “Happy Path”, porque el uso de “&” es común hoy en día, pero es automáticamente reemplazado por un “&amp” a menos que sea manejado correctamente.

 

Historia #4
Una conversión de datos de un coma flotante de 64 bits a valor entero de 16 bits causa un overflow y una excepción de hardware; el resultado es un cohete espacial que se desestabiliza y explota.

El problema había surgido al convertir un número almacenado en algo que los programadores llaman ‘coma flotante de 64 bits’ en ‘entero de 16 bits’.

Los números de ‘coma flotante’ son otra forma de decir ‘números decimales’. Y lo que sucedió fue algo así como si al convertir el valor ‘32790,789’ en un número entero en vez de ‘32790’ el resultado fuera ‘0’, ‘-500’ o un error similar (en los números enteros de 16 bits el valor máximo es 32767).

Curiosamente esa parte del código sólo se usaba durante la preparación para el despegue; una vez en marcha no tenía utilidad. Sin embargo, como otro de esos encadenamientos de causas que suelen provocar estos catastróficos fallos ese código continuaba funcionando durante 40 segundos tras el despegue.

¿Por qué? El código provenía de los anteriores cohetes Ariane 4 donde sí se usaba, así que se mantuvo tal cual. Pero nadie pudo imaginar que ese código pudiera nunca contener otros valores tan diferentes, que fueran a provocar un ‘error de excepción de software’ ni que eso en combinación con otros sistemas de la nave provocara que los datos de vuelo fueran incorrectos y se convirtieran en órdenes capaces de modificar la trayectoria del cohete, llegando a destrozarlo en pleno vuelo.

El resultado del incidente fueron muchas lecciones aprendidas, unos 500 millones de dólares en carga perdidos y meses de desarrollo desaprovechados… a cambio de unos curiosos y carísimos ‘fuegos artificiales’.

Con esto volvemos a redefinir que es un testing de happy path y mejor pensemos en readecuar el proceso de pruebas en pos de descubrir los problemas antes que ocurran tan catastróficamente en producción.

 

¿Conclusiones?
Las metáforas pueden ser útiles, pero también podrían conducir a la confusión, falta de comunicación, o a una falacia de reificación. Muchas personas podrían, y usarán distintas terminologías, y no es trabajo de los testers hacer de policía del idioma.

Cuando se trata del “Happy path”, es labor del tester averiguar y explorar que es lo que el happy path significa en el contexto del producto y sus usuarios.

Los verdaderos usuarios tendrán un concepto distinto al tuyo de happy path.

Por Albert Gareev

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

Mob testing: Una introducción

Mob testing se trata de que todo el equipo de testing trabaje en una sola computadora, y que cada uno colabore en un esfuerzo conjunto.

Mob testing se trata de que todo el equipo de testing trabaje en una sola computadora, y que cada uno colabore en un esfuerzo conjunto.
Mobbing (Mob Programming o Mob Testing) inicia con la idea de un grupo de personas trabajando en una sola computadora, forzando a que haya un solo flujo. Por turnos, cada miembro del equipo se sienta frente a la computadora y sigue el flujo hasta que la tarea sea terminada, esta técnica hace que cada miembro trabaje en conjunto sobre un sólo estilo de navegación dentro de la aplicación.

Esto significa que quien sea que esté en el teclado(el timonel) no tendrá permitido decidir que hará con el teclado, las instrucciones vendrán del resto del equipo(los navegantes), quienes guiarán con el nivel más alto posible de abstracción. El objetivo no es que cada uno de su mejor opinión, sino entender mejor como el equipo está avanzando.

 

Nivel de abstracción, ¿Qué es eso?

Para hablar de manera eficaz mientras se navega, resulta provechoso pensar en los tres niveles abstracción:

 

  • Intención – Es el primer paso, donde explicamos lo que queremos
  • Locación – Se usa si la intención no fue suficiente como para llevar a que la acción realizada no resultara como deseamos. Por ejemplo, “Usa la búsqueda mediante un atajo desde el teclado, en vez del menú”
  • Detalles – Para explicaciones de bajo nivel de lo que queremos cuando hemos fallado en guiar las acciones en la dirección que queremos. Por ejemplo: “Teclea Ctrl + F”

 

Ejemplos de los tres niveles de abstracción

En conjunto, el grupo está intentando llevar a cabo una tarea, por ejemplo, probar la funcionalidad de búsqueda. Imagina que estás sentado frente al teclado y te han pedido que abras la aplicación para que el grupo pueda probar la funcionalidad; si eres experto en esta aplicación, probablemente podras iniciar sin mayores detalles. Este es un ejemplo de “Intención”, pero si no es suficiente, entonces habrá que recurrir a otros niveles de abstracción.

Usar el atajo del teclado en vez del menú para llegar a la funcionalidad de búsqueda es un ejemplo de “Locación”, de donde iniciar. El navegante está en control y se asegura que el trabajo se realice de la manera en que ha tenido intención, eso gracias a la información adicional que brindó al timonel.

Si el timonel nunca ha usado la aplicación pero los navegantes sí, entonces son ellos los que guiarán el curso de la sesión dando todos los detalles necesarios. Así tendríamos el tercer nivel de abstracción, “Detalles”.

El detalle de estos niveles son para tener un control del trabajo hecho con los navegantes, mientras apoyan las acciones del timonel. Cuando las palabras dichas por los navegantes hacen que las pruebas avancen de la manera en que ellos quieren, los niveles más bajos de abstracción no son necesarios.

 

Usa las palabras y no toques el teclado

Estamos acostumbrados a trasladar nuestras ideas a las acciones a través de nuestras manos, usando el teclado por ejemplo. Bajo esta practica, se remueve la conexión física y nos enfocamos en las palabras.

Cuando estas sesiones inician, es complicado encontrar las palabras adecuadas para decir. Algunos podrán no saber como decirle a las cosas que tienen en su IDE, así que buscamos las palabras que indiquen claramente que es los que queremos lograr; de igual manera, hay algunos que no están acostumbrados a escuchar pacientemente las instrucciones que alguien le intenta comunicar. Durante las sesiones de mobbing, el timonel podrá responder y sugerir nuevos métodos para avanzar, pero serán los navegantes los que tendrán el poder de decidir.

Si el timonel empieza a trabajar por su cuenta, se creará una brecha de entendimiento para varias personas en el grupo, y los navegantes se volverán revisores que intentarán interpretar las acciones tomadas por el timonel. Es importante que todos se mantengan conectados, y compartan la misma idea sobre la tarea; así mismo, la rotación de roles en lapsos de algunos minutos, promueve que todos compartan la misma idea.

 

Manos a la obra.

El grupo debe iniciar la sesión con una tarea clara. Cualquier actividad que esta sea, el primer desafío casi siempre será la comunicación.

 

Dos reglas para la comunicación en las sesiones Mob

¿Qué sucede si el grupo no está de acuerdo en como hacer algo? ¿Qué sucede si cada uno tiene una idea distinta de como realizar una tarea en particular?

 

  1. La regla “Si, y…”: El grupo trabaja en una tarea en conjunto. Cuando algo inicia, tiene que ser terminado, pero podemos agregarle acciones.

 

  1. La regla “Haz ambas…”: Si hay dos maneras de hacer algo, escuchalas, y haz ambas; empieza con la que menos te agrade, o escogela al azar; la meta es que cada opinión sea escuchada.

Cada una de estas reglas, crea acciones a realizar. ¡Dejate llevar! A medida que el grupo avanza, las cosas empezarán a trabajar de maneras que nadie pudo prever. Las acciones planeadas todavía no ocurren. Entrega el primer incremento, y hazlo lo suficientemente pequeño para que los fallos sean una opción y una oportunidad para aprender.

 

Re-examina para aprender

Independientemente de como te sientas durante y después de una sesión de mobbing, ésta deberá terminar con una retrospectiva. Habla con los miembros del grupo acerca de las observaciones sobre como trabajo el grupo, acerca de las diferentes cosas en que trabajaron y de las cosas que aprendió cada participante. No debes proyectar tus percepciones hacia las demás, sino asegurarte que cada experiencia sea escuchada, aprende de ellas y usa esa experiencia para tus futuras sesiones.

 

Obten lo mejor de cada uno en el trabajo realizado

El mecanismo de mobbing es interesante, a fin de obtener las ideas de las personas en el momento correcto, se puede sentir que otras personas no están participando mientras que otras contribuyen en la dinámica. En lugar de pensar que los miembros no vocales no están contribuyendo, deberíamos pensar en que en esos momentos están aprendiendo. Un miembro debe continuar en la sesión  siempre que esté aprendiendo o contribuyendo.

Sin embargo, siempre será necesario tener en cuenta la amabilidad, consideración y respeto. Todos los miembros de la sesión deben poder escuchar las contribuciones de todos los demás. Todas las contribuciones hechas por los miembros deben ser respetadas, sin importar si no fue provechosa en el momento en que fue hecha.

Todo lo que necesitas es un grupo de personas que compartan una computadora, todos viendo a la pantalla a la vez que trabajan en una tarea compartida. Las posibilidades de aprender de manera fortuita son interminables.

Por Maaret Pyhäjärvi

 

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

 

 

 

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

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

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

 

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

 

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

 

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

 

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

 

Beneficios esperados:

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

 

Obstaculos comunes:

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

 

Kent McDonald