La movida del testing

Para empezar el 2014 con toda la fuerza, queremos compartir algunos puntos a tener en cuenta al momento de incluir y/o mejorar el testing en una organización. No es una tarea sencilla y requiere instancias de análisis y otras de tomas de decisiones.

Es importante: pensar, apropiarse, difundir, seleccionar, definir metodología, comunicar, definir un proyecto piloto y mejorar

 

Pensar

Podemos tener la idea en nuestra cabeza de formar un equipo de testing o de contratar servicios de testing independiente. Es  mejor no actuar por impulso designando rápidamente recursos que comiencen a probar. Es probable que no se logren hacer buenas pruebas y que se generen conflictos rápidamente.

Una alternativa es que alguien externo a la organización con conocimiento en testing, proyectos y equipos analice la forma de trabajo y las dificultades que enfrenta la organización y evalúe si formar un solo equipo de testing, varios, o contratar servicios de testing independiente. Además que dimensione los equipos, e indique la capacitación requerida.

Apropiarse

Antes de crear planes de acción, tenemos que estar convencidos de los cambios y de los objetivos que nos proponemos.

La organización tendrá que analizar las propuestas y definir cuales implantar. La idea es que, si bien un actor externo propuso las recomendaciones, la organización las procese, y se convenza y apropie de las mismas.

Difundir

La difusión de los cambios que se vendrán es otra forma de que la organización se apropie de la idea y que cada actor aporte su granito de arena.

Por lo tanto, difundir en la organización la movida en temas relacionados al testing  y cuáles son los objetivos a lograr es un paso que no puede faltar.

Seleccionar

Sea cual sea la decisión, formar un equipo interno o contratar servicios, tenemos que seleccionar quiénes integrarán estos equipos.

Aunque se tercericen los servicios de testing, siempre será necesaria una contraparte dentro de la organización. La contraparte no tiene que tener conocimientos específicos en testing, pero si estar convencida de que con esta movida organizacional se mejorará la calidad de lo producido.

No es una etapa sencilla decidir quiénes formarán parte del equipo. Todos los integrantes tienen que tener conocimientos en testing, y en el corto plazo también conocimiento en el negocio de la organización.

Es usual ver una empresa que forma un equipo de testing con personas sin conocimiento en la materia que prueban sin metodología y a pura intuición, sin priorizar ni preocuparse por el cubrimiento. Claramente la experiencia no colmará las expectativas y sumará nuevos problemas.

Definir metodología

Definir una metodología y forma de trabajo del equipo de testing será el primer proyecto al que se enfrentará el equipo. La metodología no solo incluye aspectos técnicos, sino cómo serán las interacciones con los distintos equipos.

Comunicar

La metodología no pueden ser papeles en un cajón, tiene que impregnarse en la organización para que se aplique. Por lo tanto hay que comunicar la forma de trabajo y metodología propuestos. Someter la metodología a que todos la estudien y opinen es una forma de involucrar a los distintos actores.

Ante los “no tengo tiempo”, es una buena práctica generar reuniones de trabajo eficientes y productivas.

Definir un proyecto piloto

Comenzar de a poco es importante, por ejemplo definiendo un proyecto que sea de dimensiones manejables, en el que el equipo comience trabajando en conjunto y aplicando la metodología.

Mejorar

Por último, aplicar, evaluar y mejorar para continuar aplicando ayudará a alcanzar nuestros objetivos. La metodología y forma de trabajo irá cambiando y mejorando a partir de la experiencia que se va generando.

En próximas entradas del blog les contaremos, a partir de nuestra experiencia, dificultades que se presentan al saltearse algunos de los puntos detallados.

 Mariana Travieso

¿Cuánto vale el testing?

Hace unos días me pusieron ante una pregunta que es de las más difíciles que me han hecho en una reunión y además me agarró
totalmente desprevenido: ¿Cuál es el valor de los servicios del CES?

Lo primero que hice fue darle el listado de los precios de los diferentes roles, contándole además que en realidad se debía estimar el proyecto, la dificultad de la tarea a realizar y el tipo de testing. Sin embargo, me dijeron que no lo estaba entendiendo: me preguntaba por el valor y no por el costo. Y tenía razón, hay una clara diferencia entre ambos conceptos. Aunque, sin lugar a dudas, existe una estrecha relación entre ambos.

Poniendo las decisiones en perspectiva
Lo primero que hice fue pensar en un ejemplo. Supongamos que estamos ante el desarrollo de un sistema para un cliente importante. Una de las decisiones antes de comenzar el proyecto será el de evaluar el plan de testing de la aplicación y ver qué tipo de testing y que esfuerzo se dedicaría al mismo (estoy dejando fuera de manera deliberada a aquellos que se cuestionan la realización de t

esting en sí, pero tengamos en cuenta que esa gente también existe, por las dudas).

