Rrjedha e punës nga fundi në fund, integrimi CI/CD, Etika dhe Siguria: Përdorimi i AI me përgjegjësi — Inteligjenca Artificiale në Testimin e Softuerit dhe QA

Fitimet:

Aftësia për të hartuar rolin e inteligjencës artificiale dhe pikave të miratimit njerëzor në rrjedhën e cilësisë së lartë në fund nga ideja në lëshim në kontekstin e CI/CD
Në CI/CD, duke mos autorizuar AI për të 'kaluar' automatikisht testin, por duke aplikuar kufij për të mbrojtur të dhënat dhe çelësat konfidenciale
Aftësia për të kryer testimin e sigurisë brenda autoritetit dhe për qëllime mbrojtëse, dhe për të miratuar parimet e zbulimit të përgjegjshëm dhe transparencës etike.

Në dhjetë njësitë e mëparshme, ne përdorëm AI në detyra individuale: gjenerimi i skenarit, kodi i automatizimit, raportimi i gabimeve, analiza e mbulimit, testimi i mutacioneve. Kjo njësi përfundimtare i kombinon të gjitha në një rrjedhë pune të përgjegjshme. QA moderne nuk është një punë që përfundon në tavolinën e një personi; Është një proces që jeton brenda CI/CD (Integrimi i vazhdueshëm / Dorëzimi i vazhdueshëm - tubacioni ku kodi kombinohet vazhdimisht, testohet automatikisht dhe përgatitet për publikim shpesh dhe në mënyrë të sigurt). AI mund të prekë çdo fazë të këtij procesi. Por ndërsa fuqia e AI rritet, rritet edhe rëndësia e përdorimit të saj me përgjegjësi: privatësia, autoriteti në testimin e sigurisë, etika dhe më e rëndësishmja, mbajtja e vendimit cilësor në dorën e njeriut. Në këtë njësi, ju do të mësoni rrjedhën dhe kufijtë nga skaji në fund.

Rrjedha e QA e fuqizuar nga AI nga skaji në skaj

Roli i AI në udhëtimin e një veçorie nga ideja në lëshim:

1. Analiza e kërkesave. AI tregon paqartësitë në kërkesat dhe kriteret e pranimit që mungojnë ("ky rregull nuk thotë se sa karaktere është minimumi i fjalëkalimit").

2. Projektimi i testit. Skenarët dhe draftet e rasteve (njësia 2), rastet e skajeve (njësia 3) janë ndër kriteret e pranimit.

3. Automatizimi. Draftet e kodit të testimit të njësisë (6), API (5) dhe UI (4); secili konfirmohet me mutacion (10).

4. Integrimi CI/CD. Testet ekzekutohen automatikisht me çdo bashkim të kodit. AI harton konfigurimin e tubacionit (YAML), përmbledh regjistrat e testeve të dështuara, sugjeron shkakun e mundshëm rrënjësor.

5. Vendimi për lirim. Rezultatet e analizës së rrezikut (8) dhe regresionit (9) janë mbledhur - por eksperti vendos nëse mund të jetë i suksesshëm.

6. Monitorimi i prodhimit dhe reagimet. Gabimet në live bëhen teste të ardhshme; AI propozon një rast regresioni nga një defekt në prodhim.

Këshillë: Vendosni AI si një shtresë në CI/CD që "përshpejton draftet e rishikuara nga njeriu" në vend që "shkruan teste dhe merr vendime". Asnjë test i gjeneruar automatikisht nuk duhet të hyjë në tubacion pa rishikimin dhe miratimin e tyre nga një person.

AI në CI/CD: ku po, ku jo

Skena

Përshtatja e AI

njeriu është thelbësor

Drafti i kodit të testimit

Rishikim + mutacion

Drafti i tubacionit YAML

Autentifikimi + kontrollimi i çelësit sekret

Përmbledhja e regjistrit të dështuar

Konfirmimi i shkakut rrënjësor

