¿Realmente vale la pena probar el software?

Si y no. Bueno, como en todo, depende. En esta publicación, intentaré ilustrar mi experiencia con las pruebas como desarrollador y luego como fundador de una startup.

Acerca de mí

¡Hola! Soy Simone, una desarrolladora full-stack y CTO con 15 años de experiencia en codificación en varias industrias, incluidas agencias web, comercio electrónico, adultos y software empresarial. En esta publicación de blog, me gustaría compartir información sobre las pruebas de software y cómo determinar los métodos apropiados para las diferentes necesidades y etapas comerciales.

Soy el CTO y cofundador de Bugpilot, una herramienta de monitoreo de errores que ayuda a los equipos de SaaS a detectar errores que se deslizaron a través de los procesos de desarrollo, prueba y control de calidad.

Introducción

Diferentes tipos de pruebas

En el mundo del desarrollo de software, muchas prácticas de prueba se han considerado esenciales durante mucho tiempo para garantizar la confiabilidad y la calidad de los productos de software. Sin embargo, es importante reconocer que, si bien estas metodologías tienen sus ventajas, no carecen de inconvenientes.

Esta publicación de blog tiene como objetivo iniciar una conversación y arrojar luz sobre el daño potencial que TDD y QA pueden causar en los equipos de software. Al reconocer que no existe un enfoque único para todos y que los diferentes negocios y etapas requieren métodos apropiados, podemos comenzar a navegar por las complejidades del desarrollo de software de manera más efectiva.

Reconozco muchas metodologías diferentes, prácticas comunes y recomendaciones en torno a las pruebas de software; en esta publicación, me centré principalmente en el desarrollo basado en pruebas y el control de calidad.

Aquí hay una descripción general, en caso de que no esté familiarizado con los términos:

TDD

El desarrollo basado en pruebas (TDD) es un método de desarrollo de software que implica escribir pruebas automatizadas antes de escribir el código. Esto ayuda a detectar problemas en las primeras etapas del ciclo de desarrollo, lo que garantiza que el código se pruebe exhaustivamente y cumpla con los requisitos comerciales. Los desarrolladores primero definen el comportamiento esperado de una nueva característica con una prueba, luego escriben el código para pasar la prueba y finalmente optimizan el código a través de la refactorización.

control de calidad

Garantía de calidad (QA) garantiza que el software cumpla con los estándares de calidad antes del lanzamiento. Por lo general, un proceso manual llevado a cabo por un ingeniero de control de calidad identifica y corrige los defectos mediante pruebas manuales y automatizadas, como la verificación de los requisitos funcionales y la verificación del rendimiento. Esto garantiza un software confiable y estable que satisface las necesidades comerciales y del usuario final.

¡Un par de preguntas para ti!

Mi objetivo con esta publicación es iniciar una conversación. No puedo enfatizar lo suficiente que creo firmemente que se necesitan pruebas en muchos casos. Piense en dispositivos médicos, software de aeronaves, sistemas de control, banca y mucho más, software en uso por miles de millones de personas donde el color de un botón hace una diferencia significativa en las ganancias.

El desarrollo de software requiere un equilibrio entre estructura y flexibilidad, y seguir ciegamente los principios de prueba sin tener en cuenta el contexto puede conducir a resultados subóptimos: las bibliotecas de códigos probablemente se beneficien de una cobertura del 99 %. Pero, ¿su software también necesita una cobertura del 99 %?

Preparé un par de preguntas. Trate de responder sí o no, ¿por qué?

• ¿ Realmente necesita probar sus componentes de interfaz de usuario?
• ¿Necesita pruebas E2E para esa funcionalidad de "actualizar imagen de perfil"?
• ¿Reprueba el control de calidad y retrasa un lanzamiento si hay una inconsistencia menor entre los diseños de Figma y la interfaz de usuario real? ¿Cuál es el límite?
• ¿Debería despedir a John por negarse a escribir exámenes?

Capítulo 1. Mi caso contra Test-Driven-Development

Desafiando el dogma

El desarrollo basado en pruebas (TDD) ha ganado seguidores casi religiosos. Algunos afirman que ayuda con la salud mental y, a menudo, va acompañado de la creencia dogmática de que es el único camino hacia el éxito. Este capítulo tiene como objetivo explorar los inconvenientes de TDD y arrojar luz sobre la trampa de la rigidez, las limitaciones de tiempo y la falsa sensación de seguridad .