Si este cliente no tuviera exigencias de calidad en el sistema, posiblemente vería el esfuerzo adicional como un costo que no le aporta nada al proyecto. En ese caso el valor del testing es casi nulo; incluso el precio más bajo que pudiéramos darle para la realización de dicha tarea (incluso aquel precio en el cuál como proveedores podamos perder dinero) le parecerá caro. Pero supongamos que el cliente tenga requerimientos de calidad altos, con un negocio dependiente de lo que estamos desarrollando y en el cuál un error pueda representarle una pérdida de plata directa (ya sea por SLAs no cumplidos, lucro cesante por no disponer del sistema, lo que sea…), seguramente vea esos precios como una inversión y por lo tanto pague nuestros precios sin muchas objeciones.

También existen otros factores que puede darle valor a nuestro trabajo, como por ejemplo, cuanto repercuten los errores en la imagen o reputación del cliente.  Allí ponerle un valor es difícil, quizás la mejor pregunta para hacerse es cuál es el valor máximo que el cliente le da a su imagen, a su reputación. Algo mucho más subjetivo que el dinero, pero que en algunos casos, si bien no representa un costo directo, es importante.

Por defecto, la realidad me ha indicado que el testing no es de las actividades que se tienen en cuenta de planificar. Principalmente estoy convencido de que esto sucede porque no sabemos o no somos capaces de transmitir el valor de las actividades que realizamos. Un valor que nos permita hacer el switch y poder hacer el click en aquellas personas que toman las decisiones. Solo así se logrará que las tareas de testing sean vistas como algo que aporta valor en el sentido más estricto de la palabra.

Luego, atado a eso, vendrán los costos asociados a realizar esa tarea y allí se juega el otro tiempo del partido.

Poniendo precio a nuestro trabajo
El valor que tendrá nuestro trabajo para el cliente será el límite superior que nuestro precio podrá alcanzar. Si lo que nosotros marcamos a nuestro trabajo es mayor que el valor de realizar las actividades de testing, ¿Por qué el cliente se sentirá inclinado a cambiar la decisión de invertir en la calidad del producto?

Claro está que también existe algo que se llama mercado, por lo cual tenemos que tener en cuenta, a la hora de poner precio a nuestro trabajo, que el mismo no puede ser puesto basándose exclusivamente en el valor aportado (lamentablemente no somos Henry Ford vendiendo autos en el 1900, donde Ford vendía el auto del color que quisiera el cliente, siempre que fuera negro). Posiblemente allí le hayamos dejado claro el valor, pero encontrará un costo menor al nuestro para poder alcanzarlo.

Sin embargo, por más apropiado que sean nuestros precios a los del mercado, si no logramos aportar valor al desarrollo de software y por ende al producto, difícilmente alguien firme un cheque para realizar testing. Y es allí donde podemos aportar un diferencial: no necesariamente siendo más baratos, sino siendo los que aportemos más valor.

Curso online “Puertas abiertas al testing” gratis

Para todos aquellos que quieran conocer de qué trata esta apasionante disciplina o conocer cómo el CES concibe esta profesión se publicó Puertas abiertas al testing.

Es un curso que presenta una introducción general sobre el testing y sobre diferentes tipos de pruebas.  Está disponible en la plataforma de capacitación del CES, abierto a todo el mundo.

Los cursos de la Carrera de Testing del CES utilizan la plataforma de la misma forma incorporando además foros, chats, videoconferencias, ejercicios teóricos y con especial énfasis, ejercicios prácticos.

Esperamos que lo recorran y lo disfruten.

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

Contratando a un tester

Una de las problemáticas actuales en la industria de software de Uruguay es la rotación de personal, las empresas invierten una y otra vez en que las personas dominen tecnologías, dominios de aplicación y herramientas. Estos cambios se dan con desarrolladores, analistas y testers, entre otros.

Si bien en Uruguay se le está dando más importancia al testing de software en las universidades, centros de capacitación y en las empresas,  hay que tener en cuenta que el testing es una disciplina que aun está en pañales. Por lo que usualmente quienes hace tiempo testean son quienes están desempeñando tareas relacionadas al liderazgo de proyectos de testing.

Las empresas, deciden buscar en el mercado local personas dedicadas a realizar actividades de testing  ya sea porque se quiere mejorar la calidad de los productos o porque necesitan reemplazar a alguien que abandonó la empresa.  No es tan sencillo conseguir un buen tester y tenemos que ser cuidadosos en el proceso de selección y en el período de adaptación del nuevo integrante a la empresa.

Primero tenemos que pensar cómo concebir al testing, para luego bajar a tierra las ideas considerando el contexto de la organización para que nos ayude a decidir a quienes necesitamos, y con qué perfiles.

Una de las definiciones que más nos gusta es aquella que define al testing como una investigación técnica de un producto bajo prueba con el fin de brindar información sobre la calidad de un producto (James Bach). Esta definición, ni ninguna otra que veamos, nos indica quiénes, cuándo o cómo hacer esta investigación, ya que depende del contexto, del producto, del proyecto, etc., pero nos indica mínimas habilidades a considerar. Por ejemplo podemos requerir las características generales de un investigador (como que sea organizado y genere conocimiento original y relevante, entre otras).

