ಎಂಡ್-ಟು-ಎಂಡ್ ವರ್ಕ್‌ಫ್ಲೋ, CI/CD ಇಂಟಿಗ್ರೇಷನ್, ಎಥಿಕ್ಸ್ ಮತ್ತು ಸೆಕ್ಯುರಿಟಿ: AI ಅನ್ನು ಜವಾಬ್ದಾರಿಯುತವಾಗಿ ಬಳಸುವುದು

ಲಾಭಗಳು:

• 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 ಪರಿಕರಗಳಿಗೆ ಇವುಗಳನ್ನು ನೀಡಬೇಡಿ. ವೈಯಕ್ತಿಕ ಡೇಟಾವು KVKK ಮತ್ತು ಅಂತಹುದೇ ನಿಯಮಗಳಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ; ಮಾಸ್ಕ್ ಲಾಗ್‌ಗಳು ಮತ್ತು ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳು. ಸಾಧ್ಯವಾದಲ್ಲೆಲ್ಲಾ ಸಿಂಥೆಟಿಕ್ (ಕಾಲ್ಪನಿಕ) ಪರೀಕ್ಷಾ ಡೇಟಾವನ್ನು ಬಳಸಿ.

ಭದ್ರತಾ ಪರೀಕ್ಷೆ - ರಕ್ಷಣಾತ್ಮಕ ಮತ್ತು ಅಧಿಕೃತ. ಈ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕಲಿತ ಸುರಕ್ಷತಾ ಪರೀಕ್ಷೆಗಳು (ಅಧಿಕಾರ/ಐಡಿಒಆರ್ ಪರೀಕ್ಷೆಗಳು, ಫೈಲ್ ಅಪ್‌ಲೋಡ್ ಮಿತಿಗಳು, ಇನ್‌ಪುಟ್ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ) ಲಿಖಿತ ದೃಢೀಕರಣ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ನಿಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನವನ್ನು ಪರೀಕ್ಷಿಸಲು ಮಾತ್ರ. ಅನುಮತಿಯಿಲ್ಲದೆ ಬೇರೊಬ್ಬರ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು AI ಅನ್ನು ಬಳಸುವುದು, ನೈಜ ದೋಷಗಳನ್ನು ಶಸ್ತ್ರಾಸ್ತ್ರಗೊಳಿಸುವುದು ಅಥವಾ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡುವುದು ಅನೈತಿಕ ಮತ್ತು ಕಾನೂನುಬಾಹಿರವಾಗಿದೆ. ನೀವು ಭದ್ರತಾ ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಕೊಂಡಾಗ, ಜವಾಬ್ದಾರಿಯುತ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ತತ್ವವನ್ನು ಅನುಸರಿಸಿ - ದುರ್ಬಲತೆಯನ್ನು ಗೌಪ್ಯವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಅದನ್ನು ಸಂಬಂಧಿತ ಪಕ್ಷಕ್ಕೆ ವರದಿ ಮಾಡಿ ಇದರಿಂದ ಅದನ್ನು ಸರಿಪಡಿಸಬಹುದು.

ನೈತಿಕತೆ ಮತ್ತು ಪಾರದರ್ಶಕತೆ. AI ನಿಂದ ತಯಾರಿಸಲಾದ ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಕೆಲಸವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಬೇಡಿ; ನೀವು ತಂಡದೊಳಗೆ AI ಅನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಎಂದು ಹೇಳುವುದು ಪಾರದರ್ಶಕತೆ. AI-ಉತ್ಪಾದಿತ ಔಟ್‌ಪುಟ್‌ನ ಅಸಮರ್ಪಕತೆಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ - "AI ಅದನ್ನು ಬರೆದಿದೆ" ಒಂದು ಕ್ಷಮಿಸಿಲ್ಲ.

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್

ದುರ್ಬಲ: "CI ಗಾಗಿ ಪರೀಕ್ಷಾ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಹೊಂದಿಸಿ."

ಪ್ರಬಲ: "GitHub ಕ್ರಿಯೆಗಳಿಗಾಗಿ CI ವರ್ಕ್‌ಫ್ಲೋ YAML ಅನ್ನು ಡ್ರಾಫ್ಟ್ ಮಾಡಿ: ಪ್ರತಿ PR ನಲ್ಲಿ ಯೂನಿಟ್ + API ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ, ಕವರೇಜ್ ವರದಿಯನ್ನು ರಚಿಸಿ, ಮ್ಯುಟೇಶನ್ ಪರೀಕ್ಷೆ (ಸ್ಟ್ರೈಕರ್) ಅನ್ನು ವಾರಕ್ಕೊಮ್ಮೆ ರನ್ ಮಾಡಿ. ರಹಸ್ಯಗಳನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಬೇಡಿ; ರಹಸ್ಯಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿ. ಪರೀಕ್ಷೆಗಳು ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿದ್ದರೆ ವಿಲೀನವನ್ನು ನಿರ್ಬಂಧಿಸಿ. ಇದು DRAFT ಮತ್ತು ಮಾನ್ಯವಾದ NDOT ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ. 'ಫಿಕ್ಸ್' ಅಥವಾ 'ಮೈಗ್ರೇಟ್' ಹಂತವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ."

ಶಕ್ತಿಯುತ ಪ್ರಾಂಪ್ಟ್; ಇದು ಗೌಪ್ಯತೆ, ಮಾನವ ವಿಮರ್ಶೆ ಮತ್ತು "ಯಾವುದೇ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ" ಮೇಲೆ ಮಿತಿಗಳನ್ನು ಹೇರುತ್ತದೆ.

ನಾಲ್ಕು ನಕಲಿಸಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು

1) ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರೀಕ್ಷಾ ಯೋಜನೆ:

ನಿಮ್ಮ ಪಾತ್ರ: ಹಿರಿಯ QA ನಾಯಕ. ಕೆಳಗಿನ ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಕಲ್ಪನೆಯಿಂದ ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಪರೀಕ್ಷಾ ಯೋಜನೆಯನ್ನು ಕರಡು ಮಾಡಿ: [ವೈಶಿಷ್ಟ್ಯ + ಸ್ವೀಕಾರ ಮಾನದಂಡ]. ಹಂತಗಳು: ಅವಶ್ಯಕತೆಗಳ ವಿಶ್ಲೇಷಣೆ (ಅನಿಶ್ಚಿತತೆಗಳು), ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸ, ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪದರಗಳು (ಘಟಕ/API/UI), CI/CD ಏಕೀಕರಣ, ಬಿಡುಗಡೆ ನಿರ್ಧಾರದ ಮಾನದಂಡ, ಉತ್ಪಾದನೆ ಟ್ರ್ಯಾಕಿಂಗ್. ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ AI ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆ ಬಿಂದುಗಳ ಪಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ.