Como CTO, me he encontrado con colegas que insistieron firmemente en TDD incluso para las funciones más triviales. El dogma predominante parecía ser: "¡Debes hacer TDD, o eres un idiota!" Esta creencia inquebrantable en TDD como el único enfoque aceptable a menudo me hizo cuestionar mi propio juicio y competencia. Recuerdo claramente incidentes en los que se reían de mí por negarme a escribir pruebas para una función simple de 2 líneas para filtrar una matriz.

Esta experiencia personal destacó una de las trampas clave de TDD: la trampa de la rigidez. La adherencia dogmática a escribir primero las pruebas a veces puede conducir a procesos rígidos que, a su vez, pueden afectar el tiempo de comercialización de una empresa y la ventaja frente a la competencia.

¿Realmente vale la pena el tiempo?

Un desafío importante que plantea TDD es la limitación de tiempo que impone al proceso de desarrollo.

Escribir pruebas exhaustivas para cada pieza de código puede llevar mucho tiempo, especialmente para funciones triviales que tienen un impacto mínimo en el sistema general. En entornos acelerados donde las iteraciones rápidas y la entrega oportuna son cruciales, la sobrecarga adicional de TDD puede ralentizar el ciclo de desarrollo y dificultar la agilidad.

Me parece irrazonable optar siempre por el enfoque "Necesito una cobertura del 99 %". Equilibrar la minuciosidad y la eficiencia es esencial, y hay escenarios en los que un enfoque de prueba más simplificado puede ser más apropiado, lo que permite iteraciones más rápidas y respuestas más rápidas a las demandas del mercado.

Además, la complejidad y la imperfección de escribir pruebas que involucran interacciones con dependencias externas o sistemas complejos pueden agravar aún más las limitaciones de tiempo de TDD.

Como desarrollador, incluso podría decir que disfruto escribiendo pruebas, pero... busque un director ejecutivo que esté contento de que su equipo haya pasado el 80 % de su tiempo escribiendo pruebas para el código que finalmente se eliminará.

Los desarrolladores a menudo necesitan crear objetos simulados o stubs para simular el comportamiento de estas dependencias durante las pruebas. Si bien los simulacros pueden ser herramientas valiosas para aislar el código y reducir las dependencias, también pueden generar sobrecarga y complejidad adicionales.

La dependencia de los simulacros puede conducir a una representación imperfecta de las interacciones del mundo real, ya que puede ser un desafío replicar con precisión el comportamiento de los sistemas externos o los componentes de terceros. Esto puede introducir un nivel de incertidumbre en el proceso de prueba, lo que podría generar falsos positivos o falsos negativos.

Las pruebas están pasando; Puedo tener una buena noche de sueño, ¿verdad? ¿Bien?

Las pruebas están pasando; ¡Puedo dormir sano y salvo!

Existe un peligro inherente, pero a menudo pasado por alto, de depender únicamente de las pruebas : una falsa sensación de seguridad. Si bien las pruebas son, sin duda, esenciales para identificar y prevenir defectos, no son una solución infalible.

"¿Hicimos pruebas en todos los dispositivos?"

También es difícil probar todos los casos posibles. Especialmente en el ámbito del desarrollo web, hay una multitud de factores que pueden afectar la experiencia del usuario. Uno de esos factores es la diversidad de dispositivos de usuario final, incluidos diferentes tamaños de pantalla, resoluciones, sistemas operativos y navegadores. Cada combinación presenta un conjunto único de desafíos que pueden afectar la forma en que el software funciona y se muestra a los usuarios.

Considere la amplia gama de dispositivos y configuraciones: teléfonos inteligentes, tabletas, computadoras portátiles y de escritorio, que se ejecutan en iOS, Android, Windows o macOS, que utilizan varias versiones de navegadores como Chrome, Safari, Firefox, Edge o Internet Explorer. Cada combinación de dispositivo, sistema operativo y navegador puede representar el contenido web de manera diferente, y las interacciones del usuario también pueden variar. Es prácticamente imposible anticipar y tener en cuenta todos los dispositivos y configuraciones posibles, lo que dificulta que las pruebas brinden una cobertura completa.