Me gustaría compartir un artículo que leí: “The Art of Recruiting” del ex-evangelizador Apple Guy Kawasaki,en el que se detallan 10 consejos a tener en cuenta cuando se contrata personal para trabajar en una empresa.  Uno de los consejos es “Contrata gente infectada.” Indica que típicamente las organizaciones buscan gente con background educativo y profesional “correctos”. Estoy de acuerdo con Kawasaki, en que hay que agregarle una tercera cualidad, la pasión: ¿El candidato está infectado de pasión por tu producto? Porque no importa toda la educación y la experiencia profesional del mundo si el candidato no consigue apasionarse.

Este consejo sirve para contratar personas para cualquier rol, pero en testing es un factor fundamental. El testing no es una actividad sistemática, se necesita creatividad para imaginar posibles problemas y el pragmatismo para implementar y simular ambientes y situaciones para ejecutar pruebas y ver cómo se comporta nuestro software. La idea es detectar defectos y fallas antes que el usuario final las detecte, hay que conocer las características del software y también a los futuros usuarios.

Tenemos que preguntarnos qué valor le da al negocio un tester que conozca de conceptos, estrategias y técnicas de testing, pero que siempre utilice los mismos checklist, corra pruebas de regresión sin agregar nuevos casos cada vez y/o que evalúe el cubrimiento de las pruebas en extensión y no en profundidad.

Cuando estamos evaluando a una persona para desempeñar el rol de tester, tenemos que verificar cuales son los conceptos que maneja del testing.

Hay que evitar que los futuros testers tengan ideas equivocadas sobre la disciplina de testing. También hay que intentar no transmitir estas ideas y si ya son parte del posible nuevo miembro, tendremos que considerar esfuerzo para cambiárselas y hacer que no sólo se apasione por el/los productos, sino también por el testing.

Cuidado cuando se considere que:

  • algunos mitos son verdades, por ejemplo
    • Cualquiera puede testear
    • Es malo desarrollando, ponlo a testear
    • Los testers son malos desarrollando
    • Para testear es mejor no ser informático
    • Sólo los informáticos son buenos testers
    • El tester es el custodio de la calidad
  • no hay posibilidades de crecimiento, o que la participación del tester nunca será importante en la empresa
  • puede ser reemplazado por otro tester y que no se verá la diferencia
  • los resultados no serán utilizados para mejorar la calidad del producto
  • se subestiman los resultados de las pruebas

Un punto relevante en este tema son las especializaciones en testing existentes. Para pensar los títulos y diplomas para Testers como requisito para la contratación, tenemos que saber qué significa tenerlos. 

En la actualidad se imparten algunos cursos de testing para empresas de la industria y asignaturas específicas en carreras relacionadas al desarrollo de software.  No hay una capacitación en testing que considere la capacitación académica con las posibles  especializaciones. Las certificaciones más conocidas están orientadas a evaluar que se conozca una terminología común, las problemáticas frecuentes de las pruebas y algunas técnicas de diseño de pruebas. No se evalúa la práctica, experiencia ni habilidades necesarias para hacer investigación de los productos bajo prueba.

Por lo tanto al momento de contratar un nuevo tester en la empresa es importante que se planifiquen las actividades iniciales para transmitir la pasión por producto y por el testing para que la información obtenida de las pruebas le de valor negocio.

Me gusta pensar que en ocasiones es mejor un diamante bruto en mano que diamante pulido rotando. Esto significa que puede ser más productivo contratar a alguien con conocimiento en un dominio de aplicación y no tantos en testing, para irlo formando, capacitando y apasionarlo por la empresa y los productos, que contratar a alguien con certificaciones, titulaciones y/o con experiencia pero con pensamientos negativos respecto a las pruebas.

Algunos puntos a evaluar en un tester, tenga experiencia previa o no:

  • analítico, asertivo, atento, cauto, certero, claro,comprometido, conciso, creativo, crítico, curioso, deductivo, desconfiado, detallista, diplomático, explícito, buencomunicador, entre otros.
  • y otra cualidad importante es que tenga capacidad para adaptarse a los cambios

Si bien no podemos asegurar que una persona no abandone la empresa para ingresar en otra, podemos jerarquizar el testing, y darle importancia a nivel de planificación y de toma de decisiones, para que la persona vaya capacitándose en el negocio y en testing sin perder la motivación.

Básicamente el proceso de contratación consta de 3 etapas: La convocatoria, la selección dentro de los candidatos que se presentaron y la incorporación al equipo de trabajo del nuevo miembro.

Instanciar este proceso para contratar a un tester requiere que en la convocatoria detallemos las habilidades y experiencia que buscamos, pensando en el testing como actividad cognitiva. Para seleccionar al tester, además de conocer su formación tenemos que ser capaces de evaluar su capacidad por apasionarse por el testing y por nuestro producto. En base a conocer más de nuestros candidatos podremos estimar el esfuerzo para que se incorpore a nuestro equipo y obtengamos los resultados esperados.

Mariana Travieso