2) CI/CD ಪೈಪ್‌ಲೈನ್ ರೂಪರೇಖೆ:

[GitHub ಕ್ರಿಯೆಗಳು/GitLab CI/Azure ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗಾಗಿ] CI YAML ಡ್ರಾಫ್ಟ್:- PR ನಲ್ಲಿ ಘಟಕ + API ಪರೀಕ್ಷೆ + ವ್ಯಾಪ್ತಿ- ಕೆಂಪು ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಲೀನಗೊಳ್ಳುವುದನ್ನು ತಡೆಯಿರಿ- ರಹಸ್ಯ ಮೌಲ್ಯಗಳು ಮಾತ್ರ ರಹಸ್ಯಗಳೊಂದಿಗೆ; ಕೋಡ್‌ನಲ್ಲಿ ಎಂಬೆಡಿಂಗ್ ಇದು ಡ್ರಾಫ್ಟ್ ಆಗಿದೆ; ನಾನು ಪ್ರಮುಖ ನಿರ್ವಹಣೆ ಮತ್ತು ಅನುಮೋದನೆ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ. ಸ್ವಯಂ ತಿದ್ದುಪಡಿ/ಪಾಸ್ ಪರೀಕ್ಷಾ ಹಂತವನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ.

3) ವಿಫಲ ಪರೀಕ್ಷಾ ದಾಖಲೆ ವಿಶ್ಲೇಷಣೆ:

ಆ CI ಪ್ರಿಂಟ್‌ಔಟ್‌ನಲ್ಲಿ, ಪರೀಕ್ಷೆಗಳು ಕೆಂಪು ಬಣ್ಣದ್ದಾಗಿರುತ್ತವೆ. ಲಾಗ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ; ವೈಫಲ್ಯಗಳನ್ನು ಗುಂಪು ಮಾಡಿ, ಸಂಭವನೀಯ ಮೂಲ ಕಾರಣವನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಯಾವುದು ನಿಜವಾದ ವೈಫಲ್ಯವಾಗಿರಬಹುದು ಮತ್ತು ಇದು ದುರ್ಬಲ ಪರೀಕ್ಷೆ/ಪರಿಸರ ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು. ವೈಯಕ್ತಿಕ ಡೇಟಾ ಇದ್ದರೆ, ಅದನ್ನು ಮರೆಮಾಡಿ. ನಿರ್ಧಾರ ಮತ್ತು ತಿದ್ದುಪಡಿ ನನ್ನದೇ ಆಗಿರುತ್ತದೆ. ಲಾಗ್: [ಅಂಟಿಸಿ]

4) ಭದ್ರತೆ/ಗೌಪ್ಯತೆ ಪೂರ್ವ ಪರಿಶೀಲನೆ:

ಈ ಪರೀಕ್ಷಾ ಡೇಟಾ/ಲಾಗ್ ಅನ್ನು AI ಉಪಕರಣಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು, ಪರಿಶೀಲಿಸಿ: ಇದು ವೈಯಕ್ತಿಕ ಡೇಟಾ, API ಕೀ, ಆಂತರಿಕ ಸಿಸ್ಟಮ್ ವಿಳಾಸ, ಉತ್ಪಾದನಾ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆಯೇ? ಯಾವ ಪ್ರದೇಶಗಳು, ಯಾವುದಾದರೂ ಇದ್ದರೆ, ಮುಖವಾಡ/ತೆಗೆದುಹಾಕುವ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಇದ್ದಂತೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ. ವಿಷಯ: [ಅಂಟಿಸಿ]

ಮೂರು ಸಣ್ಣ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ಹರಿವಿನ ವೇಗ. ಒಂದು ತಂಡವು AI-ಚಾಲಿತ ಎಂಡ್-ಟು-ಎಂಡ್ ಫ್ಲೋನೊಂದಿಗೆ ಹೊಸ "ಚಂದಾದಾರಿಕೆ ನವೀಕರಣ" ವೈಶಿಷ್ಟ್ಯವನ್ನು ನಿಭಾಯಿಸಿದೆ: ಅವಶ್ಯಕತೆಯ ಅನಿಶ್ಚಿತತೆಗಳನ್ನು ಮುಂಭಾಗದಲ್ಲಿ ಫ್ಲ್ಯಾಗ್ ಮಾಡಲಾಗಿದೆ, ಮೂರು-ಪದರದ ಪರೀಕ್ಷೆಗಳನ್ನು ಕರಡುಮಾಡಲಾಗಿದೆ ಮತ್ತು ರೂಪಾಂತರ-ಮೌಲ್ಯಮಾಪನವನ್ನು CI ಗೆ ಕಟ್ಟಲಾಗಿದೆ. ವೈಶಿಷ್ಟ್ಯವು ಪರೀಕ್ಷಾ ಚಕ್ರವನ್ನು ಕಡಿಮೆಗೊಳಿಸಿತು, ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ 5 ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು, 2 ದಿನಗಳು; ಆದರೆ ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಮಾನವ ಅನುಮೋದನೆಯನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ, ಮತ್ತು ಅವಶ್ಯಕತೆಗಳ ಅನಿಶ್ಚಿತತೆ (ರಿಫ್ರೆಶ್ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ) ಪೂರ್ವ-ಲೈವ್ ಅನ್ನು ಮುಚ್ಚಲಾಯಿತು.

ಪ್ರಕರಣ 2 - ಕೀ ಸೋರಿಕೆಯಿಂದ ಹಿಂತಿರುಗಿ. ಡೆವಲಪರ್ CI YAML ಅನ್ನು ಉತ್ಪಾದಿಸಲು AI ಹೊಂದಿದ್ದರು, ಮತ್ತು AI ನೈಜವಾಗಿ ಕಾಣುವ API ಕೀಯನ್ನು YAML ಗೆ ಉದಾಹರಣೆಯಾಗಿ ಎಂಬೆಡ್ ಮಾಡಿದೆ. "ಭದ್ರತೆ/ಗೌಪ್ಯತೆ ಪೂರ್ವಪರಿಶೀಲನೆ" ಹಂತವು ಇದನ್ನು ಸೆರೆಹಿಡಿಯಿತು; ಕೀಲಿಯನ್ನು ರಹಸ್ಯಗಳ ಉಲ್ಲೇಖಕ್ಕೆ ಪರಿವರ್ತಿಸಲಾಗಿದೆ. ಆಡಿಟ್ ಹಂತವಿಲ್ಲದೆ, ಕೀಲಿಯು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣಕ್ಕೆ ಸೋರಿಕೆಯಾಗುತ್ತದೆ (ಜಿಟ್ ಇತಿಹಾಸ).