"¿Probé esta interfaz de usuario como si fuera mi abuela?"

Las personas y los perfiles de los usuarios agregan otra capa de complejidad. Su software puede dirigirse a una audiencia diversa con diferentes preferencias, comportamientos y necesidades de accesibilidad . Las pruebas pueden ayudar a descubrir problemas que surgen en escenarios típicos, pero pueden pasar por alto casos extremos o interacciones específicas del usuario que se desvían de la norma. Por ejemplo, los usuarios con discapacidades visuales que dependen de tecnologías de asistencia pueden enfrentar desafíos de usabilidad que son difíciles de capturar solo a través de pruebas automatizadas.

Además de las variaciones técnicas, el contexto del usuario y los escenarios del mundo real juegan un papel crucial en la configuración de la experiencia del usuario. Factores como las condiciones de la red, las limitaciones de ancho de banda o el uso simultáneo pueden afectar el rendimiento y la confiabilidad del software.

Si bien las pruebas pueden proporcionar un entorno controlado, es posible que no simulen con precisión las diversas condiciones de la red y los patrones de uso que los usuarios encuentran en su vida diaria. Si las pruebas no pueden garantizar que su software funcione bien, ¿vale la pena al final del día?

Capítulo 2. Control de calidad y la necesidad de velocidad

He sido testigo de primera mano de los desafíos que plantean las prácticas de control de calidad "estrictas", en particular cuando se trata de empresas más pequeñas que deben moverse rápidamente para mantenerse por encima de sus competidores.

Creo que esto es especialmente cierto para las empresas emergentes en etapa inicial; de alguna manera es probable que deseche toda la función pronto si sus clientes no la están usando. Entonces, ¿valió la pena esa semana entera de probar y refinar las pruebas unitarias?

Permítame compartir mis experiencias personales y arrojar luz sobre los peligros de quedar atrapado en el perfeccionismo, especialmente cuando los aspectos visuales o de presentación menores se convierten en el centro de atención de los esfuerzos de control de calidad.

En mi puesto anterior en una startup, enfrentábamos una batalla constante entre ofrecer funciones rápidamente y garantizar una calidad impecable. Hubo casos en los que nuestro ciclo de lanzamiento se retrasó innecesariamente debido a problemas mínimos, como un margen CSS desalineado, una elección de fuente incorrecta o un salto de línea faltante. Si bien la atención al detalle es importante, comencé a cuestionar el impacto de obsesionarse con estas imperfecciones cosméticas en nuestra capacidad para mantenernos a la vanguardia en el mercado.

Uno de los riesgos del control de calidad excesivo es la priorización de la perfección sobre la practicidad. En nuestra búsqueda de la perfección, a menudo nos encontramos invirtiendo una cantidad significativa de tiempo y recursos para solucionar minúsculos fallos visuales. ¿No es esto el enemigo de la productividad?

Si bien es esencial mantener altos estándares, comencé a darme cuenta de que dedicar un gran esfuerzo a estos detalles minuciosos podría ser contraproducente, desviando nuestro enfoque de la funcionalidad principal y las mejoras en la experiencia del usuario que realmente importan a nuestros clientes.

El peligro se hizo evidente cuando observamos las consecuencias de un enfoque de control de calidad demasiado cauteloso. Nuestro equipo comenzó a exhibir un comportamiento de aversión al riesgo, optando por un proceso de liberación lento y meticuloso. Si bien la intención era ofrecer un producto casi impecable, sin darnos cuenta sofocamos la innovación y obstaculizamos nuestra capacidad de responder rápidamente a las demandas de los clientes. Como una empresa pequeña (30 empleados), confiamos en nuestra agilidad para iterar rápidamente y superar a los competidores más grandes. Sin embargo, las prácticas excesivas de control de calidad dieron como resultado un temor generalizado a los "errores" que nos estaban frenando.

¿No deberíamos aceptar que existen errores? Cualquiera que trabaja comete errores; si no trabajas, nunca te equivocas. (Lo siento - cita de fútbol)

Capítulo 4. Los clientes pueden ser los mejores probadores

