Cuando trabajo en control de calidad, a menudo escucho una voz en mi cabeza que me dice: A veces es un empujón útil, pero si no se controla, empieza a convertirse en un problema. A continuación, hablaré sobre este molesto y cómo se manifiesta. "¿Estás seguro de que has comprobado todo?". error interno En este artículo, quiero compartir mis pensamientos y conocimientos que he adquirido al estudiar este fenómeno. Espero que te resulten útiles y me encantaría conocer tu perspectiva al respecto en los comentarios. Después de todo, la retroalimentación es una de las mejores formas de verme a mí mismo desde afuera y mejorar. Las ventajas del Error Interno: “¿Estás seguro de que has comprobado todo?” Te impulsa a abordar incluso las tareas más simples con cuidado y atención al detalle. Una vez, después de cambiar de tarea y de haber completado las pruebas, decidí volver a comprobar todo, por si acaso. Fue entonces cuando noté un detalle pequeño pero crucial. La tarea no incluía la fórmula para un cálculo que se suponía que debía realizar la nueva función. Curioso, volví a leer tanto la descripción de la tarea como la epopeya y, para mi sorpresa, la fórmula de cálculo no estaba especificada en ninguna parte. Entonces, ¿cómo la había estado calculando? Resulta vergonzoso admitirlo, pero había estado usando y verificando los cálculos con una fórmula de una tarea diferente. Si bien las dos tareas estaban relacionadas, se suponía que las fórmulas debían funcionar de manera independiente. Al darme cuenta de este descuido, rápidamente solicité las reglas de cálculo correctas, volví a probar la tarea y descubrí que el desarrollador había cometido el mismo error. Ellos también habían usado la fórmula de la otra tarea. Este pequeño y molesto error me permite encontrar errores no triviales y hacer que el producto sea más confiable. Una vez que he revisado el plan de prueba, este pequeño alborotador comienza a lanzar ideas como: "¿Qué pasa si el cliente usa un tamaño de fuente más grande o un sistema operativo desactualizado?" Gracias a ello, documento mis pruebas de forma más completa y a menudo incluyo vídeos y capturas de pantalla en mis informes. Esto resulta increíblemente útil cuando se realizan pruebas, la función está activa y, de repente, aparece un error. Una vez identificado y corregido, reviso mis registros de pruebas para determinar si pasé por alto el problema durante las pruebas o si se introdujo más adelante en la producción. A veces, veo el error escondido a simple vista en mis capturas de pantalla o grabaciones. Cuando esto sucede, investigo por qué lo pasé por alto y por qué no había un caso de prueba para detectarlo. En esa nota autorreflexiva, pasemos a las desventajas de esta Voz Interior. Me pone más ansioso, a menudo sin ninguna buena razón. A veces esto sucede después de una metedura de pata, pero también hay veces en las que la voz del Pequeño Insecto se escucha sin que nadie la provoque. En algunas ocasiones, no me dejaba en paz ni siquiera después de irme a la cama, y terminaba tomando notas para mí sobre qué más debería revisar. A menudo me hace perder el tiempo en casos de prueba muy complicados. Esto es una consecuencia directa del primer punto: la ansiedad genera en mi cabeza los escenarios más extraños y de pesadilla. En el momento parecen críticos, pero al mirar atrás, a menudo resultan ser algo así como “¿Qué pasaría si un tordo silba en un pino bajo la luna?”. Me impide concentrarme en otras tareas. A veces, incluso después de pasar una tarea al siguiente estado y comenzar algo nuevo, los pensamientos sobre esos casos de prueba me persiguen y me impiden concentrarme en la nueva tarea. En esos casos, puede resultar difícil dejar de lado el ansioso Checker-Bug. ¿Cómo, entonces, se puede aprovechar este error en nuestro beneficio y cómo evitar que tome el control? Lo primero Lo que me vino a la cabeza cuando escribía sobre las desventajas (y que repito como un mantra) es lo siguiente: las pruebas exhaustivas son un mito. Siempre habrá errores. No importa cuán minucioso seas, es imposible predecir cada combinación de acciones y escenarios, lo que significa que no puedes detectar cada error antes que tus usuarios lo hagan. Especialmente en un mundo en constante cambio. Esto es algo que simplemente tienes que aceptar y seguir adelante. Lo que me ayudó a aceptar esto fue analizar las causas de los errores de producción, lo que algunas personas llaman . Es cuando se habla con todos los involucrados para averiguar cómo se produjo el error y qué podemos hacer para evitar que vuelva a ocurrir. análisis post mortem Y aprendí que, en la mayoría de los casos, los defectos graves se debían a simples descuidos: a veces, los casos de prueba con valores vacíos no se verificaban, lo que provocaba que ciertos productos no se mostraran en la tienda; otras veces, se omitió la localización, lo que resultó en un título de pantalla en blanco. Sin embargo, el cielo no se derrumbó. El trabajo continuó y todos prestamos más atención a las áreas en las que habíamos cometido errores antes. La segunda cosa Para calmar al molesto Checker-Bug, implementaba técnicas de diseño de pruebas: tablas de decisiones y diagramas de transición de estados. Estos le ayudan a visualizar la lógica de la aplicación y obtener una imagen más clara de los posibles casos de prueba, lo que significa que puede estar más seguro de que no los pasará por alto. Si necesita un repaso, una tabla de decisiones es una tabla en la que ingresamos condiciones y reglas en columnas y filas. Una vez que especificamos las opciones para todas las condiciones y reglas, completamos el resultado esperado. Se utiliza un diagrama de transición de estados cuando tenemos un objeto con diferentes estados y el objeto cambia su estado en función de determinadas condiciones. No siempre es la opción adecuada, pero fue muy útil cuando trabajé en el desarrollo de un servicio de contabilidad; los objetos en esos diagramas eran cosas como informes, aplicaciones o firmas digitales. Tercero, El remedio para ese molesto error interno me lo encontré por sí solo. Resultó ser la revisión por pares de los casos de prueba y la comunicación después de los errores. Sencillo, quizá hasta obvio, pero funciona de maravillas. Y el cuarto La forma de calmar mi cerebro era evaluar la eficacia y los riesgos. Cuando el bicho interior empezaba a susurrarme al oído: “Revisa unos cuantos casos de prueba más”, yo recordaba a mi líder de equipo y le hacía tres preguntas: ¿Cuánto tiempo tardará? ¿Cuál será el beneficio? ¿Cuál es la probabilidad de que esto descubra algo importante? Sí, a veces tiene sentido realizar pruebas en varias versiones del sistema operativo, con diferentes configuraciones de idioma, temas oscuros y claros, tamaño de fuente aumentado, etc., pero la mayoría de las veces, estas comprobaciones son innecesarias. Imagina que encuentras un error mientras realizas dichas pruebas: ¿qué prioridad tendría? Debido a los pasos específicos para reproducirlo, incluso un fallo podría tener una prioridad menor. ¿Cuánto tiempo llevarán estas comprobaciones? De cinco a diez minutos, no es gran cosa, pero ni siquiera ese tiempo está siempre disponible. En ese tiempo, podrías leer la descripción de una tarea de tamaño medio. Terminando (espero) Como cualquier herramienta, ese molesto bicho interno puede ser una bendición o una maldición. A menudo se necesita experiencia y tiempo para aprender a usar algo de manera eficaz. Espero que este artículo te ayude a domar a tu crítico interno más rápido, a ahorrarte nervios y a aumentar tu confianza en ti mismo. Sólo quiero darte algo de apoyo, y tal vez, en lugar de luchar hasta que estés exhausto, encuentres una manera de trabajar con esta pequeña bestia y convertirla en tu aliada.
