നേട്ടങ്ങൾ:
- CI/CD യുടെ പശ്ചാത്തലത്തിൽ ആശയത്തിൽ നിന്ന് റിലീസിലേക്കുള്ള എൻഡ്-ടു-എൻഡ് QA ഫ്ലോയിൽ ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിൻ്റെയും മനുഷ്യ അംഗീകാര പോയിൻ്റുകളുടെയും പങ്ക് രൂപകൽപ്പന ചെയ്യാനുള്ള കഴിവ്
- CI/CD-യിൽ, ടെസ്റ്റ് സ്വയമേവ 'പാസാക്കാൻ' AI-യെ അധികാരപ്പെടുത്തുന്നില്ല, എന്നാൽ രഹസ്യാത്മക ഡാറ്റയും കീകളും പരിരക്ഷിക്കുന്നതിന് പരിധികൾ പ്രയോഗിക്കുന്നു.
- അധികാരത്തിനകത്തും പ്രതിരോധ ആവശ്യങ്ങൾക്കുമായി സുരക്ഷാ പരിശോധന നടത്താനുള്ള കഴിവ്, ഉത്തരവാദിത്ത വെളിപ്പെടുത്തലും നൈതിക സുതാര്യത തത്വങ്ങളും സ്വീകരിക്കുക.
മുമ്പത്തെ പത്ത് യൂണിറ്റുകളിൽ, ഞങ്ങൾ വ്യക്തിഗത ടാസ്ക്കുകളിൽ AI ഉപയോഗിച്ചു: സാഹചര്യം സൃഷ്ടിക്കൽ, ഓട്ടോമേഷൻ കോഡ്, ബഗ് റിപ്പോർട്ടിംഗ്, കവറേജ് വിശകലനം, മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ്. ഈ അന്തിമ യൂണിറ്റ് അവയെല്ലാം ഒരു ഉത്തരവാദിത്ത വർക്ക്ഫ്ലോയിലേക്ക് സംയോജിപ്പിക്കുന്നു. ആധുനിക QA എന്നത് ഒരാളുടെ മേശപ്പുറത്ത് അവസാനിക്കുന്ന ജോലിയല്ല; ഇത് CI/CD (തുടർച്ചയായ സംയോജനം / തുടർച്ചയായ ഡെലിവറി - കോഡ് നിരന്തരം സംയോജിപ്പിച്ച്, സ്വയമേവ പരീക്ഷിക്കുകയും ഇടയ്ക്കിടെ സുരക്ഷിതമായി പ്രസിദ്ധീകരിക്കാൻ തയ്യാറാക്കുകയും ചെയ്യുന്ന പൈപ്പ്ലൈൻ) ഒരു പ്രക്രിയയാണ്. ഈ പ്രക്രിയയുടെ എല്ലാ ഘട്ടങ്ങളും സ്പർശിക്കാൻ AI-ന് കഴിയും. എന്നാൽ AI-യുടെ ശക്തി വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അത് ഉത്തരവാദിത്തത്തോടെ ഉപയോഗിക്കേണ്ടതിൻ്റെ പ്രാധാന്യവും വർദ്ധിക്കുന്നു: സ്വകാര്യത, സുരക്ഷാ പരിശോധനയിലെ അധികാരം, ധാർമ്മികത, ഏറ്റവും പ്രധാനമായി, ഗുണമേന്മയുള്ള തീരുമാനം മനുഷ്യനുവേണ്ടി നിലനിർത്തുക. ഈ യൂണിറ്റിൽ, നിങ്ങൾ അവസാനം മുതൽ അവസാനം വരെ ഒഴുക്കും അതിരുകളും പഠിക്കും.
എൻഡ്-ടു-എൻഡ് AI- പവർഡ് QA ഫ്ലോ
ആശയത്തിൽ നിന്ന് റിലീസിലേക്കുള്ള ഒരു ഫീച്ചറിൻ്റെ യാത്രയിൽ AI യുടെ പങ്ക്:
1. ആവശ്യകതകൾ വിശകലനം. ആവശ്യകതയിലും നഷ്ടമായ സ്വീകാര്യത മാനദണ്ഡങ്ങളിലുമുള്ള അവ്യക്തതകൾ AI ഫ്ലാഗ് ചെയ്യുന്നു ("ഈ നിയമം പാസ്വേഡ് മിനിമം എത്ര പ്രതീകങ്ങളാണെന്ന് പറയുന്നില്ല").
2. ടെസ്റ്റ് ഡിസൈൻ. സാഹചര്യവും കേസ് ഡ്രാഫ്റ്റുകളും (യൂണിറ്റ് 2), എഡ്ജ് കേസുകൾ (യൂണിറ്റ് 3) സ്വീകാര്യത മാനദണ്ഡങ്ങളിൽ ഉൾപ്പെടുന്നു.
3. ഓട്ടോമേഷൻ. യൂണിറ്റ് (6), API (5), UI (4) ടെസ്റ്റ് കോഡ് ഡ്രാഫ്റ്റുകൾ; ഓരോന്നും മ്യൂട്ടേഷൻ വഴി സ്ഥിരീകരിക്കുന്നു (10).
4. CI/CD സംയോജനം. ഓരോ കോഡ് ലയനത്തിലും ടെസ്റ്റുകൾ സ്വയമേവ പ്രവർത്തിക്കുന്നു. AI ഡ്രാഫ്റ്റ് പൈപ്പ്ലൈൻ കോൺഫിഗറേഷൻ (YAML), പരാജയപ്പെട്ട ടെസ്റ്റുകളുടെ ലോഗുകൾ സംഗ്രഹിക്കുന്നു, സാധ്യമായ മൂലകാരണം നിർദ്ദേശിക്കുന്നു.
5. റിലീസ് തീരുമാനം. റിസ്ക് വിശകലനം (8), റിഗ്രഷൻ (9) ഫലങ്ങൾ ശേഖരിക്കുന്നു - എന്നാൽ ഇത് വിജയകരമാണോ എന്ന് വിദഗ്ധൻ തീരുമാനിക്കുന്നു.
6. ഉൽപ്പാദന നിരീക്ഷണവും ഫീഡ്ബാക്കും. തത്സമയ പിശകുകൾ ഭാവി പരീക്ഷണങ്ങളായി മാറുന്നു; നിർമ്മാണ വൈകല്യത്തിൽ നിന്ന് ഒരു റിഗ്രഷൻ കേസ് AI നിർദ്ദേശിക്കുന്നു.
നുറുങ്ങ്: "ടെസ്റ്റുകൾ എഴുതുകയും തീരുമാനങ്ങൾ എടുക്കുകയും" ചെയ്യുന്നതിനുപകരം, "മനുഷ്യ-അവലോകനം ചെയ്ത ഡ്രാഫ്റ്റുകൾ ത്വരിതപ്പെടുത്തുന്ന" ഒരു ലെയറായി CI/CD-യിൽ AI സജ്ജീകരിക്കുക. സ്വയമേവ സൃഷ്ടിക്കപ്പെട്ട പരിശോധനകളൊന്നും മനുഷ്യൻ അവലോകനം ചെയ്യാതെയും അംഗീകരിക്കാതെയും പൈപ്പ്ലൈനിൽ പ്രവേശിക്കരുത്.
CI/CD-യിലെ AI: എവിടെ അതെ, എവിടെ ഇല്ല
സ്റ്റേജ്
AI ഫിറ്റ്
മനുഷ്യൻ അത്യാവശ്യമാണ്
ടെസ്റ്റ് കോഡ് ഡ്രാഫ്റ്റ്
അതെ
പുനരവലോകനം + മ്യൂട്ടേഷൻ
പൈപ്പ്ലൈൻ YAML ഡ്രാഫ്റ്റ്
അതെ
പ്രാമാണീകരണം + രഹസ്യ കീ പരിശോധന
ലോഗ് സംഗ്രഹം പരാജയപ്പെട്ടു
അതെ
മൂലകാരണ സ്ഥിരീകരണം
ദുർബലമായ പരിശോധനാ രോഗനിർണയം
അതെ
ശാശ്വത പരിഹാര തീരുമാനം
"ഒരു പതിപ്പ് ഉണ്ടാകുമോ?"
ഇല്ല
വിദഗ്ദ്ധ വിധിയും ഉത്തരവാദിത്തവും
ടെസ്റ്റ് സ്വയമേവ "പാസാക്കുക"
ഒരിക്കലും
—
മുൻകരുതൽ: CI/CD-യിൽ "പരാജയപ്പെടുന്ന പരീക്ഷയിൽ വിജയിക്കാൻ ഇത് ശരിയാക്കുക" പോലെയുള്ള ഒരു മാൻഡേറ്റ് AI-ക്ക് ഒരിക്കലും നൽകരുത്. ഇത് പരിശോധനയുടെ ഉദ്ദേശ്യത്തെ പരാജയപ്പെടുത്തുകയും പിശകുകൾ യാന്ത്രികമായി മറയ്ക്കുകയും ചെയ്യുന്നു. AI-ന് പിശക് വിശദീകരിക്കാനും തിരുത്തൽ നിർദ്ദേശിക്കാനും കഴിയും; എന്നാൽ "പരീക്ഷണത്തിന് പച്ച പെയിൻ്റിംഗ്" എന്നത് ഒരു വ്യക്തിയുടെ ബോധപൂർവവും യുക്തിസഹവുമായ തീരുമാനമായിരിക്കണം.
സ്വകാര്യത, ഡാറ്റ, സുരക്ഷ: മാറ്റമില്ലാത്ത അതിരുകൾ
സ്വകാര്യത. ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ, യഥാർത്ഥ ഉപഭോക്തൃ ഡാറ്റ, പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് പകർപ്പുകൾ, API കീകൾ, ആന്തരിക സിസ്റ്റം വിവരങ്ങൾ എന്നിവ സെൻസിറ്റീവ് ആണ്. പൊതു AI ഉപകരണങ്ങൾക്ക് ഇവ നൽകരുത്. വ്യക്തിഗത ഡാറ്റ കെവികെകെയ്ക്കും സമാനമായ നിയന്ത്രണങ്ങൾക്കും വിധേയമാണ്; മാസ്ക് ലോഗുകളും സ്ക്രീൻഷോട്ടുകളും. സാധ്യമാകുന്നിടത്തെല്ലാം സിന്തറ്റിക് (സാങ്കൽപ്പിക) ടെസ്റ്റ് ഡാറ്റ ഉപയോഗിക്കുക.
സുരക്ഷാ പരിശോധന - പ്രതിരോധവും അംഗീകൃതവും. ഈ മൊഡ്യൂളിൽ പഠിക്കുന്ന സുരക്ഷാ പരിശോധനകൾ (അംഗീകാരം/IDOR ടെസ്റ്റുകൾ, ഫയൽ അപ്ലോഡ് പരിധികൾ, ഇൻപുട്ട് മൂല്യനിർണ്ണയം) രേഖാമൂലമുള്ള അംഗീകാരത്തിനും നിർവചിക്കപ്പെട്ട സ്കോപ്പിനും ഉള്ളിൽ നിങ്ങളുടെ സ്വന്തം ഉൽപ്പന്നം പരിശോധിക്കുന്നതിന് മാത്രമാണ്. അനുമതിയില്ലാതെ മറ്റൊരാളുടെ സിസ്റ്റം ആക്സസ് ചെയ്യുന്നതിനോ യഥാർത്ഥ കേടുപാടുകൾ ആയുധമാക്കുന്നതിനോ അല്ലെങ്കിൽ പരിധിക്ക് പുറത്തുള്ള പരിശോധന നടത്തുന്നതിനോ AI ഉപയോഗിക്കുന്നത് അനീതിപരവും നിയമവിരുദ്ധവുമാണ്. നിങ്ങൾ ഒരു സുരക്ഷാ അപകടസാധ്യത കണ്ടെത്തുമ്പോൾ, ഉത്തരവാദിത്ത വെളിപ്പെടുത്തൽ തത്വം പാലിക്കുക - അപകടസാധ്യത രഹസ്യമായി സൂക്ഷിക്കുകയും ബന്ധപ്പെട്ട കക്ഷിക്ക് അത് റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യുക, അതുവഴി അത് പരിഹരിക്കാനാകും.
നൈതികതയും സുതാര്യതയും. AI നിർമ്മിച്ച ടെസ്റ്റുകൾ നിങ്ങളുടെ സ്വന്തം സൃഷ്ടിയായി അവതരിപ്പിക്കരുത്; നിങ്ങൾ ടീമിനുള്ളിൽ AI ഉപയോഗിക്കുന്നുണ്ടെന്ന് പ്രസ്താവിക്കുന്നത് സുതാര്യതയാണ്. AI-ഉൽപാദിപ്പിക്കുന്ന ഔട്ട്പുട്ടിൻ്റെ കൃത്യതയില്ലായ്മയ്ക്ക് നിങ്ങൾ ഉത്തരവാദിയാണ് - "AI അത് എഴുതി" എന്നത് ഒരു ഒഴികഴിവല്ല.
ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്
ദുർബലമായത്: "CI-ക്കായി ടെസ്റ്റ് പൈപ്പ്ലൈൻ സജ്ജമാക്കുക."
ശക്തമായത്: "GitHub പ്രവർത്തനങ്ങൾക്കായി ഒരു CI വർക്ക്ഫ്ലോ YAML ഡ്രാഫ്റ്റ് ചെയ്യുക: ഓരോ PR-ലും യൂണിറ്റ് + API ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക, കവറേജ് റിപ്പോർട്ട് സൃഷ്ടിക്കുക, മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ് (സ്ട്രൈക്കർ) പ്രതിവാരം നടത്തുക. രഹസ്യങ്ങൾ കോഡിൽ ഉൾപ്പെടുത്തരുത്; രഹസ്യ റഫറൻസ് മാത്രം ഉപയോഗിക്കുക. ടെസ്റ്റുകൾ ചുവപ്പ് ആണെങ്കിൽ ലയിക്കുന്നത് തടയുക. ഇത് ഒരു DRAFT ആണ്, ഒരു DRAFT, എഡിറ്റ് ചെയ്യാനുള്ള രഹസ്യം അവലോകനം ചെയ്യുകയും എഡിറ്റ് ചെയ്യുക. 'പരിഹരിക്കുക' അല്ലെങ്കിൽ 'മൈഗ്രേറ്റ്' ഘട്ടം പരിശോധിക്കുന്നു."
ശക്തമായ പ്രോംപ്റ്റ്; ഇത് രഹസ്യാത്മകത, മനുഷ്യ അവലോകനം, "ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് ഇല്ല" എന്നിവയിൽ പരിധികൾ ചുമത്തുന്നു.
പകർത്താവുന്ന നാല് ടെംപ്ലേറ്റുകൾ
1) എൻഡ്-ടു-എൻഡ് ടെസ്റ്റിംഗ് പ്ലാൻ:
നിങ്ങളുടെ റോൾ: മുതിർന്ന QA നേതാവ്. ഇനിപ്പറയുന്ന ഫീച്ചർ റിലീസ് ചെയ്യുന്നതിനായി ആശയത്തിൽ നിന്ന് ഒരു എൻഡ്-ടു-എൻഡ് ടെസ്റ്റിംഗ് പ്ലാൻ തയ്യാറാക്കുക: [ഫീച്ചർ + സ്വീകാര്യത മാനദണ്ഡം]. ഘട്ടങ്ങൾ: ആവശ്യകതകൾ വിശകലനം (അനിശ്ചിതത്വങ്ങൾ), ടെസ്റ്റ് ഡിസൈൻ, ഓട്ടോമേഷൻ ലെയറുകൾ (യൂണിറ്റ്/എപിഐ/യുഐ), സിഐ/സിഡി ഇൻ്റഗ്രേഷൻ, റിലീസ് തീരുമാന മാനദണ്ഡം, പ്രൊഡക്ഷൻ ട്രാക്കിംഗ്. ഓരോ ഘട്ടത്തിലും AI, ഹ്യൂമൻ അപ്രൂവൽ പോയിൻ്റുകൾ എന്നിവയുടെ പങ്ക് പ്രത്യേകം വ്യക്തമാക്കുക.
2) CI/CD പൈപ്പ്ലൈൻ രൂപരേഖ:
[GitHub Actions/GitLab CI/Azure Pipelines] എന്നതിനായുള്ള CI YAML ഡ്രാഫ്റ്റ്:- യൂണിറ്റ് + API ടെസ്റ്റ് + PR-ലെ സ്കോപ്പ്- റെഡ് ടെസ്റ്റിൽ ലയിക്കുന്നത് തടയുക- രഹസ്യ മൂല്യങ്ങൾ മാത്രം; കോഡിൽ ഉൾച്ചേർക്കൽ ഇതൊരു ഡ്രാഫ്റ്റാണ്; പ്രധാന മാനേജ്മെൻ്റും അംഗീകാര നടപടികളും ഞാൻ അവലോകനം ചെയ്യും. ഒരു ഓട്ടോകറക്റ്റ്/പാസ് ടെസ്റ്റ് സ്റ്റെപ്പ് ചേർക്കുന്നു.
3) പരാജയപ്പെട്ട ടെസ്റ്റ് ലോഗ് വിശകലനം:
ആ CI പ്രിൻ്റൗട്ടിൽ, ടെസ്റ്റുകൾ ചുവപ്പാണ്. ലോഗ് പരിശോധിക്കുക; പരാജയങ്ങൾ ഗ്രൂപ്പുചെയ്യുക, സാധ്യമായ മൂലകാരണം വേർതിരിച്ചറിയുക, ഏതാണ് യഥാർത്ഥ പരാജയം, അത് ദുർബലമായ പരീക്ഷണം/പരിസ്ഥിതി പ്രശ്നമാകാം. വ്യക്തിഗത ഡാറ്റ ഉണ്ടെങ്കിൽ, അത് മറയ്ക്കുക. തീരുമാനവും തിരുത്തലും എൻ്റേതായിരിക്കും. ലോഗ്: [ഒട്ടിക്കുക]
4) സുരക്ഷ/സ്വകാര്യത മുൻകൂട്ടി പരിശോധിക്കുക:
ഈ ടെസ്റ്റ് ഡാറ്റ/ലോഗ് AI ടൂളിലേക്ക് അയയ്ക്കുന്നതിന് മുമ്പ്, പരിശോധിക്കുക: അതിൽ വ്യക്തിഗത ഡാറ്റ, API കീ, ആന്തരിക സിസ്റ്റം വിലാസം, പ്രൊഡക്ഷൻ ഡാറ്റ എന്നിവ അടങ്ങിയിരിക്കുന്നുണ്ടോ? ഏതൊക്കെ മേഖലകൾ, ഉണ്ടെങ്കിൽ, മുഖംമൂടി/നീക്കം ചെയ്യേണ്ടതുണ്ട്. അത് പോലെ പ്രോസസ്സ് ചെയ്യുന്നു. ഉള്ളടക്കം: [ഒട്ടിക്കുക]
മൂന്ന് മിനി കേസുകൾ
കേസ് 1 - എൻഡ്-ടു-എൻഡ് ഫ്ലോയുടെ വേഗത. AI- പവർഡ് എൻഡ്-ടു-എൻഡ് ഫ്ലോ ഉപയോഗിച്ച് ഒരു ടീം ഒരു പുതിയ “സബ്സ്ക്രിപ്ഷൻ പുതുക്കൽ” സവിശേഷത കൈകാര്യം ചെയ്തു: ആവശ്യകത അനിശ്ചിതത്വങ്ങൾ മുന്നിൽ ഫ്ലാഗ് ചെയ്തു, മൂന്ന്-ലെയർ ടെസ്റ്റുകൾ ഡ്രാഫ്റ്റ് ചെയ്ത് മ്യൂട്ടേഷൻ-സാധുവാക്കൽ, CI-യുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. പരമ്പരാഗത പ്രക്രിയയിൽ 5 ദിവസമെടുത്ത ടെസ്റ്റിംഗ് സൈക്കിൾ ഫീച്ചർ 2 ദിവസമായി കുറച്ചു; എന്നാൽ മനുഷ്യരുടെ അംഗീകാരം എല്ലാ ഘട്ടത്തിലും സംരക്ഷിക്കപ്പെട്ടു, കൂടാതെ ഒരു ആവശ്യകത അനിശ്ചിതത്വം (പുതുക്കൽ പരാജയപ്പെട്ടാൽ എന്ത് സംഭവിക്കും) ലൈവിനു മുമ്പായി അടച്ചു.
കേസ് 2 - കീ ചോർച്ചയിൽ നിന്ന് മടങ്ങുക. ഒരു ഡെവലപ്പർക്ക് CI YAML സൃഷ്ടിക്കാൻ AI ഉണ്ടായിരുന്നു, കൂടാതെ AI ഒരു ഉദാഹരണമായി YAML-ൽ ഒരു യഥാർത്ഥ API കീ ഉൾപ്പെടുത്തി. “സുരക്ഷ/സ്വകാര്യത മുൻകൂർ പരിശോധന” ഘട്ടം ഇത് ക്യാപ്ചർ ചെയ്തു; കീ രഹസ്യ റഫറൻസിലേക്ക് പരിവർത്തനം ചെയ്തു. ഓഡിറ്റ് ഘട്ടം കൂടാതെ, കീ പതിപ്പ് നിയന്ത്രണത്തിലേക്ക് (ജിറ്റ് ഹിസ്റ്ററി) ചോർന്നുപോകും.
കേസ് 3 - അധികാര പരിധി. "എനിക്ക് ജിജ്ഞാസയുണ്ടായിരുന്നു" എന്നതിൽ നിന്ന് ഒരു ബിസിനസ്സ് പങ്കാളിയുടെ ലൈവ് സിസ്റ്റത്തിൽ താൻ പഠിച്ച IDOR ടെസ്റ്റ് പ്രയോഗിക്കാൻ ഒരു ടീം അംഗം ആഗ്രഹിച്ചു. QA നേതാവ് നിർത്തി: രേഖാമൂലമുള്ള അംഗീകാരവും നിർവചിക്കപ്പെട്ട വ്യാപ്തിയും ഇല്ലാതെ മറ്റൊരു സിസ്റ്റത്തിൽ സുരക്ഷാ പരിശോധന നടത്തുന്നത് നിയമവിരുദ്ധമാണ്. അവരുടെ സ്വന്തം ഉൽപ്പന്നങ്ങളുടെ പരീക്ഷണ പരിതസ്ഥിതിയിൽ മാത്രമാണ് പരിശോധന നടത്തിയത്, അധികാരത്തോടെ; തുറന്ന ഉത്തരവാദിത്തമുള്ള പാർട്ടി ബന്ധപ്പെട്ട ടീമിനെ അറിയിച്ചു.
സാധാരണ തെറ്റുകൾ
- AI-യെ റിലീസ് തീരുമാനങ്ങൾ എടുക്കുന്നു. "ഇത് റിലീസ് ചെയ്യാൻ കഴിയുമോ?" എന്ന ചോദ്യം ചോദിക്കുന്നു. AI-യിലേക്ക് ഉത്തരം ഒപ്പിൻ്റെ സ്ഥാനത്ത് ഇടുക.
- ഓട്ടോമേറ്റഡ് ടെസ്റ്റ് "പാസാകുന്നു". CI-യിൽ, AI ടെസ്റ്റിന് പച്ച പെയിൻ്റ് ചെയ്യുക; തെറ്റുകൾ മറയ്ക്കുന്നു.
- വാഹനത്തിന് രഹസ്യ ഡാറ്റ/താക്കോൽ നൽകുന്നു. മേൽനോട്ടമില്ലാതെ പ്രൊഡക്ഷൻ ഡാറ്റയോ വ്യക്തിഗത ഡാറ്റയോ API കീകളോ പങ്കിടുന്നു.
- അനധികൃത സുരക്ഷാ പരിശോധന. സ്കോപ്പും അനുമതിയും ഇല്ലാതെ മറ്റൊരു സിസ്റ്റത്തിൽ അറ്റാക്കർ ടെസ്റ്റിംഗ്.
- അവലോകനം കൂടാതെ പൈപ്പ്ലൈനിലേക്ക് ടെസ്റ്റുകൾ അവതരിപ്പിക്കുന്നു. മനുഷ്യൻ്റെ അംഗീകാരമില്ലാതെ AI സ്കെച്ച് സ്വയമേവ പ്രവർത്തിപ്പിക്കുക.
- AI യിൽ കുറ്റം ചുമത്തുന്നു. "AI എഴുതിയത്" എന്ന് പറഞ്ഞുകൊണ്ട് തെറ്റായ ഔട്ട്പുട്ടിനെ പ്രതിരോധിക്കുന്നു.
ചുരുക്കത്തിൽ
എൻഡ്-ടു-എൻഡ് ക്യുഎ എന്നത് ആവശ്യകതകൾ മുതൽ പ്രൊഡക്ഷൻ ട്രാക്കിംഗ് വരെ നീളുകയും സിഐ/സിഡിയിൽ ജീവിക്കുകയും ചെയ്യുന്ന ഒരു പ്രക്രിയയാണ്; ഓരോ ഘട്ടത്തിലും, AI ഡ്രാഫ്റ്റുകൾ നിർമ്മിക്കുകയും ലോഗ് സംഗ്രഹിക്കുകയും മൂലകാരണങ്ങൾ നിർദ്ദേശിക്കുകയും ചെയ്യുന്നു. എന്നാൽ അതിരുകൾ മാറ്റമില്ലാത്തതാണ്: മനുഷ്യർ പരീക്ഷണ തീരുമാനങ്ങൾ എടുക്കുകയും അംഗീകാരം നൽകുകയും ചെയ്യുന്നു; ടെസ്റ്റ് സ്വയമേവ "പാസാക്കാൻ" AI-ക്ക് ഒരിക്കലും അധികാരം നൽകിയിട്ടില്ല; രഹസ്യ വിവരങ്ങളും കീകളും വാഹനത്തിൽ പ്രവേശിക്കുന്നില്ല; രേഖാമൂലമുള്ള അംഗീകാരത്തിനും നിർവചിക്കപ്പെട്ട പരിധിക്കും ഉള്ളിൽ, പ്രതിരോധ ആവശ്യങ്ങൾക്കായി, നിങ്ങളുടെ സ്വന്തം ഉൽപ്പന്നത്തിൽ മാത്രമാണ് സുരക്ഷാ പരിശോധന നടത്തുന്നത്, കണ്ടെത്തലുകൾ ഉത്തരവാദിത്ത വെളിപ്പെടുത്തലോടെ റിപ്പോർട്ട് ചെയ്യുന്നു. നിങ്ങൾ AI ഉപയോഗിക്കുമ്പോൾ സുതാര്യമായിരിക്കുക; ഔട്ട്പുട്ടിൻ്റെ കൃത്യതയ്ക്ക് നിങ്ങൾ ഉത്തരവാദിയാണ്. AI ത്വരിതപ്പെടുത്തുന്നു; ഗുണനിലവാരത്തിനും ധാർമ്മികതയ്ക്കും നിങ്ങൾ ഉറപ്പ് നൽകുന്നു.
ആപ്ലിക്കേഷൻ ടാസ്ക്
നിങ്ങളുടെ സ്വന്തം പ്രോജക്റ്റിൽ നിന്നുള്ള ഒരു ഫീച്ചറിനായി "എൻഡ്-ടു-എൻഡ് ടെസ്റ്റ് പ്ലാൻ" ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് റിലീസ് ചെയ്യുന്നതിനായി ആശയത്തിൽ നിന്ന് ഒരു പ്ലാൻ തയ്യാറാക്കുക; ഓരോ ഘട്ടത്തിലും AIയുടെയും മനുഷ്യ അംഗീകാര പോയിൻ്റുകളുടെയും പങ്ക് വെവ്വേറെ അടയാളപ്പെടുത്തുക. തുടർന്ന് "CI/CD പൈപ്പ്ലൈൻ ഔട്ട്ലൈൻ" ഉപയോഗിച്ച് ഒരു YAML സൃഷ്ടിക്കുകയും, ഉൾച്ചേർത്ത കീ/രഹസ്യ ഡാറ്റ പരിശോധിക്കാൻ ഈ YAML-ലേക്ക് "സുരക്ഷ/സ്വകാര്യത മുൻകൂട്ടി പരിശോധിക്കുക" പ്രയോഗിക്കുകയും ചെയ്യുക. അവസാനമായി, നിങ്ങളുടെ പ്ലാനിലെ എല്ലാ "മനുഷ്യ തീരുമാന" പോയിൻ്റുകളും ലിസ്റ്റുചെയ്യുകയും ഈ തീരുമാനങ്ങൾ AI- ലേക്ക് ഏൽപ്പിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ടെന്ന് ഒരു വാചകത്തിൽ ന്യായീകരിക്കുകയും ചെയ്യുക.
ചെക്ക്ലിസ്റ്റ്
- മോചനവും പരീക്ഷണ തീരുമാനങ്ങളും മനുഷ്യരുടെ അംഗീകാരത്തിന് കാരണമായി ഞാൻ കണക്കാക്കുന്നു; ഞാൻ അത് AI-ക്ക് കൈമാറിയില്ല.
- [ ] CI/CD-യിൽ, ടെസ്റ്റ് സ്വയമേവ "പാസാക്കാൻ/തിരുത്താൻ" ഞാൻ AI-ക്ക് അനുമതി നൽകിയില്ല.
- [ ] വാഹനത്തിലേക്ക് അയയ്ക്കുന്നതിന് മുമ്പ് ഞാൻ രഹസ്യ ഡാറ്റ, വ്യക്തിഗത ഡാറ്റ, കീകൾ എന്നിവ പരിശോധിച്ച് മറച്ചു.
- [ ] രേഖാമൂലമുള്ള അംഗീകാരത്തിനും വ്യാപ്തിക്കും ഉള്ളിൽ, എൻ്റെ സ്വന്തം ഉൽപ്പന്നത്തിൽ സുരക്ഷാ പരിശോധന മാത്രമേ ഞാൻ പരിഗണിച്ചിട്ടുള്ളൂ.
- [ ] ഉത്തരവാദിത്ത വെളിപ്പെടുത്തൽ എന്ന തത്ത്വത്തിൽ കണ്ടെത്തിയ കേടുപാടുകൾ ഞാൻ അഭിസംബോധന ചെയ്തു.
- [ ] ഞാൻ AI ഉപയോഗിച്ചുവെന്നും ഔട്ട്പുട്ടിൻ്റെ കൃത്യതയ്ക്ക് ഞാൻ ഉത്തരവാദിയാണെന്നും ഞാൻ സുതാര്യമായി പ്രസ്താവിച്ചു.
മൊഡ്യൂൾ പരീക്ഷ
1. എങ്ങനെയാണ് 'തെറ്റായ പാസ്' QA സന്ദർഭത്തിൽ ഏറ്റവും കൃത്യമായി നിർവചിക്കുന്നത്?
- എ) ടെസ്റ്റ് പച്ചയായി മാറുന്നുണ്ടെങ്കിലും, ഇത് യഥാർത്ഥത്തിൽ ഒരു പെരുമാറ്റവും സ്ഥിരീകരിക്കുന്നില്ല; ✔ കോഡ് കേടായാലും ചുവപ്പ് നിറമാകില്ല
- ബി) ടെസ്റ്റ് വളരെ സാവധാനത്തിൽ നടക്കുന്നു.
- സി) ടെസ്റ്റ് ഒരു യഥാർത്ഥ പിശക് കണ്ടെത്തുകയും ചുവപ്പായി മാറുകയും ചെയ്യുന്നു
- ഡി) ടെസ്റ്റ് ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ മാത്രം പ്രവർത്തിക്കുന്നു
വിശദീകരണം: ഒരു ടെസ്റ്റ് 'പാസ്' എന്ന് പറയുകയും എന്നാൽ യഥാർത്ഥത്തിൽ അർത്ഥവത്തായ ഒന്നും സ്ഥിരീകരിക്കാതിരിക്കുകയും ചെയ്യുന്നതാണ് കപട-പാസ്; പരീക്ഷ പച്ചയാണ്, പക്ഷേ സോഫ്റ്റ്വെയർ തകരാറിലാണെങ്കിൽ പോലും അത് പിടിക്കില്ല. QA-യിലെ AI-യുടെ ഒന്നാം നമ്പർ അപകടസാധ്യത ഇതാണ്, കാരണം AI വൃത്തിയായി കാണപ്പെടുന്നതും എന്നാൽ പൊള്ളയായതുമായ ടെസ്റ്റുകൾ നിർമ്മിക്കാൻ പ്രവണത കാണിക്കുന്നു.
2. ടെസ്റ്റിംഗിലും QA പ്രക്രിയയിലും ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിൻ്റെ ഏറ്റവും കൃത്യമായ സ്ഥാനം എന്താണ്?
- എ) മനുഷ്യൻ്റെ അംഗീകാരമില്ലാതെ പതിപ്പ് പുറത്തിറക്കാനാകുമോ എന്ന് ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിന് തീരുമാനിക്കാം
- ബി) ഡ്രാഫ്റ്റുകളും ആശയങ്ങളും സൃഷ്ടിക്കുന്ന ഒരു സഹായിയാണ് ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ്; 'ഇത് പ്രസിദ്ധീകരണത്തിന് തയ്യാറാണോ' എന്ന തീരുമാനവും ഉത്തരവാദിത്തവും വിദഗ്ധരുടേതാണ് ✔
- സി) ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് ടെക്സ്റ്റ് മാത്രമേ എഴുതൂ, ടെസ്റ്റ് കോഡ് കൈകാര്യം ചെയ്യാൻ കഴിയില്ല
- ഡി) ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് എപ്പോഴും മനുഷ്യനേക്കാൾ ശരിയായ പരീക്ഷ എഴുതുന്നു, അതിനാൽ അവലോകനം ആവശ്യമില്ല
വിവരണം: ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് ഒരു ടെസ്റ്റിംഗ് അസിസ്റ്റൻ്റ്, ഡ്രാഫ്റ്റ് ജനറേറ്റർ, ഐഡിയ മൾട്ടിപ്ലയർ എന്നിവയാണ്; ടെസ്റ്റ് സാഹചര്യങ്ങളും ഓട്ടോമേഷൻ കോഡും റിപ്പോർട്ട് ഡ്രാഫ്റ്റുകളും നിർമ്മിക്കുന്നു. എന്നിരുന്നാലും, 'ഈ സോഫ്റ്റ്വെയർ പ്രസിദ്ധീകരണത്തിന് തയ്യാറാണോ' അല്ലെങ്കിൽ 'ഈ ടെസ്റ്റ് വിജയിച്ചോ' എന്നിങ്ങനെയുള്ള ഗുണമേന്മയുള്ള തീരുമാനങ്ങളുടെ ഉത്തരവാദിത്തവും അന്തിമ അംഗീകാരവും കഴിവുള്ള വിദഗ്ദ്ധൻ്റെതാണ്.
3. പിശകുകൾ കൂടുതലും സംഭവിക്കുന്നത് ത്രെഷോൾഡ് മൂല്യങ്ങളിലാണെന്ന വസ്തുതയെ അടിസ്ഥാനമാക്കി, 18 പ്രായപരിധിക്കായി 17, 18, 19 എന്നിവയെ വെവ്വേറെ പരീക്ഷിക്കുന്നത് ഏത് ടെസ്റ്റ് ഡിസൈൻ ടെക്നിക്കാണ്?
- എ) സ്റ്റേറ്റ് ട്രാൻസിഷൻ ടെസ്റ്റ്
- ബി) തീരുമാന പട്ടിക
- C) അതിർത്തി മൂല്യ വിശകലനം ✔
- ഡി) പര്യവേക്ഷണ പരിശോധന
വിശദീകരണം: ബൗണ്ടറി മൂല്യ വിശകലനം, ബൗണ്ടറികളിലും ടെസ്റ്റ് ത്രെഷോൾഡ് മൂല്യങ്ങളിലും (കുറച്ച് താഴെ, തൊട്ടു മുകളിൽ, പരിധിക്ക് മുകളിൽ) വെവ്വേറെ പിഴവുകൾ സംഭവിക്കുന്ന നിരീക്ഷണത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. തുല്യതാ ക്ലാസുകൾ പൂർത്തീകരിക്കുന്ന ശക്തമായ ഒരു സാങ്കേതികതയാണിത്.
4. ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് ഉപയോഗിച്ച് നിർമ്മിച്ച യുഐ ടെസ്റ്റ് ഓട്ടോമേഷൻ കോഡിലെ ദുർബലത കുറയ്ക്കുന്നതിന് എലമെൻ്റ് സെലക്ഷനിൽ ഏത് സമീപനമാണ് മുൻഗണന നൽകേണ്ടത്?
- എ) സാധ്യമായ ഏറ്റവും ദൈർഘ്യമേറിയ എക്സ്പാത്ത് പാത ഉപയോഗിക്കുന്നു
- ബി) സ്ക്രീനിലെ പിക്സൽ സ്ഥാനത്തിനനുസരിച്ച് ഘടകം തിരഞ്ഞെടുക്കുന്നു
- സി) CSS ക്ലാസ് പേരുകൾ അടിസ്ഥാനമാക്കിയുള്ള സെലക്ടറുകൾ ഉപയോഗിക്കുന്നത്
- ഡി) സ്ഥിരതയുള്ള ആട്രിബ്യൂട്ടുകൾ ഉപയോഗിക്കുന്നത് (ഡാറ്റ-ടെസ്റ്റിഡ്) ടെസ്റ്റിംഗിനായി ചേർത്തു ✔
വിശദീകരണം: ദൈർഘ്യമേറിയ XPath പാതകളും CSS ക്ലാസ് പേരുകളും പേജ് ഘടനയെയും രൂപകൽപ്പനയെയും വളരെയധികം ആശ്രയിച്ചിരിക്കുന്നു; ചെറിയ ഇൻ്റർഫേസ് മാറ്റത്തിൽ ഇത് തകരുന്നു. ടെസ്റ്റിംഗിനായി പ്രത്യേകം ചേർത്ത സ്ഥിരതയുള്ള ആട്രിബ്യൂട്ടുകളെ (ഉദാ. ഡാറ്റ-ടെസ്റ്റിഡ്) ഡിസൈൻ മാറ്റങ്ങളാൽ ബാധിക്കില്ല, മാത്രമല്ല പരിശോധനകൾ ശക്തമാക്കുകയും ചെയ്യുന്നു.
5. ഒരു API ടെസ്റ്റിന് HTTP സ്റ്റാറ്റസ് കോഡ് (ഉദാ. 200) പരിശോധിക്കുന്നത് എന്തുകൊണ്ട് പര്യാപ്തമല്ല?
- എ) കാരണം ശരിയായ സ്റ്റാറ്റസ് കോഡുള്ള ബോഡി ഡാറ്റ കേടായേക്കാം, കൂടാതെ സ്റ്റാറ്റസ് ചെക്ക് മാത്രം ഇത് പിടിക്കില്ല (കപട-വിശ്വാസം) ✔
- B) കാരണം API ടെസ്റ്റുകളിൽ സ്റ്റാറ്റസ് കോഡുകൾ ഒട്ടും വിശ്വസനീയമല്ല
- സി) കാരണം സ്റ്റാറ്റസ് കോഡ് പരിശോധന ടെസ്റ്റിനെ വളരെയധികം മന്ദഗതിയിലാക്കുന്നു
- ഡി) കാരണം എപിഐ ടെസ്റ്റുകളിൽ സ്റ്റാറ്റസ് കോഡ് ഒരിക്കലും നൽകില്ല
വിശദീകരണം: സെർവർ ശരിയായ സ്റ്റാറ്റസ് കോഡ് നൽകുമ്പോൾ, അത് ബോഡിയിലെ കേടായ ഡാറ്റ തിരികെ നൽകിയേക്കാം (തെറ്റായ തരം, വിട്ടുപോയ ഫീൽഡ്, തെറ്റായി കണക്കാക്കിയ മൂല്യം). സാഹചര്യം മാത്രം നോക്കുന്ന പരിശോധനയ്ക്ക് ഇത് കാണാനാകില്ല, തെറ്റായ ആത്മവിശ്വാസം നൽകുന്നു. അതിനാൽ സ്കീമ/കരാർ, ബിസിനസ് റൂൾ മൂല്യനിർണ്ണയം എന്നിവയും ചേർക്കണം.
6. യൂണിറ്റ് ടെസ്റ്റുകൾ അച്ചടിക്കുമ്പോൾ 'സ്വീകാര്യത നിയമമനുസരിച്ച് പ്രതീക്ഷിക്കുന്ന മൂല്യം സ്വമേധയാ കണക്കാക്കാൻ, ഫംഗ്ഷൻ്റെ നിലവിലെ ഔട്ട്പുട്ട് റഫറൻസ് ചെയ്യരുത്' എന്ന് AI-യോട് പറയുന്നത് നിർണ്ണായകമായിരിക്കുന്നത് എന്തുകൊണ്ട്?
- എ) കാരണം മാനുവൽ കണക്കുകൂട്ടൽ ടെസ്റ്റുകൾ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു
- B) അല്ലാത്തപക്ഷം, ടെസ്റ്റ് കോഡിൻ്റെ നിലവിലെ (ഒരുപക്ഷേ ബഗ്ഗി) സ്വഭാവം 'ശരി' ആയി അംഗീകരിക്കുകയും ബഗ് സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നു ✔
- സി) കാരണം ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിന് ദശാംശ സംഖ്യകൾ കണക്കാക്കാൻ കഴിയില്ല
- ഡി) കാരണം സ്വീകാര്യത നിയമങ്ങൾ ടെസ്റ്റുകളിൽ ഒരിക്കലും ഉപയോഗിക്കില്ല
വിശദീകരണം: ടെസ്റ്റിന് കീഴിലുള്ള ഫംഗ്ഷൻ്റെ ഔട്ട്പുട്ടിൽ നിന്ന് AI പ്രതീക്ഷിക്കുന്ന മൂല്യം നേടുകയാണെങ്കിൽ, അത് ഫംഗ്ഷൻ തകരാറിലാണെങ്കിൽപ്പോലും പരിശോധനയെ 'പാസാക്കി' മാറ്റും; അതായത്, കോഡ് എന്തുതന്നെയായാലും, പരിശോധന ശരിയാണെന്ന് കണക്കാക്കുന്നു. സ്വീകാര്യത നിയമത്തിൽ നിന്ന് സ്വതന്ത്രമായി പ്രതീക്ഷിക്കുന്ന മൂല്യം കണക്കാക്കുന്നത്, ടെസ്റ്റ് നിയമത്തിലേക്കുള്ള ഒരു ഗേറ്റ്കീപ്പറാണെന്ന് ഉറപ്പാക്കുന്നു, കോഡിൻ്റെ കണ്ണാടിയല്ല.
7. ഒരു നല്ല ബഗ് റിപ്പോർട്ടിൻ്റെ ഏറ്റവും വ്യതിരിക്തമായ സവിശേഷത ഇനിപ്പറയുന്നവയിൽ ഏതാണ്?
- എ) കഴിയുന്നത്ര ദൈർഘ്യമേറിയതും സാങ്കേതികവുമായിരിക്കണം
- ബി) ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസ് എഴുതിയത്
- സി) ഡെവലപ്പർക്ക് സ്വതന്ത്രമായി പിന്തുടരാനും പിശക് സൃഷ്ടിക്കാനും കഴിയുന്ന നിർണ്ണായക പുനർനിർമ്മാണ ഘട്ടങ്ങൾ അടങ്ങിയിരിക്കുന്നു ✔
- ഡി) ഇതൊരു സ്ക്രീൻഷോട്ട് മാത്രമാണ്
വിശദീകരണം: ഒരു ബഗ് റിപ്പോർട്ടിൻ്റെ യഥാർത്ഥ മൂല്യം ഡെവലപ്പർക്ക് നിങ്ങളുടെ സഹായമില്ലാതെ ബഗ് പുനർനിർമ്മിക്കാൻ കഴിയും എന്നതാണ്. ആദ്യം മുതൽ നിർണ്ണായകവും കണ്ടെത്താവുന്നതുമായ പുനരുൽപാദന ഘട്ടങ്ങൾ ഇത് ഉറപ്പാക്കുന്നു; ഈ ഘട്ടങ്ങൾ നഷ്ടമായാൽ, റിപ്പോർട്ട് 'ഉത്പാദിപ്പിക്കാൻ കഴിഞ്ഞില്ല' എന്ന് പലപ്പോഴും ക്ലോസ് ചെയ്യും.
8. ഹോം പേജിൽ കമ്പനിയുടെ പേര് തെറ്റായി എഴുതിയതിലെ പിശകിൻ്റെ തീവ്രതയും മുൻഗണനയും തമ്മിലുള്ള ബന്ധത്തിന് ഏറ്റവും കൃത്യമായ പദപ്രയോഗം ഏതാണ്?
- എ) തീവ്രതയ്ക്കും മുൻഗണനയ്ക്കും എല്ലായ്പ്പോഴും ഒരേ മൂല്യം ഉണ്ടായിരിക്കണം
- ബി) ഈ പിശകിൻ്റെ തീവ്രതയും മുൻഗണനയും തീർച്ചയായും കുറവാണ്
- സി) തീവ്രതയും മുൻഗണനയും ഒരേ ആശയമാണ്, ഒരു ലേബൽ മതി
- ഡി) സാങ്കേതിക തീവ്രത കുറവായിരിക്കാം എന്നാൽ ബിസിനസ് മുൻഗണന (പ്രശസ്തി) ഉയർന്നതായിരിക്കാം; രണ്ടും വ്യത്യസ്തമായി വിലയിരുത്തപ്പെടുന്നു ✔
വിശദീകരണം: തീവ്രത എന്നത് പിശകിൻ്റെ സാങ്കേതിക ആഘാതമാണ് (അക്ഷരത്തെ സാങ്കേതികമായി കുറവാണ്), അത് എത്ര അടിയന്തിരമായി പരിഹരിക്കണം എന്നതിനാണ് മുൻഗണന (എല്ലാ സന്ദർശകനും കാണുന്ന ഒരു പ്രശസ്തി ഘടകമായതിനാൽ ഉയർന്നതാണ്). രണ്ടും എപ്പോഴും ഒരേ ദിശയിലല്ല; ഈ ഉദാഹരണം കുറഞ്ഞ തീവ്രത-ഉയർന്ന മുൻഗണനാ സാഹചര്യമാണ്.
9. 90% ലൈൻ കവറേജുള്ള ഒരു ടെസ്റ്റ് സ്യൂട്ടിൻ്റെ ഏറ്റവും കൃത്യമായ വ്യാഖ്യാനം ഏതാണ്?
- എ) വരികൾ എക്സിക്യൂട്ട് ചെയ്തിട്ടുണ്ടെന്ന് ഇത് കാണിക്കുന്നു, പക്ഷേ അവ ശരിയായി പെരുമാറുന്നുവെന്ന് തെളിയിക്കുന്നില്ല; ✔ ഉയർന്ന കവറേജ് തെറ്റായ ആത്മവിശ്വാസം നൽകും
- B) 90% സോഫ്റ്റ്വെയറും ബഗ് രഹിതമാണെന്ന് നിർണായകമായി തെളിയിക്കുന്നു
- സി) ഇത് മികച്ച ടെസ്റ്റ് ഗുണനിലവാരത്തിൻ്റെ ഒരു നിശ്ചിത അളവാണ്.
- ഡി) ഇനി അധിക പരീക്ഷകളൊന്നും എഴുതേണ്ടതില്ലെന്ന് സൂചിപ്പിക്കുന്നു
വിശദീകരണം: വരികൾ മാത്രമേ എക്സിക്യൂട്ട് ചെയ്തിട്ടുള്ളൂ എന്ന് വരി കവറേജ് സൂചിപ്പിക്കുന്നു; അത് ശരിയായ ഫലം നൽകുന്നുവെന്ന് തെളിയിക്കുന്നില്ല. ഉറപ്പില്ലാത്ത പരിശോധനകളിലൂടെ പോലും, 90% കവറേജ് നേടാനാകും. സ്കോപ്പ് എന്നത് 'എവിടെയും നോക്കാത്ത' ഭൂപടമാണ്, 'എല്ലാം പരീക്ഷിച്ചു' എന്ന ഉറപ്പല്ല; മ്യൂട്ടേഷൻ പരിശോധനയിലൂടെയാണ് യഥാർത്ഥ സംരക്ഷണം അളക്കുന്നത്.
10. റിസ്ക് അധിഷ്ഠിത പരിശോധനയിൽ, പരിമിതമായ പരിശോധനാ പ്രയത്നത്തിലേക്ക് നയിക്കുന്നതിന് ഒരു സവിശേഷതയുടെ അപകടസാധ്യത എങ്ങനെയാണ് കണക്കാക്കുന്നത്?
- എ) കോഡിൻ്റെ വരികളുടെ എണ്ണം കൊണ്ട് മാത്രം
- B) പരാജയപ്പെടാനുള്ള സാധ്യതയും അത് തകരുമ്പോൾ ഉണ്ടാകുന്ന ഫലവും ഗുണിക്കുന്നതിലൂടെ ✔
- സി) ഫീച്ചർ വികസിപ്പിച്ച ക്രമത്തിൽ മാത്രം
- ഡി) പരീക്ഷ എഴുതാൻ എളുപ്പമുള്ള ഫീച്ചറിന് മാത്രം മുൻഗണന നൽകുക
വിശദീകരണം: അപകടസാധ്യത അടിസ്ഥാനമാക്കിയുള്ള പരിശോധനയിൽ, സാധ്യത = പ്രോബബിലിറ്റി (തകർച്ചയുടെ സാധ്യത) × ആഘാതം (തകർന്നാൽ കേടുപാടുകൾ) ആയി കണക്കാക്കുന്നു. ഉയർന്ന പ്രോബബിലിറ്റിയും ഉയർന്ന ഇംപാക്ട് ഡൊമെയ്നുകളും (പേയ്മെൻ്റ്, പ്രാമാണീകരണം) ഏറ്റവും തീവ്രമായ പരിശോധനയ്ക്ക് അർഹമാണ്, അതേസമയം താഴ്ന്ന×കുറഞ്ഞ ഡൊമെയ്നുകൾക്ക് നേരിയ പരിശോധന ലഭിക്കും.
11. കോഡ് മാറിയിട്ടില്ലെങ്കിലും ചിലപ്പോൾ വിജയിക്കുകയും ചിലപ്പോൾ പരാജയപ്പെടുകയും ചെയ്യുന്ന (പൊട്ടുന്ന / അടരുകളായി) ഒരു ടെസ്റ്റിലേക്ക് വീണ്ടും ശ്രമിക്കുന്നതിനുള്ള പ്രധാന അപകടസാധ്യത എന്താണ്?
- എ) ടെസ്റ്റിൻ്റെ റണ്ണിംഗ് സമയം കുറയ്ക്കുന്നു
- ബി) കവറേജ് ശതമാനം കുറയ്ക്കുന്നു
- സി) ഒരു യഥാർത്ഥ കൺകറൻസി പിശക് അല്ലെങ്കിൽ മൂലകാരണം മറയ്ക്കുകയും രോഗലക്ഷണത്തെ അടിച്ചമർത്തുകയും ചെയ്യുക ✔
- ഡി) ടെസ്റ്റിൻ്റെ പേര് മാറ്റുന്നു
വിശദീകരണം: വീണ്ടും ശ്രമിക്കുക ഒരു രോഗനിർണയ ഉപകരണമാണ്, ചികിത്സയല്ല. വിവേചനമില്ലായ്മ പലപ്പോഴും യഥാർത്ഥ റേസ് അവസ്ഥയിൽ നിന്നോ ആസക്തിയിൽ നിന്നോ വരുന്നു; വീണ്ടും ശ്രമിച്ചുകൊണ്ട് ടെസ്റ്റ് 'പാസ്' ആക്കുന്നത് ഈ യഥാർത്ഥ പിശക് മറയ്ക്കുകയും തത്സമയത്തിൽ ഗുരുതരമായ പ്രശ്നങ്ങൾ ഉണ്ടാക്കുകയും ചെയ്യും. മൂലകാരണം ആദ്യം കണ്ടെത്തണം.
12. ഒരു ടെസ്റ്റ് സ്യൂട്ട് യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്നുണ്ടോ എന്ന് അളക്കുന്നതിനുള്ള ഏറ്റവും സത്യസന്ധമായ രീതിയായ മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ് എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്?
- എ) ടെസ്റ്റുകളുടെ റണ്ണിംഗ് സ്പീഡ് അളക്കുന്നതിലൂടെ
- ബി) കോഡിൻ്റെ എത്ര വരികൾ എഴുതിയിട്ടുണ്ടെന്ന് എണ്ണുന്നതിലൂടെ
- സി) വ്യത്യസ്ത ഓർഡറുകളിൽ ടെസ്റ്റുകൾ നടത്തുന്നതിലൂടെ
- ഡി) കോഡിൽ ബോധപൂർവം ചെറിയ ഇടവേളകൾ സൃഷ്ടിച്ച് ടെസ്റ്റുകൾ പിടിക്കുന്നുണ്ടോ എന്ന് അളക്കുന്നതിലൂടെ ✔
വിവരണം: മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ് സോഴ്സ് കോഡിൽ ചെറിയ മനഃപൂർവ്വമായ വികലങ്ങൾ (മ്യൂട്ടേഷനുകൾ) ഉണ്ടാക്കുന്നു; ഒരു നല്ല ടെസ്റ്റ് സ്യൂട്ട് ഈ വികലങ്ങൾ പിടിച്ച് ചുവപ്പായി മാറണം. പിടിക്കപ്പെടാത്ത (അതിജീവിച്ച) മ്യൂട്ടേഷനുകൾ സൂചിപ്പിക്കുന്നത് പരിശോധനകൾ ആ സ്വഭാവത്തെ സംരക്ഷിക്കുന്നില്ല എന്നാണ്. മ്യൂട്ടേഷൻ സ്കോർ ശതമാനം കവറേജിനേക്കാൾ വളരെ സത്യസന്ധമായ ഗുണനിലവാരമാണ്.
13. സുരക്ഷാ പരിശോധന നടത്തുമ്പോൾ പാലിക്കേണ്ട പ്രധാന പരിധി എന്താണ് (ഉദാ. അംഗീകാരം/IDOR ടെസ്റ്റുകൾ)?
- എ) പ്രതിരോധ ആവശ്യങ്ങൾക്കായി, രേഖാമൂലമുള്ള അംഗീകാരത്തിനും നിർവചിക്കപ്പെട്ട പരിധിക്കും ഉള്ളിൽ, സ്വന്തം ഉൽപ്പന്നത്തിൽ മാത്രമേ ഇത് ചെയ്യാവൂ ✔
- ബി) താൽപ്പര്യമുള്ള ഏത് സംവിധാനത്തിലും ഇത് സ്വതന്ത്രമായി പ്രയോഗിക്കാൻ കഴിയും
- സി) അനുമതിയില്ലാതെ ബിസിനസ്സ് പങ്കാളികളുടെ ലൈവ് സിസ്റ്റങ്ങളിൽ ഇത് പരീക്ഷിക്കാവുന്നതാണ്
- ഡി) എന്തെങ്കിലും കേടുപാടുകൾ കണ്ടെത്തിയാൽ ഉടനടി പരസ്യമായി പ്രസിദ്ധീകരിക്കണം.
വിവരണം: ഈ മൊഡ്യൂളിൽ പഠിക്കുന്ന സുരക്ഷാ പരിശോധനകൾ, രേഖാമൂലമുള്ള അംഗീകാരത്തിനും നിർവചിക്കപ്പെട്ട പരിധിക്കും ഉള്ളിൽ, പ്രതിരോധ ആവശ്യങ്ങൾക്കായി നിങ്ങളുടെ സ്വന്തം ഉൽപ്പന്നം പരിശോധിക്കുന്നതിന് മാത്രമുള്ളതാണ്. അനുമതിയില്ലാതെ മറ്റൊരാളുടെ സിസ്റ്റത്തിലേക്ക് പ്രവേശിക്കുകയോ പരിധിക്ക് പുറത്തുള്ള പരിശോധന നടത്തുകയോ ചെയ്യുന്നത് അനീതിപരവും നിയമവിരുദ്ധവുമാണ്; കണ്ടെത്തിയ ഏതെങ്കിലും കേടുപാടുകൾ ഉത്തരവാദിത്ത വെളിപ്പെടുത്തലിലൂടെ റിപ്പോർട്ട് ചെയ്യുന്നു.
14. CI/CD പൈപ്പ്ലൈനിൽ AI-ക്ക് ഒരിക്കലും എന്ത് അധികാരം നൽകരുത്?
- എ) പരാജയപ്പെട്ട ടെസ്റ്റ് ലോഗുകളുടെ സംഗ്രഹം
- B) പരാജയപ്പെട്ട (ചുവപ്പ്) പരീക്ഷയിൽ സ്വയമേവ 'പാസാകുന്ന' അല്ലെങ്കിൽ പച്ച പെയിൻ്റ് ചെയ്യാനുള്ള അധികാരം ✔
- സി) ഒരു ടെസ്റ്റ് കോഡ് ഡ്രാഫ്റ്റ് നിർദ്ദേശിക്കുന്നു
- D) പൈപ്പ്ലൈൻ YAML ഫയൽ ഡ്രാഫ്റ്റിംഗ്
വിവരണം: AI-ന് ടെസ്റ്റ് കോഡ് ഔട്ട്ലൈൻ, പൈപ്പ്ലൈൻ YAML, ലോഗ് സംഗ്രഹം എന്നിവ CI/CD-യിൽ നിർമ്മിക്കാൻ കഴിയും; എന്നിരുന്നാലും, പരാജയപ്പെട്ട ഒരു ടെസ്റ്റ് സ്വയമേവ 'പാസാക്കാൻ/പരിഹരിക്കാനുള്ള' കഴിവ് ഒരിക്കലും നൽകരുത്. ഇത് പരിശോധനയുടെ ഉദ്ദേശ്യത്തെ പരാജയപ്പെടുത്തുകയും പിശകുകൾ യാന്ത്രികമായി മറയ്ക്കുകയും ചെയ്യുന്നു. ടെസ്റ്റ് ഗ്രീൻ പെയിൻ്റ് ചെയ്യുന്നത് ഒരു വ്യക്തിയുടെ ബോധപൂർവവും യുക്തിസഹവുമായ തീരുമാനമായിരിക്കണം.