Seminario gratuito: Introducción al Testing de Software

 

seminario

En el marco de actividades que QAbility y Exo Training Center realizan en conjunto, anunciamos el Seminario Gratuito de Introducción al Testing de Software.

El mismo se llevará a cabo el 27 de abril de 2016, de 9 a 11 horas, en la sede de Exo Training Center: San Martín 510, Microcentro.

La idea de esta charla es acercar la temática del Testing a todas aquellas personas interesadas en conocer más a fondo esta actividad, ya sea para poder insertarse en el mercado laboral, como para fortalecer sus competencias actuales.

La temática a desarrollar será la siguiente:

¿Qué es hacer pruebas?
La importancia del Testing en el ciclo de vida de desarrollo.
Tipos, niveles y estrategias de pruebas.
Cualidades de un buen Tester
El proceso de pruebas
Cómo se prueba en diferentes dispositivos
Herramientas más utilizadas.
Oportunidades laborales y de carrera.
Cómo automatizar las pruebas

Durante las dos horas del seminario, aprovecharemos también para escuchar sus inquietudes, ideas y comentarios sobre el mundo del Testing de Software.

¡Los esperamos!

Para consultar o inscribirse: Consultas

Adelante el UAT para dejar atrás los problemas

Uno de los principios del Manifiesto Agil dice “Colaboración con el cliente antes que negociación de un contrato“. Este principio es uno de los que más cuesta implementar en la práctica, ya que no depende del propio equipo, sino que implica a un tercero (el cliente, a quien, justamente, hay que incluir en el equipo para ser exitosos).

El UAT (User Acceptance Test) es uno de los momentos en que más se anhela que el cliente adopte una actitud colaborativa. Sin embargo, suele pasar que el cliente mantiene una postura típica de proyectos waterfall, donde esperaba pasivamente a que el software le fuera demostrado y se sentía en posición de mostrar el pulgar arriba o el pulgar abajo, a la manera del Emperador romano, con la potestad de aprobar o no.

Gladiator

Una forma de incentivar mayor colaboración del cliente, además de otros beneficios, es adelantar el UAT en el proceso de desarrollo. Se lo ubica antes del Testing, e incluso antes del code review, haciendo que el cliente revise la user story recién desarrollada y confirme que es exactamente lo que esperaba.

Creía que quería A, pero en realidad quiero B

El motivo más frecuente por el que una user story no pasa el UAT es que el cliente se da cuenta de que aquello que pidió no es exactamente lo que quería o necesitaba. O, lo que produce el mismo resultado, que se entendió mal el requerimiento.

O bien se da cuenta de que la funcionalidad resultaría mejor con algunos cambios. En todo caso, salen a la luz aquellas cosas que no tuvo en cuenta en un primer momento y que al ver el producto terminado se le hacen evidentes.

Con el UAT temprano, podemos identificar antes esos problemas, ahorrando ciclos y re-trabajo. Además, se produce el efecto de que el cliente asume mayor responsabilidad por sus requerimientos, lo cual facilita también las negociaciones cuando se decide que los cambios que solicita no se van a hacer.

Testing aliviado

Otro de los beneficios de adelantar el UAT es que se alivianan las tareas de Testing, ya que los Testers no tienen que preocuparse por las validaciones básicas de si se entendieron bien los requerimientos, si se cumplió con lo que quería el cliente, lo cual siempre implica idas y vueltas de preguntas y diálogos que llevan tiempo.

De esta manera, los Testers pueden concentrarse en detectar errores, haciendo su trabajo más eficiente (y divertido), acelerando los tiempos y minimizando los ciclos.

Desarrollo más seguro

El beneficio más visible para los Desarrolladores es que se sienten más seguros de que están desarrollando el requerimiento correcto, porque se minimizan los malos entendidos. Y, en los casos en que hay que rehacer el trabajo, esto se hace antes, cuando tienen el código más fresco y les cuesta menos introducir modificaciones.

Ahorro de tiempo y dinero

Lo más importante: menos ciclos, menos re-trabajo, menos tareas de Testing equivale a un significativo ahorro en los costos del proyecto.

Esto puede hacerse claramente visible después de un tiempo de implementada esta práctica. Al principio, puede resultar incómodo para el equipo tener al cliente involucrado tan tempranamente, cuando los desarrollos parece que todavía están un poco “verdes”. Pero a la larga, los beneficios son muy claros.

