Gracias por todo, no vuelvas más! El rol del Tester en Kanban

Kanban es uno de los métodos ágiles (1) más utilizados, junto con Scrum. Incluso, muchos equipos que dicen usar Scrum en realidad lo que hacen es Kanban o un híbrido entre ambos que se ha dado en llamar “Scrumban“.

Kanban está entre los modelos de proceso más livianos (menos prescriptivos) para trabajar en desarrollo de software. Esto quiere decir que sus exigencias son mínimas: apenas un tablero con columnas, que representan estados; tarjetas que representan tareas, y el principio básico de limitar el “work in progress“, es decir, la cantidad de tareas que pueden estar al mismo tiempo en una columna. Con esto solo se puede empezar a trabajar, resulta ideal para equipos que realizan mantenimiento de aplicaciones, aunque en realidad Kanban no se limita sólo al software, puede aplicarse a cualquier tipo de tarea, si bien cuando se trata de comenzar un nuevo desarrollo de cero, es aconsejable incorporar algunas prácticas de Scrum (convertirlo en Scrumban, como dijimos arriba).

El primer paso para implementar Kanban es conseguir un tablero, unas tarjetas (para representar tareas) y definir cuáles van a ser las columnas en el tablero, es decir, los posibles estados de nuestras tareas. Aquí es donde suele aparecer el primer problema, que es no definir al menos una columna para el Testing. Este error, que solemos atribuir a las metodologías ágiles (porque, es cierto, algunos de los libros clásicos de Scrum, XP o Kanban ni mencionan al Testing), es en realidad un viejo vicio de nuestra Industria, que cada vez que puede se inclina por hacer un Testing insuficiente, o directamente nada de Testing. A este viejo vicio, los métodos ágiles que omiten hablar de Testing le vinieron como anillo al dedo (2).

Sin embargo, la importancia del Testing está muy lejos de ser discutible. Según cálculos recientes, en Estados Unidos, los bugs de software que no se detectan durante el desarrollo y llegan al usuario final, producen anualmente pérdidas por casi 60 mil millones de dólares (la fuente, aquí). Esta simple estadística debería ser suficiente para ponernos de acuerdo en que es sumamente necesaria la tarea de Testing (cuya principal función es, justamente, evitar que los bugs lleguen al usuario final). El Testing es necesario sin importar la metodología o el modelo de proceso que se utilice y Kanban, por supuesto, no es la excepción.

En consecuencia, el primer paso, fundamental, para hacer Testing en Kanban (y para hacerlo bien), es definir al menos una columna (3) para las tareas de Testing. Esto viene de la mano con el concepto de “definition of done”, es decir, cuándo vamos a poder decir que una tarea está completa (“done”). Aquí, debemos luchar contra la natural tendencia de los Desarrolladores a considerar completa una tarea cuando terminaron de escribir el código. En realidad, una tarea no está completa hasta que está probada, hasta que superó el Testing. Por esto es una buena idea agregar a nuestro tablero una columna de Testing antes de la columna Done. Esto le da a todo el equipo una visión bien clara de lo que se debe lograr: cada tarea debe estar desarrollada y probada para considerarla completa.

Una vez que hemos logrado que el Testing sea parte del proceso, el mismo debería fluir naturalmente. No obstante, muchos equipos encuentran en el Testing un cuello de botella, donde las tareas se acumulan. La forma en que Kanban prevé lidiar con este problema es limitar el “work in progress”. Como dijimos antes, se debe definir un número máximo de tareas que pueden estar al mismo tiempo en una columna. Si se ha alcanzado ese número, no puede moverse una nueva tarea a la columna hasta haber sacado otra. Esto obliga a que el equipo tome un enfoque colaborativo y flexible, que en la práctica significa que todo el equipo se dedica a eliminar el cuello de botella (en el ejemplo del Testing, desarrolladores e implementadores se pondrían a ejecutar pruebas, hasta limpiar la columna de tareas). Esto, en el largo plazo, no es la solución ideal. Para evitar que Testing se convierta en un cuello de botella, es una buena idea utilizar la automatización.

La automatización no reemplaza al Tester (4). No es su objetivo, ni debería serlo. El principal objetivo de la automatización es aliviar al Tester de las tareas repetitivas, que tranquilamente pueden ser llevadas a cabo por un robot. La principal de estas tareas son las pruebas de regresión. Estas pruebas son repetitivas, monótonas, pero muy necesarias, es preciso ejecutarlas ante cada modificación del software. Es por eso que son candidatos ideales para automatizar, dejándole al Tester la labor más compleja de ejecutar pruebas exploratorias, donde se requiere el uso de su experiencia y su creatividad y donde, al menos por el momento, un robot no puede ayudar.

