Revisiona una consegna Taiga con le prove

Parti dal risultato dell’iniziativa

Il servizio fittizio di attrezzature consente ora ai dipendenti di vedere le proprie richieste. Inizia la revisione da risultato e ambito dell’iniziativa. Individua cosa deve essere vero e cosa la modifica deve lasciare intatto.

Per questa consegna, un dipendente non deve leggere la richiesta di un altro. I manager devono mantenere l’accesso definito. Un test che apre soltanto la pagina non dimostra nessuna delle due condizioni.

Collega le registrazioni

La pagina Runs registra i tentativi, inclusi i fallimenti. Ogni esecuzione identifica il piano eseguito. Una pagina di esecuzione è un registro da esaminare; le decisioni che cambiano il lavoro si prendono nell’iniziativa.

Leggi le prove dei passi per test e formattazione. Taiga rende visibili verifiche fallite o non eseguite. Non trasformare «non eseguito» in «superato» nel riepilogo della revisione.

Esamina ipotesi e confini

Cerca ipotesi su modello di accesso, schema, ambiente e servizi esterni. Confrontale con l’intento pubblicato e il codice effettivo.

Per il servizio di attrezzature, esamina dove viene controllata la titolarità della richiesta. Prova una richiesta autorizzata, la richiesta di un altro dipendente e una richiesta inesistente. Verifica che i log non rivelino contenuti riservati delle richieste.

Revisiona anche le modifiche ai test. Un esito positivo del test vale poco se la modifica ha rimosso l’asserzione che rileverebbe il difetto. Tratta le modifiche a workflow e configurazione dei test come parte dell’ambito di revisione.

Fornisci feedback su cui si possa agire

Individua comportamento, risultato atteso e prove necessarie. Per esempio: «L’endpoint verifica l’accesso autenticato ma non la titolarità della richiesta. Aggiungi il controllo lato server e un test che usi la richiesta di un altro dipendente».

Taiga può rispondere al feedback di revisione delle pull request e alle verifiche fallite con modifiche sullo stesso branch. Dopo gli aggiornamenti, esamina il nuovo commit e le verifiche. Le prove precedenti potrebbero non coprire un artefatto modificato.

Se l’esecuzione si è fermata perché il piano era incompleto o una verifica è stata indebolita, leggi il motivo dichiarato. Non rimuovere lo stato di bozza solo perché il riepilogo visibile delle verifiche è verde.

Prendi la decisione corretta di accettazione

Registra quali criteri sono verificati e quali restano irrisolti. Lascia che revisioni e verifiche obbligatorie del repository facciano rispettare il confine del merge. Conserva ogni decisione separata di rilascio.

Taiga osserva i deployment eseguiti dalla tua pipeline. Verifica ambiente e artefatto prima di comunicare agli utenti che la modifica è disponibile. Un deployment fallito può lasciare la precedente versione riuscita a servire traffico.

Concludi con una verifica a livello di servizio: il dipendente può usare la funzionalità, l’accesso non autorizzato è negato e il responsabile operativo può osservare i guasti. Prosegui con la gestione di un’interruzione.