ಪ್ರಕರಣ 3 - ಅಧಿಕಾರದ ಮಿತಿ. ತಂಡದ ಸದಸ್ಯರೊಬ್ಬರು ತಾವು ಕಲಿತ IDOR ಪರೀಕ್ಷೆಯನ್ನು ವ್ಯಾಪಾರ ಪಾಲುದಾರರ ಲೈವ್ ಸಿಸ್ಟಮ್‌ಗೆ ಅನ್ವಯಿಸಲು ಬಯಸಿದ್ದರು. QA ನಾಯಕ ನಿಲ್ಲಿಸಿದ್ದಾರೆ: ಲಿಖಿತ ಅನುಮತಿ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವ್ಯಾಪ್ತಿ ಇಲ್ಲದೆ ಮತ್ತೊಂದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು ಕಾನೂನುಬಾಹಿರವಾಗಿದೆ. ಪರೀಕ್ಷೆಯನ್ನು ತಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನಗಳ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಮಾತ್ರ ಮಾಡಲಾಯಿತು, ಅಧಿಕಾರದೊಂದಿಗೆ; ಮುಕ್ತ ಜವಾಬ್ದಾರಿಯುತ ಪಕ್ಷವನ್ನು ಸಂಬಂಧಿತ ತಂಡಕ್ಕೆ ಸೂಚಿಸಲಾಗಿದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• AI ಬಿಡುಗಡೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಂತೆ ಮಾಡುವುದು. "ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದೇ?" ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವುದು. AI ಗೆ ಮತ್ತು ಉತ್ತರವನ್ನು ಸಹಿಯ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ.
• ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು "ಉತ್ತೀರ್ಣ". CI ನಲ್ಲಿ, AI ಪರೀಕ್ಷೆಯನ್ನು ಹಸಿರು ಬಣ್ಣ ಬಳಿಯುವುದು; ತಪ್ಪುಗಳನ್ನು ಮುಚ್ಚಿಡುತ್ತಿದ್ದಾರೆ.
• ವಾಹನಕ್ಕೆ ಗೌಪ್ಯ ಡೇಟಾ/ಕೀಲಿಯನ್ನು ನೀಡುವುದು. ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ ಉತ್ಪಾದನಾ ಡೇಟಾ, ವೈಯಕ್ತಿಕ ಡೇಟಾ ಅಥವಾ API ಕೀಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು.
• ಅನಧಿಕೃತ ಭದ್ರತಾ ಪರೀಕ್ಷೆ. ವ್ಯಾಪ್ತಿ ಮತ್ತು ಅನುಮತಿಯಿಲ್ಲದೆ ಮತ್ತೊಂದು ಸಿಸ್ಟಂನಲ್ಲಿ ಆಕ್ರಮಣಕಾರರ ಪರೀಕ್ಷೆ.
• ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗುತ್ತಿದೆ. ಮಾನವ ಅನುಮೋದನೆಯಿಲ್ಲದೆ AI ಸ್ಕೆಚ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರನ್ ಮಾಡಿ.
• AI ಮೇಲೆ ಆರೋಪವನ್ನು ಹಾಕುವುದು. "AI ಬರೆದರು" ಎಂದು ಹೇಳುವ ಮೂಲಕ ತಪ್ಪಾದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸಮರ್ಥಿಸಿಕೊಳ್ಳುವುದು.

ಸಾರಾಂಶದಲ್ಲಿ

ಎಂಡ್-ಟು-ಎಂಡ್ ಕ್ಯೂಎ ಎನ್ನುವುದು ಅವಶ್ಯಕತೆಗಳಿಂದ ಉತ್ಪಾದನಾ ಟ್ರ್ಯಾಕಿಂಗ್‌ಗೆ ವಿಸ್ತರಿಸುವ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು CI/CD ಒಳಗೆ ಜೀವಿಸುತ್ತದೆ; ಪ್ರತಿ ಹಂತದಲ್ಲಿ, AI ಡ್ರಾಫ್ಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಲಾಗ್ ಅನ್ನು ಸಾರಾಂಶಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲ ಕಾರಣಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಆದರೆ ಗಡಿಗಳು ಬದಲಾಗುವುದಿಲ್ಲ: ಮಾನವರು ಪರೀಕ್ಷಾ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅನುಮೋದನೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಾರೆ; ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ "ಪಾಸ್" ಮಾಡುವ ಅಧಿಕಾರವನ್ನು AI ಗೆ ಎಂದಿಗೂ ನೀಡಲಾಗುವುದಿಲ್ಲ; ಗೌಪ್ಯ ಡೇಟಾ ಮತ್ತು ಕೀಗಳು ವಾಹನವನ್ನು ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ; ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನದ ಮೇಲೆ, ಲಿಖಿತ ದೃಢೀಕರಣ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ, ರಕ್ಷಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾತ್ರ ನಡೆಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಶೋಧನೆಗಳನ್ನು ಜವಾಬ್ದಾರಿಯುತ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯೊಂದಿಗೆ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ. ನೀವು AI ಬಳಸುವಾಗ ಪಾರದರ್ಶಕವಾಗಿರಿ; ಔಟ್‌ಪುಟ್‌ನ ನಿಖರತೆಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ. AI ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ; ಗುಣಮಟ್ಟ ಮತ್ತು ನೈತಿಕತೆಗಾಗಿ ನೀವು ಭರವಸೆ ನೀಡುತ್ತೀರಿ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ನಿಮ್ಮ ಸ್ವಂತ ಪ್ರಾಜೆಕ್ಟ್‌ನಿಂದ ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ "ಎಂಡ್-ಟು-ಎಂಡ್ ಟೆಸ್ಟ್ ಪ್ಲಾನ್" ಟೆಂಪ್ಲೇಟ್‌ನೊಂದಿಗೆ ಬಿಡುಗಡೆ ಮಾಡಲು ಕಲ್ಪನೆಯಿಂದ ಯೋಜನೆಯನ್ನು ಕರಡು ಮಾಡಿ; ಪ್ರತಿ ಹಂತದಲ್ಲಿ AI ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆಯ ಬಿಂದುಗಳ ಪಾತ್ರವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಗುರುತಿಸಿ. ನಂತರ "CI/CD ಪೈಪ್‌ಲೈನ್ ಔಟ್‌ಲೈನ್" ನೊಂದಿಗೆ YAML ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಎಂಬೆಡೆಡ್ ಕೀ/ರಹಸ್ಯ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಲು ಈ YAML ಗೆ "ಭದ್ರತೆ/ಗೌಪ್ಯತೆ ಪೂರ್ವ ಪರಿಶೀಲನೆ" ಅನ್ನು ಅನ್ವಯಿಸಿ. ಅಂತಿಮವಾಗಿ, ನಿಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ಎಲ್ಲಾ "ಮಾನವ ನಿರ್ಧಾರ" ಅಂಶಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಈ ನಿರ್ಧಾರಗಳನ್ನು AI ಗೆ ಏಕೆ ನಿಯೋಜಿಸಲಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಒಂದೇ ವಾಕ್ಯದಲ್ಲಿ ಸಮರ್ಥಿಸಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು ಬಿಡುಗಡೆ ಮತ್ತು ಪರೀಕ್ಷಾ ನಿರ್ಧಾರಗಳನ್ನು ಮಾನವ ಅನುಮೋದನೆಗೆ ಕಾರಣವಾಗಿದ್ದೇನೆ; ನಾನು ಅದನ್ನು AI ಗೆ ಹಸ್ತಾಂತರಿಸಲಿಲ್ಲ.
• [ ] CI/CD ಯಲ್ಲಿ ನಾನು ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ "ಪಾಸ್/ಸರಿಪಡಿಸಲು" AI ಅನುಮತಿಯನ್ನು ನೀಡಿಲ್ಲ.
• [ ] ವಾಹನಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು ನಾನು ಗೌಪ್ಯ ಡೇಟಾ, ವೈಯಕ್ತಿಕ ಡೇಟಾ ಮತ್ತು ಕೀಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ ಮತ್ತು ಮರೆಮಾಚಿದ್ದೇನೆ.
• [ ] ನಾನು ಲಿಖಿತ ದೃಢೀಕರಣ ಮತ್ತು ವ್ಯಾಪ್ತಿಯೊಳಗೆ ನನ್ನ ಸ್ವಂತ ಉತ್ಪನ್ನದ ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸಿದ್ದೇನೆ.
• [ ] ನಾನು ಜವಾಬ್ದಾರಿಯುತ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ತತ್ವದೊಂದಿಗೆ ಕಂಡುಬರುವ ದುರ್ಬಲತೆಗಳನ್ನು ತಿಳಿಸಿದ್ದೇನೆ.
• [ ] ನಾನು AI ಅನ್ನು ಬಳಸಿದ್ದೇನೆ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನ ನಿಖರತೆಗೆ ನಾನೇ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತೇನೆ ಎಂದು ನಾನು ಪಾರದರ್ಶಕವಾಗಿ ಹೇಳಿದ್ದೇನೆ.