Hay otras prácticas que la aplicación de Kanban nos llevará a considerar, como la Integración Continua, o el uso de “andariveles”, que resultan muy útiles, pero que ya son parte de la práctica más avanzada de este método. Seguramente los abordaremos en un futuro post. Por el momento, nos quedamos con que la clave está en incorporar el Testing al proceso y, hecho esto, abordar una estrategia de automatización que nos ayude a evitar los cuellos de botella. Dejar al Testing afuera del modelo es un error que sólo conduce a grandes pérdidas y, en muchos casos, al fracaso del proyecto.

kanban_board
Ejemplo de un tablero Kanban

(1) deliberadamente evito el término “metodología”, lo cual Kanban no pretende ser y que no es apropiada para lo que es apenas un (pequeño) conjunto de prácticas. En la industria, sin embargo, es habitual referirse a estas prácticas como “metodologías ágiles” y hasta el momento no tengo conocimiento de que esto haya producido víctima alguna.

(2) Creo que el malentendido se origina en que los métodos ágiles proponen que se construya la calidad desde el momento cero (“build quality in”) y que sea responsabilidad de todo el equipo. Por ejemplo, un Desarrollador debería realizar pruebas unitarias de su código independientemente de otros tipos de pruebas que se realicen después. De ahí a eliminar el rol del Tester, hay un abismo (donde terminan cayendo muchos proyectos sin Testing…). Otra fuente de malos entendidos es que las prácticas ágiles no definen el rol del Tester (como no definen ningún rol en realidad), mientras que el rol del Desarrollador parece obvio, el del Tester no lo es tanto.

(3) Algunos equipos que llevan un tiempo usando Kanban definen más de una columna para el Testing. Por ejemplo, se podría tener una columna de Testing Funcional o Exploratorio, otra de Testing de Regresión y tantas columnas como tipos de pruebas necesitemos aplicar.

(4) Sobre este tema, te invito a leer nuestro post: ¿La automatización reemplaza al Tester?

 

Diferencias entre Herramientas de Test de Performance

Introducción
Básicamente hay dos maneras de obtener indicadores de performance:

  • Fijar los usuarios concurrentes y medir los tiempos de respuesta de uno o más pasos por llamada/s (la experiencia del usuario, la cantidad de usuarios que supuestamente soporto concurrentes en línea)
  • Fijar la tasa de requests que se quiere obtener y medir los tiempos de respuesta (la experiencia del server con los usuarios arriba intentando ver mi contenido)

Hay dos herramientas Open Source que se utilizan habitualmente para fijar la cantidad de usuarios (o threads concurrentes) y medir tiempo de respuesta:

ab (Apache Benchmarking)
Línea de comandos, normalmente instalado por default cuando se instala Apache.

JMeter (Apache JMeter)
Mucho más sofisticada. Interfaz gráfica, Java, permite hacer varios pasos por llamada y varias llamadas, parseo de regular expressions, graduar cantidad de threads concurrentes, etc.

Diferencias entre AB y JMeter
En caso de querer comparar los resultados de un test de stress entre estas diferentes herramientas con el objetivo de que los resultados sean similares se sugiere leer esta breve descripción:

1) El testing con JMeter se lo debe ejecutar teniendo destildado en la pantalla HTTP Request http Client el checkbox: Recuperar todos los recursos empotrados en el archivo HTML (retrieve all embedded resources from html files) dado que AB sólo hace la llamada al HTML y no a lo que el mismo tiene embebido.

2) En JMeter el tester coloca Número de Hilos (threads) que es la Concurrencia y cantidad de pedidos (requests) que repite un usuario; la multiplicación de ambas nos da la muestra total de la prueba. Ej: 10 hilos x 10 req/hilo = 100 req totales de las 10 concurrencias (total de la muestra).

Por otro lado Apache Benchmarking, en cambio se colocan los siguientes valores:
ab –n(valor) –c(valor) http://hostname:port/path

Donde a diferencia de JMeter –n no es la cantidad de request por usuario sino la cantidad total de request de toda la concurrencia, es decir lo que para JMeter es la muestra total, mientras que –c es la Concurrencia (o Grupo de Hilos para JMeter).

De esta manera, para que las pruebas en las diferentes herramientas, se ejecuten con el mismo nivel de carga con el objetivo de validar los resultados entre ambas se muestra el siguiente ejemplo:
En JMeter                                                        En AB
Prueba 1: 30 hilos x 1 req/hilo = 30               ab -n 30 -c 30 http://hostname:port/path
Prueba 2: 30 hilos x 10 req/hilo = 300         ab -n300 -c30 http://hostname:port/path
Prueba 3: 30 hilos x 100 req/hilo = 3000      ab -n3000 -c30 http://hostname:port/path

