Câștiguri:
- Capacitatea de a distinge unde inteligența artificială economisește timp real în procesul de asigurare a calității și unde deciziile de calitate, cum ar fi „gata pentru publicare”, sunt lăsate în seama oamenilor, în funcție de nivelul de risc al sarcinii
- Abilitatea de a recunoaște riscul de treceri false și de a implementa o disciplină de verificare care testează fiecare test AI prin încălcarea deliberată a codului
- Capacitatea de a proteja datele de testare, datele personale și cheile și de a dobândi obiceiul de a efectua teste de securitate numai cu autorizare și în scopuri defensive.
Luați în considerare o noapte de eliberare. Au fost efectuate sute de teste, toate au primit undă verde, echipa a fost ușurată și software-ul a intrat în funcțiune. A doua zi dimineață, clientul a raportat că ecranul de plată s-a prăbușit. Testele au fost verzi, dar el nu a văzut eroarea. Acesta este cel mai insidios coșmar al profesiei de asigurare a calității (QA), adică disciplina care asigură sistematic că software-ul este de calitatea dorită: testul care strălucește verde, dar de fapt nu confirmă nimic. Când inteligența artificială (AI – software care extrage tipare din date istorice și generează text și cod) intră în această profesie, există atât o accelerare uriașă, cât și o mărire a exact acest coșmar. Promisiunea inițială a acestui modul este clară: AI este un asistent de testare, un generator de planuri și un multiplicator de idei; Sunteți testerul care semnează decizia „Este acest software gata de lansare”.
În această primă unitate ne vom concentra pe disciplină, nu pe instrument. Veți afla unde AI economisește timp real în procesul de asigurare a calității, unde este periculos, de ce așa-numitul „false-pass” verde înșelător este cel mai mare risc, cum să verificați fiecare rezultat și ce date puteți oferi unui instrument. Fără a pune această bază, unitățile ulterioare vor rămâne în aer.
Unde este AI utilă în procesul de testare?
Să împărțim joburile de testare în două grupuri mari. Primul cluster: joburi repetitive, producibile, draft. Elaborarea unui caz de testare dintr-o cerință, listarea punctelor de întrerupere, scrierea unui schelet de cod de automatizare pentru un ecran, traducerea unui caz de eroare complex într-un raport de eroare ordonat, rezumarea sutelor de rânduri de fișiere jurnal, extragerea unei scheme dintr-un răspuns API. În aceste sarcini, AI reduce minutele la secunde și nu obosește.
Al doilea grup: decizii al căror rezultat este calitate, încredere și responsabilitate. Decizii precum „poate intra în vigoare această versiune”, „este această eroare critică sau poate fi amânată”, „este suficientă acoperirea testului”, „acest scenariu captează riscul real al utilizatorului” etc. necesită context, cunoștințe despre produs și responsabilitate. Aici AI generează opțiuni, schițe – dar tu decizi „trece/eșuează” și „du-te/nu merg”.
Să clarificăm distincția într-o singură propoziție: AI este puternic la „ce situații pot fi testate și cum să scrie cod care îl testează”; Decizia vă aparține când vine vorba de întrebarea „Acest software chiar funcționează și cine garantează pentru el?”
Sfat: înainte de a preda un job către AI, întreabă: „Ce se întâmplă dacă această ieșire este greșită și nu observ?” Dacă răspunsul este „Voi pierde câteva minute”, delegați ușor. Dacă răspunsul este „software-ul defect se lansează”, lasă AI să producă schița și tu iei decizia și verificarea.
Trecere falsă: riscul numărul unu al IA în QA
Când un test se aprinde în verde, poate însemna două lucruri: fie software-ul funcționează corect, fie nu vede eroarea deoarece testul a fost scris incorect. Al doilea se numește trecere falsă - testul spune „trece”, dar de fapt nu confirmă nimic. Acest risc crește semnificativ în testele produse cu AI, deoarece AI are mare succes la scrierea de teste fluente, cu aspect neted, dar goale.
Cele mai comune trei forme de pseudo-pass sunt: (1) Testare fără aserțiune — codul rulează, nu conține aserțiuni, trece întotdeauna. (2) Test de autoverificare — valoarea așteptată a testului este calculată din rezultatul codului testat; Adică, orice produce codul, testul acceptă drept „corect”. (3) Test care verifică lucrul greșit - asserția există, dar verifică ceva trivial (de exemplu, „răspunsul nu este nul”), nu regula comercială reală.
Atenție: Un panou de testare verde nu este o dovadă a calității; În cel mai bun caz, scrie „controalele pe care le-am scris nu sunt rupte chiar acum”. Nu vă mângâiați să vedeți o „recuperare” la testul pe care îl produce AI - adevărata întrebare este: va deveni acest test în roșu dacă încalc codul în mod deliberat? Dacă nu se rotește, acel test este un decor.
Regula de aur care se repetă de-a lungul acestui modul: testați fiecare test AI prin încălcarea deliberată a codului. Dacă testul este încă verde, acel test nu funcționează. (Vom aprofunda această idee ca testare a mutațiilor în unitatea 10.)
Disciplina de verificare: trei etape
AI vorbește cu încredere; Asta nu înseamnă că este adevărat. Dezvoltați un reflex în trei pași pe care să îl aplicați la fiecare rezultat:
- Leagă-l la cerință. Fiecare caz de testare și afirmă că AI produce trebuie să se bazeze pe o cerință reală sau pe criterii de acceptare (condiții pe care trebuie să le îndeplinească un loc de muncă pentru a fi considerat „terminat”). „Ce regulă confirmă acest scenariu?” intreaba.
- Vezi roșu. Rulați testul generat o dată, rupând codul. Dacă nu devine roșu, testul este invalid. Acesta este pasul nenegociabil în testarea AI.
- Treceți-l prin filtrul de context. Rezultatul se potrivește cu ceea ce știți că este comportamentul produsului, arhitectura, fluxul real al utilizatorilor? Cunoștințele dvs. de domeniu sunt filtrul final.
Confidențialitatea și securitatea datelor: ce se duce unde?
Datele cu care lucrați în mediul de testare sunt adesea sensibile: înregistrări ale clienților reali, copii ale bazei de date de producție, chei API, adrese interne ale sistemului, funcții care nu vor fi încă anunțate. Faceți o clasificare simplă: Datele deschise (documentate, disponibile publicului) pot intra în orice vehicul. Date interne (fragmente de cod sursă, documentație internă) numai pentru instrumentele aprobate de agenție. Datele confidențiale (date reale ale clienților, informații de identitate, detalii de vulnerabilitate, chei) intră doar în instrumentele contractate ale instituției, ale căror date nu merg la training model, de preferință mascate.
Există o limită suplimentară în contextul testării de securitate: tot ceea ce se învață în acest modul este în scopuri defensive - pentru a testa în mod autorizat securitatea propriului produs. Folosirea inteligenței artificiale pentru a se infiltra fără permisiune în sistemul altcuiva, a arma vulnerabilități reale sau a testa un sistem pentru care nu aveți autoritate este atât lipsită de etică, cât și criminală. Nicio testare ofensivă nu va fi făcută fără autorizație (domeniul de aplicare și permisiunea).
Sfat: utilizați date de testare sintetice (produse artificial) în locul datelor reale ale clienților. Cererea AI „să genereze date de testare realiste, dar complet fictive”, păstrează confidențialitatea și diversifică cazurile marginale.
trei mini cutii
Cazul 1 — Economie de timp în locul potrivit. Testerul unei echipe Ekomerce a petrecut 6 ore creând manual un scenariu de testare din documentul de cerințe de 30 de pagini pentru fiecare lansare. El a dat documentul (partea care nu conținea secrete comerciale) lui YZ și a cerut un proiect de scenariu structurat; Timpul a fost redus la 90 de minute. El și-a dedicat timpul economisit verificării prin el însuși, adăugând cazuri marginale ale regulilor de afaceri pe care AI le-a ratat. AI a înlăturat munca repetitivă, lăsând judecata în seama omului.
Cazul 2 – Pasaj fals prins. Un dezvoltator a avut AI să scrie 12 teste unitare pentru o funcție de calcul; toate erau verzi. Testerul a implementat pasul „vezi roșu”: schimbarea deliberată a semnului de adunare din interiorul funcției în multiplicare. Doar 3 din 12 teste au revenit roșu. Celelalte 9 teste nu au oferit nicio confirmare reală; Spunea doar „nu a aruncat o eroare”. Au fost șterse 9 teste decorative și în schimb au fost scrise 5 teste reale.
Cazul 3 – Întoarcere de la încălcarea confidențialității. Un stagiar a lipit într-un instrument public un jurnal de erori care conține e-mailuri reale ale clienților și ultimele patru cifre ale cardului din baza de date de producție și a spus „explicați această eroare”. Liderul QA a intervenit: acestea erau date personale scăpate de sub control și o încălcare a KVKK (Legea privind protecția datelor cu caracter personal). Aceeași muncă a fost făcută într-un vehicul omologat de instituție, mascând zonele personale și lăsând doar o urmă de stivă.
Patru șabloane copiabile
1) Evaluarea adecvării postului:
Rolul dumneavoastră: lider senior QA. Îți voi descrie o lucrare de testare. Spuneți-mi (1) dacă această activitate este o lucrare de redactare/analiza care poate fi delegată în siguranță către IA sau o decizie de calitate pe care trebuie să o ia omul, (2) costul potențial al rezultatelor incorecte, (3) verificarea pe care ar trebui să o fac înainte de a delega. Job: [inserați jobul aici]
2) Control pseudo-pass:
Consultați testul de mai jos. Spune-mi:- Ce comportament confirmă acest test? (o propoziție)- Cum pot sparge codul testat, astfel încât testul să devină ROȘU?- Există vreo slăbiciune care ar putea face ca acest test să treacă întotdeauna (afirmare lipsă, autovalidare, verificare trivială)? Test: [paste testul aici]
3) Controlul mascării datelor de testare:
Jurnalul/datele pe care vi le voi furniza pot conține câmpuri personale sau confidențiale (e-mail, nume, card, cheie, adresă internă). Mai întâi, enumerați câmpurile care trebuie mascate; O voi masca și o voi trimite din nou. Nu-l analiza așa cum este.
4) Generarea de date de testare sintetică:
Generați 20 de rânduri de date de testare complet fictive și realiste pentru [următoarea structură de câmp]. Nu utilizați date reale despre persoane/organizații. Includeți, de asemenea, cazuri de margine: spațiu gol, text prea lung, valori limită, format nevalid.
Prompt slab / Prompt puternic
Slab: „Scrieți teste pe acest cod”.
Strong: „Calculați acest lucru Scrieți teste unitare pentru funcția de reducere. Criterii de acceptare pentru funcție: 10% reducere peste 1000 TL, 20% reducere peste 5000 TL; suma negativă ar trebui să arunce o eroare. Specificați cu o linie de comentariu ce regulă validați pentru fiecare test. Testați valorile limită (999, 1000, 1000, 1000 - 1000) Separat, folosiți afirmații reale care vor deveni roșii dacă rup codul sau nu scriu aserții banale.
prompt puternic; Acesta oferă criterii de acceptare, valori limită, așteptări de validare și instrucțiuni explicite anti-spoofing. Promptul slab invită AI să scrie un test decorativ.
Greșeli comune
- Cu încredere în verde. Gândirea că trecerea testului este o dovadă. Adevărata întrebare este: devine roșu când spargi codul?
- Solicitarea unui test fără a oferi niciun motiv. AI produce teste generice, adesea inutile, fără a ști ce trebuie verificat.
- Sari peste verificare. Spunând „AI a scris-o, probabil că este adevărat”. Responsabilitatea revine persoanei care utilizează rezultatul.
- Lipirea datelor reale/sensibile în instrument. Lucrul cu date de producție, chei sau date personale.
- Testare de securitate neautorizată. Încercarea de testare ofensivă fără scop și permisiune.
- Utilizarea AI pentru a delega luarea deciziilor. Punând întrebarea „Poate fi lansată această versiune?” la AI și punând răspunsul în semnătură.
În concluzie
AI este un asistent puternic în procesul de QA care accelerează munca repetitivă și productivă; Dar responsabilitatea pentru decizia de calitate revine omului. Riscul numărul unu al AI în această profesie este pseudo-pass: teste verzi care arată bine, dar nu confirmă nimic. Testați fiecare test AI prin încălcarea deliberată a codului; Dacă nu devine roșu, acel test este un decor. Leagă-l la cerință, vezi roșu, trece-l prin filtrul de context. Mascați datele confidențiale, efectuați teste de securitate numai în scopuri autorizate și defensive.
Sarcina de aplicare
Luați 5 teste unitare generate de AI (sau generate de AI) din propriul proiect. Pentru fiecare: (1) scrieți într-o propoziție ce comportament verifică, (2) spargeți și rulați în mod deliberat codul testat și notați câte devin roșii, (3) marcați pe cele care nu devin roșii ca „teste de decor” și rescrieți-le cu afirmația reală. Puneți rezultatul într-un tabel: numele testului / regulă pe care a verificat-o / a fost spart când a fost întrerupt / acțiune.
lista de verificare
- [ ] Înainte de a preda lucrarea, am pus întrebarea „ce voi pierde dacă merge prost?”
- [ ] Am testat fiecare test AI prin spargerea codului; Am înlocuit-o pe cea care nu s-a înroșit cu testul real.
- [ ] Am legat cazurile de testare de criteriile reale de cerință/acceptare.
- [ ] Am mascat date sensibile/reale fără a le oferi instrumentului; Am folosit date sintetice dacă se poate.
- [ ] Am considerat testarea de securitate numai în cadrul autorității și în scopuri defensive.
- [ ] Am lăsat decizia „dacă versiunea va fi lansată” în seama mea, nu a AI-ului.