فائدہ:
- 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 مینوفیکچرنگ کی خرابی سے ریگریشن کیس تجویز کرتا ہے۔
ٹپ: AI کو CI/CD میں ایک پرت کے طور پر سیٹ اپ کریں جو "ٹیسٹ لکھنے اور فیصلے کرنے" کے بجائے "انسانی نظرثانی شدہ مسودوں کو تیز کرتا ہے"۔ خود بخود پیدا ہونے والے ٹیسٹوں کو انسانی جائزہ اور منظوری کے بغیر پائپ لائن میں داخل نہیں ہونا چاہئے۔
CI/CD میں AI: کہاں ہاں، کہاں نہیں۔
اسٹیج
AI فٹ
انسان ضروری ہے
ٹیسٹ کوڈ ڈرافٹ
جی ہاں
نظر ثانی + اتپریورتن
پائپ لائن YAML ڈرافٹ
جی ہاں
تصدیق + خفیہ کلید کی جانچ
ناکام لاگ کا خلاصہ
جی ہاں
جڑ کی تصدیق
نازک ٹیسٹ کی تشخیص
جی ہاں
مستقل حل کا فیصلہ
"کیا کوئی ورژن ہو سکتا ہے؟"
نہیں
ماہرانہ فیصلہ اور ذمہ داری
خود بخود ٹیسٹ "پاس" کریں۔
کبھی نہیں
-
احتیاط: AI کو کبھی بھی CI/CD میں "فیلنگ ٹیسٹ پاس کرنے کے لیے اسے ٹھیک کریں" جیسا مینڈیٹ نہ دیں۔ یہ جانچ کے مقصد کو ناکام بناتا ہے اور خود بخود غلطیوں کو چھپا دیتا ہے۔ AI غلطی کی وضاحت کر سکتا ہے، اصلاح کا مشورہ دے سکتا ہے۔ لیکن "ٹیسٹ کو گرین پینٹ کرنا" ایک شخص کا شعوری، معقول فیصلہ ہونا چاہیے۔
پرائیویسی، ڈیٹا اور سیکیورٹی: ناقابل تغیر حدود
رازداری ٹیسٹ کے ماحول میں، اصل کسٹمر ڈیٹا، پروڈکشن ڈیٹا بیس کاپیاں، API کیز اور اندرونی نظام کی معلومات حساس ہوتی ہیں۔ یہ عوامی AI ٹولز کو نہ دیں۔ ذاتی ڈیٹا KVKK اور اسی طرح کے ضوابط کے تابع ہے۔ ماسک لاگ اور اسکرین شاٹس۔ جہاں بھی ممکن ہو مصنوعی (افسانہ) ٹیسٹ ڈیٹا استعمال کریں۔
سیکیورٹی ٹیسٹنگ - دفاعی اور مجاز۔ اس ماڈیول میں سیکھے گئے سیکیورٹی ٹیسٹ (اجازت/آئی ڈی او آر ٹیسٹ، فائل اپ لوڈ کی حدیں، ان پٹ توثیق) صرف تحریری اجازت اور متعین دائرہ کار کے اندر آپ کی اپنی مصنوعات کی جانچ کے لیے ہیں۔ بغیر اجازت کے کسی اور کے سسٹم تک رسائی حاصل کرنے کے لیے AI کا استعمال کرنا، حقیقی کمزوریوں کو ہتھیار بنانا، یا دائرہ کار سے باہر جانچ کرنا غیر اخلاقی اور غیر قانونی ہے۔ جب آپ کو کوئی حفاظتی خطرہ نظر آتا ہے، تو ذمہ دارانہ انکشاف کے اصول کی تعمیل کریں — خطرے کو خفیہ رکھتے ہوئے اور متعلقہ فریق کو اس کی اطلاع دیں تاکہ اسے ٹھیک کیا جا سکے۔
اخلاقیات اور شفافیت۔ AI کے ذریعہ تیار کردہ ٹیسٹوں کو اپنے کام کے طور پر پیش نہ کریں۔ یہ بتانا کہ آپ ٹیم کے اندر AI استعمال کر رہے ہیں شفافیت ہے۔ آپ AI سے تیار کردہ آؤٹ پٹ کی غلطی کے ذمہ دار ہیں - "AI نے اسے لکھا" کوئی عذر نہیں ہے۔
کمزور فوری / مضبوط اشارہ
کمزور: "CI کے لیے ٹیسٹ پائپ لائن سیٹ اپ کریں۔"
مضبوط: "GitHub ایکشنز کے لیے CI ورک فلو YAML کا مسودہ تیار کریں: ہر PR پر یونٹ + API ٹیسٹ چلائیں، کوریج رپورٹ بنائیں، میوٹیشن ٹیسٹنگ (اسٹرائیکر) ہفتہ وار چلائیں۔ راز کو کوڈ میں ایمبیڈ نہ کریں؛ صرف راز کا حوالہ استعمال کریں۔ اگر ٹیسٹ سرخ ہوں تو انضمام کو روکیں۔ یہ ایک ڈرافٹ اور ایڈٹ مینجمنٹ کا اہم مرحلہ ہے؛ NDOOT کے انتظام کے اہم قدم کا جائزہ لیں گے۔ ایک خودکار ٹیسٹنگ 'فکس' یا 'منتقل' مرحلہ شامل کریں۔"
طاقتور فوری؛ یہ رازداری، انسانی جائزے، اور "کوئی خودکار جانچ نہیں" پر حدود عائد کرتا ہے۔
چار کاپی کرنے کے قابل ٹیمپلیٹس
1) اینڈ ٹو اینڈ ٹیسٹنگ پلان:
آپ کا کردار: سینئر QA لیڈر۔ مندرجہ ذیل خصوصیت کے لیے جاری کرنے کے لیے آئیڈیا سے لے کر اینڈ ٹو اینڈ ٹیسٹنگ پلان کا مسودہ تیار کریں: [خصوصیت + قبولیت کا معیار]۔مرحلے: ضروریات کا تجزیہ (غیر یقینی صورتحال)، ٹیسٹ ڈیزائن، آٹومیشن لیئرز (یونٹ/API/UI)، CI/CD انضمام، ریلیز کے فیصلے کا معیار، پروڈکشن ٹریکنگ۔ ہر مرحلے پر AI اور HUMAN منظوری پوائنٹس کے کردار کو الگ الگ بیان کریں۔
2) CI/CD پائپ لائن کا خاکہ:
CI YAML ڈرافٹ برائے [GitHub Actions/GitLab CI/Azure Pipelines]:- یونٹ + 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 پر الزام لگانا۔ "AI نے لکھا" کہہ کر غلط آؤٹ پٹ کا دفاع کرنا۔
خلاصہ میں
اینڈ ٹو اینڈ کیو اے ایک ایسا عمل ہے جو ضروریات سے لے کر پروڈکشن ٹریکنگ تک پھیلا ہوا ہے اور CI/CD کے اندر رہتا ہے۔ ہر مرحلے پر، AI ڈرافٹ تیار کرتا ہے، لاگ کا خلاصہ کرتا ہے، اور بنیادی وجوہات تجویز کرتا ہے۔ لیکن حدود متغیر ہیں: انسان آزمائشی فیصلے کرتے ہیں اور منظوری جاری کرتے ہیں۔ AI کو کبھی بھی خود بخود ٹیسٹ پاس کرنے کا اختیار نہیں دیا جاتا ہے۔ خفیہ ڈیٹا اور چابیاں گاڑی میں داخل نہیں ہوتی ہیں۔ حفاظتی جانچ صرف آپ کی اپنی مصنوعات پر، تحریری اجازت اور متعین دائرہ کار کے اندر، دفاعی مقاصد کے لیے کی جاتی ہے، اور نتائج کو ذمہ دارانہ انکشاف کے ساتھ رپورٹ کیا جاتا ہے۔ جب آپ AI استعمال کرتے ہیں تو شفاف رہیں۔ آپ آؤٹ پٹ کی درستگی کے ذمہ دار ہیں۔ AI تیز کرتا ہے؛ آپ معیار اور اخلاقیات کی ضمانت دیتے ہیں۔
درخواست کا کام
آپ کے اپنے پروجیکٹ کی ایک خصوصیت کے لیے "آخر سے آخر تک ٹیسٹ پلان" ٹیمپلیٹ کے ساتھ جاری کرنے کے لیے آئیڈیا سے ایک منصوبہ تیار کریں۔ ہر مرحلے پر AI کے کردار اور انسانی منظوری کے مقامات کو الگ الگ نشان زد کریں۔ پھر "CI/CD پائپ لائن آؤٹ لائن" کے ساتھ YAML بنائیں اور ایمبیڈڈ کلید/خفیہ ڈیٹا کو چیک کرنے کے لیے اس YAML پر "سیکیورٹی/پرائیویسی پری چیک" لگائیں۔ آخر میں، اپنے پلان میں تمام "انسانی فیصلے" پوائنٹس کی فہرست بنائیں اور ایک جملے میں جواز پیش کریں کہ یہ فیصلے AI کو کیوں نہیں سونپے جا سکتے۔
چیک لسٹ
- میں رہائی اور جانچ کے فیصلوں کو انسانی منظوری سے منسوب کرتا ہوں۔ میں نے اسے AI کے حوالے نہیں کیا۔
- CI/CD میں میں نے AI کو خود بخود ٹیسٹ کو "پاس/درست" کرنے کی اجازت نہیں دی۔
- میں نے گاڑی کو بھیجنے سے پہلے خفیہ ڈیٹا، ذاتی ڈیٹا اور چابیاں چیک کیں اور ان پر نقاب پوش کیا۔
- میں نے تحریری اجازت اور دائرہ کار کے اندر صرف اپنے پروڈکٹ پر حفاظتی جانچ پر غور کیا ہے۔
- میں نے ذمہ دارانہ انکشاف کے اصول کے ساتھ پائی جانے والی کمزوریوں کو دور کیا۔
- میں نے شفافیت سے کہا کہ میں نے AI کا استعمال کیا اور اپنے آپ کو آؤٹ پٹ کی درستگی کا ذمہ دار ٹھہرایا۔
ماڈیول امتحان
1. QA سیاق و سباق میں 'غلط پاس' کی سب سے درست وضاحت کیسے کی جاتی ہے؟
- A) اگرچہ ٹیسٹ سبز ہو جاتا ہے، لیکن یہ حقیقت میں کسی رویے کی تصدیق نہیں کرتا؛ ✔ کوڈ کرپٹ ہونے پر بھی سرخ نہیں ہوتا
- ب) ٹیسٹ بہت آہستہ چلتا ہے اور وقت ختم ہو جاتا ہے۔
- C) ٹیسٹ ایک حقیقی غلطی کا پتہ لگاتا ہے اور سرخ ہو جاتا ہے۔
- D) ٹیسٹ صرف پیداواری ماحول میں چلتا ہے۔
وضاحت: سیوڈو پاس وہ ہوتا ہے جب کوئی ٹیسٹ کہتا ہے 'پاس' لیکن حقیقت میں کسی معنی خیز کی تصدیق نہیں کرتا ہے۔ ٹیسٹ سبز ہے، لیکن یہاں تک کہ اگر سافٹ ویئر ناقص ہے، تو یہ اسے نہیں پکڑے گا۔ یہ QA میں AI کا پہلا خطرہ ہے کیونکہ AI ایسے ٹیسٹ تیار کرتا ہے جو صاف نظر آتے ہیں لیکن کھوکھلے ہیں۔
2. جانچ اور QA کے عمل میں مصنوعی ذہانت کی سب سے درست پوزیشننگ کیا ہے؟
- A) مصنوعی ذہانت یہ فیصلہ کر سکتی ہے کہ آیا اس ورژن کو انسانی منظوری کے بغیر جاری کیا جا سکتا ہے۔
- ب) مصنوعی ذہانت ایک معاون ہے جو ڈرافٹ اور آئیڈیاز تیار کرتی ہے۔ 'کیا یہ اشاعت کے لیے تیار ہے' کا فیصلہ اور ذمہ داری ماہر کی ہے۔
- C) مصنوعی ذہانت صرف متن لکھتی ہے اور ٹیسٹ کوڈ سے بالکل بھی نمٹ نہیں سکتی
- ڈی) مصنوعی ذہانت ہمیشہ انسان کے مقابلے میں درست ٹیسٹ لکھتی ہے، اس لیے جائزہ غیر ضروری ہے۔
تفصیل: مصنوعی ذہانت ایک ٹیسٹنگ اسسٹنٹ، ڈرافٹ جنریٹر اور آئیڈیا ضرب ہے۔ ٹیسٹ کے منظرنامے، آٹومیشن کوڈ اور رپورٹ ڈرافٹ تیار کرتا ہے۔ تاہم، 'کیا یہ سافٹ ویئر اشاعت کے لیے تیار ہے' یا 'کیا یہ ٹیسٹ پاس ہوا ہے' جیسے معیاری فیصلوں کی ذمہ داری اور حتمی منظوری اہل ماہر کی ہے۔
3. اس حقیقت کی بنیاد پر کہ غلطیاں زیادہ تر حد کی قدروں پر ہوتی ہیں، کونسی ٹیسٹ ڈیزائن تکنیک 17، 18 اور 19 کو 18 سال کی عمر کی حد کے لیے الگ الگ جانچنے کے لیے ہے؟
- A) ریاستی منتقلی کا امتحان
- ب) فیصلہ کی میز
- سی) باؤنڈری ویلیو کا تجزیہ ✔
- ڈی) تحقیقی جانچ
وضاحت: باؤنڈری ویلیو کا تجزیہ اس مشاہدے پر مبنی ہے کہ غلطیاں اکثر حدود پر ہوتی ہیں اور حد کی قدروں کو الگ الگ جانچتی ہیں (بالکل نیچے، بالکل اوپر، اور حد سے اوپر)۔ یہ ایک طاقتور تکنیک ہے جو برابری کی کلاسوں کی تکمیل کرتی ہے۔
4. مصنوعی ذہانت کے ساتھ تیار کردہ UI ٹیسٹ آٹومیشن کوڈ میں نزاکت کو کم کرنے کے لیے عنصر کے انتخاب میں کس نقطہ نظر کو ترجیح دی جانی چاہیے؟
- A) طویل ترین XPath راستہ استعمال کرنا
- ب) عنصر کو اسکرین پر اس کی پکسل پوزیشن کے مطابق منتخب کرنا
- C) CSS کلاس کے ناموں پر مبنی سلیکٹرز کا استعمال
- D) مستحکم صفات کا استعمال کرتے ہوئے (ڈیٹا ٹیسٹڈ) جانچ کے لیے شامل کیا گیا ہے ✔
وضاحت: طویل XPath راستے اور CSS کلاس کے نام صفحہ کی ساخت اور ڈیزائن پر بہت زیادہ منحصر ہیں۔ یہ انٹرفیس کی معمولی تبدیلی پر ٹوٹ جاتا ہے۔ خاص طور پر جانچ کے لیے شامل کیے گئے مستحکم اوصاف (جیسے ڈیٹا ٹیسٹڈ) ڈیزائن کی تبدیلیوں سے متاثر نہیں ہوتے ہیں اور ٹیسٹ کو مضبوط بناتے ہیں۔
5. API ٹیسٹ کے لیے صرف HTTP اسٹیٹس کوڈ (جیسے 200) کو چیک کرنا کیوں ناکافی ہے؟
- A) کیونکہ صحیح اسٹیٹس کوڈ کے ساتھ باڈی ڈیٹا کرپٹ ہوسکتا ہے اور صرف اسٹیٹس چیک ہی اسے نہیں پکڑے گا (سیڈو ٹرسٹ) ✔
- ب) کیونکہ اسٹیٹس کوڈ API ٹیسٹوں میں بالکل بھی قابل اعتماد نہیں ہیں۔
- C) کیونکہ سٹیٹس کوڈ کی جانچ پڑتال ٹیسٹ کو بہت سست کر دیتی ہے۔
- D) کیونکہ اسٹیٹس کوڈ کبھی بھی API ٹیسٹوں میں واپس نہیں کیا جاتا ہے۔
وضاحت: جب کہ سرور درست اسٹیٹس کوڈ واپس کرتا ہے، تو یہ جسم میں خراب ڈیٹا (غلط قسم، گمشدہ فیلڈ، غلط حساب کی گئی قدر) واپس کر سکتا ہے۔ وہ امتحان جو صرف حالات کو دیکھتا ہے اسے نہیں دیکھ سکتا اور غلط اعتماد دیتا ہے۔ اس لیے اسکیما/معاہدے اور کاروباری اصول کی توثیق کو بھی شامل کیا جانا چاہیے۔
6. AI کو یہ بتانا کیوں ضروری ہے کہ 'قبولیت کے اصول کے مطابق دستی طور پر متوقع قیمت کا حساب لگائیں، فنکشن کے موجودہ آؤٹ پٹ کا حوالہ نہ دیں' جب یونٹ ٹیسٹ پرنٹ کرتے ہیں؟
- A) کیونکہ دستی حساب کتاب تیزی سے ٹیسٹ چلاتا ہے۔
- ب) کیونکہ بصورت دیگر ٹیسٹ کوڈ کے موجودہ (شاید چھوٹی چھوٹی) رویے کو 'درست' کے طور پر قبول کرتا ہے اور بگ کی تصدیق کرتا ہے ✔
- ج) کیونکہ مصنوعی ذہانت اعشاریہ کو بالکل بھی شمار نہیں کر سکتی
- D) کیونکہ قبولیت کے اصول کبھی بھی ٹیسٹوں میں استعمال نہیں ہوتے ہیں۔
وضاحت: اگر AI ٹیسٹ کے تحت فنکشن کے آؤٹ پٹ سے متوقع قدر حاصل کرتا ہے، تو یہ ٹیسٹ کو 'پاس' کر دے گا چاہے فنکشن ناقص ہو۔ یعنی جو بھی کوڈ تیار کرتا ہے، ٹیسٹ کو درست شمار کیا جاتا ہے۔ قبولیت کے اصول سے آزادانہ طور پر متوقع قدر کا حساب لگانا اس بات کو یقینی بناتا ہے کہ ٹیسٹ قاعدے کا دربان ہے، کوڈ کا آئینہ نہیں۔
7. درج ذیل میں سے کون سی اچھی بگ رپورٹ کی سب سے نمایاں خصوصیت ہے؟
- A) جتنا ہو سکے لمبا اور تکنیکی ہونا
- ب) مصنوعی ذہانت سے لکھا گیا۔
- C) تعییناتی پنروتپادن کے اقدامات پر مشتمل ہے جن کی پیروی ڈویلپر آزادانہ طور پر کر سکتا ہے اور غلطی پیدا کر سکتا ہے ✔
- D) یہ صرف ایک اسکرین شاٹ ہے۔
وضاحت: بگ رپورٹ کی اصل قدر یہ ہے کہ ڈویلپر آپ کی مدد کے بغیر بگ کو دوبارہ پیش کر سکتا ہے۔ شروع سے تعین کرنے والے، قابل تجدید اقدامات اس بات کو یقینی بناتے ہیں۔ اگر یہ اقدامات غائب ہیں، تو رپورٹ اکثر 'پیش نہیں ہو سکی' کے طور پر بند ہو جاتی ہے۔
8. ہوم پیج پر کمپنی کے نام کی غلط ہجے کی غلطی میں شدت اور ترجیح کے درمیان تعلق کا سب سے درست اظہار کون سا ہے؟
- ا) شدت اور ترجیح کی ہمیشہ ایک ہی قدر ہونی چاہیے۔
- ب) اس غلطی کی شدت اور ترجیح دونوں یقینی طور پر کم ہیں۔
- ج) شدت اور ترجیح ایک ہی تصور ہے، ایک لیبل کافی ہے۔
- D) تکنیکی شدت کم ہو سکتی ہے لیکن کاروباری ترجیح (ساکھ) زیادہ ہو سکتی ہے۔ دونوں کا مختلف انداز میں جائزہ لیا جاتا ہے ✔
وضاحت: شدت غلطی کا تکنیکی اثر ہے (ٹائپو تکنیکی طور پر کم)، ترجیح یہ ہے کہ اسے کس حد تک فوری طور پر ٹھیک کرنے کی ضرورت ہے (اعلیٰ کیونکہ یہ شہرت کا عنصر ہے جسے ہر دیکھنے والا دیکھتا ہے)۔ دونوں ہمیشہ ایک ہی سمت میں نہیں جاتے۔ یہ مثال کم شدت والی اعلی ترجیحی صورتحال ہے۔
9. 90% لائن کوریج کے ساتھ ٹیسٹ سوٹ کی سب سے درست تشریح کون سی ہے؟
- A) یہ ظاہر کرتا ہے کہ لائنوں پر عمل کیا گیا ہے لیکن یہ ثابت نہیں کرتا ہے کہ وہ صحیح طریقے سے برتاؤ کرتے ہیں؛ ✔ زیادہ کوریج غلط اعتماد دے سکتی ہے۔
- ب) مکمل طور پر ثابت کرتا ہے کہ 90% سافٹ ویئر بگ فری ہے۔
- C) یہ بہترین ٹیسٹ کے معیار کا ایک حتمی پیمانہ ہے۔
- D) اشارہ کرتا ہے کہ اب کوئی اضافی ٹیسٹ لکھنے کی ضرورت نہیں ہے۔
وضاحت: قطار کی کوریج اس بات کی نشاندہی کرتی ہے کہ صرف قطاریں چلائی گئی تھیں۔ اس سے یہ ثابت نہیں ہوتا کہ یہ صحیح نتائج دیتا ہے۔ بغیر دعویٰ کے ٹیسٹ کے باوجود بھی 90% کوریج حاصل کی جا سکتی ہے۔ دائرہ کار ایک 'کبھی کہاں نہیں دیکھا' نقشہ ہے، نہ کہ 'ہر چیز کی جانچ کی گئی ہے' کی یقین دہانی؛ اصل تحفظ کی پیمائش اتپریورتن ٹیسٹنگ سے کی جاتی ہے۔
10. خطرے پر مبنی جانچ میں، کسی خصوصیت کے خطرے کو براہ راست محدود جانچ کی کوششوں میں کیسے شمار کیا جاتا ہے؟
- A) صرف کوڈ کی لائنوں کی تعداد سے
- ب) ناکامی کے امکان اور اس کے ٹوٹنے پر ہونے والے اثر کو ضرب دے کر ✔
- ج) صرف اس ترتیب میں جس میں خصوصیت تیار کی گئی تھی۔
- D) صرف اس خصوصیت کو ترجیح دینا جس کے لیے ٹیسٹ لکھنا آسان ہے۔
وضاحت: خطرے پر مبنی جانچ میں، خطرے کا اندازہ امکان = امکان (بریک ڈاؤن کا امکان) × اثر (ٹوٹنے پر نقصان) کے طور پر کیا جاتا ہے۔ زیادہ امکان اور زیادہ اثر والے ڈومینز (ادائیگی، تصدیق) انتہائی سخت جانچ کے مستحق ہیں، جبکہ کم × کم ڈومینز ہلکی جانچ حاصل کرتے ہیں۔
11. کسی ایسے ٹیسٹ میں دوبارہ کوشش کرنے کا بنیادی خطرہ کیا ہے جو کبھی پاس ہو جاتا ہے اور کبھی ناکام ہو جاتا ہے (بھورنے والا/فضول) حالانکہ کوڈ تبدیل نہیں ہوا ہے؟
- A) ٹیسٹ کے چلنے کے وقت کو مختصر کرنا
- ب) کوریج کا فیصد کم کرتا ہے۔
- ج) ایک حقیقی ہم آہنگی کی غلطی یا بنیادی وجہ کو چھپانا اور علامت کو دبانا ✔
- D) ٹیسٹ کا نام تبدیل کرنا
وضاحت: دوبارہ کوشش کرنا ایک تشخیصی آلہ ہے، علاج نہیں۔ غیر فیصلہ کن پن اکثر نسل کی اصل حالت یا لت سے آتا ہے۔ دوبارہ کوشش کر کے ٹیسٹ کو 'پاس' کرنا اس اصل غلطی کو چھپا دیتا ہے اور لائیو میں سنگین مسائل پیدا کر سکتا ہے۔ سب سے پہلے اس کی بنیادی وجہ تلاش کرنی چاہیے۔
12. میوٹیشن ٹیسٹنگ، یہ پیمائش کرنے کا سب سے ایماندار طریقہ کیسے کام کرتا ہے کہ آیا ٹیسٹ سویٹ دراصل حفاظت کرتا ہے؟
- A) ٹیسٹ کے چلنے کی رفتار کی پیمائش کرکے
- ب) کوڈ کی کتنی لائنیں لکھی گئی ہیں اس کی گنتی کرکے
- ج) مختلف ترتیبوں میں ٹیسٹ چلا کر
- D) جان بوجھ کر کوڈ میں چھوٹے وقفے پیدا کرکے اور پیمائش کرکے کہ آیا ٹیسٹ ان کو پکڑتے ہیں ✔
تفصیل: اتپریورتن کی جانچ سورس کوڈ میں چھوٹے جان بوجھ کر بگاڑ (میوٹیشن) پیدا کرتی ہے۔ ایک اچھے ٹیسٹ سوٹ کو ان بگاڑ کو پکڑنا چاہئے اور سرخ ہونا چاہئے۔ تغیرات جو پکڑے نہیں گئے (بچ گئے) اس بات کی نشاندہی کرتے ہیں کہ ٹیسٹ اس طرز عمل کو محفوظ نہیں رکھتے ہیں۔ اتپریورتن سکور فیصد کی کوریج کے مقابلے میں معیار کا ایک بہت زیادہ ایماندارانہ پیمانہ ہے۔
13. سیکورٹی ٹیسٹنگ (مثلاً اجازت/IDOR ٹیسٹ) کرتے وقت کس بنیادی حد کی پیروی کی جائے؟
- A) یہ صرف اس کی اپنی مصنوعات پر، تحریری اجازت اور متعین دائرہ کار کے اندر، دفاعی مقاصد کے لیے کیا جانا چاہیے ✔
- ب) اسے کسی بھی مفاد کے نظام پر آزادانہ طور پر لاگو کیا جا سکتا ہے۔
- C) بغیر اجازت کے کاروباری شراکت داروں کے لائیو سسٹمز پر اسے آزمایا جا سکتا ہے۔
- D) پائے جانے والے کسی بھی کمزوری کو فوری طور پر عوامی طور پر شائع کیا جانا چاہئے۔
تفصیل: اس ماڈیول میں سیکھے گئے سیکیورٹی ٹیسٹ صرف تحریری اجازت اور متعین دائرہ کار کے اندر دفاعی مقاصد کے لیے آپ کی اپنی مصنوعات کی جانچ کے لیے ہیں۔ بغیر اجازت کے کسی اور کے سسٹم تک رسائی حاصل کرنا یا دائرہ کار سے باہر جانچ کرنا غیر اخلاقی اور غیر قانونی ہے؛ پائے جانے والے کسی بھی کمزوری کی اطلاع ذمہ دارانہ انکشاف کے ذریعے دی جاتی ہے۔
14. CI/CD پائپ لائن میں کبھی بھی AI کو کون سا اختیار نہیں دیا جانا چاہیے؟
- A) ناکام ٹیسٹ لاگز کا خلاصہ
- ب) ناکام (سرخ) ٹیسٹ کو خود بخود 'پاس' کرنے یا اسے سبز رنگ کرنے کا اختیار ✔
- C) ٹیسٹ کوڈ کا مسودہ تجویز کرنا
- D) پائپ لائن YAML فائل ڈرافٹنگ
تفصیل: AI CI/CD میں ٹیسٹ کوڈ آؤٹ لائن، پائپ لائن YAML، اور لاگ سمری تیار کر سکتا ہے۔ تاہم، ناکام ٹیسٹ کو خود بخود 'پاس/ٹھیک' کرنے کی صلاحیت کبھی نہیں دی جانی چاہیے۔ یہ جانچ کے مقصد کو ناکام بناتا ہے اور خود بخود غلطیوں کو چھپا دیتا ہے۔ ٹیسٹ کو سبز رنگ دینا ایک شخص کا شعوری اور مدلل فیصلہ ہونا چاہیے۔