Verità non dette sui test
In genere, l'automazione dei test viene generalmente liquidata come una perdita di tempo. Questo ovviamente non è vero.
L'automazione dei test è una perdita di tempo se inizia con test unitari non strutturati e finisce con un test di sistema automatizzato che può essere eseguito e mantenuto solo da un esperto.
Con i test delle unità generate automaticamente, l'inizio è ancora senza sforzo, perché gli sviluppatori hanno ancora a disposizione molti strumenti familiari.
I test sono automatizzati senza il tempo necessario per la ricerca e lo sviluppo e
i team di sviluppo per seguire le interfacce necessarie per l'automazione.
A livello di test di sistema, l'automazione non è più automatizzata perché il grado di complessità sembra troppo elevato oppure i tester di sistema non hanno alcun know-how nel campo dei principi e delle pratiche di sviluppo. Inoltre, l'automazione viene spesso avviata nei posti sbagliati.
In particolare i prerequisiti per l'implementazione del sistema (firmware dei dispositivi, portare il sistema in uno stato iniziale definito, ecc.
Saremo lieti di aiutarvi ad automatizzare correttamente i test giusti,
ma anche di non automatizzare i test giusti. È importante mantenere i quadri di automazione dei test semplici e renderli accessibili anche ai partecipanti al progetto che non fanno parte del team di sviluppo principale
includere la possibilità di partecipare in modo efficiente all'automazione dei test.
L'automazione dei test NON è una perdita di tempo.
Colui che misura un sacco di merda. E' vero, naturalmente. Vi aiutiamo ad elaborare le metriche giuste e ad argomentarle. Solo con le giuste metriche il responsabile del test può giudicare se la qualità è in costante miglioramento o se mantiene il livello desiderato.
È importante chiarire quali obiettivi devono essere raggiunti con le metriche, quali dati devono essere raccolti a questo scopo e se lo sforzo di raccolta e configurazione è adeguato in relazione al guadagno.
SOSTEGNO Metrico
& INCORAGGIO.
Naturalmente c'è il pericolo di produrre molta carta con i processi. Soprattutto quando i processi sono scritti per il loro stesso scopo. Ma i processi non soddisfano mai un fine in sé stessi. Vi aiutiamo a definire i processi necessari con lo scopo di evitare un'eccessiva regolamentazione e di raggiungere comunque il grado di standardizzazione desiderato.
I processi di prova generano
STRUTTURA.
Naturalmente, la visualizzazione è un buon modo per trasportare le questioni tecniche alla direzione. Oltre a ciò, la corretta visualizzazione ha anche il vantaggio di poter condensare più dati in modo semplice e veloce, ad esempio durante un'esecuzione di test, in modo che gli stati possano essere registrati in modo rapido e chiaro e le attività richieste possano essere ricavate rapidamente. In questo modo è possibile evitare l'interruzione del test o il completo fallimento di una prova e risparmiare sui costi.
Una corretta visualizzazione
aiuta voi e il vostro TEAM.
I nuovi approcci innescano sempre prima una discussione sulla loro utilità. Questo è del tutto normale e anche una parte importante dei processi di cambiamento. BDD rappresenta un ulteriore sviluppo di TDD e la qualità dei vostri prodotti migliorerà.
BDD migliora la qualità in modo dimostrabile
La responsabilità non è delegabile né divisibile. Deve essere sempre chiaro a tutti coloro che indossano il "cappello di prova" e che sono responsabili della garanzia della qualità. Le decisioni prese in Scrum da persone di altri settori portano a una perdita di qualità.
Esperienze e conoscenze diverse devono essere considerate individualmente
nel progetto.
Il punto più importante nel test del software è l'atteggiamento interiore. I test vengono utilizzati principalmente per trovare gli stati di errore e gli effetti di errore. Non è a fuoco dimostrare che un oggetto di prova funziona.