Siguenos en:

jueves, 12 de mayo de 2016

Someto a la aprobación de la sociedad de la media noche, esta historia a la que llamo. . . . . . . . . El bug



La semana pasada se celebro el STAR East (Software Testing Analysis and Review East) y dos de las sesiones que más llamaron mi atención estuvieron relacionadas con las historias de testing, charlas impartidas por Isabel Evans y Jennifer Bonine.

Los reportes de bugs son para los testers la forma principal de comunicación, pero, ¿Qué tan efectivos son nuestros reportes? Al final de cuentas esta comunicación es en la que se basa la colaboración ya que de los reportes, se desencadenan preguntas como ¿Es un bug? ¿Lo vamos a resolver? ¿Cómo lo resolvemos?

Para quienes entiendan la referencia del título, así es como se inician las historias de terror, y es que con el tiempo me he dado cuenta, que si las historias de testing, son de terror, es más sencillo que se involucren todos los stakeholders. No es lo mismo reportar:

a)   Error de validaciones en login (con sus respectivos detalles)

A reportar

b)   Es posible ingresar a la cuenta de otros usuarios sin conocer su contraseña poniendo en riesgo la integridad y confidencialidad de la información (con sus respectivos detalles)

Si los reportes son técnicos, las cosas pueden minimizarse, debemos recordar que es importante alertar a los involucrados cuando es necesario.
Un ejemplo sencillo que se mencionó en una de las charlas fue la forma en que la tripulación se asegura que los pasajeros encargados de la puerta de emergencia hayan leído las instrucciones con detenimiento. 
La pregunta general es:

a)   ¿Ha leído usted los pasos necesarios para abrir la puerta de emergencia en caso de incidente?

Pregunta que muchos de nosotros contestamos afirmativamente cuando en ocasiones puede no ser verdad, pero ¿qué pasaría si en lugar de esa pregunta se hace la siguiente?

b)   ¿Está usted preparado para abrir la puerta la puerta de emergencia que lo salvará a usted y a los otros 180 pasajeros en este vuelo en caso de un accidente?

La forma en la que la historia se cuenta, es fundamental para que los demás se involucren. Es común que un reporte tenga distintas secciones, en mi opinión, un buen reporte de bug, debe poder responder ciertas preguntas, las plantillas, los estándares pueden omitirse si se tiene la responsabilidad de que estas preguntas puedan responderse dentro de las cuales debe estar:

¿Y si no lo resolvemos?

Esta es justo la pregunta a la que me refiero. No todas las historias deben ser de terror, pero si aquellas en las que como testers creemos que se debe poner énfasis, la priorización de actividades y riesgos es fundamental para elegir nuestras historias.


Para ustedes ¿Qué tan común es que el reporte de bug que escriben/resuelven pueda contestar esta pregunta?

viernes, 30 de enero de 2015

¿Cómo saber si estas probando bien?





Se me ha enseñado a ver el testing como un proceso infinito, “Las pruebas exhaustivas son imposibles”, “No existe software libre de errores” y “Las pruebas son dependientes del contexto” son 3 de los 7 principios de las pruebas de software diseñados por ISTQB.

Entender el testing como un proceso que lejos de terminarse, es suspendido, puede causar cierta incertidumbre en que tan bien estamos haciéndolo, a continuación listo algunas de las lecciones y los indicadores que me ayudan a saber si estoy probando bien.

Confías en tu equipo de pruebas: Tu equipo tiene la experiencia y el conocimiento adecuado para probar algo, tienen conocimiento tanto del dominio en el que el sistema se desenvuelve, como de aspectos técnicos que los apoyan en las pruebas no funcionales, recordemos: Un tester sólo puede probar lo que conoce.

Tienes muchas preguntas: La curiosidad es el alma del testing, utiliza el pensamiento crítico para cuestionar y evaluar todos los elementos con los que estas trabajando.

Te encuentras a ti mismo en situaciones que no habías pensado antes: De pronto te das cuenta que acabas de encontrar como es que se creó el calendario romano, qué idiomas se hablan en américa latina, como funciona la encriptación asimétrica, el tamaño máximo de un archivo permitido en distintos sistemas operativos entre otras…

Big Bugs: Más que la cantidad de incidencias reportadas, es importante evaluar qué tipo de escenarios estamos reportando, si tus reportes son de alta relevancia en la calidad del producto, es que los esfuerzos se están canalizando de manera adecuada.

Te juzgan de loco: Las pruebas comienzan a tornarse un poco “locas” al incluir escenarios que pudieran sonar poco probables para algunos, tal vez quieras echar un vistazo a la priorización de tus pruebas y ejecutar primero las que sean más probables, pero también son importantes los escenarios “raros”, recordemos que: El pensamiento lateral es el arma fundamental de un tester.

Estás orgulloso de lo que vas a liberar: Las pruebas ayudan a tener una visión amplia de la calidad del producto, los testers deberán estar orgullosos de lo que están liberando, de lo contrario, no se estará agregando confianza al producto o servicio.

Estas aprendiendo: El contexto es una parte fundamental del testing, se debe ver al testing como un proceso multidisciplinario en el que cada sistema traerá consigo el reto de aprender sobre algún tema nuevo.