ಮಾಡ್ಯೂಲ್ ಪರೀಕ್ಷೆ

1. QA ಸಂದರ್ಭದಲ್ಲಿ 'ಸುಳ್ಳು ಪಾಸ್' ಅನ್ನು ಹೇಗೆ ಅತ್ಯಂತ ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ?

• ಎ) ಪರೀಕ್ಷೆಯು ಹಸಿರು ಬಣ್ಣಕ್ಕೆ ತಿರುಗಿದರೂ, ಅದು ವಾಸ್ತವವಾಗಿ ಯಾವುದೇ ನಡವಳಿಕೆಯನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ; ✔ ಕೋಡ್ ದೋಷಪೂರಿತವಾಗಿದ್ದರೂ ಸಹ ಕೆಂಪು ಬಣ್ಣಕ್ಕೆ ತಿರುಗುವುದಿಲ್ಲ
• ಬಿ) ಪರೀಕ್ಷೆಯು ತುಂಬಾ ನಿಧಾನವಾಗಿ ನಡೆಯುತ್ತದೆ ಮತ್ತು ಸಮಯ ಮೀರುತ್ತದೆ.
• ಸಿ) ಪರೀಕ್ಷೆಯು ನಿಜವಾದ ದೋಷವನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಂಪು ಬಣ್ಣಕ್ಕೆ ತಿರುಗುತ್ತದೆ
• ಡಿ) ಪರೀಕ್ಷೆಯು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಮಾತ್ರ ನಡೆಯುತ್ತದೆ

ವಿವರಣೆ: ಪರೀಕ್ಷೆಯು 'ಪಾಸ್' ಎಂದು ಹೇಳಿದಾಗ ಹುಸಿ-ಪಾಸ್ ಆಗಿದೆ ಆದರೆ ವಾಸ್ತವವಾಗಿ ಅರ್ಥಪೂರ್ಣವಾದ ಯಾವುದನ್ನೂ ದೃಢೀಕರಿಸುವುದಿಲ್ಲ; ಪರೀಕ್ಷೆಯು ಹಸಿರು ಬಣ್ಣದ್ದಾಗಿದೆ, ಆದರೆ ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷಪೂರಿತವಾಗಿದ್ದರೂ, ಅದು ಅದನ್ನು ಹಿಡಿಯುವುದಿಲ್ಲ. ಇದು QA ಯಲ್ಲಿ AI ಯ ಮೊದಲ ಅಪಾಯವಾಗಿದೆ ಏಕೆಂದರೆ AI ಅಚ್ಚುಕಟ್ಟಾಗಿ ಕಾಣುವ ಆದರೆ ಟೊಳ್ಳಾದ ಪರೀಕ್ಷೆಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

2. ಪರೀಕ್ಷೆ ಮತ್ತು QA ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯ ಅತ್ಯಂತ ನಿಖರವಾದ ಸ್ಥಾನ ಯಾವುದು?

• ಎ) ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ಮಾನವ ಅನುಮೋದನೆಯಿಲ್ಲದೆ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು
• ಬಿ) ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ಕರಡುಗಳು ಮತ್ತು ಆಲೋಚನೆಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಸಹಾಯಕ; 'ಇದು ಪ್ರಕಟಣೆಗೆ ಸಿದ್ಧವಾಗಿದೆಯೇ' ಎಂಬ ನಿರ್ಧಾರ ಮತ್ತು ಜವಾಬ್ದಾರಿಯು ತಜ್ಞರದ್ದಾಗಿದೆ ✔
• ಸಿ) ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ಪಠ್ಯವನ್ನು ಮಾತ್ರ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಕೋಡ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
• D) ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ಯಾವಾಗಲೂ ಮಾನವರಿಗಿಂತ ಸರಿಯಾದ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಮರ್ಶೆಯು ಅನಗತ್ಯವಾಗಿರುತ್ತದೆ