Las implicaciones financieras de los ciclos de liberación prolongada se hicieron evidentes. Las ventanas de mercado perdidas, la generación de ingresos retrasada y la pérdida de clientes potenciales comenzaron a pasar factura. No podíamos darnos el lujo de perder el tiempo como una pequeña empresa con recursos limitados. Necesitábamos aprovechar nuestra agilidad y velocidad para aprovechar las oportunidades y mantener una ventaja competitiva.

El tiempo dedicado a perfeccionar detalles menores debía equilibrarse con la necesidad de una iteración rápida y la capacidad de respuesta del mercado. Posponer, posponer y posponer cada lanzamiento hasta que estemos “más seguros” de que todo funciona; el envío los martes se convirtió en la opción preferida. ¿Por qué enviar el lunes si podemos tomar un día más para probar todo?

Si bien las pruebas ayudan a identificar y prevenir defectos, es igualmente importante aceptar los comentarios de los usuarios como una valiosa fuente de información. Las experiencias, preferencias y sugerencias de los usuarios pueden proporcionar información que va más allá de lo que pueden descubrir las pruebas por sí solas. Podemos crear un producto centrado en el usuario que satisfaga sus expectativas fomentando un ciclo de retroalimentación con los usuarios, escuchando activamente sus necesidades e incorporando sus aportes al proceso de desarrollo.

En lugar de confiar únicamente en pruebas internas exhaustivas, involucrar a los usuarios en el proceso de prueba puede ser muy beneficioso. Las primeras pruebas de usuario, como las pruebas beta o los estudios de usabilidad, permiten observar escenarios del mundo real e interacciones de los usuarios.

Este enfoque centrado en el usuario ayuda a identificar puntos débiles, problemas de usabilidad y problemas imprevistos que pueden no detectarse solo mediante pruebas internas. La incorporación de estos comentarios desde el principio puede mejorar en gran medida la experiencia y la satisfacción del usuario.

Desafortunadamente, personalmente presencié un fuerte “desequilibrio” en muchos equipos de software. Aquí hay una pregunta para usted: ¿Debe fallar el control de calidad por una inconsistencia de la interfaz de usuario? ¿Con qué frecuencia debe fallar el control de calidad?

Capítulo 5. "¡Los usuarios se irán si encuentran un error!"

La investigación destaca constantemente el impacto negativo de la funcionalidad rota en la retención de usuarios. Nos han dicho que muchos estudios muestran que es menos probable que los usuarios continúen usando un producto si encuentran fallas, bloqueos o errores frecuentes que interrumpen su experiencia.

Según una encuesta realizada por Qualitest , el 88% de los usuarios abandonará una aplicación después de uno o dos casos de bajo rendimiento. Estos hallazgos enfatizan el papel fundamental que desempeña la estabilidad funcional en la retención de usuarios y la creación de un compromiso a largo plazo.

Cuando los usuarios encuentran una funcionalidad rota, se erosiona su confianza en el producto y en el equipo de desarrollo que lo respalda. Incluso si los problemas finalmente se resuelven, los usuarios pueden desarrollar una percepción negativa y ser reacios a regresar. Los usuarios pueden perder la confianza en un sitio web o aplicación si experimentan fallas o errores funcionales repetidamente.

Pero… ¿sigue siendo cierto en 2023?

Los errores están en todas partes, y todos sabemos que es posible que el software libre de errores nunca exista .

Los usuarios pueden encontrar errores de vez en cuando y es importante distinguir entre errores menores y problemas críticos de funcionalidad. Los usuarios pueden ser hoy en día más indulgentes con los errores menores que no afectan significativamente su experiencia general. Desde nuestro punto de vista, los usuarios han aprendido a aceptar los errores como algo inevitable en el desarrollo de software; Los insectos son parte de nuestra vida diaria.

Sin embargo, cuando se trata de una funcionalidad central rota que dificulta su capacidad para usar el software según lo previsto, es probable que los usuarios sean menos indulgentes y busquen alternativas.

Los errores B2B son más dolorosos (¿o no?)

En escenarios B2B, la funcionalidad rota puede tener graves consecuencias para los usuarios y sus negocios. Puede dar lugar a retrasos en los plazos de los proyectos, incumplimiento de los plazos e incluso una pérdida financiera de 440 millones de dólares .

