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

Office development Software more adecuate than Software Factory

Mientras que los procesos manufactureros se concentran en los procesos, los procesos de desarrollo de software suelen estar centradas en las personas. Es por eso que tal vez  los ahorros y los beneficios que se producen en la industria del software debido a la mejora del proceso de actividades, no son realmente importantes.
Por ejemplo, parte del proceso SIX-SIGMA consiste en identificar la causa raíz de los problemas y luego encontrar y aplicar una solución. Un requisito para lograr la mayor efectividad del proceso, es que las operaciones sean repetitivas.
Procesos como SIX-SIGMA son principalmente aplicables a industrias donde las operaciones y las actividades son prácticamente idénticos y repetitivas, mientras que quizás esta característica no existente en los procesos de desarrollo de software.
No hay que ser drásticos ni decir que SIX-SIGMA no es aplicable a los procesos de desarrollo de software, pero si es posible decir y comprobar que su aplicación no mejorará sustancialmente los beneficios como lo puede hacer en la industria manufacturera.

Algunas diferencias entre estas dos industrias son:

1 – en Manufacturing, cada producto de la serie tiende a ser idéntico a un modelo específico. En el desarrollo de software cada producto es personalizado (de otra manera no hay nada que desarrollar)
2 – en Manufacturing, para cada operación el proceso es idéntico, mientras que en el desarrollo del software varían en términos de contenidos.
3 –  en Manufacturing, los trabajadores ejecutan su trabajo en niveles muy parejo de efectividad, mientras que en desarrollo de software las habilidades varían ampliamente, como también los niveles de calidad y efectividad.

De esta manera es facil observar que las actividades implementadas para mejorar un proceso específico o resolver un problema de desarrollo de software, pueden no ser válidos para otro de la misma empresa. También el grado de éxito cada proyecto es siempre diferente.

Se puede concluir que en el proceso de desarrollo de software existe una variabilidad por la componente humana, que introduce grandes cantidades de errores que necesariamente escaparán a cualquier control. Esto evita en gran medida la obtención de procesos de consistencia hermética.

Entonces tal vez deberíamos modificar el término Software Factory evitando hacer un parangón con los procesos de fabricación manufacturera y pasar a un término más acorde, como puede ser “Office Software”. De esta forma también se delimita la forma en que cada una de estas industrias utiliza sus recursos y habilidades.