Prueba tus conocimientos sobre pruebas con el Atlassian QA Challenge

Hoy he encontrado el Atlassian QA Challenge en este post durante mi revisión matutina de feeds; y me ha encantado el reto. La empresa detrás de JIRA y Confluence proponen unos cuantos ejercicios para entrenar tus habilidades en pruebas de seguridad.

En el primer ejercicio tendrás que vulnerar un formulario de inicio de sesión y autenticarte en el sistema.  Tras completar este primer ejercicio estarás ansios@ de probar tus habilidades en el resto de retos!

atlassian qa challenge

Informe mundial de Calidad 2013-2014

Hace unos meses me ofrecieron la oportunidad de participar en la encuesta sobre Calidad que lleva a cabo Cap Gemini, Sogeti y HP y me parecieron interesantes muchos de los aspectos en los que ésta profundizaba. Hace unos días revisé los resultados de la encuesta anterior (2013-2014) y los resultados muestran un escenario positivo para el mundo del testing. A continuación podéis encontrar los aspectos más destacados de los resultados de la encuesta y una infografía muy interesante.

  • Las funciones de QA se están volviendo más maduras estructuralmente. La cantidad de organizaciones con una TCOE totalmente funcional aumentaron del 6% en 2012 al 19% en 2013
  • Las organizaciones siguen aumentando la proporción de su presupuesto de IT para Testing. De un 18% en 2012 a un 23% en 2013.
  • Les equipos de QA siguen siendo involucrados demasiado tarde en el ciclo de desarrollo de aplicaciones, lo que contribuye a incrementar el coste del testing dentro del presupeuesto de IT para poder resolver las ineficiencias operacionales i de calidad.
  • El Testing de aplicaciones móbiles se muestra como una disciplina clave: el 55% de las organizaciones lo llevan a cabo ahora, en comparación con el 31% del último año.
  • Las organizaciones se enfrentan a retos para gestionar los entornos de pruebas y crear datos de test. El 16% de los proyectos se ejecutan con datos creados sobre la marcha, creciendo un 5% desde 2012.

wold quality report 2013-2014
El informe completo podéis encontrarlo aquí [link]

Agile Testing y los retos para los testers

El próximo 27 de Febrero expo:QA organiza un nuevo afterwork informal entre amigos y profesionales del sector de Testing Software y QA, en el contexto de “Agile Testing y los retos para los testers”

A continuación podéis encontrar más detalles:

Les invitamos a una charla y aperitivo con nuestro ponente Graham Moran, dedicado al mundo de la calidad de software y testing desde hace 15 años.

Graham ha trabajado para IBM y AIG entre Irlanda y España. Tiene pasión por las pruebas de software y en particular por la formación de las mismas. Estos últimos años ha estado trabajando con las metodologías ágiles y está certificado como profesor de ‘Certified Agile Tester’

¿Deben tener los testers una actitud distinta para trabajar en un ámbito ágil?

Esta charla describe lo que es el ‘Agile Testing’ y explora no solo los retos diarios a los que los testers se enfrentan, sino a los cambios de actitud que ellos mismos adoptan.

Graham os hará un Quizz un tanto divertido, con alguna que otra sorpresa más…

  • Fecha: 27/02/2014
  • Horario: de 19:00 a 21:00.
  • Precio: gratis
  • Más información e inscripciones aquí.

Análisis y gestión de requisitos

Acabo de ver en el Blog del Centro de Innovación en Productividad de Microsoft este vídeo muy gracioso y real sobre análisis y gestión de requisitos.

Una situación bastante cómica pero a la vez muy real. No siempre es trivial alinear las expectativas sobre como debe comportarse un sistema.

La vida de un defecto

Pere Felices me acaba de enviar un texto muy simpático sobre la vida de un defecto (de software), que comparto con vosotros para que también la disfrutéis:

I am defect. For some people I am a mild inconvenience and for some I am their worst nightmare, probably a life threatening nightmare. For many years, people like you have treated me as a hunting target and treated me as a non-living entity – without any emotion, say or dreams. Till now, I kept my silence but now I had it enough. TestingGeek has allowed me to tell my story to the world, to tell you truth about me and my feelings.

You call me so many names (And all of them are bad BTW), but do you know anything at all about me? Do you know where I lived before you forced me to live in your code – to be found, discussed, killed, ignored and humiliated?  People tell me so many things, but do you realize reasons for my existent? I know I am not desired, I know I am not welcomed and to be honest, I do not want to come anywhere near your (sometime dirty) code, requirements etc. But you force me to live in your requirements, code, network and so many unimaginable places because of your misunderstandings, lack of knowledge or plain sloppiness some time.

You do not realize, but I pay a great price for your sloppiness and your lack of understanding. I take blame for lost life, money and happiness for many users. Plane is crashed because there was a defect; transaction was not complete because there was a bug and so on. Why don’t you pause, think and say plane was crashed because someone did not do their job properly. I am there not because I love staying in your code, but because someone took short cut, invited me there to be found by someone else. I was invited, ignored and now I am blamed. Where is justice? Unfortunately defects cannot trial humans in their court, but I hope our fate will change.