Usando una u otra herramienta, siempre se sugiere tener un panorama bien amplio y probar:

  • URL de Home
  • URL de Nota / Aviso / Post
  • URL inexistente (Error 404) como una forma de medir cuanto le cuesta al webserver resolverlo

En la otra vertiente de fijar requests/segundo se encuentra otra herramienta Open Source:

httperf
Línea de comandos, la estamos usando en combinación con autobench (un script para automatizar ejecuciones sucesivas de httperf.
Desde el punto de la estabilidad, el uso de httperf permite encontrar más rápidamente los puntos de saturación que con las otras herramientas suele disimularse. Fundamentalmente porque la carga es un producto de la cantidad de usuarios concurrentes por los requests que realiza cada uno. Así que fijar una carga de esta manera implica cantidad de usuarios pero también un comportamiento esperado. En cambio, la tasa de requests por segundo bruta es un indicador más directo del umbral que soporta el server y de los efectos bola de nieve que se producen cuando se encuentra la saturación. Permitiendo encontrar además otros indicadores paralelos en CPU y memoria, pudiéndose validar la cercanía a un punto de quiebre/saturación directamente en un access.log.

Claro que existen también herramientas pagas -algunas incluso muy costosas- pero entendemos que, a menos que necesitemos alguna funcionalidad específica que estas herramientas puedan proveer, para las pruebas básicas de Performance que podemos hacer desde Testing, las mencionadas arriba son más que suficientes.

Las principales ventajas:

  • Son gratuitas
  • No requieren de demasiado tiempo ni esfuerzo para dominar sus funcionalidades básicas
  • Ofrecen flexibilidad para obtener reportes e información de performance con diferentes indicadores

En próximos posts iremos profundizando sobre algunas de las pruebas de performance típicas, como planificarlas, ejecutarlas, reportar y los aspectos a tener en cuenta en cada una.

 

 

Cuál es el verdadero valor de un curso?

¿Estás pagando por algo que podrías tener gratis?

Con la masificación de las nuevas tecnologías, aunada a la necesidad de encontrar una salida laboral rápida, la oferta de cursos de capacitación ha crecido enormemente. Han surgido numerosas empresas de capacitación, con la favorable consecuencia de que se puede elegir. Sin embargo, no todas las opciones son igualmente valiosas, y habría que someterlo a un breve análisis, para determinar cuál es la elección más conveniente.
Sabemos que hoy en día todo se puede encontrar en Internet, que ha facilitado enormemente la difusión de conocimientos y que, además, es el reino de la copia y la duplicación. Así, no sólo es posible descargar manuales y libros de cualquier tema, sino que además, cuando uno comienza a buscar, encuentra que numerosos sitios ofrecen cursos “gratis” de lo que sea. Normalmente, estos cursos son auto-guiados, es decir, que uno mismo debe ocuparse de leer el material (o mirar videos) y auto-evaluarse. Bastante parecido a leer un libro o un manual en los ratos libres o en el viaje en subte.
Por otro lado, existen algunas empresas de Educación en IT que cobran por cursos de capacitación que en realidad son dictados por algún “recién llegado”, que se aprendió el tema a las corridas, y que se limita a repetir el material (muchas veces copiado de otro lado), como un robot. Incluso, suele suceder, que la misma persona que “enseña”, por ejemplo, Testing, dicta también los cursos de Java, Excel y reparación de celulares. Esto, que parece un chiste, es fácilmente verificable entrando a la Web de alguna de estas empresas de Educación en IT.
En estos casos, nos preguntamos, ¿cuál es la diferencia con el curso gratuito? Los asistentes a estos cursos, ¿no están pagando por algo que podrían tener gratis? A grandes rasgos, creemos que sí, dado que están adquiriendo un producto que les aporta muy poco valor y les dará poco beneficio cuando se encuentren con la realidad de la práctica profesional.
Entonces, debemos volver a la pregunta del título: ¿cuál es el verdadero valor de un curso?

 

Creemos que tiene una respuesta muy simple: el verdadero valor de un curso está en la experiencia que pueden aportar quienes lo dictan. Los conceptos teóricos, impartidos por sí solos, además de que pueden encontrarse fácilmente en cualquier parte (y gratis), no tienen más valor que el leer un libro. Es decir, sólo nos van a aportar la base teórica, que es tan importante, pero a la que se necesita sumar la experiencia para poder aplicarla a la práctica, sobre todo cuando uno pretende alcanzar la tan mentada “salida laboral”.
Los profesionales que integramos QAbility, aparte de que nos dedicamos específicamente al Testing y la Calidad, contamos con más de 20 años de experiencia como profesionales reconocidos en el mercado y, lo más importante, seguimos en la actividad profesional, resolviendo día a día los desafíos que nuestras actividades nos presentan. Es así que, a cada uno de los conceptos teóricos, podemos enriquecerlos con ejemplos y casos de la “vida real”, a partir de nuestras experiencias en la práctica. El asistente a nuestros cursos se lleva un valor agregado que va mucho más allá de la simple lectura de un manual. Cuenta con la base teórica, desde ya, pero enriquecida con el conocimiento de cómo se aplica cada concepto en la práctica. Esto es de enorme valor a la hora de encarar la actividad profesional en proyectos reales, donde la mayoría de las veces la realidad que uno encuentra difiere bastante de lo que dicen los libros y, por lo tanto, la aplicación directa de la teoría de poco sirve.
Por todo esto, a la hora de elegir un curso de capacitación, les recomendamos investigar la trayectoria y experiencia de quienes lo dictan. Incluso, no tener miedo de preguntar y solicitar los antecedentes profesionales de los capacitadores, para asegurarse de que son capaces de agregar verdadero valor al curso. De lo contrario, para incorporar solamente la teoría, nuestro consejo es no pagar por algo que se puede conseguir gratis.

Una visión del equipo de QA sobre el rediseño de TN 2016

Y acá estamos… después de otro gran hito, nos encontramos escribiendo nuevamente una nota para el Blog Dev… ¡Para contarles sobre el trabajo que hicimos con la nueva Web de TN!

Esta vez desarrollamos una nueva versión de las aplicaciones nativas (Android / iOS), un nuevo backoffice para la redacción de TN.com.ar, el sitio web para escritorio, el sitio web para móviles y los nuevos Instant Articles de TN en Facebook.

Esta nueva entrega vino a reemplazar un producto que tuvimos más de 3 años online, que fue premiado y reconocido tanto aquí, en nuestro país como afuera en varias ocasiones. Ahora tenemos la misión de superar esos logros e ir por mucho más.

La idea del post es enfocarnos en QA (Quality Assurance) y contar cómo se trabajó durante los 8 meses de desarrollo del proyecto desde nuestro equipo y cómo hemos adaptado las áreas y los procesos al nuevo marco metodológico. Esta vez, y a diferencia del 2013, todo el desarrollo del proyecto lo hicimos íntegramente basados en una Metodología Ágil: Scrum.

¿De qué hablamos cuando hablamos de Scrum? Es el marco metodológico de desarrollo de software más divulgado y sus características más importantes son:

  • Estrategia de desarrollo incremental, en lugar de ejecución completa del producto.
  • Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Repasemos parecidos y diferencias entre los proyectos: ‘Rediseño 2013’ y ‘Rediseño 2016’.

  • Ambos proyectos duraron 8 meses en su fase de desarrollo.
  • En ‘Rediseño 2013’ participaron alrededor de 20 personas mientras que en ‘Rediseño 2016’ cerca de 60, entre desarrolladores, testers, diseñadores, periodistas, editores, etc.
  • En ‘Rediseño 2013’ se trabajaba con metodología tradicional, algo tipo Cascada, donde el testing venía luego de la entrega de cada nueva versión.
  • En cambio en ‘Rediseño 2016’ hubo testing constante, de Sprint a Sprint y durante todo el proyecto.
  • Esta metodología además permitió que se pueda sostener con sólo 3 QA’s (1 menos que en 2013!) un equipo de desarrollo y producto que creció a más del doble. Con una proporción aproximada de 1 QA por cada 4 ó 5 desarrolladores.
  • ‘Rediseño 2016’ tuvo el triple de issues (UserStories, Tareas, Subtareas, Defectos, Mejoras), que ‘Rediseño 2013’; ésto pudo tener varias explicaciones:

– Este nuevo proyecto fue mucho más ambicioso: Todo un nuevo Backoffice / Rediseño completo de Frontend para Desktop y Webmobile / Nueva versión de las Apps / Instant Articles Facebook

– Todos los Requerimientos, representados en UserStories, se documentaron en la misma herramienta donde se hizo todo el tracking de todo el proyecto, llegando a ser el 25% de los issues totales.

– Se discriminaron mejor las Tareas de desarrollo:

  • Por Plataforma: Desktop / Webmobile / Apps / Backoffice / Backend / IA FB
  • Tipo de Contenido: Vivos / VOD / Fotos / Galerías / Gifs / Audios / MaM

– Desarrollo gestionó y documentó de mejor manera las Subtareas Técnicas.

Esto hizo que comparando ambos proyectos, en la relación Defectos/Mejoras reportadas, y comparándola con su cantidad total de issues, mejoró rotundamente, ya que:

captura1

Entre los 3 QA’s hemos reportado 697 Defectos y Mejoras, los cuales representan el 33% de los issues totales de todo el proyecto.

Siendo los componentes Desktop / Webmobile los que concentraron el 44% de los defectos, siguiéndole Backoffice que concentró el 20% de los mismos.

captura3

Conclusión:

Encontramos una mejora significativa en el Proceso de Trabajo respecto de hace 3 años.

Todo ésto gracias a la capacidad de adaptación de las personas del equipo y a su enorme voluntad por generar mejores productos y procesos, amparados sobre una metodología que funciona!!

Test de Seguridad: Tipos de Ataques

Desde el surgimiento de la Web 2.0, el aumento de intercambio de información a través de redes sociales y la creciente adopción empresarial de la Web como un medio para hacer negocios y ofrecer un servicio, los sitios web son a menudo atacados directamente. Como resultado, la industria está prestando una mayor atención a la seguridad de las aplicaciones web y no solo de la seguridad de las redes y sus sistemas operativos.

Según un importante proveedor de seguridad informática las siguientes son las vulnerabilidades mas explotadas:

  • Cross Site Scripting (Secuencias de comandos en sitios cruzados)
  • SQL Injection (Inyección de SQL)
  • Path Disclosure (Divulgación de ruta)
  • Denial of Service (Denegación de servicio)
  • Code Execution (Ejecución de código)
  • Memory Corruption (Corrupción de memoria)
  • Cross Site Request Forgery (Falsificación de petición en sitios cruzados)
  • Information Disclosure (Divulgación de información)
  • Arbitrary File (Archivo arbitrario)
  • Local File Include (Inclusión de archivo local)
  • Remote File Include (Inclusión de archivo remoto)
  • Overflow (ataque con Tests de Stress)
  • Otros

A continuación se explicaran las vulnerabilidades más importantes y comunes:

Cross Site Scripting

Un ataque de Cross Site Scripting (XSS) permite que una persona mal intencionada inyectar en páginas web código JavaScript (u otro lenguaje de scripting similar), evitando medidas de control. Este tipo de vulnerabilidad está muy extendida y puede afectar a cualquier aplicación web que utiliza la información de un usuario en la salida que genera a través del navegador Web, sin validación o codificación de los datos de entrada de la aplicación. En múltiples ocasiones, no se le da la importancia que realmente tiene este tipo de ataques. Mediante una vulnerabilidad de XSS es relativamente sencillo enviar código malicioso a otro usuario desprevenido. El navegador del usuario objetivo no tiene forma de saber si lo que recibe es confiable y ejecuta el código malicioso al suponer que el script proviene de una fuente segura. Este script puede acceder a las cookies, los tokens de sesión u otra información sensible robando incluso la misma sesión.

Este es un ejemplo de un ataque XSS indirecto (que es el más común), tomado de Wikipedia:

Supongamos que un sitio web tiene la siguiente forma:

http://www.example.com/home.asp?frame=menu.asp

y que al acceder se creará un documento HTML enlazando con un frame a menu.asp.

En este ejemplo, ¿Qué pasaría si se pone como URL del frame un código javascript?

javascript:while(1)alert(“Este mensaje saldrá indefinidamente”);

Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que es del mismo dominio, suponiendo que no puede ser nada malo y de resultado tendrá un bucle infinito de mensajes.

Un atacante en realidad trataría de colocar un script que robe las cookies de la víctima, para después poder personificarse como con su sesión, o hacer automático el proceso con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el atacante podría ejecutar acciones con los permisos de la víctima sin siquiera necesitar su contraseña.

Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere decir que la víctima ve en la barra de direcciones un sitio, pero realmente está en otro. La víctima introduce su contraseña y se la envía al atacante.

Una página como la siguiente:

error.php?error=Usuario%20Invalido

es probablemente vulnerable a XSS indirecto, ya que si escribe en el documento “Usuario Inválido”, esto significa que un atacante podría insertar HTML y JavaScript si así lo desea.

Por ejemplo, un tag como que ejecute código javascript, cree otra sesión bajo otro usuario y mande la sesión actual al atacante.

Para probar vulnerabilidades de XSS en cookies, se puede modificar el contenido de una cookie de forma sencilla, usando el siguiente script. Sólo se debe colocar en la barra de direcciones, y presionar ‘Enter’.

javascript:void prompt(“Introduce la cookie:”,document.cookie).replace( /[^;]+/g,function( ){document.cookie=;});

SQL Injection

Una inyección SQL se da cuando se inserta código SQL “invasor” dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código “invasor” incrustado, en la base de datos.

La forma principal de inyección de código SQL consiste en la inserción directa de código en variables especificadas por el usuario que se concatenan con comandos SQL y se ejecutan. Existe un ataque menos directo que inyecta código dañino en cadenas que están destinadas a almacenarse en una tabla o como metadatos. Cuando las cadenas almacenadas se concatenan posteriormente en un comando SQL dinámico, se ejecuta el código dañino.

A continuación un ejemplo de una inyección de SQL en PHP:

Esta sería una query común de logueo de usuario enviada desde el formulario de nuestro sitio web:

$sql=”SELECT * FROM tbl_user WHERE username= ‘”.$_POST[‘username’].”‘ AND password= ‘”.$_POST[‘password’].”‘”;
$result=mysql_query($sql);

Supongamos ahora que el atacante en “Usuario” y “Password” escribe “x’ OR ‘x’=’x’”, la query enviada sería la siguiente:

SELECT * FROM tbl_user WHERE username=’x’ OR ‘x’=’x’ AND password=’x’ OR ‘x’=’x’;

La fórmula “x’ OR ‘x’=’x’” lo que hace es garantizar que lo enviado en ese campo sea verdad sin importar la formula anterior, por lo tanto la query siempre va a devolver “true”, de esa manera el atacante puede loguearse en el sitio. Cabe aclarar que este es un ejemplo planteado en un sitio con un nivel de seguridad MUY bajo.

Path Disclosure

Una vulnerabilidad del tipo File o Path Disclosure es cuando queda al descubierto la ruta donde esta alojada la aplicación y de esta forma saber en qué directorio específicamente se encuentra el sitio web. Si bien esta vulnerabilidad no es peligrosa resulta bastante útil para explotar otro tipo de vulnerabilidades.

La clásica forma para lograr explotar esta vulnerabilidad es transformando las variables sospechosas pasadas por GET, por ejemplo:

http://sitio.com/index.php?module=login&action=etcetc

Lo transformamos en:

[[http://sitio.com/index.php?module[]=login&action=etcetc]]

Si el sitio no está correctamente desarrollado, lo que hará el sistema es intentar incluir el archivo “login” obteniendo el nombre del fichero desde la variable “module” y si esta variable es un array, mostrará un error o un warning donde podremos ver el path completo del sitio.
Otra forma muy común es, teniendo el mismo caso anterior, remplazar “login” por cualquier cosa:

http://sitio.com/index.php?module=holaholahola&action=etcetc

De esta manera el sistema intentará incluir el fichero “holaholahola” y como no existe, mostrará un warning o error también con el path completo del sitio.

Denial of Service (DoS )

Se genera mediante la saturación de los puertos con flujo de información, haciendo que el servidor se sobrecargue y no pueda seguir prestando servicios, por eso es denominado “denial of service” (denegación de servicio), ya que hace que el servidor no dé abasto con la cantidad de solicitudes. Una ampliación del ataque “DoS” es el “DDoS” o Distributed Denial of Service (ataque distribuido de denegación de servicio) el cual se lleva a cabo generando un gran flujo de información desde varios puntos de conexión.

Un ataque DoS puede ser llevado a cabo de varias formas, aunque básicamente consisten en:

  • Consumo de recursos, tales como ancho de banda, espacio de disco, o tiempo de procesador.
  • Alteración de información de configuración, tales como la información de rutas.
  • Alteración de información de estado, tales como interrupción de sesiones TCP (TCP reset).
  • Interrupción de componentes físicos de red.
  • Obstrucción de medios de comunicación entre usuarios de un servicio y la víctima, de manera que ya no puedan comunicarse adecuadamente.

La forma más común de realizar un DoS es a través de una botnet, siendo esta técnica el ciberataque más usual y eficaz por su sencillez tecnológica. En ocasiones, esta herramienta ha sido utilizada como un buen método para comprobar la capacidad de tráfico que un equipo puede soportar sin volverse inestable y afectar a los servicios que presta.

En un próximo post veremos cómo poner a prueba los sitios para detectar posibles vulnerabilidades.

 

¿Cómo escribir Tests de Aceptación?

banner

Una habilidad clave para el Tester Agil

A partir de la proliferación de las metodologías ágiles, el rol del Tester ha sufrido un proceso de mutación. En las metodologías tradicionales, el Tester escribía casos de prueba detallados, partiendo de un documento funcional escrito por un Analista, incluso antes de que se escribiera la primera línea de código del proyecto. En el mundo Agil, en cambio, el documento funcional no existe, por lo que el Tester deberá completar las especificaciones para cada historia de usuario (user story), generalmente en forma de Tests de Aceptación.

descarga

¿Qué son los Tests de Aceptación?

A diferencia de las especificaciones tradicionales, las historias de usuario tienen un enfoque de negocio y están escritas por una persona con ese perfil (Product Owner).Típicamente, la historia de usuario tiene el siguiente formato:

Como usuario (X)… Quiero (Y)… De manera que (Z)…

(Y) representa una funcionalidad, (Z) es el beneficio para el negocio y (X) es la persona o rol que se beneficiará con esa funcionalidad.

Como puede verse, las historias de usuario se concentran en qué debe hacer el software para satisfacer una necesidad de negocio, pero dicen poco y nada sobre cómo debe hacerlo.
Esto implica un desafío para todo el equipo, pero especialmente para el Tester, que será el encargado de averiguar y documentar cómo deben ser implementadas cada una de las funcionalidades que el cliente está solicitando.
Para ello se utilizan los Tests de Aceptación (*), también llamados Tests de Historia de Usuario (Acceptance Tests/Story Tests). Los Tests de Aceptación verifican que la historia de usuario se ha desarrollado correctamente y por consiguiente, entregará al usuario el valor esperado para su negocio.

¿Cómo se escriben los Tests de Aceptación?

En primer lugar, el Tester deberá tomar cada una de las historias de usuario y escribir los Tests de Aceptación que verifiquen la funcionalidad solicitada. El formato que se recomienda para escribir dichos Tests es el siguiente:

Si… (X)
Cuando… (Y)
Entonces… (Z)

(X) representa el contexto, todas aquellas condiciones que deben cumplirse para que el usuario pueda realizar la acción y, por lo tanto, ejecutarse el Test.
(Y) es la acción que el usuario va a realizar en el contexto definido previamente.
(Z) es la respuesta esperada del sistema ante las acciones del usuario detalladas previamente.

De esta manera, el Tester comenzará a especificar cómo deberá comportarse el software ante los diferentes escenarios que se vayan planteando, de acuerdo a la funcionalidad requerida por la historia de usuario.
Deberán considerarse la mayor cantidad de escenarios posibles, tanto los normales como los alternativos, intentando abarcar todos los modos de uso del software que estarán a disposición de los usuarios.

¿Y cuando me falta información?

El proceso de escribir los Tests de Aceptación es un proceso iterativo, no es algo de se realiza de una vez. El Tester deberá comenzar con un pequeño set de Tests de acuerdo a la información con la que cuente, y se espera que a partir de ahí, vaya refinando los tests. Es decir, agregando mayor detalle y escribiendo nuevos Tests, a partir de los escenarios que se van disparando cuando va consiguiendo nueva información.
Es evidente que en este proceso, es fundamental la comunicación. El Tester deberá mantenerse en contacto permanente con el Product Owner o con el Analista de Negocio, si lo hubiera, y formular todas las preguntas necesarias para abarcar el mayor número de escenarios posible, llevándolos al mismo tiempo al máximo nivel de detalle necesario.
Resulta imprescindible que el Tester sepa ubicarse en los zapatos del cliente y entender a fondo sus negocios y las necesidades que del mismo se derivan. A su vez, es clave que sepa formular las preguntas correctas para obtener los requisitos. Algunas de esas preguntas podrían ser:

¿Cuál es el objetivo de esta funcionalidad?
¿Qué roles tienen objetivos relacionados a la funcionalidad?
¿Cómo podemos saber que la funcionalidad entregada es la correcta?
¿Cuáles son las salidas que el cliente espera?
¿Qué harán los usuarios antes y después de utilizar esta funcionalidad en particular?
¿Qué es lo peor que podría pasar cuando el usuario utiliza esta funcionalidad? ¿Qué es lo mejor?
¿Se pueden obtener ejemplos de cómo el usuario va a utilizar esta funcionalidad?
¿Existen requerimientos no funcionales que deban tenerse en cuenta?

Estas son sólo algunas de las preguntas que pueden hacerse y normalmente, las respuestas nos dispararán nuevas preguntas. Es por eso que decimos que la escritura de Tests de Aceptación es un proceso iterativo, que se irá refinando con el tiempo, a medida que vayamos obteniendo más información. E, incluso, que el propio cliente vaya teniendo mayor claridad sobre qué es lo que necesita.

Como conclusión, los Tests de Aceptación completos, resultarán sumamente útiles, no sólo para el Tester sino para todo el equipo, ya que los desarrolladores podrán basar su código en ellos, adaptándolo según la especificación de los tests. Por su parte, el Product Owner podrá saber cuándo una historia de usuario puede considerarse “terminada”, en función de que haya superado exitosamente todos los Tests de Aceptación.

 

(*) no confundir con las Pruebas de Aceptación, que se realizan junto con el usuario para validar que el software desarrollado está conforme a los requerimientos.

banner

¿Anda bien?: Así probamos la actualización de la aplicación de TN en iOS y Android

banner

por Guillermo Alvis

No todas las aplicaciones que descargamos funcionan bien. Incluso, muchas de las que lo hacen tienen “oportunidades de mejora” que bordean la frontera con el “bug” o con la “usabilidad discutible”. Las “oportunidades de mejora” se pueden presentar en diferentes áreas: consumo de CPU, memoria o batería; problemas de performance, como puede ser el renderizado de imágenes; o simplemente pueden resultarle lentas a los usuarios.

 

Cuando publicamos nuestras nuevas aplicaciones, la comunicación se enfocó en el funcionamiento. “TN anda bien”, decíamos en las promociones. Y aunque quizás suene redundante porque todas las aplicaciones deberían “andar bien”, ahora queremos compartir con ustedes por qué desde el equipo de QA de TN creemos en eso.

Este fue uno de los proyectos más desafiantes que asumimos por la complejidad de los escenarios a testear. En el plan de pruebas contemplamos:

Pruebas de Performace de la App

Concentramos la mayor cantidad de pruebas sobre el uploader de imágenes y videos de TN y la Gente para realizar publicaciones en bulk (de hasta 1000 usuarios simultáneos).

Para llevar a cabo estas pruebas se tuvo que superar un “desafío técnico” que pudo lograr nuestro equipo de Desarrollo. El mismo tenía que ver con estresar el uploader. Había que contemplar que no podíamos usar los mismos archivos files.json en los que se particiona un video, debido a que cada uno tiene información única e irrepetible vinculada al archivo de video original. En síntesis: no se podía reutilizar el mismo set de archivos y agregarle concurrencia.

Pruebas funcionales y de performace de los servicios .JSON que usa la App

  • Desde lo funcional se probaron todos los servicios .JSON (tanto GET como POST) para constatar que trajeran de manera correcta toda la información requerida.
  • Desde el stressing se probaron todos los servicios con JMeter con altos niveles de concurrencia para ver cómo respondían.

 

Pruebas de performance de la app con diferentes anchos de banda de conectividad de red

Se probó con: 4G, 3G, Edge y 2G. Esto se pudo llevar a cabo mediante el uso de una herramienta llamada Charles, que es paga pero barata (¡Je!) pero que además nos permite apuntar la aplicación, al ambiente en el que quisiéramos probar (Desa/Test/Prepro).

Pruebas de performance de la app en los equipos

Se ejecutó el test en los equipos Android más avanzados, con las siguientes “Opciones de Desarrollador” activas:

  • Mostrar superposición de GPU
  • Si / No: conservar actividades

 

Pruebas funcionales de la App

Para estas pruebas se utilizó el siguiente set de dispositivos:

Los dispositivos en los que probamos la actualización

En estos equipos se realizó un conjunto de pruebas funcionales que consolidamos en un checklist. Para los uploaders de imágenes y videos se usaron todos los formatos no nativos de cada uno de los dispositivos. Para las pruebas del upload de fotos de TN y la Gente se contemplaron: .gif, .png, .tif, .bmp y .jpg; mientras que para el upload de video se usaron: .mp4, .3gp, .flv, .mov, .avi, .mpg y .wmv.

Con eso se consiguió un gran nivel de cobertura entre dispositivos y formatos de archivo.

Testing de las nuevas funcionalidades de video

La nueva versión de la aplicación incorpora dos novedades respecto al video tanto en iOS como en Android. Estos últimos desarrollos le permite al usuario visualizar los videos de una nota sin tener que salir de la portada, con players bien simples que se cargan de manera dinámica y automática a medida que el usuario va descubriendo el contenido.

La señal de TN en vivo se reproduce en un nuevo player de pantalla completa también integrado a la App. El usuario accede a la transmisión con un solo botón y sin demoras. Creemos que esto la convierte en una aplicación ideal para informarse con rapidez y comodidad.

El desarrollo tuvo como objetivo la usabilidad y la mejora de la experiencia en video que muchos usuarios criticaron en los stores. Para eso el equipo de diseño y desarrollo trabajó en los detalles y realizando pruebas con usuarios para poder consolidar mejores resultados.

Informe del estado de la App con Monkop

Monkop es una herramienta para el test de Apps en Android (hay versiones pagas y una free). Se encuentra en “la nube” y sólo debe subirse el .apk de instalación de la app a testear. Luego se encarga de enviarnos un reporte con los resultados de las pruebas, donde brinda información muy útil al equipo de desarrollo porque sugiere oportunidades de mejora del orden de performance, uso de CPU, memoria y energía, entre otras.

Todas estas tareas del equipo de QA, sumadas al trabajo de los desarrolladores de aplicaciones y el área de producto explican, a mi criterio, porque la App de TN ¡anda bien!

¿A ustedes qué les parece? ¿Ya la probaron? Les dejo los enlaces al store de iOS y Android para que la descarguen.

 Post publicado originalmente en: http://blogs.tn.com.ar/dev/anda_bien_asi_probamos_la_actualizacion_de_la_aplicacion_de_tn_en_ios_y_android/