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.

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.

En el primer post de honey expliqué como configurarlo y correrlo. En este me dedicaré a explicar las partes del archivo de configuración de modo que se puedan crear redes simples pero bien simuladas. Se pueden crear muchos escenarios complejos con esta herramienta, incluyendo el uso de rutas y diferentes tipos de dispositivos de red. Básicamente la estructura de un archivo de configuración de honeyd consiste en:

1. Personality (debe coincidir con el nombre exacto de un fingerprint del archivo de nmap (base de fingerprints usado para correr honeyd).

2. Puertos TCP y UDP

3. Acción por defecto de los puertos (default action, en el caso de que el puerto no sea especificado no debería responder)

4. Binds, para asignar la ip específica a una personalidad determinada.

Este es un archivo de configuración de ejemplo:

create template

set template personality "AIX 4.0 - 4.2"

add template tcp port 80 "sh scripts/web.sh"

add template tcp port 22 LISTEN

add template tcp port 23 proxy 192.168.110.10:23

add template udp port 100 LISTEN

set template default tcp action reset
set template default udp action reset

create template2

set template personality "Linux 2.2.14"
add template tcp port 80 LISTEN

add template tcp port 21 LISTEN

add template tcp port 22 proxy 192.168.110.5:22

add template udp port

set template2 default tcp action reset

set template2 default udp action reset

bind 10.0.0.1 template

bind 10.0.0.12 template2
bind 10.0.0.32 template

1. Personality: Los nombres template y template2 son simplemente etiquetas para nuestras personalidades. Como escribí anteriormente es importante asegurarse de que el nombre de la personalidad coincida con algún nombre exacto de un fingerprint en el archivo de fingerprints usado al correr honeyd.

2. Puertos TCP y UDP: Esto es muy importante para hacer la red mas realística. Hay varias formas de simular puertos:

a. Especificando el estado (ej: LISTEN o FILTERED)

b. Usando scripts (ej: sh scripts/web.sh, este script simula un web server) Pueden encontrarse algunos scripts en la página de honedy (www.honeyd.org) que pueden utilizarse para simular diferentes servicios.

c. Proxiando el puerto a una máquina física (ej: proxy 192.168.110.5:22). En este caso si nos conectamos al puerto en la red simulada en realidad nos estaríamos conectando al puerto de la máquina especificada luego de la palabra proxy.

3. Default action al puerto: Especificando esto nos aseguramos que ningún puerto que no se especifique en la lista no responda. Es necesario poner el comportamiento esperado por defecto como en el ejemplo.

4. Bindings: Con esto tenemos la posibilidad de asignar las ip a las diferentes personalidades usando la misma personalidad en diferentes ips.

También es posible reducir las comunicaciones a uno o muchos puertos usando la opción ‘tarpit’ para hacerlo más realista:

ej: add template tcp port 25 tarpit LISTEN

It is possible to create several complex scenarios with this tool, including the use of routers and many kind of devices. Basically the structure of the configuration file consist in:

1. Personality (it should match with the name of any available fingerprint in a nmap configuration file used to run honeyd).

2. TCP and UDP ports

3. Default action for the ports (in case that the port wasn’t specified, it should not respond)

4. Bindings to the specific ip addresses of our simulated network

This is an example configuration file:

create template

set template personality "AIX 4.0 - 4.2"

add template tcp port 80 "sh scripts/web.sh"

add template tcp port 22 LISTEN

add template tcp port 23 proxy 192.168.110.10:23

add template udp port 100 LISTEN

set template default tcp action reset
set template default udp action reset

create template2

set template personality "Linux 2.2.14"
add template tcp port 80 LISTEN

add template tcp port 21 LISTEN

add template tcp port 22 proxy 192.168.110.5:22

add template udp port

set template2 default tcp action reset

set template2 default udp action reset

bind 10.0.0.1 template

bind 10.0.0.12 template2
bind 10.0.0.32 template

1. Personality: The names template and template2 are just labels for our personalities. As I wrote before it is important to make sure that the name of the personality matches with any available name in the nmap fingerprints file used to run honeyd.

2. TCP and UDP ports: This is very important to make this more realistic. There are many ways to simulate ports:

a. Specifying the state (e.g. LISTEN or FILTERED).

b. Using scripts (e.g. sh scripts/web.sh, this script simulates a web server.) Some scripts can be found in the honeyd page (www.honeyd.org) that can be used to simulate many services.

c. By proxying the port to a physical box (e.g. proxy 192.168.110.5:22). In this case if we connect to the port in the simulated network we will be actually connecting to the computer specified after the word proxy.
3. Default action to the port: By specifying this we make sure that the ports not entered in the list will not respond. It is necessary only to put the default action like in the example.
4. Bindings: The great thing of this is that we can reuse the personalities many times in different ips in our simulated network. For example, we can have template and template2 and have many hosts as we can in the whole network, many of them will be the same but we can reuse them.

It is also possible to slow down communications in any or all ports by using the ‘tarpit’ option:
e.g: add template tcp port 25 tarpit LISTEN

Esta técnica de testing se aplica a aplicaciones en las cuales se necesita instalar ya sea la aplicación completa en un equipo, un cliente o un server. Como su nombre lo dice, consiste en probar que la instalación de nuestro producto funcione correctamente.

En la prueba de instalación, hay que tener en cuenta los siguientes aspectos:

• El correcto funcionamiento del instalador: Comprobar que muestre los diálogos correctos y que haga las preguntas necesarias.
• Las diferentes plataformas soportadas: Probar en cada plataforma soportada.
• Los usuarios del equipo y la instalación: Un ejemplo de esto es en un sistema windows que sucede si se instala en un usuario no administrador o asegurarse que si se instala como administrador el aplicativo pueda ejecutarse en los demás usuarios.
• Los requerimientos mínimos del sistema: Probar que sucede con requerimientos suficientes e insuficientes.
• Keys necesarias para instalar el producto: Muchas veces en necesario un product key para poder instalarlo.
• Activación del producto si es necesario: Esto puede ser con una clave o por red, en caso de tener esta opción muchísimos casos de prueba surgen.
• Asegurarse de que se instale donde se especificó.
• Asegurarse de que se creen los directorios correctos y que no falte ningún archivo.

Pueden haber otros aspectos a considerar. Esto es una lista, en líneas generales, de lo que uno debería observar a la hora de hacer un installation testing de una aplicación genérica. Obviamente uno debe ver que requerimientos de instalación existen, cada aplicación tiene sus particularidades.

Yo aconsejo realizar una regresión en líneas generales de este tipo de testing antes de lanzar el producto, ya que la instalación es vital porque es lo primero que el cliente observa.

Boundary testing es testear los límites de un campo. Muchas veces sin darnos cuenta terminamos haciendo este testing cuando tenemos que testear un campo por ejemplo numérico.

Lo primero que hay que hacer para realizar este tipo de testing es primero identificar las clases de equivalencia.

Supongamos que tenemos un campo mes, que toma el número de mes. Los valores posibles son de 1 a 12 inclusive. Lo que debemos hacer es probar el borde del campo (esto sería un caso limpio) y que el sistema de el mensaje de error correcto al pasar ese límite (casos sucios).

Entonces nuestros testcases serían los siguientes:

1. Ingresar 1 en campo mes -> Resultado esperado: Debería aceptarlo como válido.
2. Ingresar 12 en campo mes -> Resultado esperado: Debería aceptarlo como válido.
3. Ingresar 0 en campo mes -> Resultado esperado: Debe mostrar un mensaje de error indicando que el nro de mes es inválido.
4. Ingresar 13 en campo mes -> Resultado esperado: Debe mostrar un mensaje de error indicando que el nro de mes es inválido.

De esta forma nos aseguramos de que los rangos válidos que deberían tener los campos queden respetados por el sistema. Aceptando valores válidos y avisando en caso de que el valor ingresado es inválido.

Se define al testing basado en requerimientos como: Testing focalizado en proveer que el programa satifaga cada requerimiento contenido en un documento de requerimientos.

Esta técnica de testing puede ser muy interesante y efectiva pero surge el problema de encontrarse con requerimientos incompletos que necesitan ser pulidos. Ahí entramos en verificar que el requerimiento sea testeable.

Nos podemos encontrar con las siguientes situaciones:

- Que el producto a testear sea nuevo: Entonces no sabemos nada del mismo. Es vital en estos casos contar con un requerimiento claro y completo, aunque sucede que los analistas funcionales o quien sea el encargado de crear el requerimiento no se meta a fondo a definir cada parte de un feature a probar. Por ejemplo puede definir que nuestro software para realizar una búsqueda utilizará un wizard pero especificar muy poco del mismo o nada. En ese caso hay que realizar las preguntas necesarias para poder testearlo y sucede que muchas veces el creador del requerimiento no tiene idea de las limitaciones técnicas y decide dejar que ciertas desiciones corran por parte del desarrollador. Entonces uno entra en una búsqueda de la verdad del requerimiento, tratando de encontrar una persona que nos pueda responder nuestras preguntas para tener todo claro y poder comenzar a escribir nuestros casos de uso.

- Que el requerimiento a testear pase a ser un feature nuevo de un producto existente: Esto nos hace el trabajo más fácil. Ya conocemos el producto y ya tenemos idea de donde puede fallar. Entonces nuestras preguntas para mejorar ese requerimiento son más directas y concretas. Puede suceder que el analista funcional deje cosas bajo el criterio de los desarrolladores también, pero como dije antes, el conocer el producto nos hace el trabajo más fácil.

Hay que siempre tratar de desglosar el requerimiento en cosas que hay que tener en cuenta a la hora de crear los casos de prueba. Una buena práctica es ir leyendo detenidamente el requerimiento e ir anotando como items cada una de las cosas que hay que probar. Una vez obtenida la lista cada item puede formar un caso de prueba o más (según corresponda). Además hay que tener en cuenta las preguntas hechas a los desarrolladores en caso de que algún aspecto quede por cuenta de ellos.

Muchas veces varios requerimientos se cruzan, entonces si se trabaja en grupos es una buena idea luego intercambiar los casos de prueba de cada requerimiento, para asegurarse de que no hayan casos redundantes.

Un analista de QA puede pasar mucho tiempo analizando requerimientos, creando casos de pruebas, viendo procesos, siguiendo defectos, pero el momento de la verdad es cuando se ejecuta un caso de prueba. En ese momento es cuando el analista debe pasar frente al software a probar con el caso de prueba a correr y ver si se encuentra un defecto, varios o ninguno.

Mis consejos para este “sagrado” momento son los siguientes:

• Tratar que las sesiones de prueba no tarden períodos demasiados largos de tiempo. En el libro lessons learned in software testing aconsejan 90 minutos, pero yo pienso que hay que hacer lapsos de tiempo menores. Creo que con períodos de 30 minutos es mejor con pausas de 10 o 5 minutos en el medio para despejar la mente. Es preferible tomarnos una pausa a que se nos pase algo por alto. Elegir una cantidad de casos de prueba que esten relacionados para cada sesión.
• Nunca parar hasta completar una cantidad de casos de prueba. Es decir, si yo estimé que en 30 minutos iba a poder correr 5 casos de prueba y en ese tiempo me quedo el quinto caso en el tercer paso (y supongamos que ese caso tiene 10 pasos) no hay que cortar la prueba ahí, se termina el caso. En una palabra: que los casos de prueba siempre sean atómicos en su ejecución.
• Revisar los casos de prueba antes de correrlos, leerlos paso a paso y ver que se encuentre toda la información necesaria.
• Cuando se encuentra un defecto, juntar toda la información necesaria para escribir el reporte, pero seguir ejecutando los casos hasta terminar con la sesión. Terminada la sesión escribir los reportes de todos los bugs encontrados y así repetidamente.
• Revisar si es necesaria alguna configuración especial para los casos a correr en el software que estamos probando.
• Si estamos escuchando música, tratar de escucharla en un volumen que no nos distraiga, es importante prestar atención durante todo el proceso de prueba.

Puede que alguna herramienta no permita por ejemplo el acumular bugs para el final de la sesión. Para mi es importante seguir enfocado en la tarea de la ejecución y no cambiar a pensar en un reporte, pero bueno si la herramienta tiene esa limitación no nos queda otra opción. En ese caso se tiene la ventaja de que a la hora de escribir el bug se tiene más fresco lo que sucedió (es cuestión de preferencias, yo por eso aconsejo guardar información de lo que pasó en el momento y continuar, de esta forma no solo se sigue focalizado en el trabajo sino que esto permite que el tester pueda tomarse su tiempo para escribir un reporte con mayor calidad).