Diagnoza e testit të brishtë

Vendim për zgjidhje të përhershme

"A mund të ketë një version?"

Gjykimi dhe përgjegjësia e ekspertit

"Kalojeni" testin automatikisht

kurrë

Kujdes: Asnjëherë mos i jepni AI një mandat si "rregullojeni për të kaluar testin e dështuar" në CI/CD. Kjo e mposht qëllimin e testimit dhe automatikisht mbulon gabimet. AI mund të shpjegojë gabimin, të sugjerojë korrigjim; por "të lyesh testin me ngjyrë të gjelbër" duhet të jetë vendim i vetëdijshëm dhe i arsyetuar i një personi.

Privatësia, të dhënat dhe siguria: kufij të pandryshueshëm

Privatësia. Në mjedisin e testimit, të dhënat aktuale të klientit, kopjet e bazës së të dhënave të prodhimit, çelësat API dhe informacioni i brendshëm i sistemit janë të ndjeshme. Mos ua jepni këto mjeteve publike të AI. Të dhënat personale i nënshtrohen KVKK-së dhe rregulloreve të ngjashme; Regjistrat e maskave dhe pamjet e ekranit. Përdorni të dhëna testimi sintetike (fiktive) kudo që të jetë e mundur.

Testimi i sigurisë - mbrojtës dhe i autorizuar. Testet e sigurisë të mësuara në këtë modul (testet e autorizimit/IDOR, kufijtë e ngarkimit të skedarëve, vlefshmëria e hyrjes) janë vetëm për testimin e produktit tuaj brenda autorizimit me shkrim dhe fushës së përcaktuar. Përdorimi i AI për të hyrë në sistemin e dikujt tjetër pa leje, për të armatosur dobësitë reale ose për të kryer testime jashtë fushëveprimit është joetike dhe e paligjshme. Kur gjeni një cenueshmëri sigurie, zbatoni parimin e zbulimit të përgjegjshëm - mbajtja e cenueshmërisë konfidenciale dhe raportimi i tij tek pala përkatëse në mënyrë që të mund të rregullohet.

Etika dhe transparenca. Mos i paraqisni testet e prodhuara nga AI si punë tuajën; Të thuash që po përdor AI brenda ekipit është transparencë. Ju jeni përgjegjës për pasaktësinë e një produkti të prodhuar nga AI - "AI e ka shkruar atë" nuk është një justifikim.

Prompt i dobët / Prompt i fortë

E dobët: "Konfiguro tubacionin e provës për CI."

Strong: "Hartoni një rrymë pune CI për Veprimet e GitHub: ekzekutoni testet e njësisë + API në çdo PR, gjeneroni raportin e mbulimit, ekzekutoni testimin e mutacioneve (Stryker) çdo javë. Mos i futni sekretet në kod; përdorni vetëm referencën e sekreteve. Blloko bashkimin nëse testet janë të kuqe. Ky është një DRAFT; testimi i hapit 'rregullim' ose 'migrimi'."

Prompt i fuqishëm; Ai vendos kufizime në konfidencialitetin, rishikimin njerëzor dhe "asnjë testim të automatizuar".

Katër shabllone të kopjueshëm

1) Plani i testimit nga fundi në fund:

Roli juaj: udhëheqës i lartë i SC. Hartoni një plan testimi nga fundi në fund nga ideja në lëshim për veçorinë e mëposhtme: [veçori + kriteret e pranimit]. Fazat: analiza e kërkesave (pasiguritë), dizajni i testit, shtresat e automatizimit (njësia/API/UI), integrimi CI/CD, kriteret e vendimit të lëshimit, gjurmimi i prodhimit. Specifikoni rolin e AI dhe pikave të miratimit HUMAN në secilën fazë veç e veç.

2) Skica e tubacionit CI/CD:

Drafti CI YAML për [GitHub Actions/GitLab CI/Azure Pipelines]:- Njësia + testi API + shtrirja në PR- Parandalimi i bashkimit në testin e kuq- Vlerat sekrete vetëm me sekrete; futja në kod Ky është një draft; Unë do të shqyrtoj hapat kryesorë të menaxhimit dhe miratimit. Shtimi i një hapi të provës së korrigjimit/kalimit automatik.

3) Analiza e regjistrit të testit të dështuar:

Në atë printim CI, testet janë të kuqe. Ekzaminoni regjistrin; gruponi dështimet, dalloni shkakun e mundshëm rrënjësor dhe CILI mund të jetë dështimi i vërtetë dhe cili mund të jetë një problem i brishtë testi/mjedisi. Nëse ka të dhëna personale, maskoni ato. Vendimi dhe korrigjimi do të jenë të miat. Regjistri: [ngjit]

4) Kontrolli paraprak i sigurisë/privatësisë:

Përpara se këto të dhëna/regjistri testimi të dërgohen te mjeti AI, kontrolloni: a përmban ai të dhëna personale, çelësin API, adresën e brendshme të sistemit, të dhënat e prodhimit? Listoni cilat zona, nëse ka, duhet të maskohen/hiqen. Duke u përpunuar ashtu siç është. Përmbajtja: [ngjit]

tre mini kuti

Rasti 1 - Shpejtësia e rrjedhës nga fundi në fund. Një ekip trajtoi një veçori të re të "rinovimit të abonimit" me një rrjedhë nga fundi në fund të fuqizuar nga AI: pasiguritë e kërkesave të shënuara përpara, teste me tre shtresa të hartuara dhe të vërtetuara me mutacione, të lidhura me CI. Funksioni reduktoi ciklin e testimit, i cili zgjati 5 ditë në procesin tradicional, në 2 ditë; por miratimi njerëzor u ruajt në çdo fazë dhe një pasiguri e kërkesave (çfarë ndodh nëse rifreskimi dështon) u mbyll para transmetimit.

Rasti 2 - Kthimi nga rrjedhja e çelësit. Një zhvillues kishte krijuar AI-n CI YAML, dhe AI-ja nguliti një çelës API me pamje reale në YAML si shembull. Hapi i "kontrollit paraprak të sigurisë/privatësisë" e kapi këtë; çelësi i konvertuar në referencë sekrete. Pa hapin e auditimit, çelësi do të rrjedhë në kontrollin e versionit (historia e git).

Rasti 3 - Kufiri i autoritetit. Një anëtar i ekipit donte të aplikonte testin IDOR që mësoi në sistemin e drejtpërdrejtë të një partneri biznesi nga "Isha kurioz". Udhëheqësi i QA ndaloi: është e paligjshme kryerja e testimit të sigurisë në një sistem tjetër pa autorizim me shkrim dhe qëllim të përcaktuar. Testimi është bërë vetëm në mjedisin e testimit të produkteve të tyre, me autoritet; Ekipi përkatës është njoftuar nga pala përgjegjëse e hapur.

Gabimet e zakonshme

Marrja e AI të marrë vendime për lirimin. Duke bërë pyetjen "A mund të lirohet?" tek UA dhe vendosja e përgjigjes në vend të nënshkrimit.
"Kalimi" i testit të automatizuar. Në CI, duke pasur AI të ngjyrosur testin me ngjyrë të gjelbër; duke mbuluar gabimet.
Dhënia e të dhënave/çelësave konfidenciale për automjetin. Ndarja e të dhënave të prodhimit, të dhënave personale ose çelësave API pa mbikëqyrje.
Testim i paautorizuar i sigurisë. Testimi i sulmuesit në një sistem tjetër pa qëllim dhe leje.
Futja e testeve në tubacion pa rishikim. Drejtoni automatikisht skicën e AI pa miratimin e njeriut.
Duke i vënë fajin AI. Mbrojtja e prodhimit të pasaktë duke thënë "AI e shkroi atë".

