નફો:
- 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 ડ્રાફ્ટ
હા
પ્રમાણીકરણ + ગુપ્ત કી ચકાસણી
નિષ્ફળ લોગ સારાંશ
હા
મૂળ કારણ પુષ્ટિ
નાજુક પરીક્ષણ નિદાન
હા
કાયમી ઉકેલનો નિર્ણય
"શું કોઈ સંસ્કરણ હોઈ શકે?"
ના
નિષ્ણાત ચુકાદો અને જવાબદારી
આપમેળે પરીક્ષણ "પાસ" કરો
ક્યારેય નહીં
-
સાવધાન: AI ને ક્યારેય CI/CD માં "ફેલિંગ ટેસ્ટ પાસ કરવા માટે તેને ઠીક કરો" જેવો આદેશ આપશો નહીં. આ પરીક્ષણના હેતુને નષ્ટ કરે છે અને આપમેળે ભૂલોને આવરી લે છે. AI ભૂલ સમજાવી શકે છે, સુધારણા સૂચવી શકે છે; પરંતુ "પરીક્ષણને લીલું રંગવું" એ વ્યક્તિનો સભાન, તર્કસંગત નિર્ણય હોવો જોઈએ.
ગોપનીયતા, ડેટા અને સુરક્ષા: અપરિવર્તનશીલ સીમાઓ
ગોપનીયતા. પરીક્ષણ વાતાવરણમાં, વાસ્તવિક ગ્રાહક ડેટા, ઉત્પાદન ડેટાબેઝ નકલો, API કી અને આંતરિક સિસ્ટમ માહિતી સંવેદનશીલ હોય છે. આને સાર્વજનિક AI ટૂલ્સને આપશો નહીં. વ્યક્તિગત ડેટા KVKK અને સમાન નિયમોને આધીન છે; માસ્ક લોગ અને સ્ક્રીનશૉટ્સ. જ્યાં શક્ય હોય ત્યાં સિન્થેટિક (કાલ્પનિક) ટેસ્ટ ડેટાનો ઉપયોગ કરો.
સુરક્ષા પરીક્ષણ - રક્ષણાત્મક અને અધિકૃત. આ મોડ્યુલમાં શીખેલ સુરક્ષા પરીક્ષણો (અધિકૃતતા/IDOR પરીક્ષણો, ફાઇલ અપલોડ મર્યાદા, ઇનપુટ માન્યતા) ફક્ત લેખિત અધિકૃતતા અને નિર્ધારિત અવકાશમાં તમારા પોતાના ઉત્પાદનના પરીક્ષણ માટે છે. પરવાનગી વિના કોઈ બીજાની સિસ્ટમને ઍક્સેસ કરવા, વાસ્તવિક નબળાઈઓને હથિયાર બનાવવા અથવા અવકાશની બહાર પરીક્ષણ કરવા માટે AI નો ઉપયોગ કરવો એ બંને અનૈતિક અને ગેરકાયદેસર છે. જ્યારે તમને સુરક્ષાની નબળાઈ મળે, ત્યારે જવાબદાર જાહેરાતના સિદ્ધાંતનું પાલન કરો — નબળાઈને ગોપનીય રાખો અને સંબંધિત પક્ષને તેની જાણ કરો જેથી કરીને તેને ઠીક કરી શકાય.
નૈતિકતા અને પારદર્શિતા. AI દ્વારા ઉત્પાદિત પરીક્ષણોને તમારા પોતાના કાર્ય તરીકે રજૂ કરશો નહીં; તમે ટીમમાં AI નો ઉપયોગ કરી રહ્યા છો તે જણાવવું એ પારદર્શિતા છે. તમે AI દ્વારા ઉત્પાદિત આઉટપુટની અચોક્કસતા માટે જવાબદાર છો — “AI એ લખ્યું છે” એ બહાનું નથી.
નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ
નબળા: "CI માટે ટેસ્ટ પાઇપલાઇન સેટ કરો."
મજબૂત: "GitHub ક્રિયાઓ માટે CI વર્કફ્લો YAML ડ્રાફ્ટ કરો: દરેક PR પર એકમ + API પરીક્ષણો ચલાવો, કવરેજ રિપોર્ટ બનાવો, મ્યુટેશન ટેસ્ટિંગ (સ્ટ્રાઇકર) સાપ્તાહિક ચલાવો. કોડમાં રહસ્યો એમ્બેડ કરશો નહીં; માત્ર રહસ્યો સંદર્ભનો ઉપયોગ કરો. જો પરીક્ષણો લાલ હોય તો મર્જને અવરોધિત કરો. આ એક ડ્રાફ્ટ અને એડિટેશન કી સ્ટેપ છે; હું આઇડીઓટી મેનેજમેન્ટની સમીક્ષા કરીશ. સ્વયંસંચાલિત પરીક્ષણ 'ફિક્સ' અથવા 'માઇગ્રેટ' પગલું ઉમેરો."
શક્તિશાળી પ્રોમ્પ્ટ; તે ગોપનીયતા, માનવ સમીક્ષા અને "કોઈ સ્વચાલિત પરીક્ષણ નથી" પર મર્યાદા લાદે છે.
ચાર નકલ કરી શકાય તેવા નમૂનાઓ
1) એન્ડ-ટુ-એન્ડ ટેસ્ટિંગ પ્લાન:
તમારી ભૂમિકા: વરિષ્ઠ QA નેતા. નીચેની સુવિધા માટે રીલીઝ કરવાના વિચારથી અંત-થી-એન્ડ પરીક્ષણ યોજનાનો મુસદ્દો તૈયાર કરો: [સુવિધા + સ્વીકૃતિ માપદંડ]. તબક્કાઓ: આવશ્યકતાઓનું વિશ્લેષણ (અનિશ્ચિતતાઓ), પરીક્ષણ ડિઝાઇન, ઓટોમેશન સ્તરો (યુનિટ/API/UI), CI/CD એકીકરણ, પ્રકાશન નિર્ણય માપદંડ, ઉત્પાદન ટ્રેકિંગ. દરેક તબક્કે AI અને HUMAN એપ્રુવલ પોઈન્ટની ભૂમિકા અલગથી સ્પષ્ટ કરો.
2) CI/CD પાઇપલાઇન રૂપરેખા:
[GitHub Actions/GitLab CI/Azure Pipelines] માટે CI YAML ડ્રાફ્ટ:- યુનિટ + API ટેસ્ટ + PR માં અવકાશ- રેડ ટેસ્ટમાં મર્જ અટકાવો- માત્ર રહસ્યો સાથે ગુપ્ત મૂલ્યો; કોડમાં એમ્બેડ કરવું આ એક ડ્રાફ્ટ છે; હું મુખ્ય સંચાલન અને મંજૂરીના પગલાંની સમીક્ષા કરીશ. ઑટોકોરેક્ટ/પાસ ટેસ્ટ સ્ટેપ ઉમેરવું.
3) નિષ્ફળ પરીક્ષણ લોગ વિશ્લેષણ:
તે CI પ્રિન્ટઆઉટમાં, પરીક્ષણો લાલ હોય છે. લોગની તપાસ કરો; નિષ્ફળતાઓનું જૂથ બનાવો, સંભવિત મૂળ કારણને ઓળખો અને જે વાસ્તવિક નિષ્ફળતા હોઈ શકે છે અને જે એક નાજુક પરીક્ષણ/પર્યાવરણ સમસ્યા હોઈ શકે છે. જો વ્યક્તિગત ડેટા હોય, તો તેને માસ્ક કરો. નિર્ણય અને કરેક્શન મારો રહેશે. લોગ: [પેસ્ટ કરો]
4) સુરક્ષા/ગોપનીયતા પૂર્વ-તપાસ:
આ ટેસ્ટ ડેટા/લોગ AI ટૂલ પર મોકલવામાં આવે તે પહેલાં, તપાસો: શું તેમાં વ્યક્તિગત ડેટા, API કી, આંતરિક સિસ્ટમ સરનામું, ઉત્પાદન ડેટા છે? સૂચિબદ્ધ કરો કે કયા ક્ષેત્રો, જો કોઈ હોય તો, માસ્ક / દૂર કરવાની જરૂર છે. જેમ છે તેમ પ્રોસેસિંગ. સામગ્રી: [પેસ્ટ]
ત્રણ નાના કેસો
કેસ 1 - એન્ડ-ટુ-એન્ડ ફ્લોની ઝડપ. એક ટીમે AI-સંચાલિત એન્ડ-ટુ-એન્ડ ફ્લો સાથે નવી "સબ્સ્ક્રિપ્શન નવીકરણ" સુવિધાનો સામનો કર્યો: આવશ્યક અનિશ્ચિતતાઓ આગળ ધ્વજાંકિત, ત્રણ-સ્તરના પરીક્ષણોનો મુસદ્દો તૈયાર કરવામાં આવ્યો અને પરિવર્તન-માન્ય, CI સાથે જોડાયેલ. વિશેષતાએ પરીક્ષણ ચક્રને ઘટાડ્યું, જે પરંપરાગત પ્રક્રિયામાં 5 દિવસનો સમય લેતો હતો, તે 2 દિવસ સુધી ઘટાડ્યો; પરંતુ માનવીય મંજૂરી દરેક તબક્કે સાચવવામાં આવી હતી, અને અનિશ્ચિતતાની જરૂરિયાતો (જો તાજું નિષ્ફળ જાય તો શું થાય છે) પ્રી-લાઈવ બંધ કરવામાં આવ્યું હતું.
કેસ 2 — કી લીકમાંથી પાછા ફરો. વિકાસકર્તા પાસે AI જનરેટ CI YAML હતું, અને AI એ ઉદાહરણ તરીકે YAML માં વાસ્તવિક દેખાતી API કી એમ્બેડ કરી હતી. "સુરક્ષા/ગોપનીયતા પ્રીચેક" પગલાએ આને કબજે કર્યું; કી ગુપ્ત સંદર્ભમાં રૂપાંતરિત. ઓડિટ પગલા વિના, કી આવૃત્તિ નિયંત્રણ (ગીટ ઇતિહાસ) માં લીક થઈ જશે.
કેસ 3 - સત્તાની મર્યાદા. એક ટીમના સભ્ય "હું વિચિત્ર હતો" માંથી બિઝનેસ પાર્ટનરની લાઇવ સિસ્ટમમાં શીખેલ IDOR ટેસ્ટ લાગુ કરવા માગતો હતો. QA નેતાએ અટકાવ્યું: લેખિત અધિકૃતતા અને વ્યાખ્યાયિત અવકાશ વિના અન્ય સિસ્ટમ પર સુરક્ષા પરીક્ષણ કરવું ગેરકાયદેસર છે. પરીક્ષણ ફક્ત તેમના પોતાના ઉત્પાદનોના પરીક્ષણ વાતાવરણમાં, સત્તા સાથે કરવામાં આવ્યું હતું; ખુલ્લેઆમ જવાબદાર પક્ષને સંબંધિત ટીમને જાણ કરવામાં આવી હતી.
સામાન્ય ભૂલો
- AI બનાવવાથી રિલીઝના નિર્ણયો લેવામાં આવે છે. પ્રશ્ન પૂછીને "શું તે મુક્ત થઈ શકે છે?" AI ને અને સહીની જગ્યાએ જવાબ મૂકવો.
- સ્વચાલિત પરીક્ષા "પાસ કરવી". CI માં, AI એ ટેસ્ટને લીલો રંગ કરે છે; ભૂલોને ઢાંકવી.
- વાહનને ગોપનીય ડેટા/કી આપવી. દેખરેખ વિના ઉત્પાદન ડેટા, વ્યક્તિગત ડેટા અથવા API કી શેર કરવી.
- અનધિકૃત સુરક્ષા પરીક્ષણ. અવકાશ અને પરવાનગી વિના અન્ય સિસ્ટમ પર હુમલાખોર પરીક્ષણ.
- સમીક્ષા વિના પાઇપલાઇનમાં પરીક્ષણો રજૂ કરી રહ્યાં છીએ. માનવીય મંજૂરી વિના આપમેળે AI સ્કેચ ચલાવો.
- AI પર દોષ મૂકવો. "એઆઈએ લખ્યું છે" એમ કહીને ખોટા આઉટપુટનો બચાવ કરવો.
સારાંશમાં
એન્ડ-ટુ-એન્ડ QA એ એક પ્રક્રિયા છે જે જરૂરિયાતોથી લઈને ઉત્પાદન ટ્રેકિંગ સુધી વિસ્તરે છે અને CI/CD ની અંદર રહે છે; દરેક તબક્કે, AI ડ્રાફ્ટ્સ બનાવે છે, લોગનો સારાંશ આપે છે અને મૂળ કારણો સૂચવે છે. પરંતુ સીમાઓ અપરિવર્તનશીલ છે: મનુષ્ય પરીક્ષણના નિર્ણયો લે છે અને મંજૂરીને મુક્ત કરે છે; AI ને ક્યારેય પરીક્ષણ આપમેળે "પાસ" કરવાનો અધિકાર આપવામાં આવતો નથી; ગોપનીય ડેટા અને કીઓ વાહનમાં પ્રવેશતા નથી; સુરક્ષા પરીક્ષણ ફક્ત તમારા પોતાના ઉત્પાદન પર, લેખિત અધિકૃતતા અને નિર્ધારિત અવકાશમાં, રક્ષણાત્મક હેતુઓ માટે કરવામાં આવે છે, અને તારણો જવાબદાર જાહેરાત સાથે જાણ કરવામાં આવે છે. જ્યારે તમે AI નો ઉપયોગ કરો ત્યારે પારદર્શક બનો; તમે આઉટપુટની ચોકસાઈ માટે જવાબદાર છો. AI વેગ આપે છે; તમે ગુણવત્તા અને નીતિશાસ્ત્રની ખાતરી આપો છો.
એપ્લિકેશન કાર્ય
તમારા પોતાના પ્રોજેક્ટમાંથી એક વિશેષતા માટે "એન્ડ-ટુ-એન્ડ ટેસ્ટ પ્લાન" ટેમ્પ્લેટ સાથે રજૂ કરવા માટે વિચારથી યોજનાનો મુસદ્દો બનાવો; દરેક તબક્કે AI અને માનવીય મંજૂરી બિંદુઓની ભૂમિકાને અલગથી ચિહ્નિત કરો. પછી "CI/CD પાઇપલાઇન રૂપરેખા" સાથે YAML જનરેટ કરો અને એમ્બેડેડ કી/ગુપ્ત ડેટા તપાસવા માટે આ YAML પર "સુરક્ષા/ગોપનીયતા પ્રીચેક" લાગુ કરો. છેલ્લે, તમારી યોજનાના તમામ "માનવ નિર્ણય" મુદ્દાઓની સૂચિ બનાવો અને એક વાક્યમાં ન્યાયી ઠેરવો કે શા માટે આ નિર્ણયો AI ને સોંપી શકાતા નથી.
ચેકલિસ્ટ
- [ ] હું પ્રકાશન અને પરીક્ષણના નિર્ણયોને માનવીય મંજૂરીને આભારી છું; મેં તેને એઆઈને સોંપ્યું નથી.
- [ ] CI/CD માં મેં AI ને આપમેળે પરીક્ષણ "પાસ/સુધારો" કરવાની પરવાનગી આપી નથી.
- [ ] મેં વાહનમાં મોકલતા પહેલા ગોપનીય ડેટા, વ્યક્તિગત ડેટા અને ચાવીઓ તપાસી અને માસ્ક કર્યા.
- [ ] મેં લેખિત અધિકૃતતા અને અવકાશમાં ફક્ત મારા પોતાના ઉત્પાદન પર સુરક્ષા પરીક્ષણને ધ્યાનમાં લીધું છે.
- [ ] મેં જવાબદાર જાહેરાતના સિદ્ધાંત સાથે મળી આવેલી નબળાઈઓને સંબોધિત કરી.
- [ ] મેં પારદર્શક રીતે કહ્યું કે મેં AI નો ઉપયોગ કર્યો છે અને આઉટપુટની ચોકસાઈ માટે મારી જાતને જવાબદાર ગણાવી છે.
મોડ્યુલ પરીક્ષા
1. QA સંદર્ભમાં 'ખોટા પાસ'ને સૌથી સચોટ રીતે કેવી રીતે વ્યાખ્યાયિત કરવામાં આવે છે?
- A) ટેસ્ટ લીલો થઈ ગયો હોવા છતાં, તે વાસ્તવમાં કોઈપણ વર્તનની પુષ્ટિ કરતું નથી; ✔ કોડ બગડે તો પણ લાલ થતો નથી
- બી) ટેસ્ટ ખૂબ જ ધીરે ધીરે ચાલે છે અને સમય સમાપ્ત થાય છે.
- C) પરીક્ષણ વાસ્તવિક ભૂલ શોધે છે અને લાલ થઈ જાય છે
- ડી) પરીક્ષણ માત્ર ઉત્પાદન વાતાવરણમાં ચાલે છે
સમજૂતી: સ્યુડો-પાસ એ છે જ્યારે ટેસ્ટ 'પાસ' કહે છે પરંતુ વાસ્તવમાં અર્થપૂર્ણ કંઈપણ પુષ્ટિ કરતું નથી; ટેસ્ટ લીલો છે, પરંતુ જો સૉફ્ટવેર ખામીયુક્ત છે, તો પણ તે તેને પકડી શકશે નહીં. QA માં AI નું આ નંબર વન જોખમ છે કારણ કે AI એવા પરીક્ષણો ઉત્પન્ન કરે છે જે સુઘડ દેખાય છે પરંતુ હોલો છે.
2. પરીક્ષણ અને QA પ્રક્રિયામાં કૃત્રિમ બુદ્ધિની સૌથી સચોટ સ્થિતિ શું છે?
- A) આર્ટિફિશિયલ ઇન્ટેલિજન્સ નક્કી કરી શકે છે કે વર્ઝનને માનવ મંજૂરી વિના રિલીઝ કરી શકાય કે નહીં
- બી) કૃત્રિમ બુદ્ધિ એ સહાયક છે જે ડ્રાફ્ટ્સ અને વિચારો પેદા કરે છે; 'શું તે પ્રકાશન માટે તૈયાર છે' નો નિર્ણય અને જવાબદારી નિષ્ણાતની છે ✔
- C) કૃત્રિમ બુદ્ધિ માત્ર ટેક્સ્ટ લખે છે અને પરીક્ષણ કોડ સાથે બિલકુલ વ્યવહાર કરી શકતી નથી
- ડી) આર્ટિફિશિયલ ઇન્ટેલિજન્સ હંમેશા માનવ કરતાં સાચો ટેસ્ટ લખે છે, તેથી સમીક્ષા બિનજરૂરી છે
વર્ણન: કૃત્રિમ બુદ્ધિ એ પરીક્ષણ સહાયક, ડ્રાફ્ટ જનરેટર અને આઈડિયા ગુણક છે; પરીક્ષણ દૃશ્યો, ઓટોમેશન કોડ અને રિપોર્ટ ડ્રાફ્ટ્સ બનાવે છે. જો કે, 'શું આ સોફ્ટવેર પ્રકાશન માટે તૈયાર છે' અથવા 'આ પરીક્ષા પાસ કરી છે' જેવા ગુણવત્તાયુક્ત નિર્ણયોની જવાબદારી અને અંતિમ મંજૂરી સક્ષમ નિષ્ણાતની છે.
3. એ હકીકતના આધારે કે ભૂલો મોટાભાગે થ્રેશોલ્ડ મૂલ્યો પર થાય છે, 18 વર્ષની મર્યાદા માટે 17, 18 અને 19 ને અલગથી ચકાસવા માટે કઈ ટેસ્ટ ડિઝાઇન ટેકનિક છે?
- એ) રાજ્ય સંક્રમણ પરીક્ષણ
- બી) નિર્ણય ટેબલ
- સી) સીમા મૂલ્ય વિશ્લેષણ ✔
- ડી) સંશોધનાત્મક પરીક્ષણ
સમજૂતી: બાઉન્ડ્રી વેલ્યુ એનાલિસિસ એ અવલોકન પર આધારિત છે કે ભૂલો મોટાભાગે સીમાઓ પર થાય છે અને થ્રેશોલ્ડ મૂલ્યો (ફક્ત નીચે, માત્ર ઉપર અને મર્યાદાથી ઉપર) અલગથી પરીક્ષણ કરે છે. તે એક શક્તિશાળી તકનીક છે જે સમાનતા વર્ગોને પૂરક બનાવે છે.
4. કૃત્રિમ બુદ્ધિ સાથે ઉત્પાદિત UI ટેસ્ટ ઓટોમેશન કોડમાં નાજુકતાને ઘટાડવા માટે તત્વની પસંદગીમાં કયો અભિગમ પસંદ કરવો જોઈએ?
- A) શક્ય સૌથી લાંબો XPath પાથનો ઉપયોગ કરવો
- B) સ્ક્રીન પર તેની પિક્સેલ સ્થિતિ અનુસાર તત્વ પસંદ કરવું
- C) CSS વર્ગના નામો પર આધારિત પસંદગીકારોનો ઉપયોગ કરવો
- ડી) પરીક્ષણ માટે ઉમેરાયેલ સ્થિર વિશેષતાઓ (ડેટા-ટેસ્ટિડ) નો ઉપયોગ કરીને ✔
સમજૂતી: લાંબા XPath પાથ અને CSS વર્ગના નામો પૃષ્ઠની રચના અને ડિઝાઇન પર અત્યંત નિર્ભર છે; તે સહેજ ઇન્ટરફેસ ફેરફાર પર તૂટી જાય છે. ખાસ કરીને પરીક્ષણ માટે ઉમેરવામાં આવેલ સ્થિર વિશેષતાઓ (દા.ત. ડેટા-ટેસ્ટિડ) ડિઝાઇન ફેરફારોથી પ્રભાવિત થતી નથી અને પરીક્ષણોને મજબૂત બનાવે છે.
5. માત્ર HTTP સ્ટેટસ કોડ (દા.ત. 200) તપાસવા માટે API ટેસ્ટ માટે તે શા માટે અપૂરતું છે?
- A) કારણ કે સાચા સ્ટેટસ કોડ સાથેનો બોડી ડેટા દૂષિત થઈ શકે છે અને એકલા સ્ટેટસ ચેક આને પકડી શકશે નહીં (સ્યુડો-ટ્રસ્ટ) ✔
- બી) કારણ કે API પરીક્ષણોમાં સ્ટેટસ કોડ બિલકુલ ભરોસાપાત્ર નથી
- C) કારણ કે સ્ટેટસ કોડ તપાસવાથી ટેસ્ટ ઘણો ધીમો પડી જાય છે
- ડી) કારણ કે API પરીક્ષણોમાં સ્ટેટસ કોડ ક્યારેય પરત કરવામાં આવતો નથી
સમજૂતી: જ્યારે સર્વર સાચો સ્ટેટસ કોડ પરત કરે છે, ત્યારે તે શરીરમાં દૂષિત ડેટા પરત કરી શકે છે (ખોટો પ્રકાર, ખૂટે છે ફીલ્ડ, ખોટી રીતે ગણતરી કરેલ મૂલ્ય). પરિક્ષણ જે ફક્ત પરિસ્થિતિને જુએ છે તે આ જોઈ શકતું નથી અને ખોટો વિશ્વાસ આપે છે. તેથી સ્કીમા/કોન્ટ્રેક્ટ અને બિઝનેસ નિયમની માન્યતા પણ ઉમેરવી જોઈએ.
6. એકમ પરીક્ષણો છાપતી વખતે AI ને 'સ્વીકૃતિના નિયમ અનુસાર અપેક્ષિત મૂલ્યની જાતે ગણતરી કરવા, ફંક્શનના વર્તમાન આઉટપુટને સંદર્ભિત ન કરવા' કહેવું શા માટે મહત્વપૂર્ણ છે?
- A) કારણ કે મેન્યુઅલ ગણતરી પરીક્ષણો ઝડપથી ચલાવે છે
- બી) કારણ કે અન્યથા ટેસ્ટ કોડના વર્તમાન (કદાચ બગડેલ) વર્તનને 'સાચો' તરીકે સ્વીકારે છે અને ભૂલની પુષ્ટિ કરે છે ✔
- C) કારણ કે આર્ટિફિશિયલ ઇન્ટેલિજન્સ દશાંશ સંખ્યાની બિલકુલ ગણતરી કરી શકતી નથી
- ડી) કારણ કે સ્વીકૃતિ નિયમો ક્યારેય પરીક્ષણોમાં ઉપયોગમાં લેવાતા નથી
સમજૂતી: જો AI પરીક્ષણ હેઠળના ફંક્શનના આઉટપુટમાંથી અપેક્ષિત મૂલ્ય મેળવે છે, તો કાર્ય ખામીયુક્ત હોવા છતાં પણ તે પરીક્ષણને 'પાસ' કરશે; એટલે કે, જે પણ કોડ પેદા કરે છે, તે ટેસ્ટ સાચી ગણાય છે. સ્વીકૃતિ નિયમથી સ્વતંત્ર રીતે અપેક્ષિત મૂલ્યની ગણતરી કરવાથી ખાતરી થાય છે કે પરીક્ષણ એ નિયમનું દ્વારપાળ છે, કોડનો અરીસો નથી.
7. સારા બગ રિપોર્ટ માટે નીચેનામાંથી કયું સૌથી વિશિષ્ટ લક્ષણ છે?
- A) શક્ય તેટલું લાંબું અને તકનીકી હોવું
- બી) કૃત્રિમ બુદ્ધિ દ્વારા લખાયેલ
- C) નિર્ણાયક પ્રજનન પગલાંઓ ધરાવે છે જેને વિકાસકર્તા સ્વતંત્ર રીતે અનુસરી શકે છે અને ભૂલ પેદા કરી શકે છે ✔
- ડી) તે માત્ર એક સ્ક્રીનશૉટ છે
સમજૂતી: બગ રિપોર્ટનું વાસ્તવિક મૂલ્ય એ છે કે વિકાસકર્તા તમારી મદદ વિના બગનું પુનઃઉત્પાદન કરી શકે છે. શરૂઆતથી નિર્ધારિત, શોધી શકાય તેવા પ્રજનન પગલાં આની ખાતરી કરે છે; જો આ પગલાં ખૂટે છે, તો રિપોર્ટ ઘણીવાર 'ઉત્પાદિત કરી શક્યા નથી' તરીકે બંધ થઈ જાય છે.
8. હોમ પેજ પર કંપનીના નામની ખોટી જોડણીની ભૂલમાં ગંભીરતા અને પ્રાથમિકતા વચ્ચેના સંબંધ માટે સૌથી સચોટ અભિવ્યક્તિ કઈ છે?
- A) તીવ્રતા અને અગ્રતા હંમેશા સમાન મૂલ્ય હોવી જોઈએ
- બી) આ ભૂલની ગંભીરતા અને પ્રાથમિકતા બંને ચોક્કસપણે ઓછી છે
- સી) ગંભીરતા અને પ્રાથમિકતા એ જ ખ્યાલ છે, એક લેબલ પૂરતું છે
- ડી) તકનીકી તીવ્રતા ઓછી હોઈ શકે છે પરંતુ વ્યવસાય અગ્રતા (પ્રતિષ્ઠા) ઊંચી હોઈ શકે છે; બંનેનું મૂલ્યાંકન અલગ રીતે કરવામાં આવે છે ✔
સમજૂતી: ગંભીરતા એ ભૂલની તકનીકી અસર છે (ટાઇપો તકનીકી રીતે ઓછી), પ્રાથમિકતા એ છે કે તેને કેટલી તાકીદે ઠીક કરવાની જરૂર છે (ઉચ્ચ કારણ કે તે પ્રતિષ્ઠાનું તત્વ છે જે દરેક મુલાકાતી જુએ છે). બંને હંમેશા એક જ દિશામાં જતા નથી; આ ઉદાહરણ ઓછી ગંભીરતા-ઉચ્ચ પ્રાથમિકતાની સ્થિતિ છે.
9. 90% લાઇન કવરેજ સાથે ટેસ્ટ સ્યુટનું સૌથી સચોટ અર્થઘટન કયું છે?
- એ) તે દર્શાવે છે કે રેખાઓ ચલાવવામાં આવે છે પરંતુ તે સાબિત કરતું નથી કે તેઓ યોગ્ય રીતે વર્તે છે; ✔ ઉચ્ચ કવરેજ ખોટો વિશ્વાસ આપી શકે છે
- બી) નિર્ણાયક રીતે સાબિત કરે છે કે 90% સોફ્ટવેર બગ-ફ્રી છે
- C) તે ઉત્તમ પરીક્ષણ ગુણવત્તાનું નિશ્ચિત માપ છે.
- ડી) સૂચવે છે કે હવે કોઈ વધારાના પરીક્ષણો લખવાની જરૂર નથી
સમજૂતી: પંક્તિ કવરેજ સૂચવે છે કે માત્ર પંક્તિઓ ચલાવવામાં આવી હતી; તે સાબિત કરતું નથી કે તે સાચા પરિણામો આપે છે. નિશ્ચય વિનાના પરીક્ષણો સાથે પણ, 90% કવરેજ પ્રાપ્ત કરી શકાય છે. અવકાશ એ 'ક્યારેય જોયો નથી' નકશો છે, 'બધું પરીક્ષણ કરવામાં આવ્યું છે' ખાતરી નથી; વાસ્તવિક સંરક્ષણ પરિવર્તન પરીક્ષણ દ્વારા માપવામાં આવે છે.
10. જોખમ-આધારિત પરીક્ષણમાં, પ્રત્યક્ષ મર્યાદિત પરીક્ષણ પ્રયત્નો માટે વિશેષતાના જોખમની ગણતરી કેવી રીતે કરવામાં આવે છે?
- A) માત્ર કોડની રેખાઓની સંખ્યા દ્વારા
- B) નિષ્ફળતાની સંભાવનાનો ગુણાકાર કરીને અને જ્યારે તે તૂટી જશે ત્યારે જે અસર થશે તે ✔
- સી) ફક્ત તે ક્રમમાં કે જેમાં સુવિધા વિકસાવવામાં આવી હતી
- ડી) ફક્ત તે જ સુવિધાને પ્રાધાન્ય આપવું કે જેના માટે પરીક્ષણો લખવા માટે સૌથી સરળ છે
સમજૂતી: જોખમ-આધારિત પરીક્ષણમાં, જોખમનું મૂલ્યાંકન સંભાવના = સંભાવના (ભંગાણની સંભાવના) × અસર (તૂટે તો નુકસાન) તરીકે કરવામાં આવે છે. ઉચ્ચ સંભાવના અને ઉચ્ચ અસરવાળા ડોમેન્સ (ચુકવણી, પ્રમાણીકરણ) સૌથી તીવ્ર પરીક્ષણને પાત્ર છે, જ્યારે ઓછા × ઓછા ડોમેન્સ પ્રકાશ પરીક્ષણ મેળવે છે.
11. કોડ બદલાયો ન હોવા છતાં કેટલીકવાર પાસ થાય છે અને ક્યારેક નિષ્ફળ જાય છે (બરડ/અટપટું) ટેસ્ટમાં ફરીથી પ્રયાસ ઉમેરવાનું મુખ્ય જોખમ શું છે?
- A) ટેસ્ટનો ચાલી રહેલો સમય ટૂંકો કરવો
- બી) કવરેજ ટકાવારી ઘટાડે છે
- સી) સાચા સહવર્તી ભૂલ અથવા મૂળ કારણને ઢાંકવું અને લક્ષણને દબાવવું ✔
- ડી) કસોટીનું નામ બદલવું
સમજૂતી: ફરી પ્રયાસ એ નિદાનનું સાધન છે, સારવાર નથી. અનિર્ણાયકતા ઘણીવાર વાસ્તવિક જાતિની સ્થિતિ અથવા વ્યસનથી આવે છે; ફરીથી પ્રયાસ કરીને ટેસ્ટ 'પાસ' કરવાથી આ વાસ્તવિક ભૂલ આવરી લેવામાં આવે છે અને લાઇવમાં ગંભીર સમસ્યાઓ ઊભી કરી શકે છે. પહેલા મૂળ કારણ શોધવું જોઈએ.
12. ટેસ્ટ સ્યુટ ખરેખર રક્ષણ કરે છે કે કેમ તે માપવાની સૌથી પ્રામાણિક પદ્ધતિ, પરિવર્તન પરીક્ષણ કેવી રીતે કાર્ય કરે છે?
- એ) પરીક્ષણોની ચાલતી ઝડપને માપીને
- B) કોડની કેટલી લીટીઓ લખાઈ હતી તેની ગણતરી કરીને
- સી) વિવિધ ક્રમમાં પરીક્ષણો ચલાવીને
- ડી) કોડમાં ઇરાદાપૂર્વક નાના વિરામો બનાવીને અને પરીક્ષણો તેમને પકડે છે કે કેમ તે માપીને ✔
વર્ણન: મ્યુટેશન ટેસ્ટિંગ સ્ત્રોત કોડમાં નાની ઇરાદાપૂર્વકની વિકૃતિઓ (પરિવર્તન) પેદા કરે છે; એક સારા ટેસ્ટ સ્યુટને આ વિકૃતિઓ પકડવી જોઈએ અને લાલ થઈ જવું જોઈએ. મ્યુટેશન કે જે પકડાયા નથી (બચી ગયા છે) તે સૂચવે છે કે પરીક્ષણો તે વર્તનને સાચવતા નથી. મ્યુટેશન સ્કોર ટકાવારી કવરેજ કરતાં ગુણવત્તાનું વધુ પ્રમાણિક માપ છે.
13. સુરક્ષા પરીક્ષણ (દા.ત. અધિકૃતતા/IDOR પરીક્ષણો) કરતી વખતે અનુસરવાની મુખ્ય મર્યાદા શું છે?
- A) તે માત્ર તેના પોતાના ઉત્પાદન પર, લેખિત અધિકૃતતા અને નિર્ધારિત અવકાશમાં, રક્ષણાત્મક હેતુઓ માટે થવું જોઈએ ✔
- બી) તે રસની કોઈપણ સિસ્ટમ પર મુક્તપણે લાગુ કરી શકાય છે
- C) પરવાનગી વિના બિઝનેસ પાર્ટનર્સની લાઇવ સિસ્ટમ પર તેનો પ્રયાસ કરી શકાય છે
- ડી) કોઈપણ નબળાઈઓ જોવા મળે છે તે તરત જ જાહેરમાં પ્રકાશિત થવી જોઈએ.
વર્ણન: આ મોડ્યુલમાં શીખેલા સુરક્ષા પરીક્ષણો માત્ર લેખિત અધિકૃતતા અને નિર્ધારિત અવકાશમાં, રક્ષણાત્મક હેતુઓ માટે તમારા પોતાના ઉત્પાદનના પરીક્ષણ માટે છે. પરવાનગી વિના કોઈ બીજાની સિસ્ટમને ઍક્સેસ કરવી અથવા અવકાશની બહાર પરીક્ષણ કરવું એ બંને અનૈતિક અને ગેરકાયદેસર છે; મળેલી કોઈપણ નબળાઈઓની જાણ જવાબદાર જાહેરાત દ્વારા કરવામાં આવે છે.
14. CI/CD પાઇપલાઇનમાં AI ને કયા અધિકાર ક્યારેય ન આપવો જોઈએ?
- A) નિષ્ફળ પરીક્ષણ લોગનો સારાંશ
- B) નિષ્ફળ (લાલ) કસોટી આપમેળે 'પાસ' કરવાની અથવા તેને લીલો રંગ કરવાની સત્તા ✔
- સી) ટેસ્ટ કોડ ડ્રાફ્ટનું સૂચન કરવું
- ડી) પાઇપલાઇન YAML ફાઇલ ડ્રાફ્ટિંગ
વર્ણન: AI પરીક્ષણ કોડ રૂપરેખા, પાઇપલાઇન YAML અને CI/CD માં લોગ સારાંશનું ઉત્પાદન કરી શકે છે; જો કે, નિષ્ફળ પરીક્ષાને આપમેળે 'પાસ/ફિક્સ' કરવાની ક્ષમતા ક્યારેય આપવી જોઈએ નહીં. આ પરીક્ષણના હેતુને નષ્ટ કરે છે અને આપમેળે ભૂલોને આવરી લે છે. ટેસ્ટને લીલો રંગ કરવો એ વ્યક્તિનો સભાન અને તર્કસંગત નિર્ણય હોવો જોઈએ.