Hola, en este artículo está todo el detalle acerca sobre la deuda técnica en la que hay más detalle acerca de esta perspectiva.
Introduccion
¿Qué es el testing?
La piramide del testing
Hablemos sobre deuda técnica
Herramientas de testing
Creando el proyecto
Tu primer test
Escribiendo pruebas
Pruebas estáticas
Assertions / matchers
Setup and Teardown
Implementado Setup
Tipos de pruebas
Metodologías
Pruebas Unitarias
Pruebas unitarias
Coverage report
Instalación de Docker para este curso
Proyecto de API
Mocking, Stub, doubles
Mocking
Spies
Generando Fake Books
Integration Test & E2E
Configurando supertest en el API
Integration Test
e2e
UI Test
UI Test
Automatizar
Unit tests en GitHubActions
E2E en GitHubActions
¿Quieres más cursos de testing?
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Hablemos sobre deuda técnica
3/27Recursos
Aportes 6
Preguntas 2
Ordenar por:
Deuda Técnica
Igual que en las finanzas, las deudas no son buenas ni malas, solo son una estrategia para alcanzar algo y luego se paga.
haciendo pruebas se maneja el
riesgo
- Diseño
- Desarrollo
- Pruebas
- Producción
El momento y pruebas dependen de la fase en la que se encuentra la compañía:
- Tracción
- Inflexión
- Escala
- Expansión
La deuda de deficiencia del desarrollador puede ser alta porque en la fase de tracción, la compañía busca velocidad > precisión , de modo que en esta etapa el testing no se valora, ya que buscan lanzar, lanzar, lanzar…
Cuando se entra a la fase de inflexión, hay más usuarios y se empiezan a escribir más pruebas, curando la deuda.
Un video del profe @gndx donde explica la deuda técnica.
¿Y si la compañía somos nosotros mismos como developers? se me ocurre que cuando estamos dando nuestros primeros pasos en software es importante tener tracción y avanzar rápido para no aburrirnos o frustarnos, con el tiempo vamos reduciendo nuestra propia deuda técnica en los proyectos que desarrollamos.
Excelente clase Nicolás!, estos temas son tal vez, más importantes que solo preocuparnos de hacer buen código.
Lo que puedo entender, es que la deuda técnica es aquella que se paga, a medida de que mientras no se hagan pruebas de lo que se está desarrollando y nos aseguramos de una buena calidad, funcionamiento y una buena usabilidad en el producto, se va acumulando un costo a largo plazo donde afecta las finanzas de la empresa, en el punto en qué, si sale un error en algún módulo, o no funcione alguna sección, por ejemplo, un pago no se haga, o que no entre a la aplicación o no inicie sesión, o que no entre o algo más grave, se le cae el sistema, las pérdidas económicas serán caóticas y serán negativas para la misma, por ejemplo, se pierda un cliente potencial que pueda pagar el producto y/o servicio, o que se pierda dinero en el proceso o algo así. Espero y alguien me comenté que si mi percepción es correcta.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?