Në përmbledhje

QA nga fundi në fund është një proces që shtrihet nga kërkesat deri te gjurmimi i prodhimit dhe jeton brenda CI/CD; Në çdo fazë, AI prodhon drafte, përmbledh regjistrin dhe sugjeron shkaqet kryesore. Por kufijtë janë të pandryshueshëm: njerëzit marrin vendime testimi dhe lëshojnë miratimin; UA nuk i jepet kurrë autoriteti për të "kaluar" automatikisht testin; të dhënat konfidenciale dhe çelësat nuk hyjnë në automjet; Testimi i sigurisë kryhet vetëm në produktin tuaj, brenda autorizimit me shkrim dhe qëllimit të përcaktuar, për qëllime mbrojtëse, dhe gjetjet raportohen me zbulim të përgjegjshëm. Jini transparent kur përdorni AI; Ju jeni përgjegjës për saktësinë e prodhimit. AI përshpejtohet; Ju garantoni për cilësinë dhe etikën.

Detyra e aplikimit

Hartoni një plan nga ideja në lëshim me një model "plani testimi nga fundi në fund" për një veçori nga projekti juaj; Shënoni veçmas rolin e AI dhe pikat e miratimit njerëzor në secilën fazë. Më pas krijoni një YAML me "skicën e tubacionit CI/CD" dhe aplikoni "kontroll paraprak të sigurisë/privatësisë" në këtë YAML për të kontrolluar për çelësat/të dhënat sekrete të ngulitura. Së fundi, renditni të gjitha pikat e "vendimit njerëzor" në planin tuaj dhe arsyetoni me një fjali pse këto vendime nuk mund t'i delegohen IA.

listë kontrolli

[ ] Unë ia atribuoj vendimet e lirimit dhe testimit miratimit njerëzor; Unë nuk ia dorëzova AI.
[ ] Në CI/CD nuk i dhashë leje AI-së për të "kaluar/korrigjuar" automatikisht testin.
[ ] Kontrollova dhe maskova të dhënat konfidenciale, të dhënat personale dhe çelësat përpara se t'i dërgoja në automjet.
[ ] Kam konsideruar vetëm testimin e sigurisë në produktin tim, brenda autorizimit dhe fushëveprimit me shkrim.
[ ] Unë i trajtova dobësitë e gjetura me parimin e zbulimit të përgjegjshëm.
[ ] Unë deklarova në mënyrë transparente se përdora AI dhe e mbajta veten përgjegjës për saktësinë e prodhimit.

Provimi i Modulit

1. Si përcaktohet më saktë 'kalimi i rremë' në kontekstin e SC?

A) Edhe pse testi bëhet i gjelbër, ai në fakt nuk konfirmon ndonjë sjellje; ✔ Nuk bëhet i kuq edhe nëse kodi është i dëmtuar
B) Testi shkon shumë ngadalë dhe mbaron.
C) Testi zbulon një gabim të vërtetë dhe bëhet i kuq
D) Testi kryhet vetëm në mjedisin e prodhimit

Shpjegim: Një pseudo-kalim është kur një test thotë 'kaloni' por në fakt nuk konfirmon asgjë kuptimplotë; Testi është i gjelbër, por edhe nëse softueri është i gabuar, ai nuk do ta kap atë. Ky është rreziku numër një i AI në QA sepse AI tenton të prodhojë teste që duken të rregullta, por janë të zbrazëta.

2. Cili është pozicionimi më i saktë i inteligjencës artificiale në procesin e testimit dhe QA?

A) Inteligjenca artificiale mund të vendosë nëse versioni mund të lëshohet pa miratimin e njeriut
B) Inteligjenca artificiale është një asistent që gjeneron drafte dhe ide; Vendimi dhe përgjegjësia e 'a është gati për botim' i takon ekspertit ✔
C) Inteligjenca artificiale shkruan vetëm tekst dhe nuk mund të merret fare me kodin e testit
D) Inteligjenca artificiale gjithmonë shkruan testin e saktë se sa njeriu, kështu që rishikimi është i panevojshëm

