Lista de verificare a testării site-ului web: teste de utilizare, teste de acceptare a utilizatorilor și teste AB explicate
Publicat: 2020-12-17Rezumat: combinarea testelor de utilizare a site-ului web, a testelor de acceptare a utilizatorilor (UAT) și a testelor AB poate suna ca o mulțime de muncă. Dar a avea o listă de verificare pentru testarea site-ului web înainte de a lansa o caracteristică sau o cale economisește timp și bani pe termen lung.
Să presupunem că compania dvs. trebuie să îmbunătățească experiența de navigare a produselor. Șeful tău menționează că vei dezvolta noi modalități cheie pentru a permite utilizatorilor să navigheze – iar tu conduci proiectul. Pentru mulți agenți de marketing, acest proces arată astfel:
Tehnic vorbind, acesta are toate componentele unei noi funcții pe care o poți lansa pe site. Cu toate acestea, folosirea acestora ca pași de bază lasă succesul sau eșecul proiectului la voia întâmplării. Chiar și presupunând că sughițurile de dezvoltare nu au loc, noua cale de navigare pe care o construiți ar putea fi la fel de întreruptă sau chiar mai proastă decât cea pe care o aveți acum.
Pentru a evita toate acestea, aveți nevoie de teste. Dar care? Și când le aplici pe toate?
Aici poate ajuta o listă de verificare a testării site-ului web.
Să ne scufundăm.
1. Aplicarea testelor de utilizare
Testele de utilizare sunt, în esență, interviuri cu persoane care încearcă să folosească ceva și ar trebui incluse în lista de verificare a testării site-ului. Tu …
- … poate (și ar trebui!) să facă asta pentru site-urile concurente.
- … ar trebui să le aplici la conceptele tale de design pe măsură ce construiești noi caracteristici.
- … ar trebui să vă testați prototipurile pe măsură ce le construiți și să le testați din nou când lansați funcția reală pe site-ul dvs. web.
Teste de utilizare pe site-urile concurenței
Dacă aveți site-uri concurente care folosesc o caracteristică similară cu cea pe care doriți să o construiți, ar trebui să cereți câțiva oameni (nu vă înnebuniți prea mult cu numărul de persoane, 4-12 ar trebui să facă șmecheria) să desfășoare sarcini pe și puneți-le să discute pe parcursul procesului. Asta este în esență.
Veți putea primi comentarii despre motivul pentru care anumite lucruri funcționează și despre ce alte lucruri încalcă așteptările . Toate acestea ar trebui să fie incluse în conceptul dvs. de design. De acolo, trebuie să testați designul, prototipul și caracteristica reală atunci când se lansează pe site.
Teste de utilizare pe caracteristici interne
Principiul este simplu, chiar dacă în practică acest lucru se complică uneori.
Când finalizați conceptul de design pentru site, ar trebui să discutați cu 12 persoane . Dar nu toate deodată.
- În primul rând, obțineți 4 persoane care să încerce să îndeplinească o sarcină folosind doar conceptele dvs. de design. După ce vorbești cu 4 persoane, vei înțelege cele mai mari probleme la design.
- Veți aplica asta la desene, apoi veți vorbi cu alte 4 persoane. Ei vor surprinde cele mai mari probleme cu cea de-a doua versiune și le puteți aplica la o a treia versiune a conceptului.
- Până la cea de-a treia versiune cu setul final de 4 persoane, ar trebui să vă rămână doar probleme minore... și puteți trece la etapa următoare.
Și acesta este practic testul de utilizare. O veți rula din nou când aveți un prototip și încă o dată când se lansează caracteristica.
Nu durează atât de mult timp pe cât pare și, de fapt, economisește mai degrabă decât să coste bani pentru majoritatea companiilor . Asta pentru că atunci când treci de la etapa de proiectare la etapa de prototip, sau de la etapa de prototip la etapa de lansare, devine mai costisitoare și consumatoare de timp pentru a schimba lucrurile.
Acest proces asigură că ceea ce construiți poate fi folosit efectiv pentru a îndeplini sarcini în mod eficient și că nu aveți revizuiri costisitoare ale caracteristicilor la sfârșitul proiectului . Veți descoperi devreme cele mai mari probleme legate de experiența utilizatorului .
„Doriți să aflați mai multe despre testarea gradului de utilizare? Vă avem acoperit.Citiți „Noțiunile de bază despre testarea utilizării site-ului pe scurt” ![]() |
2. Aplicarea testelor de acceptare a utilizatorilor (UAT)
Desigur, doar pentru că ați vorbit cu oamenii despre experiența utilizatorului nu înseamnă că caracteristica reală va fi fără erori. Experiența dvs. strălucitoare de navigare a unui produs nou ar putea fi bună în faza de testare a utilizării pentru fazele de proiectare și prototip, dar dacă oprește coșul de cumpărături să funcționeze atunci când îl aplicați pe site-ul dvs., veți răni afacerea.
Aici intervine testarea de acceptare a utilizatorilor site-ului sau UAT.
După ce prototipul trece testarea de utilizare, dar înainte de lansarea caracteristicii pe site, ar trebui să existe o listă de verificare a elementelor pentru diverse resurse interne ale companiei de verificat . Această listă de verificare ar trebui să compromită o parte din lista de verificare a testării site-ului dvs. web.
Acesta este cel mai apropiat lucru de un test „lumea reală” pe care îl veți avea înainte de a vă lansa efectiv. UAT-urile vor acoperi mai mult decât scenariile de mai jos, dar cel puțin va trebui să înțelegeți dacă...
- … caracteristica planificată funcționează conform specificațiilor și permite utilizatorului să realizeze sarcina intenționată.
- … lucrul pe care îl lansați funcționează destul de bine și se încadrează într-un prag de timp de încărcare a paginii convenit.
- … modificarea pe care o planificați este compatibilă cu alte zone ale site-ului și nu creează probleme în alte părți ale site-ului dvs.
Ar trebui să existe, de asemenea, un șofer – cineva care să le reamintească oamenilor că trebuie să-și dea semnul că funcția funcționează și că nu interferează cu celelalte funcții ale site-ului.
Odată ce contabilizați UAT, întregul proces arată astfel:
Pentru unele funcții, vă puteți opri în acea etapă. Dar dacă ceea ce construiți este conceput pentru a obține o tracțiune semnificativă pentru trafic și conversii, trebuie să adăugați încă un test.
3. Aplicarea Testelor AB / Testelor Split
După ce ați vorbit cu destui utilizatori și v-ați asigurat că pot îndeplini sarcini și după ce ați efectuat teste pentru a vă asigura că funcțiile funcționează conform planului, fără a întrerupe nimic, mai rămâne ceva de lucru: optimizarea paginilor pentru un impact maxim .
Testele AB sau testele împărțite vin la sfârșitul procesului, așa că lansarea caracteristicii dvs. va arăta acum cam așa:
Testarea AB sau testarea divizată este ceva despre care am vorbit într-o altă postare de blog. Dacă aveți nevoie de un manual detaliat despre beneficii, durata testării, lucruri de evitat și alte nuanțe, puteți citi despre elementele de bază ale testării separate aici.
Dar ideea generală este că veți veni cu două versiuni ale paginii , cea pe care tocmai ați lansat-o după testele anterioare și o pagină challenger, ceva care este ușor diferit de ceea ce ați lansat - poate ați modificat ușor îndemnurile sau ești rescris titlurile zonelor de produse.
Ceea ce vor face testele împărțite este să împartă traficul între acele două pagini și, în scurt timp, veți avea statistici care arată care pagină ți-a făcut mai bine în funcție de criteriile alese.
Importanța unei liste de verificare pentru testarea site-ului web
Când combinați testele de utilizare, testele de acceptare a utilizatorilor și testele AB, ceea ce aveți în general este un cadru de testare care lasă foarte puțin la voia întâmplării .
Pare mai multă muncă, dar, în practică, cea mai mare parte a muncii vine din refacerea paginilor care nu funcționează sau a funcțiilor care sparg alte lucruri. De obicei, implementarea testelor nu are ca rezultat pierderea de timp; pentru majoritatea proiectelor dvs. mai mari, acestea vor economisi timp, deoarece nu veți schimba țintele la mijlocul fluxului sau nu veți face „modificări de panică” chiar înainte de lansare.
Cele trei teste înseamnă că veți aborda o reluare minimă. Se vor asigura că utilizatorii își vor putea îndeplini sarcinile. Și poate cel mai important, acestea vă maximizează șansele de a converti vizitatori .
Această postare a fost publicată inițial în august 2015 și a fost actualizată pentru a fi completă.