ವಿವರಣೆ: ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ಪರೀಕ್ಷಾ ಸಹಾಯಕ, ಡ್ರಾಫ್ಟ್ ಜನರೇಟರ್ ಮತ್ತು ಐಡಿಯಾ ಮಲ್ಟಿಪ್ಲೈಯರ್ ಆಗಿದೆ; ಪರೀಕ್ಷಾ ಸನ್ನಿವೇಶಗಳು, ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕೋಡ್ ಮತ್ತು ವರದಿ ಕರಡುಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, 'ಈ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಕಟಣೆಗೆ ಸಿದ್ಧವಾಗಿದೆಯೇ' ಅಥವಾ 'ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿದೆಯೇ' ಎಂಬಂತಹ ಗುಣಮಟ್ಟದ ನಿರ್ಧಾರಗಳ ಜವಾಬ್ದಾರಿ ಮತ್ತು ಅಂತಿಮ ಅನುಮೋದನೆಯು ಸಮರ್ಥ ತಜ್ಞರಿಗೆ ಸೇರಿದೆ.

3. ಥ್ರೆಶೋಲ್ಡ್ ಮೌಲ್ಯಗಳಲ್ಲಿ ದೋಷಗಳು ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತವೆ ಎಂಬ ಅಂಶದ ಆಧಾರದ ಮೇಲೆ, 18 ವಯಸ್ಸಿನ ಮಿತಿಗಾಗಿ 17, 18 ಮತ್ತು 19 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲು ಯಾವ ಪರೀಕ್ಷಾ ವಿನ್ಯಾಸ ತಂತ್ರವಾಗಿದೆ?

• ಎ) ರಾಜ್ಯ ಪರಿವರ್ತನೆ ಪರೀಕ್ಷೆ
• ಬಿ) ನಿರ್ಧಾರ ಕೋಷ್ಟಕ
• ಸಿ) ಗಡಿ ಮೌಲ್ಯ ವಿಶ್ಲೇಷಣೆ ✔
• ಡಿ) ಪರಿಶೋಧನಾ ಪರೀಕ್ಷೆ

ವಿವರಣೆ: ಗಡಿ ಮೌಲ್ಯ ವಿಶ್ಲೇಷಣೆಯು ಗಡಿಗಳಲ್ಲಿ ಮತ್ತು ಪರೀಕ್ಷೆಗಳ ಮಿತಿ ಮೌಲ್ಯಗಳಲ್ಲಿ (ಕೇವಲ ಕೆಳಗೆ, ಸ್ವಲ್ಪ ಮೇಲೆ ಮತ್ತು ಮಿತಿಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು) ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಭವಿಸುವ ಅವಲೋಕನವನ್ನು ಆಧರಿಸಿದೆ. ಇದು ಸಮಾನತೆಯ ತರಗತಿಗಳನ್ನು ಪೂರೈಸುವ ಪ್ರಬಲ ತಂತ್ರವಾಗಿದೆ.

4. ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯೊಂದಿಗೆ ಉತ್ಪಾದಿಸಲಾದ UI ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಕೋಡ್‌ನಲ್ಲಿ ಸೂಕ್ಷ್ಮತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅಂಶ ಆಯ್ಕೆಯಲ್ಲಿ ಯಾವ ವಿಧಾನವನ್ನು ಆದ್ಯತೆ ನೀಡಬೇಕು?

• ಎ) ಸಾಧ್ಯವಾದಷ್ಟು ಉದ್ದವಾದ XPath ಮಾರ್ಗವನ್ನು ಬಳಸುವುದು
• ಬಿ) ಪರದೆಯ ಮೇಲೆ ಅದರ ಪಿಕ್ಸೆಲ್ ಸ್ಥಾನದ ಪ್ರಕಾರ ಅಂಶವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು
• C) CSS ವರ್ಗದ ಹೆಸರುಗಳ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸುವುದು
• ಡಿ) ಪರೀಕ್ಷೆಗಾಗಿ ಸೇರಿಸಲಾದ ಸ್ಥಿರ ಗುಣಲಕ್ಷಣಗಳನ್ನು (ಡೇಟಾ-ಟೆಸ್ಟಿಡ್) ಬಳಸುವುದು ✔

ವಿವರಣೆ: ಉದ್ದವಾದ XPath ಮಾರ್ಗಗಳು ಮತ್ತು CSS ವರ್ಗದ ಹೆಸರುಗಳು ಪುಟದ ರಚನೆ ಮತ್ತು ವಿನ್ಯಾಸದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿವೆ; ಸಣ್ಣದೊಂದು ಇಂಟರ್ಫೇಸ್ ಬದಲಾವಣೆಯಲ್ಲಿ ಇದು ಒಡೆಯುತ್ತದೆ. ಪರೀಕ್ಷೆಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಸೇರಿಸಲಾದ ಸ್ಥಿರ ಗುಣಲಕ್ಷಣಗಳು (ಉದಾ. ಡೇಟಾ-ಟೆಸ್ಟಿಡ್) ವಿನ್ಯಾಸ ಬದಲಾವಣೆಗಳಿಂದ ಪ್ರಭಾವಿತವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ದೃಢಗೊಳಿಸುತ್ತವೆ.

5. HTTP ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು API ಪರೀಕ್ಷೆಯು ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ (ಉದಾ. 200)?

• ಎ) ಸರಿಯಾದ ಸ್ಥಿತಿ ಕೋಡ್ ಹೊಂದಿರುವ ದೇಹದ ಡೇಟಾ ದೋಷಪೂರಿತವಾಗಬಹುದು ಮತ್ತು ಸ್ಥಿತಿ ಪರಿಶೀಲನೆ ಮಾತ್ರ ಇದನ್ನು ಹಿಡಿಯುವುದಿಲ್ಲ (ಹುಸಿ-ನಂಬಿಕೆ) ✔
• ಬಿ) ಏಕೆಂದರೆ ಸ್ಥಿತಿ ಕೋಡ್‌ಗಳು API ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರುವುದಿಲ್ಲ
• ಸಿ) ಏಕೆಂದರೆ ಸ್ಥಿತಿ ಕೋಡ್ ಪರಿಶೀಲನೆಯು ಪರೀಕ್ಷೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ
• D) ಏಕೆಂದರೆ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು API ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಹಿಂತಿರುಗಿಸಲಾಗುವುದಿಲ್ಲ

