Menú

¿Qué es la deuda técnica y por qué los evaluadores de control de calidad deberían preocuparse por ella?

  • Principal
  • Pruebas Ágiles
  • ¿Qué es la deuda técnica y por qué los evaluadores de control de calidad deberían preocuparse por ella?

what is technical debt

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Deuda técnica es una idea metafórica que sostiene que así como uno puede encontrarse con problemas de deudas en finanzas, las organizaciones de software encuentran algo similar en la acumulación de trabajo sin terminar durante proyectos pasados ​​y lanzamientos de versiones / sprints.

¿Qué es la deuda técnica?

Representa el esfuerzo necesario para solucionar los problemas / defectos que permanecen en el código cuando se lanza una aplicación. En palabras simples, es la diferencia (en términos de errores) entre lo que se espera y lo que se entrega.

Cuando un equipo de desarrollo está ocupado trabajando en un proyecto y corrigiendo errores, desafortunadamente, aparecen muchos errores nuevos. Fuera de estos, algunos son fijos y otros se diferencian para su posterior publicación. Cuando esta diferencia de problemas sigue aumentando, en un momento dado se vuelve realmente difícil lanzar el producto a tiempo sin ningún problema. Esta es la peor consecuencia de Deuda técnica si no se aborda a tiempo.

En este artículo, aprenderá qué es la deuda técnica, por qué el equipo de control de calidad debe preocuparse por ella y, lo más importante, cómo administrarla.

¿Qué es la deuda tecnológica?

imagen fuente

Ward Cunningham , el fundador del software wiki, concebido de esta idea allá por la década de 1990, trazando paralelismos con el impacto de las deudas incobrables en la industria financiera, aludiendo literalmente a la desagradable experiencia de tener que pagar intereses excesivos después de incumplir con los préstamos.

para que se utilizan los archivos apk

El desafío de aumentar la deuda tecnológica por sprint se puede visualizar en la Figura 1.

Sin embargo, debe mencionarse aquí que hay una ligera diferencia en el significado de deuda técnica (también conocida como deuda de código o deuda de diseño) de su correspondiente analogía en el mundo de las finanzas: la primera es más como una idea abstracta , sin ecuaciones matemáticas para visualizar cómo se acumula realmente el interés.

creciente deuda técnica

Figura 1: Visualización del aumento escalable de la deuda tecnológica en los sprints

Lo que vas a aprender:

Por qué los equipos de control de calidad sufren más debido a la deuda técnica

Durante un ciclo típico de diseño y desarrollo de software, hay varias cosas que pueden conducir a una ' deuda técnica ”Como situación– documentación incorrecta , pruebas inadecuadas y corrección de errores, falta de cordinacion entre equipos, legado código y refactorización retrasada , ausencia de integración continua y otros factores fuera de control.

Por ejemplo, se ha observado que los esfuerzos de duplicación de código pueden llevar a cualquier cosa entre 25 a 35% trabajo extra.

cuál es el mejor sistema operativo de computadora

Sin embargo, en ninguna parte desafíos debido a la deuda técnica más evidentes que en las pruebas de control de calidad donde los equipos de prueba tienen que cumplir con plazos inesperados y todo puede salir disparado.

Con qué frecuencia sus evaluadores se han enfrentado a dilemas en el último momento cuando, inesperadamente, el gerente de entregas vino y les dijo: “¡Equipo! Tenemos que lanzar nuestro producto en una semana, lamentamos no poder comunicar esto a tiempo. Termine con todas las tareas de prueba urgentemente para que podamos estar listos con la demostración '.

Básicamente, cualquier prueba perdida o enfoque de 'resolverlo más tarde' puede conducir a un problema similar a la deuda tecnológica. Falta de cobertura de prueba , historias de usuarios de gran tamaño, sprints cortos y otros ejemplos de 'atajos' debido a la presión de entrega juegan un papel muy importante detrás de la acumulación de deuda técnica en la práctica de GC.

Un ejemplo del mundo real

Un minorista en línea con sede en EE. UU. Con presencia significativa en múltiples sitios web y aplicaciones móviles se encontró en un desafío de 'deuda técnica' del mundo real cuando la complejidad de la malla de prueba comenzó a agravarse con cada nueva pique .

Esto sucedió debido al aumento repentino en la cantidad de dispositivos móviles que se probarán, que se admitirán varios idiomas y que se aprovecharán más de media docena de sitios de redes sociales.

Con una cobertura de automatización inferior al 40%, el desafío de la deuda tecnológica se manifestaría de las siguientes maneras:

  • Consumo de tiempo excesivo en las pruebas de lanzamiento - Con el aumento de la cantidad de navegadores, dispositivos y scripts con cada sprint de prueba, el ciclo de lanzamiento seguiría retrasándose, lo que provocaría una pérdida de tiempo de comercialización.
  • El costo creciente de la contratación - La cantidad de probadores necesarios para respaldar el proyecto casi se duplicó, lo que se tradujo en costos adicionales de $ 500 mil
  • Complejidad en el proyecto - Con la creciente complejidad del proyecto, hacer un seguimiento de los casos de prueba y los errores se estaba convirtiendo en un desafío
  • Se pierde demasiado tiempo persiguiendo falsos positivos - De nuevo, una consecuencia de la creciente complejidad del proyecto.
  • Aumento del esfuerzo de desarrollo de pruebas hasta en un 60% - Va con el territorio