Përshkrimi: Inteligjenca artificiale është një asistent testimi, gjenerues drafti dhe shumëzues idesh; prodhon skenarë testimi, kode automatizimi dhe drafte raportesh. Megjithatë, përgjegjësia dhe miratimi përfundimtar i vendimeve cilësore si 'a është ky softuer gati për publikim' ose 'a ka kaluar testi' i takon ekspertit kompetent.

3. Bazuar në faktin se gabimet ndodhin më së shumti në vlerat e pragut, cila teknikë e projektimit të testit duhet të testojë 17, 18 dhe 19 veçmas për kufirin e moshës 18 vjeç?

A) Testi i tranzicionit shtetëror
B) Tabela e vendimeve
C) Analiza e vlerës kufitare ✔
D) Testimi eksplorues

Shpjegim: Analiza e vlerës kufitare bazohet në vëzhgimin se gabimet ndodhin më shpesh në kufij dhe teston vlerat e pragut (pak më poshtë, pak sipër dhe pak mbi kufirin) veçmas. Është një teknikë e fuqishme që plotëson klasat e ekuivalencës.

4. Cila qasje duhet të preferohet në përzgjedhjen e elementeve për të reduktuar brishtësinë në kodin e automatizimit të testit UI të prodhuar me inteligjencë artificiale?

A) Përdorimi i shtegut më të gjatë XPath të mundshëm
B) Zgjedhja e elementit sipas pozicionit të pikselit në ekran
C) Përdorimi i përzgjedhësve bazuar në emrat e klasave CSS
D) Përdorimi i atributeve të qëndrueshme (data-testid) të shtuara për testim ✔

Shpjegim: Shtigjet e gjata të XPath dhe emrat e klasave CSS varen jashtëzakonisht nga struktura dhe dizajni i faqes; Ai prishet me ndryshimin më të vogël të ndërfaqes. Atributet e qëndrueshme të shtuara posaçërisht për testim (p.sh. testimi i të dhënave) nuk ndikohen nga ndryshimet e dizajnit dhe i bëjnë testet të qëndrueshme.

5. Pse është e pamjaftueshme që një test API të kontrollojë vetëm kodin e statusit HTTP (p.sh. 200)?

A) Për shkak se të dhënat e trupit me kodin e saktë të statusit mund të korruptohen dhe vetëm kontrolli i statusit nuk do ta kuptojë këtë (pseudo-besim) ✔
B) Sepse kodet e statusit nuk janë aspak të besueshëm në testet API
C) Sepse kontrolli i kodit të statusit e ngadalëson shumë testin
D) Sepse kodi i statusit nuk kthehet kurrë në testet API

Shpjegim: Ndërsa serveri kthen kodin e saktë të statusit, ai mund të kthejë të dhëna të dëmtuara në trup (lloji i gabuar, fusha që mungon, vlera e llogaritur gabimisht). Testi që shikon vetëm situatën nuk mund ta shohë këtë dhe jep besim të rremë. Pra, duhet të shtohet edhe vërtetimi i skemës/kontratës dhe rregullave të biznesit.

6. Pse është kritike t'i thuash AI që 'të llogarisë manualisht vlerën e pritur sipas rregullit të pranimit, të mos referojë daljen aktuale të funksionit' kur printon testet e njësisë?

A) Sepse llogaritja manuale i kryen testet më shpejt
B) Sepse përndryshe testi pranon sjelljen aktuale (ndoshta me gabime) të kodit si 'të saktë' dhe konfirmon defektin ✔
C) Sepse inteligjenca artificiale nuk mund të llogarisë fare numra dhjetorë
D) Sepse rregullat e pranimit nuk përdoren kurrë në teste

