Tester tradicionales e ineficiencia de los procesos

 

 

 

Este título viene a raíz de un comentario que hice en uno de los grupos en los que participo en LINKEDIN. Alguien expuso:

 

… en cuanto mas sepa un desarrollador, mejor para los testers porque el codigo que escriban sera menos propenso a errores y en definitiva con menos bugs nos beneficiamos todos.
De todos modos el trabajo de tester / qa nunca deberia dejar de existir.
Por mas conocimiento que tenga un programador es un ser humano, no una maquina por lo cual siempre ocurrirán fallas.
Luego se debe auditar.. no deberiamos dar por entendido que todo lo que hicieron los programadores esta bien, tiene que haber una persona que lo compruebe.
Por ultimo los errores no solo pueden ser de programacion sino de funcionalidad por eso se debe comprobar que se cumplen los requerimientos que pide el cliente (refiriéndose a un tercero auditando el trabajo)

Mi opinión fue la siguiente:

Estimado, no estoy de acuerdo en aquello que aseveras …”De todos modos el trabajo de tester / qa nunca debería dejar de existir” si es que estás haciendo una afirmación, ni en “Luego se debe auditar”, tampoco con “tiene que haber una persona que lo compruebe”.

Algunas metodologías de desarrollo han permitido formar, facultar y fomentar equipos de desarrollo sinérgicos, sin un departamento de calidad adherido, por lo que no existen testers ni QA para auditar trabajo en fases tardías. En este contexto, el aseguramiento de calidad está a cargo de absolutamente todo el equipo de desarrollo, interesados e inclusive clientes.

Tal es así que se busca la terminación de artefactos de calidad, basados en la anticipación y prevención de defectos y no en su detección tardía. Nuevamente, no existe aquello de que debe existir alguien que audite a otros, ni compruebe si algo está bien o mal.

Con estos modelo de trabajo todas las actividades de pruebas son extremadamente importantes, yo personalmente llamo a estos equipos como “Embedded Testing Teams” (equipos embebidos en testing), y de hecho los expertos en pruebas des software son los mismos desarrolladores, quienes diseñan, desarrollan, ejecutan y mantienen las pruebas a distintos niveles.

En la vereda del frente se encuentran metodologías del desarrollo que promocionan auditorias e inspecciones a los artefactos de software que son salidas de alguna fase, o sea al final del trabajo de alguien. Absolutamente todas estas auditoras y/o inspecciones generan algún nivel de retrabajo, del mismo modo que el testing que tradicionalmente conocemos, de hecho, las auditorias e inspecciones son nada más y nada menos que técnicas de testing estático.

Colegas, admitamos que los “tester tradicionales” existen gracias a la ineficiencia de los procesos tradicionales y por supuesto a la ineficiencia no solo de sus “desarrolladores”, sino de todos los roles que admiten, se adaptan y permanecen en estos modelos de trabajo.

Advertisements

Quien es quien – I

Pensando los Roles y Competencias para definir nuestro proceso de trabajo

Las metodologías de desarrollo de software suelen establecer roles y delimitar sus competencias,  remarcar sus responsabilidad, indicar interdependencias, definir elementos de entrada-salida y proponer la repetición constante de estos ítems, con variantes que le dan alguna particularidad a los distintos procesos.

El objetivo es inicialmente presentarse de manera clara al publico usuario, como un mecanismo  estable, controlable, medible y repetible, que garantice en mayor o menor medida, el éxito de los proyectos permitiéndole llegar a su fin, con el uso de la secuencialidad propuesta.

Suele suceder que los modelos parecieran no tener en cuenta al área QA y Testing como un área independiente dentro los proyectos de productos/servicios, que genera su propio proyecto donde conviven productos/servicios que dan soporte al proyecto matríz.

Tal es así que las competencias QA y Testing no son tan bien definidas  y explicadas como las compentecias de otros roles, en la mayoría de los procesos. Y aunque algunos presentan detalles excesivos, quizás no encuadran correctamente a los roles QA.

Independientemente del proceso que se intente aplicar y su definición de roles y competencias, sugiero que las organizaciones consideren la aplicación de roles, pero justificado principalmente por el enfoque y especialización que exista o se desee.

Por ejemplo, la existencia de Líderes de Proyectos que a su vez sean verdaderos especialístas en los negocios que generan los productos que lideran.

Los Arquitectos de Sistema los mejores diseñadores y programadores, sobre todo líder especialista en “los aspectos íntimos de los sistemas”.

El Líder QA de perfil analítico transversal y el principal
“entrenado” en el uso de los productos en prácticamente todos los
niveles de los sistemas. También uno de los probadores más
importantes de la organización, guía de pruebas en todas las fases de revisión.

El equipo de testing  con competencias técnicas variadas y acabadas, conocedores de técnicas y métodos de pruebas, pero con grandes atributos actitudinales.

Las principales potencias de un equipo QA bien conformado quizás son:
capacidad analítica en el sentido transversal a lo que se supone como
la mejora solución técnica, la obsesión por demostrar que el sistema
tiene defectos, orientación bien marcada a las pruebas exploratorias,
proactividad y comunicación eficiente, entrenamiento anticipado en el
uso del sistema, énfasis en detectar debilidades en los requerimientos, énfasis en reconocer y entender por que y para que existe cada requerimiento, capacidad de proponer nuevas alternativas de uso, control del tiempo y el sentido de fin de fases.

Creo que habilidades de esta naturaleza no solo en los roles QA, sino en otros que reciben productos de fases anteriores y las destilan a fases posteriores en los procesos de desarrollo, ayudan a definir un proceso bien limpio y delimitado para elaborar, planificar, seguir y finalizar los proyectos.