ವಿವರಣೆ: ಸರ್ವರ್ ಸರಿಯಾದ ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸಿದಾಗ, ಅದು ದೇಹದಲ್ಲಿ ದೋಷಪೂರಿತ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು (ತಪ್ಪಾದ ಪ್ರಕಾರ, ಕಾಣೆಯಾದ ಕ್ಷೇತ್ರ, ತಪ್ಪಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಮೌಲ್ಯ). ಪರಿಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ನೋಡುವ ಪರೀಕ್ಷೆಯು ಇದನ್ನು ನೋಡುವುದಿಲ್ಲ ಮತ್ತು ಸುಳ್ಳು ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಸ್ಕೀಮಾ/ಕಾಂಟ್ರಾಕ್ಟ್ ಮತ್ತು ವ್ಯವಹಾರ ನಿಯಮ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಕೂಡ ಸೇರಿಸಬೇಕು.

6. ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಮುದ್ರಿಸುವಾಗ AI ಗೆ 'ಸ್ವೀಕಾರ ನಿಯಮದ ಪ್ರಕಾರ ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, ಕಾರ್ಯದ ಪ್ರಸ್ತುತ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬೇಡಿ' ಎಂದು ಹೇಳುವುದು ಏಕೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ?

• ಎ) ಏಕೆಂದರೆ ಹಸ್ತಚಾಲಿತ ಲೆಕ್ಕಾಚಾರವು ಪರೀಕ್ಷೆಗಳನ್ನು ವೇಗವಾಗಿ ನಡೆಸುತ್ತದೆ
• ಬಿ) ಇಲ್ಲದಿದ್ದರೆ ಪರೀಕ್ಷೆಯು ಕೋಡ್‌ನ ಪ್ರಸ್ತುತ (ಬಹುಶಃ ದೋಷಯುಕ್ತ) ನಡವಳಿಕೆಯನ್ನು 'ಸರಿಯಾದ' ಎಂದು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ದೋಷವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ ✔
• ಸಿ) ಏಕೆಂದರೆ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯು ದಶಮಾಂಶ ಸಂಖ್ಯೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕಲು ಸಾಧ್ಯವಿಲ್ಲ
• ಡಿ) ಏಕೆಂದರೆ ಸ್ವೀಕಾರ ನಿಯಮಗಳನ್ನು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಎಂದಿಗೂ ಬಳಸಲಾಗುವುದಿಲ್ಲ

ವಿವರಣೆ: ಪರೀಕ್ಷೆಯ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯದ ಔಟ್‌ಪುಟ್‌ನಿಂದ AI ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯವನ್ನು ಪಡೆದರೆ, ಅದು ಕಾರ್ಯವು ದೋಷಪೂರಿತವಾಗಿದ್ದರೂ ಪರೀಕ್ಷೆಯನ್ನು 'ಪಾಸ್' ಮಾಡುತ್ತದೆ; ಅಂದರೆ, ಕೋಡ್ ಉತ್ಪಾದಿಸುವ ಯಾವುದೇ, ಪರೀಕ್ಷೆಯು ನಿಜವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ಸ್ವೀಕಾರ ನಿಯಮದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದರಿಂದ ಪರೀಕ್ಷೆಯು ನಿಯಮಕ್ಕೆ ಗೇಟ್‌ಕೀಪರ್ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಕೋಡ್‌ನ ಕನ್ನಡಿಯಲ್ಲ.

7. ಕೆಳಗಿನವುಗಳಲ್ಲಿ ಯಾವುದು ಉತ್ತಮ ದೋಷ ವರದಿಯ ಅತ್ಯಂತ ವಿಶಿಷ್ಟ ಲಕ್ಷಣವಾಗಿದೆ?

• ಎ) ಸಾಧ್ಯವಾದಷ್ಟು ಉದ್ದ ಮತ್ತು ತಾಂತ್ರಿಕವಾಗಿರಲು
• ಬಿ) ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯಿಂದ ಬರೆಯಲಾಗಿದೆ
• ಸಿ) ಡೆವಲಪರ್ ಸ್ವತಂತ್ರವಾಗಿ ಅನುಸರಿಸಬಹುದಾದ ಮತ್ತು ದೋಷವನ್ನು ಉಂಟುಮಾಡುವ ನಿರ್ಣಾಯಕ ಪುನರುತ್ಪಾದನೆಯ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ✔
• ಡಿ) ಇದು ಕೇವಲ ಸ್ಕ್ರೀನ್‌ಶಾಟ್

ವಿವರಣೆ: ಬಗ್ ವರದಿಯ ನೈಜ ಮೌಲ್ಯವೆಂದರೆ ಡೆವಲಪರ್ ನಿಮ್ಮ ಸಹಾಯವಿಲ್ಲದೆ ದೋಷವನ್ನು ಪುನರುತ್ಪಾದಿಸಬಹುದು. ಮೊದಲಿನಿಂದ ನಿರ್ಣಾಯಕ, ಪತ್ತೆಹಚ್ಚಬಹುದಾದ ಪುನರುತ್ಪಾದನೆಯ ಹಂತಗಳು ಇದನ್ನು ಖಚಿತಪಡಿಸುತ್ತವೆ; ಈ ಹಂತಗಳು ತಪ್ಪಿದಲ್ಲಿ, ವರದಿಯು 'ಉತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ' ಎಂದು ಮುಚ್ಚುತ್ತದೆ.

8. ಮುಖಪುಟದಲ್ಲಿ ಕಂಪನಿಯ ಹೆಸರನ್ನು ತಪ್ಪಾಗಿ ಬರೆಯುವ ದೋಷದಲ್ಲಿ ತೀವ್ರತೆ ಮತ್ತು ಆದ್ಯತೆಯ ನಡುವಿನ ಸಂಬಂಧಕ್ಕೆ ಅತ್ಯಂತ ನಿಖರವಾದ ಅಭಿವ್ಯಕ್ತಿ ಯಾವುದು?

• ಎ) ತೀವ್ರತೆ ಮತ್ತು ಆದ್ಯತೆಯು ಯಾವಾಗಲೂ ಒಂದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು
• ಬಿ) ಈ ದೋಷದ ತೀವ್ರತೆ ಮತ್ತು ಆದ್ಯತೆ ಎರಡೂ ಖಂಡಿತವಾಗಿಯೂ ಕಡಿಮೆ
• ಸಿ) ತೀವ್ರತೆ ಮತ್ತು ಆದ್ಯತೆಯು ಒಂದೇ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ, ಒಂದು ಲೇಬಲ್ ಸಾಕು
• ಡಿ) ತಾಂತ್ರಿಕ ತೀವ್ರತೆ ಕಡಿಮೆ ಇರಬಹುದು ಆದರೆ ವ್ಯಾಪಾರದ ಆದ್ಯತೆ (ಖ್ಯಾತಿ) ಹೆಚ್ಚಿರಬಹುದು; The two are evaluated differently ✔

