La aventura de enseñar testing

Desde un pequeño país que como decía el escritor argentino Jorge Luis Borges, pone mucho tesón en diferenciarse… y que tiene algunas curiosidades… surge esta idea singular: lanzar una carrera de testing.

¡La carrera de testing propuesta por el Centro de Ensayos de Software se inicia el 2 de mayo!

Es sin duda un punto de partida, quizás uno de los más ambiciosos que el CES, con su vocación de abordar problemas inéditos, se ha planteado en su relativamente corta trayectoria.

Pero también es un punto de llegada, un jalón fundamental en esta exploración que hemos emprendido juntos, la de conocer para testear y testear para conocer, como mencionamos tantas veces.  Enseñar y aprender testing, de eso se trata.

Comenzamos dando una asignatura opcional en la carrera de Ingeniería en Computación de  la Facultad de Ingeniería, Universidad de la República.  Incorporamos posteriormente nuevos temas para transmitir y transferir la experiencia del CES suministrando servicios de testing funcional, de performance y de automatización del testing funcional en diferentes industrias.

Ampliamos los cursos al ámbito de la Comisión de Posgrados y Actualización Profesional, y preparamos cursos comerciales, para informáticos y usuarios calificados. Fue la etapa de difusión del testing.

¡Más práctica!… fue el clamor unánime, y consideramos que era imprescindible ofrecer un “Ciclo de testing en la práctica” y así lo hicimos.

Luego nos preguntamos cómo podríamos contribuir mejor a difundir una cultura de testing, a impregnar de testing las actividades de construcción o adquisición de software. Lanzamos entonces el  curso “Testing para desarrolladores” que ya hemos impartido en varias instancias en Uruguay y México.

Cada uno de estos hitos constituyó un nuevo desafío, nuevas interrogantes y generó el esfuerzo por dar más y mejores respuestas.

¿Cómo continuar profesionalizando el testing? ¿Cómo demostrar cuán creativo e interesante es el testing? ¿Cómo demostrar el retorno de la inversión en testing? ¿Cómo dar continuidad al aprendizaje? ¿Cómo profundizar en conocimiento, experiencia y especialización? ¿Cómo explicar mejor y evaluar lo aprendido? ¿Cómo garantizar que lo aprendido puede ser aplicado en la realidad, en aplicaciones de gran porte, en infraestructuras complejas? Muchas veces, a mí personalmente, las dudas me impidieron avanzar. Pero mis compañeros del CES, los que comparten conmigo la labor cotidiana, me impulsaron, inspiraron y trabajaron para que este nuevo hito, sea a la vez un punto de llegada y de partida…

Tendremos seguramente muchos aciertos y también errores que esperamos superar juntos. Pero estamos convencidos que esta carrera ayudará a quienes se desempeñan como testers de software y a quienes quieren “probar” nuevos horizontes, a profesionalizarse y ser reconocidos por el valor que aportan al compromiso compartido por la calidad y la excelencia.

Mónica Wodzislawski

El tester diplomático: siendo parte del equipo

Al tester le toca en muchas oportunidades la fastidiosa tarea de ser (en el mejor de los casos) un inspector de calidad, y en ocasiones un verdugo (la peor pesadilla) de los desarrolladores.

Las actividades de verificación traen consigo la necesidad de reportar los errores, que por más que nos desvivamos en decir que son “del producto”, y que sostengamos nuestra eterna bandera de que “se evalúan productos y no las personas”, al fin y al cabo, esto recae sobre algún desarrollador.

En tiempos donde la presión y los plazos son ambiciosos (comúnmente, en proyectos de desarrollo de software suele ser todo el tiempo, ¿verdad?), esto se puede transformar en  confrontaciones o generar climas ásperos de trabajo.

Escenarios de trabajo del testing independiente

El testing independiente puede desenvolverse en varios escenarios. En general, podríamos categorizarlos en estos cuatro principales:

  1. Proyectos cortos dentro del laboratorio de testing independiente
  2. Proyectos permanentes o de larga duración dentro del laboratorio de testing independiente
  3. Proyectos cortos en permanencia con el cliente
  4. Proyectos permanentes, o de larga duración con permanencia en el cliente

