Es lo mismo q decia mi ex jefe en mi anterior trabajo, hasta q los hackearon y el cliente ademas de exponer su BD de clientes sufrio un ramsonware que aun no son capaces de reponerse, cuento corto lo despidieron y los devs q siguieron ahi se rien cuando lo recuerdan, nunca aprendieron nada, siguen haciendo todo igual, q otros lo arreglen dicen. Esa mentalidad ha echado empresas abajo, en especial las medianas con poca espalda en capital. No quiere hacer pruebas lentas, implemente Devops. No quiere q lo auditen y le digan q su codigo no es perfecto, vaya al terapeuta, la mayoria de colegas son divas q detestan a quien les muestre q como cualquiera pueden errar, solo ego, ese es el problema del mundo Dev.
Los tests tampoco son la solución a eso que les pasó. Al final, los que desarrollan los tests (por lo general) son los mismos que hacen el código, por lo que los tests no abarcarían esos errores. El exponer la BD nada tiene que ver con testing, tampoco se pueden testear los miles de escenarios posibles en todos los proyectos.
@@emmanuelovares Ahora resulta q una inyeccion SQL hecha en el login del portal no era evitable? si tu programas de acuerdo a buenas practicas y conociendo de seguridad (q al parecer no es el caso, si no entenderías de minimizar el riesgo) no puedes generalizar a q todos los colegas lo hacen, y q la misma persona q desarrolla haga sus pruebas es síntoma de enfermedad en sus procesos, no puedo ser mi propio auditor por razones obviamente éticas colega eso es de colegio.
@@MSalAc Es que ese es mi punto, por lo general los tests lo va haciendo el mismo desarrollador, por ejemplo con el TDD. Aún así, puedo asegurarte que puedo agarrar un proyecto tuyo y encontrar fallos de seguridad que ni siquiera contemplaste, porque hay infinidad de casos posibles. Es mentira, que los tests sí o sí, te van a mitigar el 100% de casos, porque sería "imposible" por tema de tiempo, probar cada uno de los detalles de una aplicación. Y obviamente, si una persona programa con buenas practicas y conoce de seguridad, de base ya habría solucionado ese problema tan básico que les pasó.
Las metodologías ágiles y el testing son cuestiones críticas que personas ajenas al área usan de medallita porque queda bonito decir que su equipo lo aplica. El resultado suele ser gente escribiendo test para verificar los test que hizo otro y un líder verificando que todos los test sean pasados para sacar una captura que tenga numeritos en verde, y burocracia bloqueante que te hace querer hacerte autónomo en dos semanas. Como bien dijiste, saber cuándo y por qué, es clave..
La parte de enfocarse en crear mejores test estoy de acuerdo, el ciclo de testing no se basa en sólo test unitarios, el testing comienza desde la creación de requerimientos que nos permitan crear valor al cliente. El rol de tester independiente ayuda a estos problemas incluso con la automatización de pruebas e integración de estas en un pipeline para identificar posibles breaking changes. Por otro lado la documentación es importante incluso para el testing, mantener esta documentación nos puede ayudar a identificar posibles riesgos y corregirlos adecuadamente.
No hacer tests, al menos unitarios, es pan para hoy, hambre para mañana. Y, por otro lado, si un test no está probando lo que debería, el problema no es el testing, sino el/la dev que lo hizo, que no sabe escribir tests. Si un test queda obsoleto y no se hace notar en cuanto esto pasa (falla), entonces era un test mal hecho o de relleno; una vez mas, problema de los/las devs, no del testing, y por lo tanto merecen el sufrimiento de mil torturas 😂
Tambien algo importante seria que se tenga una documentacion minima sobre lo que estas desarrollando para proceder con un test para evitar perderse y terminar creando un error que nunca existio.
Hace 25 años que desarrollo software y siempre ha habido un equipo de testing: industria, financiera, juego, entretenimiento. Los que no hacen testing son los que no invierten en él ni en pagar las guardias a los desarrolladores...
@carlossalasamper si fuese como dices, las empresas no invertiría en algo que no da resultados. Tampoco podrían certificar sus soluciones con ISO9000/27000/PCI. Hay un universo de empresas y corporaciones con un renombre y trayectoria basado en la calidad del código que entregan.
Estuve todo el video esperando que pegue un giro en la dirección contraria, pero nunca llegó. Estoy parcialmente de acuerdo, es verdad que los test unitarios requieren un periodo de aprendizaje (como cualquier area del desarrollo), lo mas probable es que al comienzo los hagas mal (fragiles, lentos, etc. lo que seria antipatrones de test), tambien es cierto que probablemente una startup que esta constantemente cambiando le aporte mas testear solo su logica core que toda la app. Sin embargo, los test no vuelven tu desarrollo mas lento, todo lo contrario, trabajo en una empresa grande donde los equipos que realizan test (tanto unitarios como de integración) tienen un Throughput mayor y un menor cycletime, ademas tienen una menor taza de errores en las cosas que suben a producción y no necesitan una persona de qa para sus equipos. En gral si es una inversión, pero se requiere una cultura donde la gente vea el valor de hacer las cosas y no que las hagan para subir el numerito de sonar. Por otro lado, tener gente revisando el codigo es super buena practica, pero es absurdamente mas lento que correr una suit de test unitarios (al menos hacer una buena revisión). Mas alla de eso, me gustó tu forma de argumentar, entiendo que en muchos ambientes es dificil de generar una cultura de test en gente que nunca los hizo
Sí, no tengo nada que decir contra lo que dices: una buena metodología TDD te hace trabajar mejor, en general. Pero es que estoy viviendo una situación concreta en mi empresa que me hace estar un poco quemado con los profetas del testing… Gracias por el mensaje
@carlossalasamper es bastante complicado el tema. Si queres después nos juntamos a hablar sobre el tema a ver si puedo darte una mano para darle una vuelta al tema y que puedas sacarle el jugo a la situación 😃
Hablas mucho de testing pero a qué te refieres en concreto, ¿a los test unitarios? Eso a los nuevos los puede confundir, lo ideal es que se testee el código en la funcionalidad importante y luego tener un equipo de testers ya sean manuales o que se automaticen para que todo funcione. Un buen dev sabe valorar lo que es el testing y su gran importancia.
Es lo mismo q decia mi ex jefe en mi anterior trabajo, hasta q los hackearon y el cliente ademas de exponer su BD de clientes sufrio un ramsonware que aun no son capaces de reponerse, cuento corto lo despidieron y los devs q siguieron ahi se rien cuando lo recuerdan, nunca aprendieron nada, siguen haciendo todo igual, q otros lo arreglen dicen. Esa mentalidad ha echado empresas abajo, en especial las medianas con poca espalda en capital. No quiere hacer pruebas lentas, implemente Devops. No quiere q lo auditen y le digan q su codigo no es perfecto, vaya al terapeuta, la mayoria de colegas son divas q detestan a quien les muestre q como cualquiera pueden errar, solo ego, ese es el problema del mundo Dev.
Los tests tampoco son la solución a eso que les pasó. Al final, los que desarrollan los tests (por lo general) son los mismos que hacen el código, por lo que los tests no abarcarían esos errores. El exponer la BD nada tiene que ver con testing, tampoco se pueden testear los miles de escenarios posibles en todos los proyectos.
@@emmanuelovares Ahora resulta q una inyeccion SQL hecha en el login del portal no era evitable? si tu programas de acuerdo a buenas practicas y conociendo de seguridad (q al parecer no es el caso, si no entenderías de minimizar el riesgo) no puedes generalizar a q todos los colegas lo hacen, y q la misma persona q desarrolla haga sus pruebas es síntoma de enfermedad en sus procesos, no puedo ser mi propio auditor por razones obviamente éticas colega eso es de colegio.
@@MSalAc Es que ese es mi punto, por lo general los tests lo va haciendo el mismo desarrollador, por ejemplo con el TDD. Aún así, puedo asegurarte que puedo agarrar un proyecto tuyo y encontrar fallos de seguridad que ni siquiera contemplaste, porque hay infinidad de casos posibles. Es mentira, que los tests sí o sí, te van a mitigar el 100% de casos, porque sería "imposible" por tema de tiempo, probar cada uno de los detalles de una aplicación.
Y obviamente, si una persona programa con buenas practicas y conoce de seguridad, de base ya habría solucionado ese problema tan básico que les pasó.
Las metodologías ágiles y el testing son cuestiones críticas que personas ajenas al área usan de medallita porque queda bonito decir que su equipo lo aplica. El resultado suele ser gente escribiendo test para verificar los test que hizo otro y un líder verificando que todos los test sean pasados para sacar una captura que tenga numeritos en verde, y burocracia bloqueante que te hace querer hacerte autónomo en dos semanas. Como bien dijiste, saber cuándo y por qué, es clave..
Premio para ti 🥇
La parte de enfocarse en crear mejores test estoy de acuerdo, el ciclo de testing no se basa en sólo test unitarios, el testing comienza desde la creación de requerimientos que nos permitan crear valor al cliente. El rol de tester independiente ayuda a estos problemas incluso con la automatización de pruebas e integración de estas en un pipeline para identificar posibles breaking changes. Por otro lado la documentación es importante incluso para el testing, mantener esta documentación nos puede ayudar a identificar posibles riesgos y corregirlos adecuadamente.
No hacer tests, al menos unitarios, es pan para hoy, hambre para mañana. Y, por otro lado, si un test no está probando lo que debería, el problema no es el testing, sino el/la dev que lo hizo, que no sabe escribir tests. Si un test queda obsoleto y no se hace notar en cuanto esto pasa (falla), entonces era un test mal hecho o de relleno; una vez mas, problema de los/las devs, no del testing, y por lo tanto merecen el sufrimiento de mil torturas 😂
Tambien algo importante seria que se tenga una documentacion minima sobre lo que estas desarrollando para proceder con un test para evitar perderse y terminar creando un error que nunca existio.
Sí, para tener una referencia de los requisitos
Hace 25 años que desarrollo software y siempre ha habido un equipo de testing: industria, financiera, juego, entretenimiento.
Los que no hacen testing son los que no invierten en él ni en pagar las guardias a los desarrolladores...
Yo lo que he visto en mi experiencia con el testing es dinero cayendo en saco roto
@carlossalasamper si fuese como dices, las empresas no invertiría en algo que no da resultados.
Tampoco podrían certificar sus soluciones con ISO9000/27000/PCI.
Hay un universo de empresas y corporaciones con un renombre y trayectoria basado en la calidad del código que entregan.
@@leonardoboschiazzo1384 los que se pelean, se desean
Yo hago test de procesos generales, con la capa 8. El usuario
los testing que los haga la IA .
Estuve todo el video esperando que pegue un giro en la dirección contraria, pero nunca llegó. Estoy parcialmente de acuerdo, es verdad que los test unitarios requieren un periodo de aprendizaje (como cualquier area del desarrollo), lo mas probable es que al comienzo los hagas mal (fragiles, lentos, etc. lo que seria antipatrones de test), tambien es cierto que probablemente una startup que esta constantemente cambiando le aporte mas testear solo su logica core que toda la app. Sin embargo, los test no vuelven tu desarrollo mas lento, todo lo contrario, trabajo en una empresa grande donde los equipos que realizan test (tanto unitarios como de integración) tienen un Throughput mayor y un menor cycletime, ademas tienen una menor taza de errores en las cosas que suben a producción y no necesitan una persona de qa para sus equipos. En gral si es una inversión, pero se requiere una cultura donde la gente vea el valor de hacer las cosas y no que las hagan para subir el numerito de sonar. Por otro lado, tener gente revisando el codigo es super buena practica, pero es absurdamente mas lento que correr una suit de test unitarios (al menos hacer una buena revisión). Mas alla de eso, me gustó tu forma de argumentar, entiendo que en muchos ambientes es dificil de generar una cultura de test en gente que nunca los hizo
Sí, no tengo nada que decir contra lo que dices: una buena metodología TDD te hace trabajar mejor, en general. Pero es que estoy viviendo una situación concreta en mi empresa que me hace estar un poco quemado con los profetas del testing…
Gracias por el mensaje
@carlossalasamper es bastante complicado el tema. Si queres después nos juntamos a hablar sobre el tema a ver si puedo darte una mano para darle una vuelta al tema y que puedas sacarle el jugo a la situación 😃
Muy bien planteado, el testing cuando el proyecto crece a veces abarca menos del 10% del total del tiempo destinado
no comparto absolutamente nada pero bueno, es tu opinion
Podemos ser amigos en cualquier caso
Qué bueno verte Carlos, muy buena info, me acabó de ayudar a aterrizar expectativas
Hablas mucho de testing pero a qué te refieres en concreto, ¿a los test unitarios? Eso a los nuevos los puede confundir, lo ideal es que se testee el código en la funcionalidad importante y luego tener un equipo de testers ya sean manuales o que se automaticen para que todo funcione. Un buen dev sabe valorar lo que es el testing y su gran importancia.
No caigas en la secta del testing
@@carlossalasamper claro, porque si no tenes testing el tester será el usuario en producción.
Muy útil
😂😂
¿El testing? una mierda.
Espero que no sea de esos canales que buscan generar controversias
Un poco de todo jaja pero tampoco digo lo primero que se me ocurre, intento que tenga sentido
Por fin siento que alguien dice la verdad 💪
Solo hay una vida y no voy a gastarla mintiendo
Directo y simple, útil y buen video.
Gracias, Diego! 👌
Pole