Un dispositivo per trattamenti estetici può superare i test dei sottosistemi e comunque non funzionare correttamente a schermo, secondo le indicazioni dell'operatore. Il manipolo corretto potrebbe essere collegato, ma l'interfaccia potrebbe mostrare la modalità sbagliata. Un parametro potrebbe essere tecnicamente entro i limiti previsti, ma visualizzato con un'unità di misura poco chiara. Un allarme potrebbe interrompere l'erogazione di potenza senza indicare all'operatore cosa controllare successivamente. La pulizia e il cambio cliente potrebbero dipendere da passaggi mancanti sia nel software che nel manuale.

I test di interfaccia e flusso di lavoro esaminano il prodotto così come viene utilizzato dall'utente finale: dall'apertura della confezione e dalla configurazione, passando per l'avvio, la configurazione, la preparazione alla modalità di trattamento, il funzionamento, l'interruzione, il ripristino, il cambio di modalità, la manutenzione e lo spegnimento. L'obiettivo è confermare che software, hardware, manipoli, accessori, materiali di consumo, avvertenze e documentazione supportino una sequenza coerente prima del rilascio del modello.

Questa guida spiega come le fabbriche di dispositivi per la bellezza possono pianificare test basati su attività, identificare flussi di lavoro critici, valutare gli stati dell'interfaccia e le risposte hardware, registrare i risultati dei test di usabilità, eseguire test di regressione e confermare il software e la configurazione di produzione esatti. I prodotti SHEFMON sono utilizzati come esempi di categoria pubblica, non come affermazioni su design di interfaccia privati o risultati di test interni.

Sintesi

Prima di immettere sul mercato un dispositivo di bellezza, la fabbrica dovrebbe:

1. Testare le attività complete, non le singole schermate. Gli operatori devono passare attraverso le fasi di configurazione, selezione, attivazione, monitoraggio, interruzione, completamento, pulizia e stoccaggio.
2. Utilizzare il sistema configurato in via definitiva. È necessario identificare l'hardware della console, la versione del software, la lingua, i manipoli, gli accessori, i materiali di consumo, i sensori e le impostazioni regionali.
3. Separare il contenuto dell'interfaccia dal comportamento del sistema. Le etichette corrette non dimostrano che il dispositivo invii il comando corretto o risponda correttamente alle condizioni hardware.
4. Definire gli utenti e i contesti operativi. Un ingegnere, un formatore per i distributori, un operatore esperto, un nuovo operatore e un tecnico dell'assistenza seguono flussi di lavoro diversi e hanno autorizzazioni diverse.
5. Verificare ogni limite dei parametri. Unità, valori predefiniti, minimi, massimi, passi, preimpostazioni, conferme e mappatura software-hardware devono corrispondere alla configurazione approvata.
6. Esercitarsi sui percorsi normale, alternativo e di errore. La sola sequenza ideale non rivelerà maniglie scollegate, bottiglie vuote, guasti al sistema di raffreddamento, interruzioni di corrente, materiali di consumo non validi o manutenzione incompleta.
7. Valutare le transizioni tra le funzioni. I dispositivi multifunzione necessitano di regole chiare per il cambio di modalità, manipoli, parametri e flussi di lavoro con il paziente.
8. Verificare la conoscenza della lingua e della terminologia nel contesto. La traduzione, le troncature, i simboli, gli avvisi, le unità di misura e i contenuti della guida devono essere verificati direttamente sullo schermo.
9. Trasformare le osservazioni in problemi concreti e rintracciabili. Ogni problema necessita di un compito, uno stato, una configurazione, una conseguenza, un responsabile, una correzione e un risultato del nuovo test.
10. Blocca la linea di base dell'interfaccia rilasciata. Il caricamento in produzione, l'identificazione della versione, i manuali, la formazione, i preventivi e le informazioni di assistenza devono corrispondere al software che gli acquirenti ricevono.

I test positivi dimostrano che gli utenti previsti sono in grado di completare le attività definite e che la macchina risponde come specificato durante l'intero flusso di lavoro. Tuttavia, ciò non giustifica le affermazioni relative al trattamento né sostituisce la valutazione tecnica, di sicurezza e di mercato qualificata richiesta per il prodotto.

1. Che cos'è il test dell'interfaccia e del flusso di lavoro dei dispositivi di bellezza?

Il test dell'interfaccia valuta ciò che gli utenti vedono, selezionano, inseriscono, ascoltano e ricevono come feedback. Il test del flusso di lavoro valuta l'intera sequenza di azioni e risposte del sistema necessarie per completare un'attività.

L'ambito di applicazione può includere:

• pagine e navigazione touchscreen;
• pulsanti fisici, interruttori, comandi a pedale, indicatori e comandi di emergenza, ove presenti;
• Connessione e riconoscimento del manipolo o dell'applicatore;
• Selezione della modalità, dei parametri, delle preimpostazioni e della lingua;
• Informazioni in tempo reale sullo stato e sull'avanzamento dei lavori;
• avvisi, allarmi, errori e istruzioni di ripristino;
• Identificazione e sostituzione dei materiali di consumo o delle cartucce;
• Attività di installazione, pulizia, cambio formato, manutenzione e spegnimento;
• manuali, etichette, formazione e informazioni di servizio; e
• Caricamento del software di produzione e conferma della versione.

In questo articolo, il termine "interfaccia" si riferisce principalmente all'interfaccia uomo-macchina. La validazione dei connettori elettrici e meccanici rimane importante, ma viene trattata solo laddove influisce sul flusso di lavoro dell'utente.

