Quality Testing

Desde inicios del año pasado estoy trabajando con un equipo remoto en India. Mi trabajo es establecer objetivos en un testplan, coordinar el trabajo y fomentar buenas prácticas (definiendo como se hacen las cosas y microprocesos). A decir verdad aprendí bastante durante este último año, es algo difícil pero una vez que uno se acostumbra se pueden lograr muchas cosas.

Para empezar voy a describir los puntos que hay que tener en cuenta:

• Diferencias de tiempo: En mi caso el equipo remoto termina su día cuando yo empiezo el mío.
• Idioma: Si bien uno puede tener un buen nivel de inglés, a veces lleva un tiempo acostumbrarse a ciertos acentos
• Cultura: Muchos paises dondese terceariza suelen tener diferente forma de encarar el trabajo y tomar decisiones
• Tamaño de empresas involucradas: Las empresas donde se terceariza suelen ser muy grandes. En mi caso mi empresa es mediana y la tercearizada es enorme, así que suelen notarse diferencias entre la forma de trabajar de sus empleados y la mia.
• Medio de comunicación: Puede ser algo que parezca simple, pero hay que acostumbrarse a usar exclusivamente mails, teléfono, gtalk o similar, etc…No es lo mismo tener la posibilidad de explicar algo en persona que remotamente.

Consejos:

• Siempre organizarse durante el día una hora para preparar el trabajo que se quiere para el otro día.
• Llevar una planificación estimativa de las tareas para realizarse durante la semana.
• Tener directamente un “buffer” de tareas para cada persona ordenadas por prioridad. De esta forma si hay algún bloqueo con alguna tarea pueden pasar a la siguiente y no se tiene el recurso inactivo durante un día u horas.
• Mandar un mail diario a los integrantes del equipo remoto estableciendo objetivos y pautas para el día siguiente.
• Siempre establecer objetivos claros, explicando paso a paso como se quiere realizar una tarea. La forma más efectiva es hacer uno y que repitan el estilo (ejemplo, automatizacion de casos. Se automatiza uno y que el resto lo automaticen de esa misma forma)
• Asignar una parte de nuestro día para revisar el trabajo realizado por el equipo remoto.
• Hablar por teléfono a diario con el equipo remoto, al comienzo o al final de su día.
• Mantener wikis con templates y guías.
• Hacer que el equipo remoto documente en wikis, de esta forma si sacan un recurso de nuestro proyecto perderemos lo menos posible el conocimiento adquirido por esa persona.
• Tratar de mantener el expertise dentro del equipo local y no el remoto.
• Tener un calendario con los feriados del país donde se terceariza y mantener un calendario con las vacaciones de los integrantes del equipo.
• Asignar tareas con ticket, de esta forma es mas fácil de hacer un seguimiento del trabajo realizado o las tareas a realizar.

REMOTE TEAMS

From the beginings of the last year I’ve been working with a remote team located in India. My work is to establish objectives in a testplan, coordinate the work and encourage the team to follow good practices (defining how to do things and setting small processes). To be honest, I learned a lot during this last year, it is something difficult, but once you get use to it you can do a lot of things.
I’m going to start describing some points:
* Time differences: In my case, when I get to the office, the remote team is leaving.
* Language: Even if you have a good english level, it takes some time to get use to some accents.
* Culture: Some cultures has different ways to work and to take decisions.
* Size of the companies involved: In general, the offshore companies are very large. In my situation, my company is a mid size company and the offshore is huge, so it is not weird to see some differences in the work metodology.
* Comunication: This may sound simple, but it is important to use only mails, phone, gtalk or similar, etc… It is not the same to have the change to explain something personally to do it remotely.

Advices:
* Assign one hour during the day to prepare the work required to the next day.
* Follow an estimated plan of tasks to follow during the week.
* Create a buffer of tasks ordered by priority for each member of the team. With this, if there is any blocking issue with one of the task, they can go to the next one and so on.
* Assign some time of our day to review the work done by the remote team.
* Mantain a daily call with the remote team.
* Create wikis with templates and tutorials.
* Make the remote team to document everything into wikis, the idea is to mantain the knoledge in case of we loose that resource from the remote team.
* Try to keep the expertise in the local team, not into the remote one.
* Keep a calendar with the holidays from the remote country and the vacations of the team members.
* Assign the work in tickets, this will make easier to follow the progress of the work or to see the pending tasks.