En cuanto al software de consumo, los usuarios comerciales pueden sentirse frustrados y enojados cuando encuentran errores que les impiden realizar su trabajo. Su lealtad a un producto de software está estrechamente ligada a su confiabilidad y capacidad para ayudarlos a tener éxito en sus responsabilidades profesionales. La baja confiabilidad debería equivaler a una mayor rotación.

Sin embargo, he aprendido que no siempre es así. Una vez que toda una organización adopta una tecnología, ¿es tan fácil hacer que toda la empresa cambie a una solución de la competencia? Improbable.

El comercio electrónico tiene (más) desafíos de lealtad.

En el comercio electrónico, los usuarios tienen numerosas alternativas al alcance de la mano. Como usuario, su trabajo a realizar es muy claro. Necesitas comprar una aspiradora. Si la aplicación de Amazon falla, ¿cuánto tiempo antes de que pruebe la siguiente aplicación en su cajón?

La funcionalidad rota o los errores pueden provocar el abandono rápido de los carros de la compra, una disminución permanente de la satisfacción del cliente y la pérdida de oportunidades comerciales.

Capítulo 6. ¿Son TDD y QA la única solución?

Obviamente no. Si bien las pruebas juegan un papel crucial en la identificación y prevención de algunos defectos, existen medidas adicionales que se pueden tomar para minimizar el impacto de los errores en los usuarios. Aquí hay algunos enfoques que he estudiado:

Monitoreo y seguimiento de errores

La implementación de sistemas robustos de monitoreo y seguimiento de errores permite la identificación y resolución proactiva de problemas. El monitoreo en tiempo real puede ayudar a detectar anomalías, problemas de rendimiento y errores, lo que permite una corrección rápida antes de que afecten a varios usuarios. El seguimiento de errores permite la captura de detalles de errores y ayuda a priorizar las correcciones de errores en función de su impacto en los usuarios.

Herramientas como Sentry , Rollbar , Bugsnag y Bugpilot ayudan a los equipos a detectar automáticamente errores de codificación y sesiones de UX problemáticas, para que los equipos puedan abordar los problemas de manera proactiva.

Comentarios y soporte del usuario

Fomentar y recopilar comentarios de los usuarios de forma activa proporciona información valiosa sobre problemas de usabilidad, errores y áreas de mejora. Abordar rápidamente los problemas informados por los usuarios y brindar soporte demuestra un compromiso para resolver problemas y mantener una experiencia de usuario positiva.

Herramientas como Canny , Hotjar y Bugpilot ayudan a los equipos a recopilar fácilmente los comentarios de sus usuarios.

Documentación y Educación del Usuario

La documentación clara y completa y los materiales educativos para el usuario pueden ayudar a los usuarios a navegar por el software de manera efectiva y minimizar el riesgo de errores inducidos por el usuario. Proporcionar recursos que explican los problemas comunes y los pasos para la solución de problemas permite a los usuarios resolver problemas menores de forma independiente.

En Bugpilot, utilizamos una página de Notion para guardar toda nuestra documentación. Fácil y gratis.

Conclusión

Las pruebas actúan como una medida preventiva crucial al identificar problemas al principio del proceso de desarrollo. Las pruebas exhaustivas, incluidas las pruebas unitarias, las pruebas de integración y las pruebas de un extremo a otro, ayudan, hasta cierto punto, a detectar errores y garantizar la estabilidad y la funcionalidad del software. Pero es muy probable que las pruebas excesivas y los procesos demasiado estrictos perjudiquen a la empresa a largo plazo.

Sin embargo, los errores pueden colarse ocasionalmente a través de la red de prueba a pesar de nuestros mejores esfuerzos. Por lo tanto, es igualmente importante contar con estrategias de mitigación. Al implementar soluciones de mitigación, los equipos de software pueden detectar y abordar errores rápidamente, minimizando su impacto en los usuarios y resolviendo rápidamente cualquier problema que surja.

Reconociendo que ningún software puede estar completamente libre de errores , es esencial crear un entorno que fomente los comentarios de los usuarios y brinde una atención al cliente efectiva. Al escuchar activamente los informes de los usuarios y abordar rápidamente sus inquietudes, los equipos de software pueden mantener una relación positiva con sus usuarios y fomentar la confianza y la lealtad.

tl; dr

No exageres. Probablemente no necesite una cobertura de prueba unitaria del 99 %. Envíe rápido.