Errori di QA nell'ordine dei link: sette report di bug con soluzioni

Perché le soluzioni sono semplici

Notare che nessuna di esse richiede un secondo abbonamento. Il QA dei link acquistati è principalmente contabilità, e la contabilità che conta avviene nella data di consegna.

Ciò che costa è la scoperta tardiva. Sempre. Un batch di 40 link pagati in anticipo, trovati rotti tre mesi dopo, ti lascia a discutere su una finestra di garanzia che potrebbe già essere chiusa. Esegui i controlli il giorno 0, il giorno 30 e il giorno 60 e la finestra funziona per te.

Per un programma concreto con numeri inventati ma plausibili, vedi l'esempio pratico per 40 link. Per i termini usati in questo elenco, il glossario è a un click di distanza.

Dove la nostra API entra nel loop

Dopo il loop shell, chiama refdomains una volta per il dominio client e fai il diff della lista degli host rispetto al foglio. Sono 2 crediti, $0.0002, e una richiesta copre fino a 1.000 righe.

Gli host presenti nel foglio e assenti dalla lista ricevono l'etichetta pending fino al prossimo aggiornamento mensile. Gli host presenti in entrambi sono cross-confermati. Una breve lista, etichettata pulitamente, è il deliverable che il tuo manager legge davvero. Nessuno apre il JSON grezzo, e nessuno dovrebbe doverlo fare. Tieni il dump in storage nel caso un fornitore contesti una riga sei settimane dopo.

Per quanto dovrebbe durare un passaggio di QA dell'ordine dei link

Il QA dell'ordine dei link richiede meno tempo di quanto la maggior parte delle persone pensi. Il tempo va in un unico posto. Scala con il numero di URL di origine e con quanti di questi leggi a mano, mentre la dimensione del sito web del client conta molto meno.

Conta gli URL di origine, non le pagine del client

Immagina un sito di piccole dimensioni di circa 200 pagine che ha ricevuto 40 link dall'esterno. Il lavoro è costituito dalle 40 pagine di origine più gli URL di destinazione. Le altre 200 pagine dal lato client non fanno parte di un controllo dei link. Diciamo che quei 40 link provengano da 12 host distinti. Il loop di fetch viene eseguito 40 volte, una volta per URL, e il diff refdomains viene eseguito una volta per client. Contandolo in questo modo, l' stima diventa aritmetica.

Se qualcuno cita diversi giorni di lavoro per un controllo dei link, chiedi quali attività copre il preventivo. Un'audit completo del sito e un controllo dei link sono lavori diversi, e solo uno di essi richiede un crawler dell'intero dominio.

Scripta il fetch, poi leggi le eccezioni

Il loop shell in questa guida recupera ogni pagina di origine e fa il grep per il link. Una persona legge solo le righe che lo script non ha potuto confermare, come un anchor mancante o un valore rel inaspettato.

Questo sposta lo sforzo dalla lettura di ogni pagina alla decisione su una manciata di righe.

Cosa aggiunge ancora una revisione manuale

Una revisione manuale cattura ciò che uno script non può. Esempi sono un link iniettato da JavaScript, un paywall o un layout che nasconde l'anchor. Budget per questo sulle righe che contano di più, non su tutto il foglio.

Scrivi il budget prima che inizi il lavoro, così la revisione ha un punto di fine. Un'abitudine utile è campionare tre o quattro righe a mano dopo ogni batch, non ogni riga, e registrare quali righe sono state lette.

Quale dei sette bug appare per primo

Non tutti i bug si presentano il giorno 0. Alcuni aspettano un redirect, un aggiornamento del plugin o una modifica alla regola di staging. Conosci quali sono tardivi. Questo modella il secondo e il terzo checkpoint.

I redirect e le regole di staging appaiono presto

Se l'URL di destinazione effettua due redirect, o una regola di staging blocca i bot, il problema di solito appare nella prima settimana. È per questo che il bug 5 appartiene allo script del giorno 0 e non a uno successivo.