Estas son algunas de las ventajas de adelantar el UAT a una etapa más temprana. Claro está que una vez que se pasó la etapa de Testing, el cliente puede darle una mirada final para formalizar el sign off. Pero esto será un paso mucho más simple y directo porque el cliente ya vio el desarrollo tempranamente y lo aprobó. Se evita asimismo la ansiedad de esperar para ver qué le van a mostrar, en qué se convirtió su requerimiento. Y algunas sesiones de UAT en las que nos ha tocado estar donde el aire se corta con un cuchillo, porque el clima es tenso, como cuando el Emperador muestra su pulgar y nadie está seguro de si lo va a mover felizmente hacia arriba o trágicamente hacia abajo.

Esta práctica viene funcionando muy bien para nosotros y en proyectos donde algunos colegas nos cuentan que la han implementado. Los invitamos a probarla y contarnos cuál es su experiencia.

 

Nuevos Cursos de Testing en Exo Training Center

EXO TRAINING CENTER®, líder en Capacitación y Entrenamiento de Profesionales y Empresas de TI que buscan estar a la vanguardia del conocimiento y las Mejores Prácticas, ha anunciado recientemente un acuerdo con QAbility, para el dictado de cursos de Testing/QA de Software.

La propuesta resulta interesante, tanto para aquellos que buscan insertarse en el mercado laboral de IT, como así también para quienes necesitan fortalecer sus habilidades y así potenciar sus posibilidades de crecimiento dentro del mercado.

Se anuncian fechas para todos los meses de 2016, contemplando 4 propuestas de capacitación:

  • Formación de Testers Teórico
  • Formación de Testers Práctico
  • Testing en Mobile
  • Automatización de Testing

 

Más información en el sitio Web de Exo:

http://www.exotraining.com/cursos.html?cat=40

 

Unico Taller de Testing en Proyecto Real de Software

Dentro de la oferta de capacitación en QA/Testing, QAbility tiene una propuesta innovadora: el único Taller Práctico de Testing que se desarrolla en el marco de un proyecto real de desarrollo de software.

Esta capacitación permite que los asistentes incorporen la práctica del proceso de Testing, aplicándola en un proyecto que tiene todas las características de un verdadero desarrollo de software: se utiliza una aplicación Web desarrollada especialmente, junto con las herramientas que hoy por hoy son las más usadas en el mercado.

De esta forma, cada asistente recibirá la documentación del proyecto (muy completa para algunos requerimientos y muy informal para otros), y a partir de allí deberá diseñar los casos de prueba, ejecutarlos, descubrir los defectos existentes y reportarlos. Luego, se simula la corrección de los defectos y se ejecutan nuevos ciclos de pruebas, hasta quedar el software listo para el ambiente productivo. Es decir, tal cual sucede en cualquier proyecto de desarrollo de software en cualquier empresa. Todo esto con el permanente apoyo de los instructores, que irán guiando a los asistentes, evacuando sus dudas y consultas y colaborando para ayudarlos a incorporar buenas prácticas.

Por sus características, este curso permite a los asistentes sumar una práctica valiosa, muy cercana a la verdadera experiencia laboral, que además por su carácter intensivo les ayudará a entrar rápidamente en el ritmo de los proyectos reales.

Resulta ideal para todos aquellos que buscan incorporarse al mercado laboral en un área de Testing. Asimismo, es muy útil para quienes ya se encuentran trabajando en el área y desean fortalecer sus competencias.

Esta capacitación ya se encuentra disponible para empresas y próximamente anunciaremos las fechas en que estará disponible para el público en general.

Consultar

2 años de Tests de Performance en TN

Desde QA (aka Quality Assurance) trabajamos para mejorar la calidad de lo que producimos. Un ejemplo es el proceso de tests de performance que venimos haciendo desde hace tiempo en éste proyecto de TN que tanto queremos.

Antes que nada, es necesario aclarar las diferencias entre los tipos de pruebas de performance. No todas son iguales ni tienen los mismos objetivos.

  1. Test de carga: prueba de largo plazo de la aplicación con el caudal de tráfico de datos y usuarios habituales, los cuales llamamos concurrencia.
  2. Test de volumen: prueba de más corto plazo de la aplicación pero con un caudal mayor de tráfico de datos y concurrencia.
  3. Test de stress: su objetivo es conocer el “punto de quiebre” del sistema, ya sea en términos de hardware como de software. Es saber hasta donde “se la aguanta”. Para eso hacemos pruebas con niveles verdaderamente grandes de usuarios concurrentes, en los cuales simulamos acciones en el sitio y consumo de diferentes servicios.

Básicamente hay 2 maneras de obtener indicadores de performance:

  1. Fijar los usuarios concurrentes y sus repeticiones de acciones para medir los tiempos de respuesta de las llamadas (la experiencia de usuario, la cantidad de usuarios concurrentes que supuestamente soporta el sistema)
  2. 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)