ವಿವರಣೆ: ತೀವ್ರತೆಯು ದೋಷದ ತಾಂತ್ರಿಕ ಪರಿಣಾಮವಾಗಿದೆ (ಮುದ್ರಣ ದೋಷ ತಾಂತ್ರಿಕವಾಗಿ ಕಡಿಮೆ), ಆದ್ಯತೆಯು ಅದನ್ನು ಎಷ್ಟು ತುರ್ತಾಗಿ ಸರಿಪಡಿಸಬೇಕು (ಹೆಚ್ಚು ಏಕೆಂದರೆ ಇದು ಪ್ರತಿ ಸಂದರ್ಶಕನು ನೋಡುವ ಖ್ಯಾತಿಯ ಅಂಶವಾಗಿದೆ). The two don't always go in the same direction; ಈ ಉದಾಹರಣೆಯು ಕಡಿಮೆ ತೀವ್ರತೆ-ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ.

9. 90% ಲೈನ್ ಕವರೇಜ್ ಹೊಂದಿರುವ ಪರೀಕ್ಷಾ ಸೂಟ್‌ನ ಅತ್ಯಂತ ನಿಖರವಾದ ವ್ಯಾಖ್ಯಾನ ಯಾವುದು?

• ಎ) ಸಾಲುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ ಆದರೆ ಅವು ಸರಿಯಾಗಿ ವರ್ತಿಸುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ; ✔ high coverage can give false confidence
• ಬಿ) 90% ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷ ಮುಕ್ತವಾಗಿದೆ ಎಂದು ನಿರ್ಣಾಯಕವಾಗಿ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ
• ಸಿ) ಇದು ಅತ್ಯುತ್ತಮ ಪರೀಕ್ಷಾ ಗುಣಮಟ್ಟದ ನಿರ್ಣಾಯಕ ಅಳತೆಯಾಗಿದೆ.
• ಡಿ) ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ

ವಿವರಣೆ: ಸಾಲು ವ್ಯಾಪ್ತಿಯು ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ; ಇದು ಸರಿಯಾದ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ದೃಢವಾದ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಸಹ, 90% ವ್ಯಾಪ್ತಿಯನ್ನು ಸಾಧಿಸಬಹುದು. ವ್ಯಾಪ್ತಿ 'ಎಲ್ಲಿ ನೋಡಿಲ್ಲ' ನಕ್ಷೆ, 'ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ' ಭರವಸೆ ಅಲ್ಲ; ನಿಜವಾದ ರಕ್ಷಣೆಯನ್ನು ರೂಪಾಂತರ ಪರೀಕ್ಷೆಯಿಂದ ಅಳೆಯಲಾಗುತ್ತದೆ.

10. ಅಪಾಯ-ಆಧಾರಿತ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಸೀಮಿತ ಪರೀಕ್ಷಾ ಪ್ರಯತ್ನವನ್ನು ನಿರ್ದೇಶಿಸಲು ವೈಶಿಷ್ಟ್ಯದ ಅಪಾಯವನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕಲಾಗುತ್ತದೆ?

• A) Only by number of lines of code
• ಬಿ) ವೈಫಲ್ಯದ ಸಂಭವನೀಯತೆ ಮತ್ತು ಅದು ಮುರಿದಾಗ ಉಂಟಾಗುವ ಪರಿಣಾಮವನ್ನು ಗುಣಿಸುವ ಮೂಲಕ ✔
• ಸಿ) ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಕ್ರಮದಲ್ಲಿ ಮಾತ್ರ
• ಡಿ) ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ಸುಲಭವಾದ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಮಾತ್ರ ಆದ್ಯತೆ ನೀಡುವುದು

ವಿವರಣೆ: ಅಪಾಯ-ಆಧಾರಿತ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಅಪಾಯವನ್ನು ಸಂಭವನೀಯತೆ = ಸಂಭವನೀಯತೆ (ವಿಘಟನೆಯ ಸಾಧ್ಯತೆ) × ಪರಿಣಾಮ (ಒಡೆದರೆ ಹಾನಿ) ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ ಡೊಮೇನ್‌ಗಳು (ಪಾವತಿ, ದೃಢೀಕರಣ) ಅತ್ಯಂತ ತೀವ್ರವಾದ ಪರೀಕ್ಷೆಗೆ ಅರ್ಹವಾಗಿವೆ, ಆದರೆ ಕಡಿಮೆ × ಕಡಿಮೆ ಡೊಮೇನ್‌ಗಳು ಬೆಳಕಿನ ಪರೀಕ್ಷೆಯನ್ನು ಪಡೆಯುತ್ತವೆ.

11. ಕೋಡ್ ಬದಲಾಗದಿದ್ದರೂ ಸಹ ಕೆಲವೊಮ್ಮೆ ಉತ್ತೀರ್ಣರಾಗುವ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ವಿಫಲಗೊಳ್ಳುವ (ಬ್ರಿಟಲ್/ಫ್ಲೇಕಿ) ಪರೀಕ್ಷೆಗೆ ಮರುಪ್ರಯತ್ನವನ್ನು ಸೇರಿಸುವ ಮುಖ್ಯ ಅಪಾಯ ಏನು?

• A) Shortening the running time of the test
• B) Decreases the coverage percentage
• ಸಿ) ನಿಜವಾದ ಏಕಕಾಲಿಕ ದೋಷ ಅಥವಾ ಮೂಲ ಕಾರಣವನ್ನು ಮುಚ್ಚಿಹಾಕುವುದು ಮತ್ತು ರೋಗಲಕ್ಷಣವನ್ನು ನಿಗ್ರಹಿಸುವುದು ✔
• D) Changing the name of the test

ವಿವರಣೆ: ಮರುಪ್ರಯತ್ನವು ರೋಗನಿರ್ಣಯದ ಸಾಧನವಾಗಿದೆ, ಚಿಕಿತ್ಸೆಯಲ್ಲ. ಅನಿರ್ದಿಷ್ಟತೆ ಸಾಮಾನ್ಯವಾಗಿ ನಿಜವಾದ ಜನಾಂಗದ ಸ್ಥಿತಿ ಅಥವಾ ವ್ಯಸನದಿಂದ ಬರುತ್ತದೆ; ಮರುಪ್ರಯತ್ನದ ಮೂಲಕ ಪರೀಕ್ಷೆಯನ್ನು 'ಪಾಸ್' ಮಾಡುವುದರಿಂದ ಈ ನೈಜ ದೋಷವನ್ನು ಮುಚ್ಚುತ್ತದೆ ಮತ್ತು ಲೈವ್‌ನಲ್ಲಿ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. The root cause must be found first.