2. Perché è necessario eseguire dei test prima del rilascio del prodotto

I problemi di interfaccia possono avere conseguenze che vanno oltre la qualità visiva. Possono causare:

• selezione della funzione o del manipolo errati;
• fraintendimento di un'unità o di un parametro;
• configurazione incompleta;
• risposta ritardata a un guasto;
• pulizia o manutenzione trascurate;
• formazione incoerente;
• Diagnosi di servizio errata;
• discrepanza tra le versioni linguistiche;
• preventivi o manuali che descrivono un'altra versione del software; e
• unità di produzione che si comportano in modo diverso dai campioni approvati.

La scoperta tardiva di un errore è costosa perché la correzione può avere ripercussioni su codice, grafica, traduzioni, manuali, video di formazione, script di test, caricamento in produzione, materiale per i distributori e unità già prodotte.

3. Testare i quattro livelli dell'esperienza utente

Uno schermo può superare la revisione dei contenuti anche se la mappatura dei comandi è errata. L'hardware può rispondere correttamente, ma l'operatore non riesce a capire cosa fare. Pertanto, i quattro livelli dovrebbero essere testati insieme prima del rilascio.

4. Definire l'utente rilasciato e il contesto d'uso

Il piano di test dovrebbe identificare:

• tipologia di attività commerciale di riferimento;
• Destinato all'utente professionale;
• Formazione ed esperienza richieste;
• Disposizione della sala di trattamento e condizioni ambientali;
• normale flusso di clienti e schema degli appuntamenti;
• Posizione del dispositivo e posizione dell'operatore;
• Manipoli standard e opzionali;
• accessori, punte, cartucce, flaconi o altri materiali di consumo;
• responsabilità di pulizia e manutenzione;
• mercati di destinazione e lingue; e
• ruoli di assistenza e supporto tecnico.

Un flusso di lavoro che funziona per l'ingegnere di sviluppo potrebbe non essere chiaro all'operatore che vede il prodotto per la prima volta.

5. Identificare ogni ruolo e autorizzazione dell'utente

I ruoli possibili includono:

• Titolare o amministratore di un'azienda;
• operatore qualificato;
• operatore senior o avanzato;
• istruttore;
• specialista in dimostrazioni per distributori;
• personale addetto alla manutenzione;
• tecnico dell'assistenza; e
• collaudatore di produzione.

Per ogni ruolo, definire le funzioni accessibili, le impostazioni protette, i dati salvati, le schermate di servizio, l'autorizzazione all'aggiornamento e la formazione prevista. Testare sia le azioni consentite che quelle vietate. Una funzione protetta deve rimanere inaccessibile anche in caso di navigazione alternativa, riavvio, cambio di lingua o interruzione del funzionamento.

6. Creare una configurazione di test controllata

Ciascun risultato deve identificare il sistema testato:

• modello e prototipo o numero di serie di produzione;
• Revisione dell'hardware e della scheda di controllo;
• hardware di visualizzazione;
• Sviluppo del software e del firmware;
• linguaggio di interfaccia;
• tensione e configurazione regionale;
• manipolo collegato, applicatore, punta o cartuccia;
• accessori e materiali di consumo;
• stato del sensore, del sistema di raffreddamento, del vuoto, del fluido o di altri sottosistemi;
• ruolo utente e account, ove applicabile;
• dati di prova o impostazioni salvate; e
• deviazioni dalla data di rilascio prevista.

Testare un'unità di ingegneria non identificata non può garantire il software che gli acquirenti riceveranno.

7. Creare un inventario dei flussi di lavoro

Elenca le attività che l'utente deve completare durante l'intero ciclo di vita del prodotto.

L'inventario dovrebbe includere attività che si verificano raramente ma che, se eseguite in modo errato, possono avere gravi conseguenze.

8. Selezionare i flussi di lavoro critici e frequenti

Non tutte le attività hanno la stessa importanza. Assegna priorità ai flussi di lavoro in base a:

• frequenza;
• conseguenza dell'errore;
• numero di passaggi e decisioni;
• dipendenza dallo stato dell'hardware;
• livello di esperienza utente;
• Sostituzione del manipolo o dei materiali di consumo;
• differenze regionali o linguistiche;
• difficoltà di recupero;
• onere del servizio; e
• Storico derivante da prodotti precedenti, dimostrazioni o casi di assistenza.

I flussi di lavoro critici richiedono criteri di accettazione più rigorosi e una copertura di regressione più ampia. Anche le attività frequenti a basso rischio meritano attenzione, poiché piccole inefficienze si accumulano nell'uso quotidiano.

9. Scrivere casi di test basati su scenari

Uno scenario utile prevede quanto segue:

• ruolo dell'utente;
• condizione iniziale;
• obiettivo;
• istruzioni o formazione disponibili;
• configurazione del dispositivo;
• azioni previste;
• risposte previste del sistema;
• criteri di completamento;
• osservazioni da raccogliere; e
• condizioni che interrompono o invalidano il test.

Ad esempio, uno scenario potrebbe richiedere a un operatore addestrato di sostituire un applicatore approvato, verificare che l'interfaccia lo riconosca, selezionare la modalità consentita, regolare un parametro, rispondere a un avviso di connessione simulato e riportare il sistema allo stato di pronto.

10. Testare il primo avvio e la configurazione iniziale

Verificare la sequenza dallo stato di confezionamento o ripristino allo stato di pronto:

• istruzioni per l'installazione fisica;
• Connessione di alimentazione e accessori;
• comportamento di avvio dello schermo;
• identificazione di prodotti e software;
• selezione della lingua;
• impostazioni di data, ora, unità o regione, ove applicabili;
• accettazione delle comunicazioni richieste;
• Autovalutazione iniziale;
• Rilevamento degli elementi collegati;
• avvisare in caso di liquido mancante, bottiglia, filtro, maniglia o altro elemento necessario;
• ruolo utente predefinito; e
• Conferma chiara che il dispositivo è pronto.

Test di configurazione interrotta e sequenze errate. Il sistema non deve lasciare l'operatore in uno stato inspiegabile o parzialmente configurato.

11. Testare gli stati di avvio, arresto e riavvio.

Valutare:

• normale tempo di accensione e feedback;
• Autodiagnosi all'avvio e rilevamento dei guasti;
• ripristino delle impostazioni approvate;
• Collegamento delle maniglie prima e dopo l'avvio;
• percorso di arresto normale;
• protezione contro l'uscita accidentale durante il funzionamento;
• Spegnimento con interventi di manutenzione incompleti, ove necessario;
• Riavvio dopo interruzione del software;
• Riavvio dopo un'interruzione di corrente;
• comportamento dopo un arresto di emergenza o un'interruzione protettiva, ove applicabile; e
• Conservazione o cancellazione di contatori, impostazioni e cronologia degli errori.

Il piano di test dovrebbe specificare quali dati devono essere mantenuti e quali devono essere ripristinati.

12. Testare la navigazione e l'architettura delle informazioni

Verificare se gli utenti riescono a individuare:

• modalità di servizio principali;
• manipolo o applicatore collegato;
• controlli dei parametri;
• azioni di avvio, pausa, arresto e ritorno;
• impostazioni e lingua;
• attività di manutenzione;
• informazioni sui materiali di consumo o sulle cartucce;
• avvisi e risoluzione dei problemi;
• modello e versione del software;
• contenuti formativi o di aiuto laddove forniti; e
• informazioni di servizio pertinenti al loro ruolo.

Conta i passaggi superflui e registra i loop, i vicoli ciechi, i pulsanti Indietro ambigui, le conferme nascoste e il posizionamento incoerente dei menu. La terminologia di navigazione deve corrispondere a quella utilizzata nei manuali e nella formazione.

13. Riconoscimento del manipolo e dell'applicatore di prova

Per ogni combinazione rilasciata, eseguire il test:

• connessione prima dell'avvio;
• connessione dopo l'avvio;
• nome o immagine corretti;
• Modalità e parametri approvati;
• disconnessione durante il periodo di inattività;
• disconnessione durante uno stato consentito o attivo in condizioni controllate;
• riconnessione;
• collegamento di un altro elemento approvato;
• risposta relativa a un elemento non supportato, danneggiato o illeggibile, ove pertinente;
• limiti delle versioni software e hardware; e
• Informazioni diagnostiche per l'assistenza.

Il riconoscimento dovrebbe portare al flusso di lavoro corretto. La visualizzazione del nome dell'elemento non è sufficiente se il set di parametri errato rimane attivo.

14. Selezione della modalità di test

L'interfaccia dovrebbe rendere chiara la funzione attiva. Valutare:

• Nome e descrizione della modalità;
• manipolo o materiale di consumo associato;
• ruolo utente consentito;
• impostazioni predefinite;
• conferma al cambio di modalità;
• gestione dei valori non salvati;
• combinazioni proibite;
• tornare a uno stato di inattività sicuro;
• stato visibile dopo un cambio di modalità; e
• corretta attivazione dell'hardware.

Le apparecchiature multifunzione non dovrebbero basarsi esclusivamente sul colore per indicare quale sottosistema è selezionato.

15. Unità di misura, intervalli e passi dei parametri di test

Per ogni modalità e configurazione, verificare:

• etichetta e unità;
• minimo e massimo;
• incremento di regolazione;
• valore predefinito;
• valore preimpostato, ove previsto;
• relazione tra parametri collegati;
• modifiche consentite durante il funzionamento;
• comportamento di confine;
• ripristino dopo il cambio di modalità o di maniglia;
• precisione visualizzata;
• mappatura dei comandi da software ad hardware; e
• valori riportati nei manuali e nel materiale formativo.

Verificare l'inserimento di valori inferiori, superiori e compresi tra i valori consentiti quando l'interfaccia permette l'immissione manuale. Il dispositivo dovrebbe gestire le selezioni non valide in modo prevedibile.

16. Test dei preset e delle impostazioni salvate

Le preimpostazioni possono migliorare la velocità e al contempo nascondere delle ipotesi. Conferma:

• fonte e scopo approvato per ciascun preset;
• modalità e manipolo associati;
• valori e unità visualizzati;
• possibilità di revisione prima dell'attivazione;
• modifica consentita;
• archiviazione per utente, client o dispositivo secondo la configurazione prevista;
• comportamento dopo l'aggiornamento del software;
• ripristino ed eliminazione;
• indipendenza linguistica; e
• Prevenzione dell'utilizzo con una configurazione incompatibile.

Non utilizzare un nome preimpostato come sostituto dei parametri visibili o del giudizio professionale richiesti dal flusso di lavoro previsto.

17. Test di attivazione, pausa, arresto e completamento

La sequenza operativa deve comunicare chiaramente lo stato. Test:

• prontezza prima dell'attivazione;
• conferma richiesta;
• Interazione tra controllo dello schermo e controllo fisico;
• comando a pedale, ove applicabile;
• indicazione dell'uscita attiva;
• informazioni relative al tempo trascorso, al tempo rimanente, al battito cardiaco, al conteggio o all'andamento, ove disponibili;
• regolazione consentita durante il funzionamento;
• pausa e ripresa;
• arresto normale;
• percorso di interruzione immediata;
• comportamento di fine sessione;
• salvare, cancellare o riassumere i dati laddove previsto; e
• ritorno allo stato di cambio formato o pronto.

