Cum îți testezi aplicația construită cu IA când n-ai mai testat software niciodată
Un ghid practic pentru testarea unei aplicații construite cu IA când nu ai experiență de QA. Unde să dai clic, ce să strici intenționat și cum să-ți dai seama când e suficient de bună ca s-o distribui.
Ai construit o aplicație cu IA. Funcționează pe calea fericită — îți tastezi numele, apeși butonul, vezi ecranul de succes. Și acum? E gata de trimis celor trei utilizatori beta? Echipei tale? Clienților tăi?
Dacă nu ai experiență în software, testarea pare unul dintre lucrurile alea pe care „dezvoltatorii adevărați” le fac — cu framework-uri, aserțiuni și pipeline-uri de CI. Vestea bună: nu asta e de fapt cea mai mare parte a testării. Cea mai mare parte a testării, mai ales când lansezi ceva mic și nou, e o singură persoană care dă clic prin aplicație cu intenție. Asta poți face. Articolul ăsta e despre cum s-o faci intenționat, ca să găsești bug-urile înainte s-o facă utilizatorii tăi.
Scopul nu e să-ți testezi aplicația construită cu IA ca un profesionist. E s-o testezi ca un prieten paranoic care chiar vrea să funcționeze.
Trucul celor două liste
Înainte să dai clic pe ceva, așază-te zece minute cu un document gol și scrie două liste.
Lista A — căile fericite. Care sunt cele trei sau patru lucruri pe care un utilizator e presupus să le facă cu aplicația asta? Pentru un SaaS tipic, ar putea fi: înregistrare, crearea primului proiect, invitarea unui coleg, exportarea unui rezultat. Pentru o aplicație de tip director: căutare, filtrare, clic pe un anunț, salvarea lui. Trei sau patru fluxuri reale, în limbaj simplu.
Lista B — căile nefericite. Ce se întâmplă dacă utilizatorul face ceva aproape corect, dar nu chiar? Își tastează e-mailul cu o greșeală. Apasă butonul „înapoi” în mijlocul unui flux. Deschide două taburi și editează același lucru în amândouă. Trimite un formular gol. Lipește conținutul unui document Word — cu tot cu formatare — într-un câmp de text. Închide laptopul și-l redeschide peste zece minute. Încearcă să invite un coleg folosind o adresă de e-mail care există deja în sistem.
Lista cu căi fericite e cea pentru care creatorul tău de aplicații cu IA a optimizat. E ce a testat IA mental în timp ce scria codul. Lista cu căi nefericite e unde trăiesc bug-urile, fiindcă aproape nimeni — nici IA, nici tu când scriai prompt-urile — nu se gândea la cazurile alea.
Când chiar testezi, parcurge mai întâi Lista A ca să confirmi că esențialul funcționează. Apoi petrece-ți cea mai mare parte a timpului pe Lista B. Lista B e unde stă valoarea. Lista B e și unde afli ce vrei de fapt să facă aplicația când lucrurile o iau razna, ceea ce adesea forțează o discuție de clarificare cu creatorul cu IA („când formularul e completat pe jumătate, ar trebui să avertizeze sau să salveze automat?”).
Trei lucruri pe care să le strici intenționat
Odată ce ai listele, iată trei categorii care prind majoritatea bug-urilor reale din aplicațiile construite cu IA.
Date de intrare goale și ciudate. Trimite formularul fără să completezi nimic. Trimite-l cu un singur câmp completat. Trimite un nume de 500 de caractere. Trimite un nume cu emoji. Lipește un URL într-un câmp care așteaptă un nume. Încearcă câmpul de e-mail cu „test”, cu „test@”, cu „test@example”, cu adresa „a@b.co” — acceptă e-mailuri scurte și legitime? Creatoarele de aplicații cu IA adesea adaugă validare, dar validarea poate fi greșită în oricare direcție — prea strictă (respinge utilizatori reali) sau prea permisivă (acceptă gunoaie).
Înapoi și în lateral. Majoritatea aplicațiilor funcționează bine dacă le parcurgi ca un grup de turiști ascultători. Se strică în clipa în care cineva explorează. Apasă butonul „înapoi”. Apasă din nou „înainte”. Reîncarcă pagina în mijlocul unui flux. Deschide aceeași pagină în două taburi și editează în amândouă. Deconectează-te și reconectează-te. Dacă ai un buton de „anulare” (undo), apasă-l de trei ori la rând. Astea nu sunt cazuri-limită. Așa folosesc software-ul oamenii reali.
Datele de după. Construiește lucrul pe care îl construiește aplicația ta. Un proiect, o postare, o înregistrare, orice. Apoi întoarce-te mâine. Mai e acolo? A supraviețuit formatarea? Dacă o editezi, se salvează editarea? Dacă o ștergi, chiar a dispărut sau revine când reîncarci? Creatoarele de aplicații cu IA adesea nimeresc fluxul de „creare” și uită că tot ce creezi trebuie să persiste și să poată fi editat mai târziu.
Cum arată „suficient de bun”
Nu-ți vei testa niciodată la perfecțiune aplicația construită cu IA. Software-ul e prea încâlcit și timpul tău e prea valoros. Întrebarea nu e „e perfectă” — e „e suficient de bună pentru următorul grup de oameni pe care îl voi pune în fața ei”.
Iată o ierarhie aproximativă pe care o poți împrumuta.
Suficient de bună pentru un demo: calea fericită funcționează fără să se prăbușească. Butoanele duc unde ar trebui. Poți arăta o înregistrare de ecran fără să tai nimic.
Suficient de bună pentru utilizatori prietenoși: căile nefericite nu pierd date. Formularele îți spun ce e greșit în loc să eșueze în tăcere. Reîncărcarea paginii nu strică lucruri. Trei prieteni o pot folosi fără să-ți scrie după ajutor.
Suficient de bună pentru utilizatori plătitori: aplicația gestionează utilizatori pe care nu i-ai întâlnit niciodată. Browserele lor, datele lor, obiceiurile lor. Ai o modalitate de a vedea când lucrurile se strică (urmărirea de bază a erorilor e suficientă — nu ai nevoie de un panou de control sofisticat). Poți repara și redistribui fără să strici lucrurile pentru oamenii care deja o folosesc.
Majoritatea constructorilor lansează la nivelul „utilizatori prietenoși” și apoi avansează pe măsură ce vine feedback-ul. Asta e corect. Greșeala e să încerci să sari de la „suficient de bună pentru un demo” direct la „suficient de bună pentru utilizatori plătitori” fără pasul intermediar. Utilizatorii prietenoși găsesc lucruri pe care le-ar găsi utilizatorii reali — dar nu se enervează din cauza lor. Folosește decalajul ăla.
Când să-i ceri IA să testeze pentru tine
Creatorul tău de aplicații cu IA te poate ajuta cu testarea, dar trebuie să fii specific cu ce vrei. „Adaugă teste” e un prompt prost. Va genera cod care arată ca niște teste și probabil trece, fără să verifice de fapt ceva ce-ți pasă. Majoritatea acelor teste autogenerate confirmă că 1+1 e tot 2.
Un prompt mai bun: „Tocmai am încercat să trimit formularul de înregistrare cu câmpul de e-mail gol și s-a prăbușit. Găsește unde se gestionează asta și adaugă o verificare care afișează o eroare prietenoasă în loc.” Bug specific, corectură specifică, rezultat specific. IA e bună la asta. E proastă la „asigură-te că aplicația mea n-are bug-uri”, fiindcă aia nu e o sarcină — e o dorință.
Celălalt lucru la care creatoarele cu IA sunt bune e să-ți rejoace bug-ul. Dacă descrii ce ai făcut, ce te așteptai și ce s-a întâmplat, creatorul poate de obicei să traseze prin cod și să propună o corectură. Disciplina de care ai nevoie e disciplina de a scrie clar cele trei lucruri. Majoritatea rapoartelor de bug ale începătorilor sunt vreo variantă de „nu funcționează”. Majoritatea rapoartelor de bug reparabile sunt „am dat clic pe X, mă așteptam la Y, am primit Z”.
Testarea înseamnă citire, nu doar clic
Un ultim lucru. Nu trebuie să înțelegi fiecare linie de cod din aplicația ta construită cu IA ca s-o testezi bine. Dar ar trebui măcar să o parcurgi pe scurt. Deschide fișierul pe care IA tocmai l-a modificat. Citește funcția pe care a adăugat-o. Nu trebuie să știi ce înseamnă fiecare cuvânt-cheie — trebuie să știi dacă funcția pare să facă ce ai cerut.
Multe dintre bug-urile construite de IA nu sunt „codul e stricat”. Sunt „codul face ceva ușor diferit de ce ai vrut”. Un câmp se salvează în locul greșit. Un buton actualizează un lucru, dar nu și lucrul înrudit. Un buton de „ștergere” ascunde în loc să șteargă. Nu poți prinde astea fără să citești ce s-a construit de fapt.
Tratează codul ca pe ceva ce poți audita, nu ca pe ceva ce trebuie să scrii. Asta e diferența dintre o aplicație construită cu IA în care ai încredere și una în care doar speri că funcționează.
Versiunea simplă
Dacă nu reții nimic altceva: scrie cele două liste, strică lucruri intenționat și decide la ce nivel de „suficient de bun” lansezi. Majoritatea bug-urilor dintr-o aplicație construită cu IA nu sunt subtile. Stau pe lista cu căi nefericite pe care nu s-a obosit nimeni s-o scrie.
Dacă vrei o temă mică: alege o aplicație pe care ai construit-o și încearcă patru lucruri — trimite un formular gol, apasă reîncarcă în mijlocul unui flux, editează o înregistrare și verific-o mâine și roagă un prieten s-o folosească fără să-l privești tu. Ce se strică e lista ta reală de bug-uri. Tot restul e amânare.