12. ಪರೀಕ್ಷಾ ಸೂಟ್ ನಿಜವಾಗಿಯೂ ರಕ್ಷಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಅಳೆಯುವ ಅತ್ಯಂತ ಪ್ರಾಮಾಣಿಕ ವಿಧಾನವಾದ ರೂಪಾಂತರ ಪರೀಕ್ಷೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ?

• A) By measuring the running speed of the tests
• ಬಿ) ಕೋಡ್‌ನ ಎಷ್ಟು ಸಾಲುಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ ಎಂದು ಎಣಿಸುವ ಮೂಲಕ
• C) By running the tests in different orders
• ಡಿ) ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕೋಡ್‌ನಲ್ಲಿ ಸಣ್ಣ ವಿರಾಮಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ಮತ್ತು ಪರೀಕ್ಷೆಗಳು ಅವುಗಳನ್ನು ಹಿಡಿಯುತ್ತವೆಯೇ ಎಂದು ಅಳೆಯುವ ಮೂಲಕ ✔

ವಿವರಣೆ: ರೂಪಾಂತರ ಪರೀಕ್ಷೆಯು ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ಸಣ್ಣ ಉದ್ದೇಶಪೂರ್ವಕ ವಿರೂಪಗಳನ್ನು (ಮ್ಯುಟೇಶನ್) ಉತ್ಪಾದಿಸುತ್ತದೆ; ಉತ್ತಮ ಪರೀಕ್ಷಾ ಸೂಟ್ ಈ ವಿರೂಪಗಳನ್ನು ಹಿಡಿಯಬೇಕು ಮತ್ತು ಕೆಂಪು ಬಣ್ಣಕ್ಕೆ ತಿರುಗಬೇಕು. ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳದ (ಬದುಕುಳಿದ) ರೂಪಾಂತರಗಳು ಪರೀಕ್ಷೆಗಳು ಆ ನಡವಳಿಕೆಯನ್ನು ಸಂರಕ್ಷಿಸುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ರೂಪಾಂತರ ಸ್ಕೋರ್ ಶೇಕಡಾವಾರು ವ್ಯಾಪ್ತಿಗಿಂತ ಗುಣಮಟ್ಟದ ಹೆಚ್ಚು ಪ್ರಾಮಾಣಿಕ ಅಳತೆಯಾಗಿದೆ.

13. ಭದ್ರತಾ ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುವಾಗ ಅನುಸರಿಸಬೇಕಾದ ಮುಖ್ಯ ಮಿತಿ ಯಾವುದು (ಉದಾ. ದೃಢೀಕರಣ/IDOR ಪರೀಕ್ಷೆಗಳು)?

• ಎ) ರಕ್ಷಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಇದು ತನ್ನ ಸ್ವಂತ ಉತ್ಪನ್ನದ ಮೇಲೆ, ಲಿಖಿತ ಅಧಿಕಾರ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿತ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಮಾತ್ರ ಮಾಡಬೇಕು ✔
• ಬಿ) ಆಸಕ್ತಿಯ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಗೆ ಇದನ್ನು ಮುಕ್ತವಾಗಿ ಅನ್ವಯಿಸಬಹುದು
• ಸಿ) ಅನುಮತಿಯಿಲ್ಲದೆ ವ್ಯಾಪಾರ ಪಾಲುದಾರರ ಲೈವ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು
• ಡಿ) ಯಾವುದೇ ದೋಷಗಳು ಕಂಡುಬಂದಲ್ಲಿ ತಕ್ಷಣವೇ ಸಾರ್ವಜನಿಕವಾಗಿ ಪ್ರಕಟಿಸಬೇಕು.

ವಿವರಣೆ: ಈ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕಲಿತ ಸುರಕ್ಷತಾ ಪರೀಕ್ಷೆಗಳು ನಿಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನವನ್ನು ರಕ್ಷಣಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ಲಿಖಿತ ದೃಢೀಕರಣ ಮತ್ತು ವ್ಯಾಖ್ಯಾನಿತ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಪರೀಕ್ಷಿಸಲು ಮಾತ್ರ. ಅನುಮತಿಯಿಲ್ಲದೆ ಬೇರೊಬ್ಬರ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದು ಅಥವಾ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿರುವ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುವುದು ಅನೈತಿಕ ಮತ್ತು ಕಾನೂನುಬಾಹಿರವಾಗಿದೆ; ಕಂಡುಬರುವ ಯಾವುದೇ ದುರ್ಬಲತೆಗಳನ್ನು ಜವಾಬ್ದಾರಿಯುತ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ಮೂಲಕ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ.

14. CI/CD ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ AI ಗೆ ಯಾವ ಅಧಿಕಾರವನ್ನು ನೀಡಬಾರದು?

• A) Summarizing failed test logs
• ಬಿ) ವಿಫಲವಾದ (ಕೆಂಪು) ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ 'ಉತ್ತೀರ್ಣ' ಮಾಡುವ ಅಥವಾ ಹಸಿರು ಬಣ್ಣ ಬಳಿಯುವ ಅಧಿಕಾರ ✔
• C) Suggesting a test code draft
• D) Pipeline YAML file drafting

ವಿವರಣೆ: AI ಪರೀಕ್ಷಾ ಕೋಡ್ ಔಟ್‌ಲೈನ್, ಪೈಪ್‌ಲೈನ್ YAML ಮತ್ತು CI/CD ಯಲ್ಲಿ ಲಾಗ್ ಸಾರಾಂಶವನ್ನು ಉತ್ಪಾದಿಸಬಹುದು; ಆದಾಗ್ಯೂ, ವಿಫಲವಾದ ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ 'ಪಾಸ್/ಫಿಕ್ಸ್' ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಎಂದಿಗೂ ನೀಡಬಾರದು. ಇದು ಪರೀಕ್ಷೆಯ ಉದ್ದೇಶವನ್ನು ಸೋಲಿಸುತ್ತದೆ ಮತ್ತು ದೋಷಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುಚ್ಚುತ್ತದೆ. ಪರೀಕ್ಷೆಯನ್ನು ಹಸಿರು ಬಣ್ಣ ಮಾಡುವುದು ವ್ಯಕ್ತಿಯ ಪ್ರಜ್ಞಾಪೂರ್ವಕ ಮತ್ತು ತಾರ್ಕಿಕ ನಿರ್ಧಾರವಾಗಿರಬೇಕು.