Gestión de la deuda tecnológica en las prácticas de control de calidad

La mayoría de los gerentes de control de calidad ven impulsivamente la deuda tecnológica como la consecuencia razonable de concentrar toda su energía solo en el sprint actual, lo que conduce a lograr la cobertura de prueba de alguna manera a través de medios manuales e ignora por completo la automatización.

Esto se conoce como enfoque rápido y sucio que ha sido cubierto en un blog por Martin Fowler, el autor de la cuadrante de deuda técnica .

Los principios ágiles dictan que visualizamos el problema de la deuda tecnológica como una incapacidad para defender y cumplir Comparativas de control de calidad .

De hecho, basado en una encuesta por el Instituto Nacional de Estándares y Tecnología (NIST), las herramientas y métodos de prueba insuficientes cuestan anualmente a la economía de EE. UU. entre .2 y $ 59.5 mil millones , con aproximadamente la mitad de este dinero gastado en pruebas adicionales por los desarrolladores de software y aproximadamente la mitad por los usuarios de software para evitar fallas.

En lugar de reaccionar a las fallas cuando ocurre el incidente, un enfoque proactivo sería identificar los defectos después de cada actividad o tarea que se pueda medir. Puede hacerlo todo manualmente, pero dados los miles de escenarios de casos de prueba para un proyecto promedio, el control de prueba automatizado es una necesidad.

Claramente, pruebas efectivas puede ayudarlo a ganar terreno en la guerra contra la deuda técnica. Entonces, ¿qué significa básicamente? Significa qué tan bien equipado está su sistema para identificar defectos en la aplicación general.

eficacia de la prueba

Como muestra la ecuación anterior, la efectividad de los casos de prueba teóricamente puede acercarse incluso al 100% si el número de defectos encontrados por el cliente (es decir, defectos de posproducción) se hubiera asignado con precisión al número de defectos encontrados en cada etapa de la cobertura de prueba.

Para tener un banco de pruebas bien diseñado que pueda medir con precisión los defectos tan pronto como aparezcan, la automatización es un requisito previo.

Automatización de pruebas lo ayuda a minimizar la cantidad de scripts que se ejecutan al informar los resultados y compararlos con ejecuciones de prueba anteriores. El método o proceso que se utiliza para ejecutar la automatización se denomina prueba. automatización marco de referencia .

Los ejemplos típicos serían herramientas comerciales o gratuitas como Selenium, MonkeyTalk, robots , Borland SilkCentral, HP Quality Center y IBM Rational Rose .

En el pasado, las organizaciones y sus equipos de software veían a menudo el control de calidad y las pruebas como una actividad de apoyo a los entregables comerciales más importantes, y no como una práctica disciplinada por derecho propio que requeriría un enfoque central y dedicado. De hecho, un enfoque no básico para QA / testing es precisamente lo que ha llevado al desafío continuo de la deuda técnica en primer lugar.

Teniendo en cuenta el rápido ritmo de evolución en las habilidades de control de calidad / pruebas que se ha producido en la última década, las organizaciones están teniendo dificultades para actualizar sus habilidades y competencias a los niveles mínimos deseados según los puntos de referencia actuales de la industria.

De hecho, existe una tendencia creciente en la industria de conformarse con nada menos que los profesionales más experimentados en automatización de pruebas, algo así como los comandos de élite de pruebas / control de calidad; se les conoce como ingenieros de software en prueba ( Ya que ) y desarrolladores de software en prueba ( SDiT ). Estos profesionales tienen una gran demanda debido a su vasta experiencia en una vertical elegida (por ejemplo, comercio electrónico) o una categoría profesional en particular.

La mayoría de las empresas de desarrollo de software y productos, como hablamos ahora, están luchando por encontrar los recursos técnicos calificados y deseados frente a tiempos de entrega más cortos. La solución a este desafío es asociarse con un actor de automatización de control de calidad en el extranjero que pueda abordar su escasez de habilidades con el grupo adecuado de recursos SDiT / SEiT.

Otros atributos deseados de un jugador de subcontratación en QA / Testing que resultan útiles incluyen un enfoque ágil y disciplinado para la ejecución de proyectos, suficiente experiencia en la industria, incluido el acceso práctico a marcos de automatización reutilizables y casos de prueba, y por último, pero no menos importante, una intención clara. y capacidad para abordar los desafíos del equipo remoto y los choques culturales para que el cliente no tenga que cargar con trabajo adicional en la gestión de contratistas.

Conclusión

Como cualquier otra deuda, la deuda técnica puede demostrar ser la pesadilla de las empresas y la causa fundamental de su acumulación es la falta de implementación de una práctica de garantía de calidad proactiva que elimine todos los retrasos en la automatización.

Sobre el autor: Esta es una publicación invitada del equipo de eInfochips. Han ideado un enfoque único llamado Deuda tecnológica cero que es una de las formas más estructuradas y eficientes de eliminar gradualmente la deuda técnica en las actividades de QA / automatización. Para saber más sobre la deuda tecnológica, mira este video en un enfoque para reducir el departamento de tecnología.

cómo abrir archivos jar en windows

Espero que tenga una idea clara sobre qué es la deuda técnica. Háganos saber si tiene alguna consulta relacionada con él o cómo gestionarlo en la práctica.

Lectura recomendada

^