L'utente deve essere in grado di distinguere gli stati pronto, attivo, in pausa, arrestato, completato e di errore.

18. Test: Feedback in tempo reale e informazioni sullo stato

Le informazioni in tempo reale possono includere:

• Modalità e manipolo selezionati;
• stato attuale rispetto allo stato selezionato;
• indicatore di uscita o di funzionamento;
• timer, conteggio, avanzamento o valore di utilizzo rimanente;
• temperatura, raffreddamento, vuoto, flusso, contatto o stato del sensore, ove applicabile;
• stato consumabile;
• stato del collegamento;
• promemoria di manutenzione; e
• priorità di avviso.

Verifica la velocità di aggiornamento, la stabilità, le unità di misura, la visibilità e il comportamento quando il segnale sottostante non è disponibile. Un valore obsoleto non dovrebbe apparire corrente senza indicazione.

19. Test di avvisi, allarmi e messaggi di errore

Ogni messaggio dovrebbe rispondere a tutte le domande pertinenti:

• Quello che è successo?
• Quale funzione o componente è interessato?
• L'output si è interrotto, è stato messo in pausa o è rimasto disponibile?
• Cosa deve controllare l'operatore?
• L'operatore può recuperare l'operazione o è necessario un intervento di assistenza?
• Quali informazioni devono essere registrate a supporto?

Verifica il messaggio nel suo contesto, tenendo conto di suono, colore, simbolo, posizionamento, persistenza, priorità e traduzione. Evita di esporre codici tecnici senza un'adeguata guida da parte dell'operatore; mantieni i codici laddove siano utili per l'erogazione di servizi autorizzati.

20. Recupero degli errori di test

I test di ripristino dovrebbero coprire l'intero percorso, dal rilevamento del guasto allo stato di pronto controllato. A seconda del dispositivo, gli scenari possono includere:

• manipolo scollegato o non compatibile;
• Bottiglia di rifornimento vuota o contenitore dei rifiuti pieno;
• Tubo, filtro, flusso d'aria o percorso di aspirazione ostruiti;
• condizione di raffreddamento o temperatura;
• Interruzione del sensore o della comunicazione;
• Punta o cartuccia non valida;
• sequenza errata;
• blocco o riavvio del software;
• interruzione di corrente; e
• condizione di manutenzione.

Verificare che l'operatore non necessiti di interventi tecnici non documentati. Se è richiesto un intervento di assistenza, l'interfaccia dovrebbe impedire tentativi ripetuti che potrebbero peggiorare la situazione.

21. Testare le transizioni sui dispositivi multifunzione

Quando diverse funzioni condividono una console, è preferibile testare le transizioni piuttosto che le singole modalità.

Controllo:

• passaggio da un manipolo all'altro;
• mantenere o cancellare i parametri precedenti;
• stato della pompa, del sistema di raffreddamento, del vuoto, della radiofrequenza, degli ultrasuoni, del motore o di altri sottosistemi, a seconda dei casi;
• conflitti tra elementi collegati;
• funzioni simultanee vietate;
• Cambio di cavo, supporto, bottiglia e accessorio;
• avvisi per la pulizia o la sostituzione;
• flusso di lavoro dopo il completamento parziale;
• tornare al corretto stato di residenza; e
• consumo cumulativo di calore o risorse in modalità consecutive.

Una funzione può essere eseguita in modo indipendente, mentre la sua transizione da un'altra funzione rimane confusa o tecnicamente incompleta.

22. Testare i flussi di lavoro relativi a materiali di consumo, punte e cartucce.

Qualora il dispositivo utilizzi elementi identificati o sostituibili, valutare:

• identificazione del pacco e dell'articolo;
• installazione e rimozione;
• orientamento e mantenimento corretti;
• riconoscimento o selezione manuale;
• parametri consentiti;
• Informazioni sul conteggio, sull'uso residuo o sulla sostituzione, ove previsto;
• risposta a un articolo errato, danneggiato, illeggibile, aperto o precedentemente utilizzato, a seconda dei casi;
• sostituzione durante la sequenza consentita;
• informazioni sullo smaltimento;
• stato del software dopo la sostituzione; e
• riordinare le informazioni nella documentazione.

L'interfaccia, l'etichetta, il manuale e le politiche relative al prodotto stesso dovrebbero utilizzare un linguaggio coerente in merito all'uso e alla sostituzione.

23. Pulizia di prova e cambio cliente

Crea una sequenza realistica che vada dal completamento di un servizio alla preparazione per il successivo. Verifica:

• Stato di arresto sicuro e di uscita;
• rimozione di articoli monouso o sostituibili;
• gestione dei rifiuti;
• Suggerimenti e istruzioni per la pulizia;
• accesso a maniglie, punte, bottiglie, tubi, filtri, supporti e superfici;
• protezione dei connettori e dei componenti elettronici;
• contatori di conferma o di manutenzione, ove previsti;
• rifornimento delle scorte;
• ripristino delle impostazioni o dei dati specifici del cliente, ove applicabile;
• conservazione di oggetti riutilizzabili; e
• conferma che il dispositivo è di nuovo pronto.

Specialisti qualificati devono esaminare le istruzioni relative alla pulizia, al ritrattamento, all'uso previsto o ai requisiti di mercato. Questa guida non prescrive un unico metodo per ogni categoria.

