El capítulo 4 trata de la suite que aún podrás cambiar dentro de seis meses: Page Object Model, separación de los datos de prueba y la lógica, tests independientes y legibles, las causas de la inestabilidad y el registro e informes. A4Q asigna aquí 150 minutos de instrucción.
Es el capítulo que separa a quien ha automatizado algo de quien ha mantenido lo que automatizó. Las preguntas van menos de sintaxis y más de consecuencias: se describe un escenario y tú dices qué dolorá después.
Dónde se pierden puntos:
Qué devuelve un método del page object. Un método que completa una navegación devuelve el page object de la página de destino: un login() que acaba en el panel devuelve un DashboardPage, no void ni un booleano.
Las aserciones no van en el page object. El page object expone estado y acciones; qué es correcto lo decide el test. Mezclarlos es la opción incorrecta que más se ofrece en esta área.
Localizadores duplicados por los tests. Un selector debe vivir en un único sitio. Cuando la página cambie querrás una edición, no una búsqueda por toda la suite.
Tests que dependen unos de otros. Si el test B necesita el registro que creó el test A, la suite no puede ejecutarse en paralelo ni parcialmente, y falla en cascada ocultando la causa real.
No toda inestabilidad es un fallo de tiempos en tu código. Un test que pasa en local y falla en un agente de CI compartido y cargado apunta al entorno, y la solución es una espera explícita correcta, no un sleep más largo ni un reintento.
Los informes son parte de la mantenibilidad. Un fallo que solo dice «assertion failed» cuesta una hora de investigación; una línea de log y una captura en el momento del fallo no cuestan nada.
Este capítulo se cubre con más intensidad (13 preguntas) en A4Q Selenium Tester — Examen de práctica 6 (Esperas, sincronización y estabilidad)