Shpjegim: Nëse AI nxjerr vlerën e pritur nga dalja e funksionit nën testim, do ta bëjë testin 'të kalojë' edhe nëse funksioni është i gabuar; Kjo do të thotë, çfarëdo që prodhon kodi, testi llogaritet si i vërtetë. Llogaritja e vlerës së pritur në mënyrë të pavarur nga rregulli i pranimit siguron që testi të jetë një derëtar i rregullit, jo një pasqyrë e kodit.

7. Cila nga sa vijon është tipari më dallues i një raporti të mirë të defekteve?

A) Të jetë sa më i gjatë dhe teknik
B) Shkruar nga inteligjenca artificiale
C) Përmban hapa riprodhues përcaktues që zhvilluesi mund të ndjekë në mënyrë të pavarur dhe të prodhojë gabimin ✔
D) Është vetëm një pamje nga ekrani

Shpjegim: Vlera e vërtetë e një raporti të defektit është se zhvilluesi mund ta riprodhojë defektin pa ndihmën tuaj. Hapat përcaktues dhe të gjurmueshëm të riprodhimit nga e para e sigurojnë këtë; Nëse këto hapa mungojnë, raporti shpesh mbyllet si 'nuk mund të prodhohej'.

8. Cila është shprehja më e saktë për marrëdhënien midis ashpërsisë dhe përparësisë në gabimin e drejtshkrimit të gabuar të emrit të kompanisë në faqen kryesore?

A) Intensiteti dhe përparësia duhet të kenë gjithmonë të njëjtën vlerë
B) Si ashpërsia dhe përparësia e këtij gabimi janë padyshim të ulëta
C) Ashpërsia dhe përparësia janë i njëjti koncept, mjafton një etiketë
D) Intensiteti teknik mund të jetë i ulët, por prioriteti i biznesit (reputacioni) mund të jetë i lartë; Të dyja vlerësohen ndryshe ✔

Shpjegim: Ashpërsia është ndikimi teknik i gabimit (gabimi teknikisht i ulët), prioriteti është sa urgjentisht duhet rregulluar (i lartë sepse është një element reputacioni që e sheh çdo vizitor). Të dy nuk shkojnë gjithmonë në të njëjtin drejtim; Ky shembull është një situatë me ashpërsi të ulët-prioritet të lartë.

9. Cili është interpretimi më i saktë i një grupi testimi me mbulim 90% të linjës?

A) Tregon se linjat janë ekzekutuar, por nuk provon se ato sillen në mënyrë korrekte; ✔ Mbulimi i lartë mund të japë besim të rremë
B) Dëshmon përfundimisht se 90% e softuerit është pa gabime
C) Është një masë përfundimtare e cilësisë së shkëlqyer të testit.
D) Tregon se nuk ka më nevojë për të shkruar ndonjë test shtesë

Shpjegim: Mbulimi i rreshtave tregon se vetëm rreshtat janë ekzekutuar; Nuk provon se jep rezultate të sakta. Edhe me teste pa konfirmim, mbulimi 90% mund të arrihet. Fushëveprimi është një hartë "kurrë nuk u pa ku", jo një garanci "gjithçka është testuar"; mbrojtja aktuale matet me testimin e mutacioneve.

10. Në testimin e bazuar në rrezik, si llogaritet rreziku i një veçorie për të drejtuar përpjekjet e kufizuara të testimit?

A) Vetëm sipas numrit të rreshtave të kodit
B) Duke shumëzuar probabilitetin e dështimit dhe efektin që do të ndodhë kur prishet ✔
C) Vetëm sipas radhës në të cilën është zhvilluar veçoria
D) Duke i dhënë përparësi vetëm veçorisë për të cilën është më e lehtë të shkruash teste

Shpjegim: Në testimin e bazuar në rrezik, rreziku vlerësohet si probabilitet = probabilitet (mundësi prishjeje) × ndikim (dëm nëse prishet). Domenet me probabilitet të lartë dhe ndikim të lartë (pagesa, vërtetimi) meritojnë testimin më intensiv, ndërsa domenet e ulët x të ulët marrin testim të lehtë.