24. Testare i flussi di lavoro di apertura e chiusura giornalieri

L'apertura giornaliera può richiedere ispezione, conferma dell'alimentazione, collegamento, autocontrollo, preparazione dei fluidi e funzionamento di prova. La chiusura giornaliera può richiedere pulizia, svuotamento, stoccaggio, completamento della documentazione, arresto e disconnessione.

Valutare se:

• i passaggi appaiono nell'ordine corretto;
• I comandi software corrispondono all'attività fisica;
• Le azioni incomplete sono visibili;
• Vengono identificati i materiali e gli strumenti necessari;
• l'operatore può confermare l'avvenuta esecuzione;
• lo stato persiste correttamente durante la notte;
• Le attività programmate si distinguono dalle attività quotidiane; e
• L'operatore successivo può comprendere lo stato del dispositivo.

Questi flussi di lavoro vengono spesso trascurati quando i test si concentrano solo sulle schermate di servizio attive.

25. Test dei flussi di lavoro di manutenzione e assistenza

Per il ruolo autorizzato, eseguire il test:

• Promemoria per la manutenzione;
• Identificazione del filtro, del fluido, della bottiglia, della punta, della cartuccia o del componente;
• accesso ai contatori e alla cronologia operativa, ove disponibili;
• Prove diagnostiche;
• Presentazione del codice di errore;
• Informazioni sulla versione del software e dell'hardware;
• Procedure di manutenzione guidate;
• Conferma di completamento e autorizzazione al ripristino;
• Controlli funzionali post-manutenzione;
• informazioni sull'escalation del servizio; e
• conservazione dei documenti richiesti.

Le funzioni di servizio devono essere protette dagli utenti comuni, pur rimanendo accessibili ai tecnici autorizzati.

26. Lingua di prova e localizzazione

Il test linguistico dovrebbe essere eseguito sull'interfaccia reale, non solo su un foglio di calcolo. Revisione:

• copertura completa della traduzione;
• accuratezza tecnica;
• terminologia coerente su schermi, etichette, manuali e materiali di formazione;
• troncamento e a capo automatico del testo;
• Dimensioni del pulsante e del campo;
• simboli, punteggiatura, convenzioni decimali, data, ora e unità di misura;
• ordine delle parole negli avvisi;
• caratteri non supportati;
• leggibilità del carattere; e
• lingua corretta dopo il ripristino, l'aggiornamento o l'intervento di assistenza.

Le traduzioni dovrebbero essere revisionate da persone che comprendono sia la lingua che il contesto del prodotto.

27. Leggibilità del test e interazione fisica

Valutare l'interfaccia nella stanza e nella posizione dell'operatore previste:

• Angolo di visuale e distanza di visione;
• Dimensioni del testo e dei simboli;
• contrasto in condizioni di illuminazione previste;
• abbagliamento e riflessi;
• distinzione tra controlli attivi, inattivi e non disponibili;
• Dimensioni e spaziatura dell'area di interazione tattile;
• risposta con guanti previsti, ove applicabile;
• rischio di attivazione accidentale;
• Coerenza tra pulsanti fisici e touchscreen;
• feedback audio e rumore ambientale; e
• capacità di operare tenendo in mano o spostando un manipolo.

Eseguire i test solo da una scrivania potrebbe non tenere conto della postura, della portata, dell'illuminazione e dei movimenti che si verificano nella sala di trattamento.

28. Tempo di risposta e prestazioni del test

Misurare i tempi di risposta rilevanti per:

• avvio;
• cambio di schermata;
• aggiornamento dei parametri;
• riconoscimento del manipolo;
• comando di attivazione e arresto;
• indicazione del sensore o del guasto;
• Impostazioni di salvataggio e caricamento;
• cambiamento di lingua;
• conferma della manutenzione; e
• Aggiornamento del software o riavvio, se necessario.

Registra lo stato e la configurazione del dispositivo. Le prestazioni possono variare in base a sessioni operative prolungate, dati memorizzati, sottosistemi multipli, temperatura o navigazione ripetuta.

29. Testare sequenze alternative e errate

Gli utenti non sempre seguono il percorso ideale. In condizioni controllate, testare:

• premere i comandi in un ordine inaspettato;
• cambio di modalità senza completare il flusso di lavoro precedente;
• collegare l'elemento sbagliato;
• Tentativo di attivazione con prerequisiti mancanti;
• input rapido ripetuto;
• lasciando una pagina di conferma;
• disconnessione durante una transizione;
• riaprire una sessione conclusa;
• accesso al servizio o alle impostazioni durante uno stato attivo; e
• Riavvio dopo un'attività incompleta.

Il comportamento previsto dovrebbe derivare da requisiti approvati e da un'analisi dei rischi, non essere improvvisato durante il test.

30. Valutare la coerenza nell'intero sistema di prodotto

Confronta l'interfaccia con:

• specifiche del prodotto;
• Matrice di configurazione e compatibilità;
• etichette e controlli fisici;
• manuale utente;
• Guida rapida;
• Istruzioni per la pulizia e la manutenzione;
• diapositive e video di formazione;
• copione per la dimostrazione di vendita;
• Guida alla risoluzione dei problemi;
• documentazione di servizio; e
• Informazioni sui prodotti per i distributori.

Nomi, unità di misura, modalità, intervalli di parametri, avvertenze e procedure devono essere coerenti. Anche un'interfaccia corretta può comportare dei rischi se il manuale descrive un flusso di lavoro obsoleto.

31. Condurre sessioni di usabilità basate su compiti specifici