My life is extremely comfortable till you guys put me in the code. After that, it’s all misery and my life becomes extremely miserable. From that moment onwards, I live my life in anticipation of to be found, broken in pieces, discussed and humiliation. I do not like being here and so always gives you hint of my presence. Sometime, I have power to give strong hints and it becomes impossible for you to ignore me. But sometime, you just do not recognize my hints, you over look what I say in log files, you don’t notice when I create slight flicker or make your system slow. You attribute things like these to something else and leave me there to rot, to get worsen. That doesn’t leave me any option but to gather strength and try harder. Most of the time I succeed and you notice me. Unfortunately I cannot understand your situation so some time by the time you notice me, I might have crashed a plane or ruined millions. So please, practice, observe and understand my hints. I will be very happy if you find me and kill me in such a way that I do not have to come again, but alas it doesn’t happen.

Most of the time, instead of killing me you just change my dress and location. Sometime, you even break me in to pieces and scatter me in your code base. Unfortunately, we do not follow the law of physics so some time when you break me in pieces, every piece could be bigger than the original itself. Even in pieces we communicate with each other, we affect each other and because of this you get confused. Rather than finding all the pieces, you take one piece and kill it or unfortunately break it in even more pieces…and cycle continues.

Buried in your millions of line of code, I wait patiently for my angles called testers who have skills and mandate to discover me. Given the right environment these angles could find most of us. But look, what have you done to my angles? You have converted them from angel to robot so rather than finding me, they are following some steps. If I am lucky, they will find me otherwise my angles will pass by me and ignore me, because someone has given them steps to follow rather than mandate to find me. Will I not feel angry about it? How would you feel if you struggle to survive in a sea and rescue boat follow the route given to them and ignores your plea? Well, that’s how I feel.

Sometime my angels create robot themselves and call it test automation. This can be extremely useful, but only if mandate for them is to find me rather than creating more robots. Unfortunately, for many people mandate is limited to the creation of these robots and they are worse for me. Well, it’s like missing rescue boat in periodic manner, after every check-in, after every few hours or on nightly basis.

I am not selfish and understand that sometime you just can’t kill me, but believe me I will be very happy if you can find me, discuss me meaningfully and take conscious decision to keep me in the code. Because, if you do that I’ll understand that I’ll never ever kill someone because of my presence, I’ll know that I will not ruin your millions. So as long as you have assessed risk associated with me staying in your code, I can live there happily. I just do not want to live there with feeling that I am not wanted here and I can possibly hurt someone.

Please, I do not want to stay in your code or system. I am extremely happy outside, don’t invite me inside. I know some of us are a bit naughty and will come without invitation. For those naughty defects, give our angels mandate to find them in best possible way rather than following steps or creating just robots. I am good at heart and do not want to hurt anyone, so please find me and get me out of your code base.

Remember, I am a defect buried in your code and waiting for you. Please be aware of my presence and keep your eyes open for me.

Waiting to be found – A defect.

Fuente: Testinggeek.com

ISTQB Advanced (Test Manager) – Mapa Mental

ISTQB Mind Map

Hace unas semanas andaba preparando el examen de certificación ISTQB Advanced Level (Test Manager). Se trata de una titulación oficial que demuestra la cualificación de los candidatos en varias disciplinas:

  • Software Testing Basics.
  • Testing Process.
  • Test Management.
  • Reviews.
  • Defect and Incident Management.
  • Standards and Test Improvement Process.
  • Test Tools and Automation.
  • Team Composition.

Para preparar la certificación me hice un mapa mental con todos los conceptos básicos del temario, que podéis descargar siguiendo estos enlaces:

ISTQB Advanced Level – Test Manager (FreeMind format)

ISTQB Advanced Level – Test Manager (Xmind format)

Si te interesa el mapa mental en algún otro formato, puedo enviártelo.

Diferencia entre un Software Test Engineer y Software Quality Engineer

Estaba dando una vuelta por los mensajes pendientes en los grupos de LinkedIn y me encontré uno especialmente interesante en el grupo de Test Republic, donde Annamariale Chandran (Senior Engineer) explicaba las diferencias entre un STE (Software Test Engineer) y un SQE (Software Quality Engineer). Podéis leer el debate completo aquí.

El tema no tendría mayor importancia si no fuese porqué muy a menudo ambos puestos (y responsabilidades) se confunden. Y es que todavía cobra mayor criticidad cuando las expectativas dentro de la organización no están claras respecto a ambos perfiles. En la mayoría de empresas se contratan STE, esperando que estos ejecuten el rol de SQE y esto entraña diferentes peligros. El mas importante: los STE precisan de un gran conocimiento sobre el aplicativo a probar, mientras que los SQE han de ser grandes conocedores del ciclo de vida de desarrollo de los productos.

A continuación podéis encontrar un pequeño resumen de las expectativas que deben cumplir ambos roles:

Software Test Engineer (STE)

  • Objetivo: Verificar y validar que el producto cumple con las especificaciones.
  • Entregables: Análisis del producto en lo que se refiere a los unidades  desarrolladas (componente, sub-sistema, sistema, aplicativo, …) y resultados de las ejecuciones de pruebas.

Software Quality Engineer (SQE)

  • Objetivo: Verificar que el producto es desarrollado conforme a los procesos definidos, así como la revisar e implementar cambios en los procesos.
  • Entregables: Análisis de las desviaciones en los procesos del proyecto e identificación de oportunidades de mejora.

Obviamente estas dos definiciones admiten modelados específicos a cada organización y pueden adaptarse a escenarios mas complejos o cambiantes.

Métricas de calidad en el código

Ilustracion de las metricas de calidad

Aunque es una viñeta bastante graciosa, en algunos casos puede caerse en la tentación de pensar que somos tan buenos desarrollando nuestros propios productos que éstos ni tan solo tendrán defectos.

Y esto es lo que pasa después de la revisión de un mal código (con defectos importantes): se termina reaccionando bajo alarmas.