Pruebas estáticas Revisiones que sí encuentran defectos: todo se decide antes de la reunión Aprobar un documento por cansancio no encuentra defectos. El éxito de una revisión técnica no se decide en la sala, sino antes: depende de fijar un objetivo claro, repartir roles y dar tiempo para leer a solas antes de reunirse a discutir.
Pruebas estáticas Pruebas estáticas: los defectos que se encuentran leyendo, antes de ejecutar nada No hace falta esperar a que el software se ejecute para empezar a probar. Revisar requisitos, diseños y código permite encontrar el defecto directamente en el documento original, antes de que se convierta en un fallo costoso de rastrear.
Ciclo de vida Pruebas de regresión: qué hacer cuando ya no se puede correr todo Conforme el software crece, correr toda la suite en cada cambio resulta imposible por tiempo y costo. Para no frenar entregas ni perder confianza, se necesita una estrategia que defina qué pruebas correr, en qué punto de control y cómo priorizar por riesgo.
Ciclo de vida Pruebas de confirmación y de regresión: qué comprueba cada una después de un cambio Cada cambio en el software exige responder dos preguntas: si la corrección funcionó y si algo que servía se rompió. Conoce la diferencia entre pruebas de confirmación y de regresión, cómo definir su alcance con análisis de impacto y por qué repetirlas es su verdadero valor.
Ciclo de vida Los tipos de prueba: qué evalúa cada uno y cómo elegirlos Probar solo que el sistema funcione deja el desempeño o la seguridad para el final. Conoce qué evalúa cada tipo de prueba según el ISTQB y cómo aplicarlos con el ejemplo de una solicitud de préstamo bancario.
Ciclo de vida Los cinco niveles de prueba: qué busca cada uno y cuándo usarlo Conocer los cinco niveles de prueba y el objetivo de cada uno te permite elegir la etapa adecuada para evaluar desde la lógica interna hasta los procesos de negocio.
Casos de estudio Caso de estudio: la app que falló sin un solo cambio en su código Tus pruebas pasaron y nadie tocó tu código, pero tu app se cierra al abrirse. Analizamos cómo un cambio en las banderas de configuración del SDK de Google Analytics provocó fallas en iOS y qué lecciones nos deja para probar la integración con dependencias externas y vigilar producción.
Casos de estudio Caso de estudio: el bug que dejó sin potencia a la Fórmula 1 en Sepang Ocho autos de Fórmula 1 perdieron potencia en Sepang sin que se rompiera una sola pieza: el software enfrentó una combinación de condiciones que nunca se había probado. Analizamos el caso para entender por qué conviene probar que lo esencial funcione aun cuando el sistema opera degradado.
Ciclo de vida Escribir la prueba antes que el código: TDD, ATDD y BDD TDD, ATDD y BDD escriben la prueba antes que el código, a distinta escala: TDD guía cada pieza de código con una prueba que falla; ATDD, cada historia con sus criterios de aceptación; y BDD, el comportamiento esperado con ejemplos en lenguaje natural.
Gestión de pruebas Un plan de pruebas que alguien quiera leer Un plan de pruebas fija qué se prueba, con qué medios, quién lo hace y cuándo termina. Cabe en una página si responde cinco preguntas: por qué probamos, qué probamos y qué dejamos fuera, cómo, quién lo hace y cuándo nos detenemos.
Fundamentos ¿Quién debe probar lo que construimos? Independencia y equipo completo Quién prueba el software cambia qué defectos se detectan. Una mirada independiente nota lo que el autor pasa por alto por sus sesgos, pero aislar a quien prueba frena al equipo. Descubre cómo equilibrar la independencia técnica y el enfoque de equipo completo.
Fundamentos Probar software empieza por la curiosidad, no por el código Evaluar un sistema informático no exige dominar código ni automatizaciones desde el inicio. La efectividad de un ingeniero de pruebas depende, ante todo, de su curiosidad, pensamiento analítico y capacidad de comunicación. La técnica se aprende; el criterio humano marca la diferencia.
Fundamentos Siete verdades incómodas sobre probar software En los equipos de tecnología existe una expectativa común pero imposible: asumir que un ciclo de pruebas riguroso puede entregar un sistema totalmente libre de fallas. Cuando surge un incidente en producción, la primera reacción suele ser preguntar por qué el equipo de aseguramiento de calidad no detectó esa situación
Fundamentos ¿Cuánto cuesta no probar? El caso de negocio de la calidad Las pruebas de software se ven como un costo que retrasa entregas porque su beneficio es intangible: los incidentes evitados. Justificarlas exige traducirlas a valor financiero y menor riesgo. Además, confundir aseguramiento de calidad y pruebas lleva a presupuestar mal la prevención y la detección.