Gli utenti rappresentativi devono completare gli scenari definiti con il livello di formazione e documentazione previsto per il rilascio. Gli osservatori possono registrare:

• completamento dell'attività;
• errori e quasi errori;
• richieste di aiuto;
• tempo o passaggi ripetuti, ove pertinente;
• percorso di navigazione;
• termini o simboli fraintesi;
• stato o avvisi non rilevati;
• soluzioni alternative;
• fiducia nella prossima azione; e
• commenti dopo l'attività.

Gli osservatori dovrebbero evitare di fornire istruzioni durante l'esecuzione del compito, a meno che il protocollo non preveda espressamente tale assistenza. La sessione dovrebbe distinguere un problema di interfaccia da una formazione insufficiente, istruzioni poco chiare, guasti hardware o uno scenario non realistico.

32. Classificare i risultati in base alle conseguenze

La gravità dovrebbe riflettere le conseguenze e il contesto del compito, mentre la priorità può considerare anche la frequenza, i tempi di rilascio e i mercati interessati.

33. Registrare i problemi di interfaccia riproducibili

Una segnalazione di un problema dovrebbe includere:

• dispositivo e numero di serie;
• hardware, software, linguaggio e configurazione;
• ruolo dell'utente;
• stato iniziale;
• manipolo o materiale di consumo collegato;
• passaggi precisi;
• risposta prevista;
• risposta osservata;
• screenshot, video, registri o misurazioni, ove utili;
• frequenza e ripetibilità;
• conseguenze e flussi di lavoro interessati;
• soluzione temporanea, se disponibile;
• proprietario e obiettivo di costruzione; e
• Risultato del nuovo test e della regressione.

“"Lo schermo è confusionario" è un problema difficile da risolvere. "Tre dei cinque operatori addestrati hanno selezionato il comando Indietro e hanno perso le impostazioni non salvate al sesto passaggio" fornisce un problema di progettazione più chiaro.

34. Costruire una matrice di test di regressione

Le modifiche all'interfaccia possono influire su più pagine oltre a quella modificata. Mappa le modifiche a:

• modalità e parametri correlati;
• Manipoli e applicatori;
• lingue;
• ruoli utente;
• allarmi e ripristino;
• impostazioni salvate;
• funzioni di manutenzione e assistenza;
• manuali e formazione;
• carico di produzione; e
• hardware meno recente o configurazioni installate supportate, ove pertinente.

I controlli automatizzati possono supportare un comportamento ripetibile del software, mentre i test fisici integrati rimangono necessari per il tocco, l'hardware, i sensori, le maniglie, i fluidi, il raffreddamento, la temporizzazione e il flusso di lavoro dell'utente.

35. Confermare la baseline del software di produzione

Prima del rilascio, identificare:

• Software e firmware approvati;
• Hardware compatibile e revisione del display;
• pacchetto lingua;
• modello e configurazione regionale;
• impugnature, punte, cartucce e accessori supportati;
• database dei parametri o file di configurazione;
• checksum o altra conferma interna, ove utilizzata;
• metodo di caricamento;
• metodo di prova di produzione;
• visualizzazione della versione e recupero del servizio; e
• Regole di aggiornamento, ripristino e supporto sul campo, ove applicabili.

La linea di produzione deve essere in grado di confermare che il software caricato corrisponda all'unità in fase di assemblaggio.

36. Eseguire i test di configurazione della versione finale

Il test finale dovrebbe utilizzare hardware destinato alla produzione, software approvato, manipoli e materiali di consumo già in commercio, manuali aggiornati, etichette e impostazioni regionali.

Confermare:

• I flussi di lavoro critici passano dall'inizio alla fine;
• Sono coperte tutte le modalità e configurazioni rilasciate;
• Le questioni in sospeso hanno una risoluzione approvata;
• I risultati corretti presentano evidenze di regressione;
• Le traduzioni sono complete;
• Caricamento e verifica della produzione;
• I test di fabbrica o le funzioni di servizio sono controllati correttamente;
• I manuali e la formazione sono compatibili con il dispositivo;
• È possibile identificare le unità dimostrative; e
• il record di rilascio indica la linea di base esatta.

Una build di ingegneria riuscita non sostituisce questo controllo finale della configurazione.

37. Controllo della personalizzazione dell'interfaccia OEM/ODM

IL Pagina OEM/ODM di SHEFMON Descrive le aree di personalizzazione relative a interfaccia, lingua, funzione, logo, confezione, manuale, aspetto esterno, meccanica e connessione del manipolo. Per un progetto di interfaccia personalizzata, definire:

• base software standard;
• Linguaggio e terminologia approvati dall'acquirente;
• logo, colori, immagini e tema;
• modalità, parametri o flusso di lavoro modificati;
• Configurazione dell'hardware e del manipolo;
• Schermate o funzioni specifiche per il cliente;
• responsabilità per il testo originale e l'approvazione della traduzione;
• ambito di verifica e regressione interessato;
• Autorità competente per l'approvazione del campione e della versione finale;
• caricamento della produzione e identificazione del modello; e
• titolarità degli aggiornamenti successivi.

Una modifica al tema grafico può comunque influire su contrasto, leggibilità, troncamento, manuali e configurazione di produzione. Pertanto, dovrebbe essere sottoposta a una revisione documentata.

38. Esempio A0648: Flusso di lavoro multifunzione per il viso

La pagina ufficiale per il Sistema di idromicrodermoabrasione SHEFMON A0648 viene presentata come una piattaforma per il viso a nove funzioni, tra cui pulizia, esfoliazione, estrazione e idratazione.