Para dar una definición más acertada, deberíamos precisar los términos “cortos” o “permanentes”. Para el caso práctico, tomaremos como ejemplo de proyectos cortos aquellos que van desde dos o tres semanas, hasta dos o tres meses de duración máxima. Proyectos de larga duración, suelen consumir períodos mayores, y muchas veces, sin una fecha de finalización definida.

La premisa de una institución de testing como CES, es lograr ejecutar el mejor conjunto de pruebas dado el contexto, aportando información de valor a los interesados, como resultado de la aplicación de ingeniería de software y de testing (muchas veces en conocimiento, metodología e incluso en análisis con refinamiento o construcción de requerimientos).

Si bien, nuestro trabajo es encontrar los incidentes, cazar bugs… es diferente la actitud que debemos tomar dependiendo del contexto, y de ello dependerá su impacto y muchas veces nuestras relaciones interpersonales a futuro.

Para el propósito de este artículo, los escenarios 1 y 2 son casi análogos, dado que la interacción con el cliente suele ser menos frecuente, y en reuniones planificadas.

Los escenarios más delicados son el 3 y 4, siendo este último el más sensible y el foco de este artículo. Esto se debe a que la interacción con múltiples actores, el dinamismo, y el ritmo cambiante pueden ser el hábitat natural de estos testers.

Actitudes en relaciones interpersonales

En estas circunstancias, nos ha dado mucho resultado hacer foco en las siguientes actitudes:

  • Proactividad
  • Involucramiento con el equipo
  • Involucramiento con el producto y actitud ante el hallazgo de incidentes
  • Comunicación efectiva
  • Aprendizaje continuo y valor agregado

Proactividad

Este término todos los conocemos. Se trata de tener una actitud activa hacia las tareas del proyecto. Buscar la información y las soluciones, construirlas a partir de las múltiples visiones de los actores involucrados. Interactuar con las personas indicadas, respetando siempre los tiempos del otro, y considerando que en situaciones de alta presión, las personas son muy celosas de su tiempo disponible, por este motivo, la consulta de información tiene que ser certera y esquemática, apoyada en un análisis previo de los temas a tratar. Cuando no es posible llegar, o se han acumulado muchas dudas respecto a determinada situación, o se obtienen opiniones muy desencontradas, será necesario tener una instancia de reunión; pero este debería ser siempre uno de los últimos recursos. La proactividad implica buscar las soluciones, optimizando nuestro tiempo y el tiempo de los demás.

Involucramiento con el equipo.

Es importante sentirse miembro del equipo, y tratar de realmente serlo, haciendo que el resto de las personas nos perciban como tal. La interacción persona a persona, el preferir la comunicación verbal al correo electrónico, valorar los aportes de los diferentes expertos explícitamente y comunicar pequeños o grandes logros, retribuyendo a las personas involucradas con un comentario positivo, son algunas de las actitudes que pueden ayudar a lograrlo. Por supuesto que involucrarse en actividades sociales es altamente positivo (reuniones extra laborales, participación grupal en comidas, actividades deportivas), generar propuestas, y tener la iniciativa. La experiencia indica que las opiniones negativas hacia una persona tienden a desaparecer cuando se comparten actividades sociales de este estilo con compañeros de trabajo.

Involucramiento con el producto / Actitud ante el hallazgo de incidentes

Hacernos y sentirnos parte del equipo, nos facilitará el tomar la actitud de ser parte también en la construcción de ese producto, desde el punto de vista del aporte en calidad. Por ese motivo, se debe tornar desde el foco “destructivo” del testing (intentando rápidamente quebrar el producto en cuanto a su funcionalidad y rendimiento), al foco de “despojar de errores y mejorar la calidad”. Si bien el trabajo es el mismo, y la intensidad también es la misma, este último enfoque es el más adecuado para interactuar con las personas que están construyendo un producto, sean desarrolladores, arquitectos o gerentes de tecnología, entre otros. En nuestras interacciones interpersonales se notará que nosotros de alguna manera “queremos” al producto y estamos preocupados por la presencia de incidentes en él. Nuestra retribución personal ante el hallazgo de incidentes cambia de ser cazadores voraces de los más grandes y mejores bugs, para luego de reparados mejorar la calidad del producto; sino es el encontrar incidentes, lo antes posible, antes de que los usuarios finales los encuentren, y ver el producto, también “nuestro” producto, mejorando su calidad gracias a nuestro trabajo. Y este es uno de los puntos más importantes que quiero destacar.

