Domande Colloquio Selenium

Avete scritto test che passano in locale ma falliscono nella pipeline, e sospettate che la risposta riguardi i wait senza riuscire a spiegarlo con chiarezza. I selezionatori lo sanno, per questo i wait aprono la maggior parte dei colloqui su Selenium. Questa sezione mostra come suona una risposta completa.

• Implicit contro explicit wait. Un implicit wait è un'impostazione globale che verifica la presenza dell'elemento a ogni ricerca. Un explicit wait punta a un elemento e a una condizione, come clickable o visible. L'explicit è preferito perché dichiara esplicitamente cosa si sta aspettando.
• Perché non bisogna mescolarli? Combinare entrambi può sommare i timeout in modi difficili da prevedere, per questo la maggior parte dei team imposta l'implicit wait a zero e usa explicit wait ovunque.
• Cos'è un fluent wait? Un explicit wait con un intervallo di polling configurabile e tipi di exception ignorati.
• Perché Thread.sleep è sbagliato? È incondizionato. Rallenta un test che passerebbe e comunque fa fallire uno lento.
• CSS selector o XPath? Preferite un attributo identificatore di test stabile, poi CSS per la leggibilità. XPath si guadagna il suo posto quando dovete risalire a un parent o abbinare in base al testo.
• Cosa rende fragile un locator? Nomi di classe generati automaticamente, XPath assoluto e selezione basata su indice. Dite cosa chiedereste a uno sviluppatore di aggiungere al posto loro.

I selezionatori ascoltano la ragione dietro ogni scelta. Nominare una preferenza senza indicarne il costo suona come una risposta imparata a memoria.

I test flaky sono l'argomento reale della maggior parte dei colloqui senior sull'automazione, perché una suite di cui nessuno si fida è peggio di nessuna suite.

• Cosa causa StaleElementReferenceException? Il riferimento all'elemento punta a un nodo non più collegato, di solito perché il framework ha ri-renderizzato quella parte della pagina. Ricercate l'elemento invece di riutilizzare il riferimento salvato.
• E ElementNotInteractableException? L'elemento esiste ma non può essere azionato: nascosto, disabled, coperto da un overlay, o fuori schermo.
• Come gestite NoSuchElementException? Distinguete un problema di tempistica da un elemento genuinamente assente, e non copritelo con uno sleep più lungo.
• Perché i test falliscono solo nella pipeline? Dimensione del viewport diversa, ambiente più lento, dati di test mancanti, animazioni che finiscono più tardi, e test paralleli che collidono su uno stato condiviso.
• Come risolvete un test flaky? Diagnosticate prima la categoria, poi correggete la causa. L'auto-retry nasconde i fallimenti ed è un ultimo rimedio che dovreste dichiarare come tale.
• Come gestite frame, nuove finestre e alert? Cambiando contesto esplicitamente, e tornando indietro dopo.

A un QA engineer in colloquio per un ruolo di automazione mid-level è stato chiesto perché una suite falliva due volte a settimana senza modifiche al codice. La risposta vincente non era un dettaglio dell'API di Selenium, ma che i test condividevano un unico account seeded e si ostacolavano a vicenda. I selezionatori premiano quell'ordine diagnostico: prima ambiente e dati, poi l'API.

Altre raccolte di domande per ruolo e strumento si trovano sotto interview questions by role.

Oltre l'API, i panel vogliono sapere se sapete gestire una suite. Queste domande pesano di più per i ruoli senior.

• Spiegate il Page Object Model. Le page class espongono le azioni e nascondono i locator, così un cambio UI tocca un solo file. Dite quale problema risolve; descrivere solo la struttura delle cartelle non coglie il punto.
• Cosa può andare storto con i Page Object? Crescono fino a diventare classi da migliaia di righe e iniziano ad asserire dentro i page method. Le assertion appartengono ai test.
• Come esegue il vostro framework i test in parallelo? Gestione thread-safe del driver così le istanze non sono condivise tra thread, più dati di test indipendenti per ogni test.
• A cosa serve Selenium Grid? Distribuire i test su più macchine e versioni di browser, con un hub e dei node, o un cloud provider che svolge lo stesso ruolo.
• Cosa è cambiato in Selenium 4? Il protocollo W3C WebDriver è diventato lo standard e il vecchio JSON wire protocol è stato rimosso, sono arrivati i relative locator, ed è stato esposto l'accesso al Chrome DevTools Protocol.
• Quando non usereste Selenium? Controlli a livello di API, logica testabile con unit test, e tutto ciò che è fuori dal browser. Conoscere questo confine è un segnale da senior.
• Come decidete cosa automatizzare? Percorsi stabili, ad alto valore, ripetitivi. Non tutto, e non una schermata ancora in fase di redesign.

Le risposte su Selenium sono insolitamente facili da conoscere e difficili da dire. La domanda sui wait in particolare ha una risposta in due parti, la definizione e la ragione, e i candidati che l'hanno solo letta forniscono la prima metà e poi si perdono.

Prendete le cinque domande qui che meno vorreste affrontare e rispondete a ciascuna ad alta voce in novanta secondi senza avere un editor aperto. Poi fatevi fare la domanda di approfondimento, che quasi sempre è il perché. Eseguire gli stessi prompt contro un intervistatore AI che contesta le risposte è più vicino a un colloquio reale che rileggere una lista, ed è esattamente per questo che esiste la modalità mock interview.

Aaron Cao, fondatore di SubcueAI, ha costruito l'esercizio attorno a quel divario nel parlare, piuttosto che attorno a fornire altre domande. In un colloquio dal vivo, l'app desktop e il Side Panel dell'estensione del browser possono far emergere la struttura mentre l'intervistatore parla, il che aiuta di più sul materiale già provato. Cosa fa il prodotto, e i limiti che non supera, sono spiegati nella pagina security.