Kasu:
- Võimalus eristada, kus tehisintellekt säästab QA protsessis reaalaega ja kus kvaliteediotsused, nagu näiteks „avaldamiseks valmis”, jäetakse inimeste teha, olenevalt ülesande riskitasemest
- Võimalus ära tunda valede läbimiste riski ja rakendada kontrollimise distsipliini, mis testib iga AI-testi tahtlikult koodi murdes
- Võimalus kaitsta testiandmeid, isikuandmeid ja võtmeid ning omandada harjumus teostada turvateste ainult volituse piires ja kaitseotstarbel.
Kaaluge vabastamisõhtut. Testid tehti sadu, need kõik said rohelise tule, meeskond sai kergendust ja tarkvara läks käima. Järgmisel hommikul teatas klient, et makseekraan jooksis kokku. Testid olid rohelised, kuid ta ei näinud viga. See on kvaliteedi tagamise (QA) elukutse ehk distsipliini, mis süstemaatiliselt tagab, et tarkvara on soovitud kvaliteediga, salakavalam õudusunenägu: test, mis helendab roheliselt, kuid tegelikult ei kinnita midagi. Kui tehisintellekt (AI — tarkvara, mis ammutab ajaloolistest andmetest mustreid ning genereerib teksti ja koodi) sellesse erialasse siseneb, toimub nii tohutu kiirendus kui ka täpselt selle õudusunenägu võimendus. Selle mooduli esialgne lubadus on selge: AI on testimise assistent, plaanide generaator ja ideede kordaja; Olete testija, kes allkirjastab otsuse "kas see tarkvara on vabastamiseks valmis".
Selles esimeses üksuses keskendume distsipliinile, mitte tööriistale. Saate teada, kus AI säästab QA protsessis reaalaega, kus see on ohtlik, miks on petlik roheline niinimetatud "vale-pass" suurim oht, kuidas iga väljundit kontrollida ja milliseid andmeid millisele tööriistale anda. Ilma seda vundamenti rajamata jäävad järgmised üksused õhku.
Kus on AI testimisprotsessis kasulik?
Jagame testimistööd kahte suurde klastrisse. Esimene klaster: korduvad, toodetavad, mustandtööd. Nõudest testjuhtumi koostamine, katkestuspunktide loetlemine, ekraani automatiseerimiskoodi skeleti kirjutamine, keeruka veajuhtumi tõlkimine korralikuks veaaruandeks, sadade logifailide ridade kokkuvõtte tegemine, API vastusest skeemi eraldamine. Nende ülesannete puhul vähendab tehisintellekt minutid sekunditeks ega väsi.
Teine klaster: otsused, mille tulemuseks on kvaliteet, usaldus ja vastutus. Sellised otsused nagu "kas see versioon võib avaldada", "kas see viga on kriitiline või saab seda edasi lükata", "kas see test on piisav", "kas see stsenaarium hõlmab tegelikku kasutajariski" jne nõuavad konteksti, tooteteadmisi ja vastutust. Siin loob AI valikud, mustandid, kuid teie otsustate "läbi/ei õnnestu" ja "minna/ei lähe".
Selgitame vahet ühe lausega: AI on tugev selles, "millistes olukordades saab testida ja kuidas kirjutada koodi, mis seda testib"; Küsimus "Kas see tarkvara tõesti töötab ja kes selle eest garanteerib?" on teie otsustada?
Näpunäide. Enne töö üleandmist tehisintellektile küsige: "Mis juhtub, kui see väljund on vale ja ma ei märka?" Kui vastus on "Ma kaotan paar minutit", delegeerige seda lihtsalt. Kui vastus on "vigane tarkvara läheb reaalajas", laske tehisintellektil mustand koostada ja teie teete otsuse ja kontrolli.
Vale läbimine: tehisintellekti risk number üks kvaliteedikontrollis
Kui test süttib roheliselt, võib see tähendada kahte asja: kas tarkvara töötab tegelikult õigesti või ei näe viga, kuna test on valesti kirjutatud. Teist nimetatakse valesobituseks - test ütleb "sobib", kuid tegelikult ei kinnita midagi. See risk suureneb oluliselt tehisintellektiga toodetud testides, sest tehisintellekt on väga edukas ladusate, sujuvate, kuid tühjade testide kirjutamisel.
Kolm levinumat pseudo-läbipääsu vormi on: (1) Testimine ilma väiteta – kood töötab, ei sisalda väiteid, alati läbib. (2) Enesetõendav test — testimise eeldatav väärtus arvutatakse testitava koodi väljundist; See tähendab, et mida iganes kood toodab, tunnistab test "õigeks". (3) Test, mis kinnitab vale asja – väide on olemas, kuid see kontrollib midagi triviaalset (nt "vastus ei ole tühi"), mitte tegelikku ärireeglit.
Ettevaatust: roheline testpaneel ei tõenda kvaliteeti; Parimal juhul on kirjas, et "meie kirjutatud juhtnupud pole praegu katki". Ärge laske end lohutada, kui näete tehisintellekti tehtud testi läbimist – tegelik küsimus on: kas see test muutub punaseks, kui ma koodi tahtlikult rikun? Kui see ei pöörle, on see test kaunistuseks.
Kuldreegel, mis kordub kogu selles moodulis: testige iga AI-testi tahtlikult koodi murdes. Kui test on endiselt roheline, siis see test ei tööta. (Süvendame seda ideed mutatsioonitestina 10. üksuses.)
Kontrollimise distsipliin: kolm sammu
AI räägib enesekindlalt; See ei tähenda, et see tõsi on. Töötage välja kolmeastmeline refleks, mida rakendada iga tulemuse puhul:
- Siduge see nõudega. Iga katsejuhtum ja kinnitus, et tehisintellekt peab põhinema tegelikel nõudel või aktsepteerimiskriteeriumidel (tingimused, millele töö peab vastama, et seda saaks lugeda tehtuks). "Millist reeglit see stsenaarium kinnitab?" küsi.
- Vaata punast. Käivitage loodud test üks kord, rikkudes koodi. Kui see ei muutu punaseks, on test kehtetu. See on tehisintellekti testimise vaieldamatu samm.
- Laske see läbi kontekstifiltri. Kas väljund vastab teie teadaolevale toote käitumisele, arhitektuurile ja tegelikule kasutajavoogusele? Teie domeeniteadmised on lõplik filter.
Andmete privaatsus ja turvalisus: mis kuhu läheb?
Andmed, millega testikeskkonnas töötate, on sageli tundlikud: tõelised kliendikirjed, tootmisandmebaaside koopiad, API võtmed, sisemised süsteemiaadressid, veel teatamata funktsioonid. Tehke lihtne klassifikatsioon: avatud andmed (dokumenteeritud, avalikult kättesaadavad) võivad sisestada iga sõiduki. Siseandmed (lähtekoodi fragmendid, sisemine dokumentatsioon) ainult agentuuri heakskiidetud tööriistadele. Konfidentsiaalsed andmed (reaalsed kliendiandmed, isikuandmed, haavatavuse andmed, võtmed) sisenevad ainult asutuse lepingulistesse tööriistadesse, mille andmed ei lähe mudelikoolitusele, soovitavalt maskeeritult.
Turvatestimise kontekstis on täiendav piirang: kõik selles moodulis õpitu on kaitseotstarbel – oma toote turvalisuse autoriteetseks testimiseks. Tehisintellekti kasutamine kellegi teise süsteemi loata imbumiseks, tõeliste haavatavuste relvastamiseks või süsteemi testimiseks, mille jaoks teil pole volitusi, on nii ebaeetiline kui ka kriminaalne. Ilma loata (ulatus ja loata) ei tehta solvavaid katseid.
Näpunäide: kasutage tegelike kliendiandmete asemel sünteetilisi (kunstlikult toodetud) testandmeid. Kui tehisintellektil palutakse genereerida realistlikke, kuid täiesti väljamõeldud testiandmeid, säilitatakse nii privaatsus kui ka mitmekesistatakse äärmuslikke juhtumeid.
kolm minikarpi
Juhtum 1 – ajasäästja õiges kohas. Ekomerce'i meeskonna testija kulutas 6 tundi käsitsi testistsenaariumi loomisele iga versiooni 30-leheküljelisest nõuete dokumendist. Ta andis dokumendi (osa, mis ei sisaldanud ärisaladusi) YZ-le ja palus struktureeritud stsenaariumi mustandit; Aega vähendati 90 minutini. Ta pühendas säästetud aja selleks, et ise kontrollida, lisades ärireeglite eelisjuhtumid, mida tehisintellekt oli vahele jätnud. AI võttis ära korduva töö, jättes kohtuotsuse inimese hooleks.
Juhtum 2 – võltssöödud tabati. Arendaja lasi AI-l kirjutada arvutusfunktsiooni jaoks 12 ühikutesti; nad olid kõik rohelised. Tester rakendas sammu "vaata punast": funktsiooni sees oleva liitmismärgi tahtlikult muutmine korrutamiseks. Ainult 3 testis 12-st andsid punase tulemuse. Ülejäänud 9 testi ei andnud tõelist kinnitust; Seal oli lihtsalt kirjas "see ei tekitanud viga". 9 dekoratiivset testi kustutati ja selle asemele kirjutati 5 reaalset testi.
Juhtum 3 – naasmine privaatsusrikkumisest. Praktikant kleepis avalikku tööriista tõrkelogi, mis sisaldas tegelikke klientide e-kirju ja kaardi nelja viimast numbrit tootmisandmebaasist ning ütles: "selgitage seda viga". Kvaliteedijuht sekkus: tegemist oli kontrolli alt väljunud isikuandmetega ja KVKK (isikuandmete kaitse seaduse) rikkumine. Sama töö tehti asutuse heakskiidetud sõidukis, maskeerides isiklikud alad ja jättes ainult virna jälje.
Neli kopeeritavat malli
1) Töökoha sobivuse hindamine:
Teie roll: vanem QA juht. Kirjeldan teile testimistööd. Öelge mulle (1) kas see töö on koostamis-/analüüsitöö, mida saab ohutult AI-le delegeerida, või kvaliteediotsus, mille inimene peab tegema, (2) vale väljundi võimalikud kulud, (3) kontrollimine, mida peaksin enne delegeerimist tegema. Töö: [sisesta töökoht siia]
2) Pseudopääsmekontroll:
Vaadake allolevat testi. Öelge mulle: - Millist käitumist see test kinnitab? (üks lause)- Kuidas saan testitava koodi murda nii, et test muutuks PUNAKSEKS?- Kas on mõni nõrkus, mis võib põhjustada selle testi alati läbimise (puudub kinnitus, enesekinnitus, triviaalne kontroll)?Test: [kleebi test siia]
3) Testi andmete maskeerimise juhtimine:
Logi/andmed, mille teile annan, võivad sisaldada isiklikke või konfidentsiaalseid välju (e-post, nimi, kaart, võti, siseaadress). Esiteks loetlege väljad, mida tuleb maskeerida; Ma maskeerin selle ja saadan uuesti. Ärge analüüsige seda nii, nagu see on.
4) Sünteetilise testi andmete genereerimine:
Looge [järgmise väljastruktuuri] jaoks 20 rida täiesti väljamõeldud, realistlikke testiandmeid. Ärge kasutage tegelikke isiku/organisatsiooni andmeid. Kaasake ka ääretähed: tühi ruum, liiga pikk tekst, piirväärtused, kehtetu vorming.
Nõrk viip / Tugev viip
Nõrk: "Kirjutage selle koodi testid."
Tugev: "Arvutage see allahindlusfunktsiooni ühikutestid. Funktsiooni aktsepteerimiskriteeriumid: 10% allahindlus üle 1000 TL, 20% allahindlus üle 5000 TL; negatiivne summa peaks viskama vea. Täpsustage kommentaarireaga, millist reeglit iga testi jaoks valid. Kasutage piirväärtusi eraldi (999, 1000, 0, 10 -10) väited, mis muutuvad punaseks, kui rikun koodi tühjaks või ei kirjuta triviaalset väidet.
Võimas viip; See sisaldab aktsepteerimiskriteeriume, piirväärtusi, kinnituse ootusi ja selgeid võltsimisevastaseid juhiseid. Nõrk viip kutsub AI-d üles kirjutama dekoratiivset testi.
Levinud vead
- Usaldades rohelist. Arvates, et testi läbimine on tõend. Tegelik küsimus on: kas see muutub punaseks, kui rikute koodi?
- Testi taotlemine põhjust avaldamata. Tehisintellekt toodab üldisi, sageli kasutuid teste, teadmata, mida on vaja kontrollida.
- Kinnitamise vahelejätmine. Öeldes "AI kirjutas selle, see on tõenäoliselt tõsi". Vastutus lasub väljundit kasutaval inimesel.
- Tõeliste/tundlike andmete kleepimine tööriista. Töötamine tootmisandmete, võtmete või isikuandmetega.
- Volitamata turvatestid. Solvava testimise katse ilma ulatuse ja loata.
- AI kasutamine otsuste tegemise delegeerimiseks. Esitades küsimuse "Kas seda versiooni saab välja anda?" tehisintellektile ja pannes vastuse allkirja.
Kokkuvõttes
AI on võimas abiline kvaliteedi tagamise protsessis, mis kiirendab korduvat ja tootlikku tööd; Kuid vastutus kvaliteediotsuse eest lasub inimesel. Selle elukutse tehisintellekti risk number üks on pseudo-pass: rohelised testid, mis näevad kenad välja, kuid ei kinnita midagi. Testige iga AI-testi tahtlikult koodi murdes; Kui see ei muutu punaseks, on see test kaunistuseks. Siduge see nõudega, vaadake punast, laske see läbi kontekstifiltri. Maskeerige konfidentsiaalsed andmed, tehke turvateste ainult volitatud ja kaitseotstarbelistel eesmärkidel.
Rakenduse ülesanne
Tehke oma projektist viis tehisintellekti loodud (või tehisintellekti loodud) ühikutesti. Igaühe puhul: (1) kirjutage ühe lausega üles, millist käitumist see kontrollib, (2) murdke ja käivitage testitav kood teadlikult ning märkige, kui paljud punaseks muutuvad, (3) märkige need, mis ei muutu punaseks, "dekoortestideks" ja kirjutage need ümber tegeliku väitega. Pange tulemus tabelisse: testi nimi / reegel, mida see kontrollis / kas see oli katki / tegevus.
kontrollnimekiri
- [ ] Enne töö üleandmist esitasin küsimuse "mis ma kaotan, kui see valesti läheb?"
- [ ] Testisin iga AI-testi koodi murdes; Selle, mis punaseks ei läinud, asendasin päris testiga.
- [ ] Seosin testjuhtumid tegelike nõuete/vastuvõtukriteeriumitega.
- [ ] Maskeerisin tundlikud/reaalsed andmed neid tööriistale andmata; Võimalusel kasutasin sünteetilisi andmeid.
- [ ] Kaalusin turbetestimist ainult volituste piires ja kaitseotstarbel.
- [ ] Otsuse "kas versioon avaldatakse" jätsin endale, mitte AI-le.