Para realizar éste tipo de pruebas usamos una gran herramienta llamada Apache JMeter. Está hecha en Java, cuenta con interfaz gráfica y permite hacer varios pasos por llamada como también varias llamadas al mismo tiempo. También permite realizar parseo de expresiones regulares, graduar la cantidad de threads (hilos) concurrentes y un montón de cosas más.

JMeter simula carga en el servidor y permite estresar diferentes tipos de peticiones: HTTP, HTTPS, JSON, SQL, SMTP, LDAP y SOAP/XML como WebService SOAP. Además es Open Source, que no es un detalle menor. Este es un ejemplo de lo que podemos hacer con la herramienta:

graficos

Son los resultados de pruebas de stress ejecutadas sobre la home, la nota interna y los servicios más importantes que consume el sitio de TN. Todas fueron realizadas en entornos Beta (pre-lanzamiento). La primera corresponde al rediseño presentado en agosto de 2013; la segunda son pruebas actuales que incluyen la migración a Drupal 7.

Como se puede ver a simple vista, el trabajo constante que hacen los equipos de Desarrollo y Operaciones en performance da sus frutos. En los últimos 2 años los avances en los servicios son notorios, llegando a valores de mejora de 3000% más rápidos y eficientes. Eso quiere decir que están muy bien preparados para acompañar al crecimiento del consumo móvil de TN.

Nota del autor: originalmente publicado en el Blog de Todo Noticias

5 Principios para incorporar Testing a su Empresa

Recibimos frecuentemente la consulta de cómo “empezar a hacer Testing” en empresas que no tienen esta área formada, ni cuentan con Testers en sus equipos.

Es una realidad en el mercado de las empresas que desarrollan software, que llega un punto donde han crecido lo suficiente, y sienten esta necesidad. A menudo, surge como un desafío, de manera a veces traumática, porque se encuentran con que son capaces de entregar los desarrollos en tiempo y forma, pero el feedback que reciben de sus clientes es que el nivel de calidad percibida de los productos es muy bajo. O les sucede que tienen la oportunidad de trabajar con clientes más grandes, y estos directamente les demandan que realicen Testing de los desarrollos.