Per un nuovo dispositivo di questa categoria, i test di interfaccia e flusso di lavoro potrebbero includere:

• identificazione di ciascuna maniglia e della relativa funzione;
• Preparazione di bottiglie, fluidi, vuoto e rifiuti;
• selezione della modalità e del set di parametri;
• avvisi in caso di connessioni mancanti o errate;
• transizione tra le funzioni facciali;
• visibilità dello stato del vuoto o del fluido, ove previsto;
• Arresto e ripristino in caso di blocco o interruzione dell'alimentazione;
• pulizia, movimentazione dei tubi e cambio formato;
• rifornimento di punte e accessori; e
• Sequenze giornaliere di apertura e chiusura.

Questi sono esempi di categoria, non descrizioni del software A0648 o del record di convalida.

39. Esempio A0426: Interfaccia per la rimozione dei peli e flusso di lavoro per la gestione dei guasti

La pagina di SHEFMON per il Sistema di epilazione laser a diodo A0426 pubblica diverse opzioni di lunghezza d'onda e dimensione dello spot, nonché dettagli su raffreddamento, touchscreen e lingua.

Per lo sviluppo di un nuovo sistema in questa categoria, i test possono esaminare:

• Lunghezza d'onda esatta e configurazione del manipolo visualizzate sullo schermo;
• Mappatura delle dimensioni dello spot e dei parametri;
• ruolo dell'utente e accesso alle impostazioni;
• sequenza di prontezza e attivazione;
• Stato del raffreddamento e della temperatura;
• avvisi relativi alle condizioni di connessione o raffreddamento;
• pausa, arresto e ripristino in caso di errore;
• coerenza linguistica e di unità di misura;
• Riconoscimento del manipolo di ricambio; e
• concordanza tra software, manuale, foglio di configurazione e test di produzione.

L'esempio non specifica come si comporta l'interfaccia A0426 attuale, al di là delle informazioni pubbliche sul prodotto.

40. Esempio B0155: Transizioni di modalità su un dispositivo multifunzione per il corpo

Informazioni ufficiali per il SHEFMON B0155 Desktop Endos Velapro Descrive un sistema da tavolo multifunzione con rullo aspirante, radiofrequenza, massaggio rotante e cavitazione a 80.000 giri/min.

Per una nuova piattaforma multifunzione, testare:

• chiara differenziazione tra le funzioni;
• Riconoscimento del manipolo e della modalità;
• prontezza del sottosistema prima dell'attivazione;
• persistenza o ripristino dei parametri tra le diverse modalità;
• stati simultanei proibiti;
• Cambio del cavo e della maniglia;
• stati visibili: attivo, in pausa e arrestato;
• messaggi di errore specifici del sottosistema selezionato;
• promemoria per la pulizia e la conservazione; e
• ritorno a uno stato di pronto neutro.

Il rischio principale non riguarda solo il corretto funzionamento di ciascuna funzione, ma anche la chiarezza e il controllo delle transizioni.

41. Esempio A0152: Flusso di lavoro di materiali di consumo e parametri

L'ufficiale Sistema di microneedling a radiofrequenza SHEFMON A0152 L'elenco fornisce diversi dettagli, anche minimi, relativi alla configurazione e alla precisione, pertinenti a un piano di test dell'interfaccia.

Per un nuovo sistema in questa categoria, i test del flusso di lavoro potrebbero valutare:

• Identità e compatibilità della punta;
• installazione e riconoscimento;
• Intervallo di parametri corretto per la configurazione selezionata;
• Richiesta di sostituzione o di notifica dello stato di utilizzo, ove previsto;
• risposta a un elemento non supportato o illeggibile;
• conferma prima dell'attivazione;
• Sequenza di completamento e smaltimento;
• ripristino dopo la sostituzione della punta;
• coerenza tra i dati visualizzati sullo schermo, sulla confezione, nel manuale e nell'ordine; e
• autorizzazione per ripristini di servizio o amministrativi.

I limiti di utilizzo specifici e il comportamento del software devono essere definiti nella documentazione del prodotto approvato, non in base a questo esempio generico.

42. Lista di controllo per il rilascio dell'interfaccia e del flusso di lavoro

• Vengono identificati il modello rilasciato, l'hardware, il software, la lingua, la regione e la configurazione.
• Vengono definiti gli utenti previsti, i ruoli, le autorizzazioni, la formazione e il contesto operativo.
• Tutti i flussi di lavoro frequenti e critici sono inclusi nell'inventario dei test.
• Vengono testate le fasi di avvio, configurazione, riconoscimento, selezione, attivazione, monitoraggio, arresto, cambio di formato, manutenzione e spegnimento.
• Ogni modalità, manipolo, applicatore, punta, cartuccia e materiale di consumo rispetta le regole di compatibilità approvate.
• Vengono verificati i nomi dei parametri, le unità di misura, i valori predefiniti, i passi, i limiti, le preimpostazioni e la mappatura hardware.
• Si possono distinguere i seguenti stati: pronto, attivo, in pausa, completato, arrestato, avviso, guasto e servizio.
• Vengono trattate le sequenze normali, alternate, interrotte e scorrette.
• Gli avvisi descrivono le condizioni, lo stato del prodotto, le azioni da intraprendere da parte dell'operatore e le eventuali procedure di assistenza da seguire.
• Le procedure di pulizia, sostituzione, apertura giornaliera, chiusura giornaliera e manutenzione sono state completate.
• Ogni lingua rilasciata è stata esaminata direttamente sullo schermo.
• Vengono valutati leggibilità, elementi tattili, comandi fisici, suono, illuminazione, portata e tempo di risposta.
• Gli utenti rappresentativi completano scenari basati su attività specifiche, con formazione e documentazione pianificate.
• I risultati includono passaggi riproducibili, configurazione, conseguenze, correzione e prove di ripetizione del test.
• I test di regressione riguardano modalità, ruoli, lingue, hardware, manipoli e documenti correlati.
• La linea di produzione può caricare e confermare la configurazione software di base approvata.
• Manuali, etichette, formazione, materiale dimostrativo e informazioni di assistenza sono conformi al flusso di lavoro rilasciato.
• Le differenze visive e funzionali tra OEM e ODM vengono identificate e approvate separatamente.
• I test di rilascio finale utilizzano la configurazione completa destinata alla produzione.