Estamos armando un nuevo equipo para un producto nuevo que lanzamos en la empresa donde trabajo: www.coresecurity.com

Las posiciones abiertas son:

* Tester de automatización

* Ingeniero de testing

* Lider de testing

Todas las posiciones son para trabajar en Buenos Aires, en el barrio de Palermo. Es una excelente oportunidad, si ven que su perfil matchea alguno de estos que puse arriba por favor contactarme o mandar un mail a la dir del link.

Existe una forma rápida de compartir archivos vía web usando un simple comando de python:

python -m SimpleHTTPServer 9914

Con esto se compartirán todos los files del directorio en el que se ejecute este comando y sus subdirectorios en el puerto 9914.

Entonces es cuestión de abrir un browser en cualquier máquina que sea visible poniendo la ip y el puerto y se verán los archivos compartidos (ejemplo: http://192.168.1.1:9914)

There is a way to share files via web by entering a simple python command:

python -m SimpleHTTPServer 9914

With this, the directory where this command was executed will be shared (including the subdirectories) in the port 9914.

So, to access the file it will be a matter of open a browser with the ip and the port of the machine where the command was executed (eg.  http://192.168.1.1:9914)

El siguiente tutorial muestra rápidamente como manejar testlink. Quien hizo este tutorial, utilizó el feature de importar xmls para agregar casos, pero también los casos pueden ser creados en la herramienta.

El viernes 5 de Febrero pasé el examen de la certificación ISTQB (International Software Testing Qualification Board), contestando correctamente un 83% de las preguntas.El examen es multiple choice y consta de 40 preguntas, y el tiempo para responderlas es de 60 minutos. Para aprobar hay que responder un mínimo del 65% del total de las preguntas.

Para estudiar recomiendo el libro “Software Testing Foundations – Andreas Spillner, Tilo Linz, Hanz Schaefer”. Este link lleva a la página en Amazon. Por otro lado se puede bajar un syllabus que es de gran utilidad en este link.

On Feb 5th I successfully approved the certification exam from ISTQB (International Software Testing Qualification Board), with a score of 83%.The exam is multiple choice and consists in 40 questions, witch must be answered in 60 min. To approve it is necessary to correctly answer the 65% of the questions.

To study, I recommend the book ”Software Testing Foundations – Andreas Spillner, Tilo Linz, Hanz Schaefer”. This link goes to the book page in Amazon. You can find a syllabus in this link.

Es común que suceda que muchas veces nos esforzamos en trabajar en algo que al final nos hace que nos lleve mas tiempo llegar a cumplir nuestro objetivo. El fin de testear es encontrar bugs o asegurar que el producto funcione correctamente, esto lo tenemos que hacer cubriendo la mayor parte del producto en el menor tiempo posible.Con respecto a la desición de automatizar o no se pueden cometer dos errores:

• Podemos esforzarnos en correr casos manualmente que en realidad si los automatizamos, podemos reducir notablemente el tiempo de ejecución.
• Tomar la desición de automatizar algo que en realidad no vale la pena automatizar, ya sea porque es un test demasiado simple o porque se va a ejecutar sólo una vez.

Por eso es importante discernir cuando o no automatizar. Supongamos que tenemos un test suite que su ejecución nos llevaría 5 días y que durante el testing del producto lo debemos correr 2 veces (primer ejecución + regresión hacia el final del testing). Nos quedarían 10 días de ejecución manuales. En este caso nos conviene evaluar automatizar: dedicamos 5 días a automatizar los casos y supongamos que reducimos la ejecución de 5 días a 1 día. Terminamos usando 7 días de trabajo vs los 10 días estimados manuales, y no sólo eso, la próxima vez que haya que hacer una regresión de este feature tenemos los tests automáticos listos para correr las pruebas rápidamente, pudiendo dar una respuesta de que tan estable esta el feature o no.Por otro lado si tenemos un feature que nos lleva 1 día correr manualmente y que no se volverá a testear, en este caso nos conviene directamente correrlo manualmente. Muchas veces también puede suceder que se requiere de un ambiente demasiado complejo y es realmente necesario que una persona monitoree las pruebas, ahí si: corramos el test suite manualmente.It is common that happens that many times we put a lot of effort in working in something that at the end will make us waste our time in achieving our objective. The objective of testing is to find bugs or ensure that the product works properly, and we must do this covering the most part of the product in the less time possible.In deciding when to automatize or not we can make two different mistakes:

•  We can effort in running the testcases manually but if we automatize we can reduce notably the time of execution.
•  We can make the decision write automated scripts in something that it not worth it, this can be because it is a very simple test or it will be executed only once.

That’s why it is important to decide when automatize or not. Let’s suppose that we have a test suite that it’s execution take 5 days and during the testing of the product we must run it 2 times (firts execution + regression at the end of the testing). It will take us 10 days of manual testcase execution. In this situation we must automatize: we use 5 days to automatize the testcases and let’s suppose that with this automated tests we reduce the execution time from 5 days to 1 day. We will end up using 7 days of work vs 10 days estimated if we were doing all manually, and not just that, the next time that we needed to run the tests again we will have our automated scripts to give a quick answer of the stability of the feature.On the other hand, if we have a feature that will take us 1 day to run it manually and it will not be tested again in the future we must run it manually. It can also happen that a complex environment is required and it is really necessary to put a human to check the tests, in that case we need to run the test manually too.

Muchas veces necesitamos generar datos aleatorios para diferentes tests. En generatedata.com se puede encontrar una toolcita que permite generar archivos HTML, excel, XML, CSV y SQL con datos aleatorios.

Many times we need to generate random data for a test. In generatedata.com we can found a small tool that allows us to generate HTML, excel, XML , CSV and SQL files with random data.

Un smoke test es un testing rápido que se realiza no tanto para encontrar bugs sino para asegurarse que la funcionalidad básica del software o de una parte del software se comporta correctamente.

El smoke test es menos que una regresión, por lo general cubre una gran parte de features por lo tanto consiste en testear rápidamente la funcionalidad básica de cada feature. En mi experiencia, siempre realizamos smoke tests antes de la salida de la nueva versión. Asi nos nos aseguramos que nada quedó roto y a partir de ese smoke test tomar una decisión sobre la salida de la version a los clientes.

Las características de un smoke test son las siguientes:

• Tests cortos, idealmente un caso para probar por arriba que el feature funcione. Si esta es compleja siempre tratar de tener la mínima cantidad de casos.
• Idealmente no deben encontrarse bugs durante este test o muy pocos. Como dije antes, sirve para quedarnos tranquilos que todo funciona correctamente. Para encontrar bugs estuvieron las pruebas previas, mas exhaustivas en cada feature.
• El tiempo de ejecución del smoke test completo debe ser corto.
• Los casos por lo general son positivos. O sea, comportamiento esperado en situaciones en la que el usuario no hace nada raro.
• Debe correrse una vez que se corrieron todos los casos nuevos y regresiones en el producto. Como un chequeo final antes del release.

 Pongamos como ejemplo un sistema de un banco. Es algo grande y con muchas partes. Supongamos que ya corrimos todos los tests por separado, regresiones, y tests de integración. Ahora nos queda dar la decisión oficial de si testing aprueba la salida del sistema. Para asegurarnos que nada se rompió corremos el smoke test. El smoke test para este ejemplo tendrá pruebas concretas, por ejemplo si analizamos la parte del sistema que maneja las cuentas los tests serían muy concretos: crear cuenta corriente en dolares, crear cuenta corriente en pesos, crear caja de ahorro en dolares, crear caja de ahorro en pesos, modificar cada una y borrar cada una. Siempre con valores válidos y casos limpios. De esta forma hacemos un checkeo superficial antes de tomar una decisión.

A smoke test is a quick test. It’s objective doesn’t consist in finding bugs but in ensure that the basic functionality of the software or a part of it works correctly. In my experience, we always do this tests before the release of a new version. So we can ensure that nothing is broken and from that test make a decision about the release of the product to the customers.

The characteristics of a smoke test are the following:

• Short tests, ideally one case per feature to see that it is working. If the feature is complex always try to maintain the minimum cuantity of testcases.
• During the smoke test it is normal that we don’t find any bugs or just a few. As I said before, this is to help us to approve the version and make sure that nothing got broke. To find bugs we had the previous tests, more specific in each feature.
• The execution time of the smoke test must be short.
• The cases must be positive cases. That means the expected behavior when the user uses the software correctly.
• Run the smoke test after the execution of all the new testcases of the new features and all the regressions. It’s a final check.

En el blog de Elizabeth Hendrickson (testobsessed.com) se puede encontrar un documento con heuristicas de testing muy útiles.

Se lo pueden bajar de este link.

In Elizabeth Hendrickson’s blog (testobsessed.com) you can found a sheet with very usefull test heuristics.

It can be downloaded from  this link.

Este pequeño tutorial explica como instalar rápidamente testlink. Testlink es una aplicación web, por lo que requiere ser tener un servidor web y una base de datos para funcionar. Precisamente testlink requiere PHP y MySQL. Para no complicarnos y tener que instalar todo de cero una buena solución es la que brinda xampp, que permite fácilmente levantar el server web y mysql sin tener que complicarse. Xampp se puede obtener aca.

Tener en cuenta que esta guía permite instalar testlink rápidamente en una máquina común. O sea que la computadora donde se sigan estos pasos sería el “server” de testlink donde se conectarían los usuarios. Si algo pasa con esa computadora y no se hizo un backup de la base de datos se podría perder la info que se llenó en la herramienta.

Bien, la instalación de xampp no es complicada, es cuestión de bajarse el ejecutable y correrlo, seguir el wizard y listo. Luego esto nos instala una consola que permite ir levantando los servicios.  Sólo necesitamos levantar Apache y MySQL.

Una vez levantados esos servicios, para cambiar el password de la base de datos de MySQL abrimos un browser y vamos a http://localhost/security/xamppsecurity.php 

Necesitamos bajar testlink. Este es el site de testlink. Ir a downloads y bajarse la versión en .zip. Luego simplemente descomprimimos todo en el directorio (dir de XAMPP)\htdocs\testlink. Para iniciar la instalación de testlink en un browser ponemos http://127.0.0.1/testlink/install/index.php. Vamos a ver una pantalla como esta:

Seleccionamos new instalation y continuamos. Vamos a llegar a una pantalla donde nos va a preguntar el password de la BD, ahi ingresamos el que usamos para configurar cuando instalamos XAMPP:

Seguimos con el instalador hasta terminar. Para acceder a teslink entonces entramos : http://[la ip de la maquina donde lo instalamos]/testlink . Podemos entrar desde cualquier maquina de la red.

This small tutorial, explains how to install quickly testlink. Testlink is a web application, to run it needs a web server and a database. In fact it needs PHP and MySQL. To make things easy we are goint to use XAMMP, it will let us to run a web and database server in an easy way. You can get XAMPP in this link.

This guide is only to install testlink quickly in any computer. So that computer will be the testlink “server”where the users will connect. If something happens to that computer all the info saved there in testlink will probably lost, at least a backup is performed.

Well, the instalation of XAMPP is not complicated, is just a matter of download the executable and run it, follow the wizard. Then we can control the services provided by XAMPP from a the  XAMPP console. We will only need to have apache and mysql up.

Once the services are up, to change the MySQL password we open a browser and we enter this URL:http://localhost/security/xamppsecurity.php 

Now we need to get testlink. This is testlink site. Go to downloads and download the zip version. Then we just unzip all in the directory (XAMPP dir)\htdocs\testlink. To start the testlink installation enter the following URL in a browser:  http://127.0.0.1/testlink/install/index.php. We are going to see a screen like this:

Then we choose new instalation to continue. We are going to get another windows where we have to enter the password of the DB, there we just enter the password that we entered when installing XAMPP:

The next is just follow the installer. Once it finishes, to enter testlink we enter:  http://[the ip of the computer where we installed all]/testlink . We can access to teslink from any computer in the same network or with access to that network.