En todos los casos el problema es el mismo: descubren que necesitan incorporar prácticas de Testing, y se preguntan por dónde empezar. Vamos a ver entonces los principios básicos que se deben tener en cuenta a la hora de sumar el Testing a los desarrollos de software.

  1. Insertar el Testing en el proceso: lo primero que tenemos que ver es cómo vamos a incorporar el Testing a nuestro proceso. El primer paso es identificar con qué tipo de proceso estamos trabajando o necesitamos trabajar. Esto va a depender en gran medida del tipo de desarrollo que estemos realizando. Si tenemos la posibilidad de trabajar con metodologías ágiles, debemos tratar de incorporar el Testing desde las etapas más tempranas del proceso, sumando a los Testers desde el comienzo, para que participen de la especificación de los requerimientos, y puedan comenzar con el diseño de las pruebas lo antes posible. Si, por el contrario, el tipo de proyecto o el cliente nos exige utilizar una metodología más estructurada, deberemos tener en claro en qué momento vamos a hacer entrar el Testing, y bajo qué condiciones. En todos los casos, aplica la regla de que cuanto antes se comience con las tareas de Testing, mejor será y resultará más beneficioso para el proyecto. Un error común de quienes comienzan a leer e informarse sobre las prácticas de Testing es entender que necesitan cambiar todo el proceso. Esto produce la sensación de que incorporar Testing es algo complicado y hasta puede generar que se abandone la idea. Es importante tener en cuenta que si nuestro proceso es caótico o no está bien definido, de todas maneras podemos incorporar las prácticas de Testing, como un primer paso hacia lograr el ordenamiento. Con el tiempo, serán estas mismas prácticas las que nos ayudarán a ir delineando un proceso más disciplinado que nos permita generar resultados más previsibles.
  2. Generar condiciones de Testeabilidad: la testeabilidad se define como la factibilidad que tiene una aplicación para ponerla a prueba. Una aplicación es más testeable cuantas más pruebas podemos ejecutar sobre ella. Para ello, debemos generar condiciones de testeabilidad, cumpliendo con determinados requisitos, como: documentación del producto, tiempo suficiente para diseñar y ejecutar las pruebas, ambiente de pruebas a disposición y la aplicación instalada y funcionando en el mismo. No es indispensable contar simultáneamente con todas estas condiciones, pero al menos, deberíamos asegurarnos de cumplir con alguna de ellas. Por ejemplo, es importante contar con algún tipo de documentación que nos indique cuáles son los requerimientos funcionales y no funcionales. Es también clave contar con un ambiente adecuado y especial para las pruebas, ya que las mismas no pueden ejecutarse en el ambiente de desarrollo, porque éste no es estable, y por lo tanto los resultados obtenidos no serán confiables. Es deseable implementar al menos un versionado básico, que nos permita una correcta administración de la configuración, y de esa manera tener control sobre las versiones que se van generando, ya que esta es una de las bases sobre las que se cimenta la labor de Testing. Y por último, es indispensable asignar el tiempo necesario para las pruebas. El mismo debe ser adecuadamente planificado y respetado, para poder garantizar que ejecutamos las pruebas necesarias para asegurar un nivel de calidad aceptable en el producto final.
  3. Definir un proceso de Testing: a la hora de poner en marcha las tareas de Testing, necesitamos definir un proceso. Y con ello, no sólo las tareas que se van a llevar a cabo, sino también las herramientas que se van a utilizar, los entregables que se van a generar, etc. El proceso de Testing va a ser la guía básica para trabajar en todos los proyectos. No necesita ser un proceso complejo, puede ser algo tan simple como diseñar, ejecutar y reportar, pero sí es importante que se encuentre definido y esté claro para todo el equipo. Asimismo, las herramientas a utilizar pueden ser aquellas con las que la empresa ya cuenta (hojas de cálculo, procesadores de texto), o pueden seleccionarse herramientas específicas. Esto puede variar también de acuerdo a las exigencias de los clientes, y está relacionado con los entregables que el proceso de Testing debe generar. Normalmente, como mínimo, se generan reportes de defectos, pero también podemos necesitar listados de casos de prueba, reportes de resultados de ejecución y otros informes similares. Dentro del proceso deben definirse también los workflow para los casos de prueba y para los defectos, a fin de asegurar su correcto seguimiento.
  4. Brindar apoyo al nuevo equipo: en la práctica, no basta con armar un equipo (o contratar un Tester) e indicar que deben comenzar a realizarse tareas de Testing en el proyecto. Sobre todo, si ya contamos con un equipo de proyecto acostumbrado a trabajar sin Testing, vamos casi inevitablemente a toparnos con cierta resistencia. Esto implica que desde el management, deberemos empujar para que los Testers puedan ganarse su lugar dentro del equipo, y su labor sea valorada y respetada. De otra manera, se corre el riesgo de que sean pasados por alto o dejados de lado y todo siga funcionando como antes. Es por eso que hay que tener bien claro que los Testers van a necesitar de apoyo desde el management, al menos hasta que hayan podido insertarse en el equipo y sea claro para todos que están aportando valor. Habrá que combatir la típica visión Desarrolladores versus Testers, que sólo genera demoras y tensiones que atentan contra la productividad y la calidad. A menudo, también es necesario capacitar a todo el equipo en temas de Calidad y Testing, para que tomen conciencia de su valor y asuman que la calidad es responsabilidad de todos y no simplemente una serie de tareas asignadas a un grupo especial de personas. La capacitación bien realizada puede acelerar los tiempos de integración y hacer que ésta sea menos traumática.
  5. Formar el equipo de Testing: esto puede parecer obvio, pero está lejos de serlo. Para comenzar a hacer Testing, es necesario formar un equipo (que en principio puede ser de una sola persona) de Testers. Esto significa que debemos seleccionar profesionales idóneos para la tarea. Un Desarrollador no puede hacer Testing. Un Analista Funcional no puede hacer Testing. Un Líder de Proyecto no puede hacer Testing. Sólo un Tester puede hacer Testing de manera eficiente y generando verdadero valor para el equipo. Esto quiere decir que debemos elegir a una persona que se dedique pura y exclusivamente a testear. Debe ser una persona idónea, que idealmente cuente con experiencia y fundamentalmente que reúna determinadas características, que hemos detallado en posts anteriores. Sólo así vamos a garantizar los mejores resultados. Asimismo, si decidimos que necesitamos armar un equipo de más de una persona, deberemos considerar qué perfiles técnicos debería tener cada uno de ellos, cuál va a ser su rol y sus tareas. Siempre que se pueda, es aconsejable comenzar por una persona o dos y a partir de ahí ir creciendo, de acuerdo a las necesidades que vayan surgiendo. Armar un equipo completo de una vez es más complejo e implica mayores riesgos.

Estos son los principios básicos para comenzar a hacer Testing en nuestros proyectos. El camino para armar un área de Testing e implementar buenas prácticas es largo, pero estos principios nos van a permitir ponernos en marcha y dar los primeros pasos. A partir de ahí, las oportunidades de mejora se van a ir abriendo a medida que nos vayamos adentrando en este nuevo universo. Lo más positivo, no obstante, es que implementar estos principios básicos nos va a generar resultados que vamos a poder ver desde un comienzo. Será el puntapié inicial de un crecimiento que no tiene techo.