Domande frequenti

1. Qual è la differenza tra test di interfaccia e test di flusso di lavoro?

Il test dell'interfaccia verifica il contenuto dello schermo, i comandi, la navigazione, i parametri, i messaggi e l'input dell'utente. Il test del flusso di lavoro segue l'esecuzione completa delle attività dell'utente attraverso software, hardware, manipoli, materiali di consumo, documentazione e azioni fisiche.

2. Perché la semplice visualizzazione di schermate dell'interfaccia non è sufficiente?

Le schermate non possono mostrare i cambiamenti di stato, la mappatura dei comandi, la risposta hardware, la temporizzazione, l'input dei sensori, il ripristino dagli errori, il comportamento del tocco o la sequenza completa dell'operatore. I test devono essere eseguiti utilizzando il dispositivo integrato e configurato.

3. Chi dovrebbe partecipare ai test del flusso di lavoro dei dispositivi di bellezza?

A seconda del compito, dovrebbero partecipare figure professionali quali ingegneri di prodotto, software, sistemi, qualità, ingegneri hardware, addetti alla formazione, all'assistenza, alla documentazione e rappresentanti degli utenti finali. Specialisti qualificati dovrebbero esaminare i requisiti di sicurezza, di utilizzo previsto, professionali e specifici del mercato.

4. Tutti i manipoli opzionali devono essere inclusi nei test di rilascio?

Ogni combinazione rilasciata necessita di una copertura adeguata. Testare il riconoscimento, la mappatura delle modalità e dei parametri, gli stati di connessione, gli avvisi, il flusso di lavoro, la documentazione e gli effetti di regressione per ogni opzione approvata.

5. Come si devono testare gli intervalli dei parametri?

Verificare etichette, unità, valori predefiniti, minimi, massimi, incrementi, preimpostazioni, comportamento collegato, immissione non valida, risposta al limite e comando inviato all'hardware corretto in base alla configurazione approvata.

6. Cosa rende utile un messaggio di errore?

Dovrebbe identificare la condizione, la funzione interessata, lo stato attuale del dispositivo, l'azione appropriata da parte dell'operatore e quando è richiesto l'intervento di assistenza. Dovrebbe essere leggibile, tradotto accuratamente e testato nel flusso di lavoro effettivo di gestione dei guasti.

7. Come si dovrebbero testare le diverse versioni linguistiche?

Esaminare ciascuna lingua presente sul dispositivo per verificarne la completezza, il significato tecnico, la terminologia, le abbreviazioni, i simboli, le unità di misura, la navigazione, gli avvisi, il comportamento di ripristino e la coerenza con etichette, manuali, formazione e materiale di assistenza.

8. Quando è opportuno eseguire i test di regressione?

Eseguire il controllo dopo aver apportato modifiche a software, parametri, traduzioni, hardware, mappatura del manipolo, avvisi, dati di configurazione o documentazione correlata. L'ambito di applicazione deve seguire i flussi di lavoro e le interfacce interessati.

9. Cosa deve essere verificato sulla linea di produzione?

La fabbrica dovrebbe essere in grado di caricare il software e la configurazione approvati, identificare la versione installata, testare i controlli critici e le risposte hardware e registrare che la configurazione corrisponde al modello, alla lingua, alla regione e al pacchetto di accessori.

10. Come può un acquirente OEM/ODM esaminare un'interfaccia personalizzata con SHEFMON?

Preparare gli utenti target, le lingue, il marchio, la terminologia, la configurazione dell'hardware e del manipolo, le schermate modificate, i flussi di lavoro richiesti, i ruoli di approvazione e le fasi di campionamento previste. Quindi contattare SHEFMON per discutere la fattibilità e l'apposita procedura di revisione.

Conclusione

Il test dell'interfaccia e del flusso di lavoro dei dispositivi di bellezza collega le specifiche del prodotto a ciò che un operatore effettivamente vede e fa. Conferma che la funzione corretta sia disponibile per la configurazione corretta, che i parametri siano chiari e mappati correttamente, che gli stati dell'hardware producano un feedback comprensibile, che gli errori portino a un ripristino controllato e che le attività di routine possano essere completate con la documentazione rilasciata.

Il lavoro dovrebbe concludersi con una specifica baseline di produzione, piuttosto che con una generica dichiarazione di completamento del software. Hardware, software, linguaggio, manipoli, materiali di consumo, manuali, formazione, caricamento in produzione e registri di assistenza devono descrivere lo stesso prodotto. Tale allineamento riduce la confusione evitabile per fabbriche, distributori, formatori, operatori e team di supporto dopo il rilascio.

Esplora il Portafoglio di dispositivi di bellezza SHEFMON, rivedere il suo Capacità OEM/ODM, O contattare SHEFMON per discutere una configurazione standard del dispositivo o un progetto di personalizzazione dell'interfaccia e del flusso di lavoro controllati.