Te estas divirtiendo: Si no te estás divirtiendo en testing, es que no es para ti, o no lo estás haciendo bien, así que ¡Disfrútalo!


¿Te ha pasado?

jueves, 19 de junio de 2014

Testeando el mundo

Muchos sabemos de unas cuantas características que todo tester debería tener, por ejemplo, curiosidad, creatividad, pensamiento crítico, pensamiento lateral, etc. Y esas características nos ayudan a generar ideas sobre cómo poner a prueba aplicaciones o sistemas, permitiéndonos dar en nuestro trabajo un desempeño, como mínimo, aceptable.

Pero ¿qué pasa cuando se aplican esas características en la vida diaria? ¿En acciones o conversaciones cotidianas? Eso me pasa a mí y puedo ver que le sucede a otros testers. Y no es algo que yo elijo hacer (al menos proactivamente), y yo diría que los demás tampoco.

Muchas personas, sin ser testers, tienen algunas de éstas características, pero el enfoque organizado de estos atributos, que se adquiere al entrenarse en testing, ha hecho que se conviertan en herramientas de la vida diaria.

 Esto da como resultado poder tener una conversación interesante de prácticamente cualquier tema, aun si es algo absurdo. Provoca siempre estar receptivo a inconsistencias o anomalías en cualquier lugar: un supermercado, un libro, una tienda de ropa, hasta los vicios de lenguaje al interactuar con la gente. Hace que te tomes un segundo más para decidir o combinar cosas de una manera diferente a la tradicional y así generas hilos de pensamiento extraños, que no sabes a dónde van a llegar o si serán de utilidad, el único propósito es explorarlos.


Entonces, cuando sucede esto, exactamente ¿qué significa? Puede haber muchas respuestas, pero para mí demuestra que el testing tal vez no es sólo un trabajo, sino una manera de aproximarte a tu entorno. 

Creo que si estás un poco de acuerdo con ésto, tal vez tienes el mejor trabajo en testing que puede haber. ¿Cierto?

martes, 10 de junio de 2014

Tienes el mejor trabajo en testing que puede haber


El siguiente es un post inspirado en un post de Eric Jacobson, inspirado en un post de Michael Bolton, si, así de poco original soy.

Sin embargo me pareció relevante escribir al respecto ya que se habla del puesto perfecto en testing, y de cómo puede ser tuyo sin que aun te enteres.

Todos sabemos que el objetivo principal de las pruebas de software es el de encontrar fallas o defectos, sin embargo, ¿Será esto lo que realmente motiva a un tester?


En lo personal a mí no me motiva encontrar un defecto, reportarlo, discutirlo y que resulte que no se hará nada al respecto. La motivación viene de otras fuentes como lo es ver que en realidad se está mejorando un sistema, es claro que nunca tendremos un sistema que no falla, pero personalmente encuentro motivación en que al final de cada proyecto, el equipo de testing tiene una lista de formas en las que el sistema fallaba y nos aseguramos que al menos, no lo hace de la misma manera.

Impulsar iniciativas, desafiar el status quo, desenvolverse como profesional en medio del caos, discusiones, debates, procesos pobres, incertidumbre, técnicas de pruebas desconocidas. . . . para mi suena como el área de juegos de un tester.

En poco tiempo he aprendido a disfrutar de mi trabajo, hacer pequeños cambios, mejorar la colaboración entre desarrolladores y testers, todo gracias estos factores antes mencionados que no son otra cosa sino los mejores entrenadores que un tester pueda tener.

Así que hace poco descubrí que tengo el mejor puesto de testing que puede haber y probablemente ustedes también lo tengan.

Espero puedan compartir sus comentarios al respecto.


viernes, 24 de enero de 2014

¿Cómo va el testing en el mundo?


 Desde 2009 Capgemini, Sogeti y HP se han encargado de llevar a cabo un estudio de investigación global sobre las prácticas y tendencias relacionadas a la calidad de software en el mundo, en Septiembre del año pasado publicaron la quinta versión de esta investigación la cual contiene algunos datos que me parecieron interesantes y me gustaría compartir:
·         La inversión del presupuesto de TI en las organizaciones aumento en el área de pruebas de software de un 18% a un 23%, este crecimiento ha sido continuo y se espera que para 2015 sea de aproximadamente 28%.
·         Las pruebas de software centralizadas en un mismo equipo y proceso en las organizaciones subieron de ser un 8% en 2012 a un 26% en 2013.
·         Los ambientes de pruebas crecen, la mayoría de las organizaciones invierte en ambientes permanentes (63%) o temporales (25%) que apoyen a la ejecución de pruebas en un ambiente controlado.  
·         Crecimiento significativo en testing de aplicaciones móviles, principalmente en el área de seguridad, lo que el reporte adjudica a la reciente evolución de aplicaciones móviles ya dedicadas a las transacciones centrales de muchas organizaciones y dejar de lado aplicaciones meramente informativas.
·         La nube está bajando, los servicios y aplicaciones instalados en la nube bajo en porcentaje, personalmente me parece que el “cloud computing” seguirá creciendo aunque en un porcentaje menor ya que considero que acaba de entrar en una fase donde dejo de ser novedad y está siendo utilizado sólo por quienes ya entendieron sus ventajas y desventajas.
·         Testing sigue llegando tarde, y es que cerca de 45% de las empresas encuestadas involucran a testing hasta que la fase de codificación está terminada, lo que ocasiona un decrecimiento  en la influencia que esta fase pueda tener sobre la calidad de la aplicación construida.
Dentro de los países con más participación en el estudio se encuentran: Estados Unidos, Brasil, Holanda, Inglaterra, Suecia y Australia, entre otros con un total de 1500 entrevistas a distintos roles en la organización.
¿Cómo creen que le vaya a México en comparación? El trabajo de testing deberá estar enfocado en romper algunos de los paradigmas con esfuerzos de transformación, los invito a que le den un vistazo a las recomendaciones generales de estas organizaciones y compartan sus comentarios al respecto.

martes, 5 de noviembre de 2013

¿Cualquiera puede ser un tester?


Cocinar, como cualquier actividad requiere de habilidades, experiencia y talento. La película Ratatouille relata la historia de cómo una rata se convierte en chef, y una de las frases más recurrentes de la película es: “Cualquiera puede cocinar”.
A continuación una cita de la película donde un conocido crítico opina sobre la idea de una rata cocinando:
 “Una extraordinaria cena de una fuente singular e inesperada, decir solo que la comida y su creador han desafiado mis prejuicios sobre la buena comida, subestimaría la realidad. . . . .Al fin me doy cuenta de lo que quiso decir en realidad. No cualquiera puede convertirse en un gran artista, pero un gran artista puede provenir de cualquier lado”.
Volviendo a la idea, me pregunto: ¿Cualquiera puede ser un tester?
Personalmente, veo al testing como una actividad similar a la cocina, con requisitos de habilidades, experiencia, conocimiento y talento, sin embargo, mientras que las competencias, conocimiento podrán irse adquiriendo mientras una persona se desenvuelve en el rol, creo que existen ciertas habilidades que cualquier persona (sin importar su formación académica) puede tener para convertirse en un gran tester. Habilidades como la curiosidad, creatividad y el pensamiento lateral deberán ser fundamentales para el rol.
De esta manera creo que efectivamente cualquiera puede ser un tester, pero al igual que para cocinar, “No cualquiera puede convertirse en un tester, pero un tester puede provenir de cualquier lado
¿Tú qué opinas?

jueves, 24 de octubre de 2013

El testing solo da problemas

Es cierto, ¿o no? Alguna vez, como tester, ¿te has preguntado o has pensado cuál es tu función en su sentido más básico? Algunos dirían romper software (que personalmente creo que ya está roto desde el principio, en mayor o menor medida), otros dirían que nuestro trabajo es romper ilusiones (demostrar que no funciona, cuando se supondría que sí), acerca del producto que se prueba. ¿No es cierto también que parte de nuestro trabajo es encontrar problemas?, problemas que podrían afectar a nuestros usuarios o hacer que disminuya el valor del producto que se prueba.

Una de las definiciones de la palabra problema, la cual creo encaja muy bien en este contexto, es: Conjunto de hechos o circunstancias que dificultan la consecución de algún fin.Así pues ¿de qué sirven los problemas que encuentra un equipo de pruebas? ¿No son esos problemas revelados con el fin de evitar que los usuarios enfrenten esas dificultades para lograr sus fines? En ese sentido me gusta pensar acerca del tester como una especie de héroe de los usuarios, salvándolos de los problemas, al menos de tantos como nos sea posible.

Pero los problemas o bugs que se revelan en algún proyecto, no solo representan un problema al que un usuario podría enfrentarse. También pueden representar un problema para el desarrollo de dicho proyecto. No siempre es así ya que se puede contemplar una parte del desarrollo del proyecto a corregir bugs. Pero ¿qué pasa cuando los problemas descubiertos en el código sobrepasan el tiempo calculado? Cuando el proyecto se retrasa y las fechas de entrega se acercan. Si consideramos que un proyecto en retraso es un problema, y que los problemas que el equipo de pruebas encuentra están retrasando el proyecto, entonces podemos decir que el testing da problemas al proyecto. Lo interesante de esta situación es que si los bugs o problemas revelados no hubieran sido descubiertos por el equipo de pruebas, seguramente los usuarios los descubrirían, lo cual impactaría negativamente en la reputación y valor de cualquier producto de software y no solo de un producto sino hasta de una organización. Es aquí donde se evalúa qué representa más riesgo, si entregar el producto como está o invertir más tiempo desarrollándolo para mantener al mínimo posible los errores y retrasar más su salida.


Entonces, ¿es malo para un equipo de pruebas solo generar problemas? Más que generar problemas yo lo veo como ayudar a que los problemas se resuelvan. Para solucionar un problema el primer paso es reconocerlo o identificarlo y creo que esa es una de las aportaciones más importantes que un equipo de pruebas hace, al contribuir como parte de un equipo más grande, al desarrollo de un proyecto.