Comunicación efectiva

Tanto por correo electrónico, por teléfono o personalmente, tenemos que ser capaces de sintetizar la información a trasmitir, y la información que queremos obtener. Una buena técnica, para nada novedosa, es que antes de la comunicación hagamos un esquema con los puntos a tratar, nuestras dudas y lo que queremos informar. Para la comunicación con superiores, o personas que tengan que informarse de nuestros avances, obstáculos, o tomar decisiones a partir de nuestra información, es importante tener en cuenta la información esquematizada. Es común que estas personas tengan muy poco tiempo para consumir nuestra información e inclusive seguir la lógica de nuestro razonamiento. Cuando es mucha la información a transmitir, una buena técnica, es anexar un resumen,  al final del correo, resaltar las partes importantes en negrita, utilizar estilos, tabulación, tablas, y colores (no más de tres preferentemente dicen los entendidos en usabilidad y comunicación efectiva). Limitar nuestras dudas, reclamos y sugerencias a las que realmente apliquen. Seremos bien considerados si los problemas los acompañamos de soluciones, o sugerencias.

Aprendizaje continuo y valor agregado

En todos los entornos de trabajo y de todas las personas podemos aprender. Tener la mente abierta a incorporar nuevos conocimientos y estar atento a las diferentes visiones. Solemos no prestar demasiada atención a las personas que nos están transmitiendo información “repetida”, pero en cambio, una práctica bastante útil puede ser el consumir esa información, dado que la visión de esta otra persona, nos puede ayudar a consolidar el conocimiento ya adquirido, y tener nuevas herramientas cuando tengamos que trabajar, y retransmitir esa información. Nuestro saber se ve enriquecido, y además, podemos ser más críticos y compartir nuestro conocimiento, desde una perspectiva constructiva. Por ejemplo, es preferible mantener el silencio en una reunión, a exponer nuestro supuesto “conocimiento superior” al respecto del punto tratado, si este no tiene realmente un valor agregado al objetivo de la reunión.

Para finalizar 

En este artículo, se pretendió presentar brevemente algunas actitudes personales del testing independiente que pueden ser útiles en la interacción con grupos numerosos de diversos orígenes en proyectos complejos y de gran escala.

Además de favorecer al proyecto en sí, y la vida profesional, suelen generar muy buenas relaciones interpersonales, buen ambiente de trabajo e incluso algunos buenos amigos.

Christian Pla

¿Automatizamos las pruebas funcionales?

En general, en el ambiente del software se conocen los beneficios de disponer de pruebas automatizadas. Sin embargo, es menos común entender los costos que esto implica. No están claras las características de la inversión asociada.

El desafío es decidir cuándo y cómo invertir en automatización de pruebas para conseguir un proyecto exitoso (proyecto de automatización). Para esto es vital analizar el contexto, o sea, el producto, el proyecto de desarrollo y la empresa (desarrolladora o consumidora de software).

Para aquellos que aún no han automatizado pruebas funcionales en su ámbito de trabajo, a continuación se presentan ideas que pueden ayudar a evaluar cuándo empezar.

Es una inversión

Los beneficios de la automatización se verán luego de varios ciclos de ejecución, por lo tanto la inversión tendrá que ser sostenida.

No se trata de un esfuerzo inicial y luego esperar. De nada sirve comprar la licencia de una herramienta de automatización y no invertir en la creación, mantenimiento y ejecución de las pruebas. Sería como comprar una licencia de Visual Studio 2010 y esperar que las aplicaciones estén listas. Esto es sólo el comienzo, un proyecto de automatización de pruebas es también un proyecto de desarrollo de software.

Son conocidos los casos en los que se compran “mágicas” herramientas de automatización y luego quedan olvidadas en el armario.

Si en cambio, se decide invertir en dominar una herramienta de código abierto o libre, la situación será similar. Una vez adquirida la experticia necesaria, se deberá seguir trabajando en el proceso de creación y uso de las pruebas.