11. Cili është rreziku kryesor i shtimit të një riprovimi në një test që ndonjëherë kalon dhe nganjëherë dështon (i brishtë/i krisur) edhe pse kodi nuk ka ndryshuar?

A) Shkurtimi i kohës së kryerjes së testit
B) Ul përqindjen e mbulimit
C) Mbulimi i një gabimi të vërtetë të konkurencës ose shkaku rrënjësor dhe shtypja e simptomave ✔
D) Ndryshimi i emrit të testit

Shpjegim: Riprovimi është një mjet diagnostikues, jo një trajtim. Pavendosmëria shpesh vjen nga një gjendje aktuale e racës ose varësia; Bërja e "kalimit" të testit duke riprovuar mbulon këtë gabim të vërtetë dhe mund të shkaktojë probleme serioze në transmetim. Së pari duhet gjetur shkaku kryesor.

12. Si funksionon testimi i mutacioneve, metoda më e ndershme për të matur nëse një grup testesh mbron në të vërtetë?

A) Duke matur shpejtësinë e drejtimit të testeve
B) Duke numëruar sa rreshta kodi janë shkruar
C) Duke i drejtuar testet me radhe të ndryshme
D) Duke krijuar qëllimisht thyerje të vogla në kod dhe duke matur nëse testet i kapin ato ✔

Përshkrimi: Testimi i mutacioneve prodhon shtrembërime të vogla të qëllimshme (mutacione) në kodin burimor; Një grup i mirë testimi duhet të kapë këto shtrembërime dhe të kthehet në të kuqe. Mutacionet që nuk janë kapur (mbijetuar) tregojnë se testet nuk e ruajnë atë sjellje. Rezultati i mutacionit është një masë shumë më e sinqertë e cilësisë sesa mbulimi i përqindjes.

13. Cili është kufiri kryesor që duhet ndjekur gjatë kryerjes së testeve të sigurisë (p.sh. testet e autorizimit/IDOR)?

A) Duhet të bëhet vetëm në produktin e vet, brenda autorizimit me shkrim dhe qëllimit të përcaktuar, për qëllime mbrojtëse ✔
B) Mund të zbatohet lirisht në çdo sistem interesi
C) Mund të provohet në sisteme të drejtpërdrejta të partnerëve të biznesit pa leje
D) Çdo dobësi e gjetur duhet të publikohet menjëherë publikisht.

Përshkrimi: Testet e sigurisë të mësuara në këtë modul janë vetëm për testimin e produktit tuaj për qëllime mbrojtëse, brenda autorizimit me shkrim dhe qëllimit të përcaktuar. Hyrja në sistemin e dikujt tjetër pa leje ose kryerja e testimit jashtë fushëveprimit është joetike dhe e paligjshme; Çdo dobësi e gjetur raportohet përmes zbulimit të përgjegjshëm.

14. Çfarë autoriteti nuk duhet t'i jepet kurrë AI në tubacionin CI/CD?

A) Përmbledhja e regjistrave të testeve të dështuara
B) Autoriteti për të 'kaluar' automatikisht një test të dështuar (të kuq) ose për ta ngjyrosur atë me ngjyrë të gjelbër ✔
C) Sugjerimi i një draft kodi testimi
D) Pipeline hartimi i skedarit YAML

Përshkrimi: AI mund të prodhojë skicën e kodit të testimit, YAML të tubacionit dhe përmbledhjen e regjistrave në CI/CD; megjithatë, aftësia për të 'kaluar/rregulluar' automatikisht një test të dështuar nuk duhet të jepet kurrë. Kjo e mposht qëllimin e testimit dhe automatikisht mbulon gabimet. Ngjyrosja e provës me ngjyrë të gjelbër duhet të jetë vendim i vetëdijshëm dhe i arsyetuar i një personi.