Esegui curl -I sul tuo URL lo stesso giorno in cui il link viene segnalato live.

La deriva di rel arriva dopo gli aggiornamenti dei plugin

Un aggiornamento del plugin può riscrivere un attributo rel molto tempo dopo la consegna. Un link che era follow il giorno 0 può risultare sponsored il giorno 60, senza che nessuno tocchi l'articolo.

Quindi il controllo rel appartiene a ogni ricontrollo, non solo al primo. Analizza l'attributo dall'HTML recuperato ogni volta e confrontalo con l'ordine.

URL errati e rating errati vengono trovati allo stadio del foglio

Bug 2, la home page invece dell'articolo a pagamento, e bug 4, il confronto dei rating tra diversi strumenti, sono solitamente catturati prima che venga eseguito qualsiasi fetch. Entrambi provengono dal foglio stesso, quindi sono economici da risolvere a quel punto.

Risolvili prima della prima esecuzione dello script. Ogni passaggio successivo eredita ciò che dice il foglio, e un fetch dell'URL sbagliato restituisce una risposta apparentemente pulita sulla pagina sbagliata.

Un foglio che indica un URL di origine esatto per ogni riga, e una metrica per il rating, rimuove due delle false allarmi più comuni in tutto il processo.

Le sostituzioni richiedono gli stessi sette controlli

Un link di sostituzione è un nuovo link. Merita gli stessi sette controlli del primo batch e inizia il proprio clock. Tratta lo swap come una nuova riga di ordine. Non una patch.

Perché la riga vecchia non viene ereditata

La vecchia evidenza descrive una pagina che non trasporta più il tuo link. Non prova nulla sul nuovo. Tienila per il file di disputa e inizia un nuovo set di evidenze per la sostituzione.

Registra entrambi gli URL di origine nella stessa riga, così la traccia risulterà pulita in seguito.

Testare all'interno della finestra di sostituzione

Se il contratto nomina una finestra per lo swap di un link morto, testa lo swap all'interno di quella finestra. Una sostituzione testata nell'ultimo giorno lascia poco spazio per risolvere un secondo problema.

Usa la finestra come scadenza per il controllo, e prenota il controllo prima che scada.

Valutazione del nuovo dominio di nuovo

Una sostituzione proviene spesso da un dominio diverso, e quel dominio può avere un rating inferiore rispetto a quello che ha sostituito. Esegui di nuovo il controllo del floor sul nuovo host prima di accettare lo swap.

Una chiamata bulk_dr copre l'intera lista delle sostituzioni, quindi c'è poco motivo per saltarla.

Cosa dovrebbe mostrare il foglio del manager

Un foglio di QA dell'ordine dei link è il deliverable. Ogni riga trasporta un unico stato e alcune date, e l'evidenza si trova dietro la riga nello storage. L'evidenza rimane nascosta. Il manager legge il riepilogo.

Un solo stato per riga

Usa pass, pending o fail, e nient'altro tra loro. Una riga che è live ma non ancora indicizzata è pending, non un mezzo-pass. I mezzi-pass riportano la revisione mensile in una discussione sulla formulazione.

Se hai bisogno di un quarto stato, nominarlo nel contratto prima.

Date accanto a ogni stato

Ogni riga ha bisogno del giorno in cui hai recuperato la pagina, del giorno dell'ultimo aggiornamento che conoscevi e del giorno del prossimo controllo. Quelle tre date rispondono alla maggior parte delle domande che un manager pone.

Una riga senza date invita alla domanda se il controllo sia avvenuto o meno.

Mantenere il dump grezzo per una disputa

Memorizza l'HTML salvato, i dump delle intestazioni e le risposte API in una cartella nominata dopo il batch. Tieni la cartella per tutto il tempo in cui una disputa potrebbe ancora essere aperta, poiché un fornitore potrebbe contestare una riga molto tempo dopo la chiusura del riepilogo.

Rendi la cartella sola lettura una volta chiuso il batch, così l'evidenza corrisponda a quanto hai riportato.