Según el producto

Será necesario considerar las herramientas existentes para automatizar las pruebas según la tecnología usada, Web, GUI, Web services, protocolo de comunicación, etc. Las interfaces del producto nos dirán si automatizar las pruebas será difícil, factible, fácil, etc. La complejidad para automatizar el accionar de una interfaz y la forma de validar el resultado de una prueba nos dará información sobre el esfuerzo necesario.

El producto puede requerir trabajar en múltiples plataformas: sistemas operativos, bases de datos, navegadores, etc. Si se mantienen las interfaces para las diferentes plataformas, podemos probar con las mismas pruebas automatizadas ahorrando tiempo de desarrollo. Por ejemplo, supongamos que tenemos una aplicación que requiere ejecutar sobre plataformas de PC (Intel y Mac) y en móviles (con iOS, Android, Windows Phone), con las variantes posibles en cuanto a navegadores (IExplorer, Firefox, Chrome, Opera). Las pruebas pueden ser las mismas y simplemente ejecutarse en cada configuración.

Según el proyecto

El proyecto determina cuántas iteraciones se esperan y con qué frecuencia. También puede tratarse de un producto que no tiene un plan determinado por un proyecto, sino que el ritmo y calidad de liberación son determinadas por las exigencias del mercado. Esto nos dirá cuánto utilizaremos nuestras pruebas automatizadas.

Por ejemplo, si estamos hablando de un desarrollo con metodologías agiles, está soportado en la automatización. En el otro extremo, si esperamos pocas iteraciones le daremos menos uso a la automatización.

Hay que considerar no sólo las iteraciones en la etapa de proyecto, sino aquellas que aparecen una vez liberado el software, en el mantenimiento urgente y evolutivo. En esta etapa las pruebas automatizadas toman un valor importantísimo, para probar rápidamente liberaciones urgentes, aportando tranquilidad sobre el cubrimiento de las pruebas.

Según la empresa

Se puede afrontar el desafío de la automatización desde el inicio del proyecto de desarrollo de la aplicación o después, esto también depende de las características de las empresas.

Empresas pequeñas o nuevas quizás no lo pueden afrontar al inicio. Es posible que no tengan los recursos para destinar a la automatización.

Otras pueden afrontar el desafío, pero se pospone, llegando a un momento en el cual las versiones salen casi sin testing. Esto puede darse porque el producto es muy grande, o se liberan versiones muy frecuentemente, o tienen múltiples versiones de un producto para diferentes clientes, plataformas, etc. El testing manual no tiene la capacidad de llevar a cabo el trabajo.

Es importante analizar el entendimiento en la gerencia y en el equipo de desarrollo sobre los beneficios y trabajo detrás de la automatización. Se necesitará el apoyo y compromiso de ambas áreas para llevar adelante el proyecto.

Se tendrá que evaluar la disponibilidad de recursos humanos para destinar a la automatización. Como mencionamos, la automatización es también un proyecto de desarrollo, lo que implica que se necesita un perfil desarrollador/tester.


Cuando

El momento adecuado dependerá de todas estas variables.

Si nos adelantamos podemos encontrarnos con inmadurez en el equipo de testing, esto podría llevarnos a descuidar las pruebas manuales, que nos dan beneficios a corto plazo. Si la organización no tiene claro lo que implica la automatización, pueden aparecer expectativas no realistas, frustración y abortar el proyecto.

Como se dice comúnmente, “nunca es tarde” para hacer las cosas. Pero puede pasar que otros competidores liberen más rápido, con mayor calidad, los clientes no estén conformes con la calidad, los usuarios ya no crean en la aplicación, etc. Todos estos problemas pueden afectar seriamente las ventas del producto o el éxito del proyecto.

Por lo presentado, resulta importante evaluar desde el inicio y periódicamente si estamos en el momento adecuado para arrancar con la automatización de pruebas. Se puede comenzar con una inversión pequeña aunque sostenida, tratando de no dejar pasar el tren.

En posteriores entradas al blog hablaremos de cómo encarar de mejor manera este camino.

Mauricio Farías