فائدہ:
- چھدم اعتماد کے تین چہروں کو پہچاننے کی صلاحیت (غیر جارحانہ، خود پر زور دینے والا، معمولی دعویٰ) اور تریاق کا اطلاق
- میوٹیشن ٹیسٹنگ اور میوٹیشن سکور کو آلے یا ہاتھ سے فیصد کوریج کے مقابلے میں معیار کے زیادہ درست پیمائش کے طور پر استعمال کرنے کی اہلیت
- AI کو ٹیسٹنگ کے خلاف ریڈ ٹیم کے طور پر پوزیشن دینے اور تعریف کے جال میں پڑے بغیر خامیوں کی جانچ کرنے کی صلاحیت
اس ماڈیول کے مرکز میں ایک بار بار آنے والی وارننگ ہے: سبز چمکتا ہوا ٹیسٹ پینل معیار کا ثبوت نہیں ہے۔ اگر آپ کے ٹیسٹ آپ کو اعتماد دیتے ہیں، تو آپ کو یہ جاننے کی ضرورت ہے کہ یہ اعتماد اصلی ہے یا جعلی۔ مصنوعی ذہانت (AI) کے دور میں، یہ سوال پہلے سے کہیں زیادہ اہم ہے، کیونکہ AI سیال، ہموار نظر آنے والے لیکن کھوکھلے ٹیسٹ تیار کرنے میں ماہر ہے۔ غلط اعتماد — سافٹ ویئر پر یقین کرنا درست ہے کیونکہ ٹیسٹ سبز ہوتے ہیں، جب حقیقت میں ٹیسٹ کسی بھی چیز کی تصدیق نہیں کرتے — یہ سب سے خطرناک چیز ہے جو QA ٹیم کے ساتھ ہو سکتی ہے۔ کیونکہ یہ نہیں چھپاتا کہ کوئی غلطیاں نہیں ہیں، لیکن یہ کہ آپ غلطیاں نہیں دیکھ سکتے۔ یہ یونٹ پورے ماڈیول کے توثیق کے فلسفے کو ایک نظم میں اکٹھا کرتا ہے: آپ کے ٹیسٹوں کی جانچ کرنا۔
جانچ کے معیار کی پیمائش کے لیے گولڈ اسٹینڈرڈ: میوٹیشن ٹیسٹنگ
یہ سمجھنے کا سب سے طاقتور طریقہ ہے کہ آیا کوئی ٹیسٹ حقیقت میں تحفظ فراہم کرتا ہے یا نہیں، میوٹیشن ٹیسٹنگ ہے (میوٹیشن ٹیسٹنگ - ایک تکنیک جو ماخذ کوڈ میں جان بوجھ کر چھوٹی چھوٹی تحریفات/میوٹیشنز پیدا کرتی ہے اور یہ پیمائش کرتی ہے کہ آیا ٹیسٹ ان بگاڑ کا پتہ لگاتے ہیں)۔ منطق آسان ہے: اگر آپ جان بوجھ کر کوڈ کو توڑتے ہیں (a + into -, a > into >=، سچ کو غلط میں)، ایک اچھے ٹیسٹ سوٹ کو اس بدعنوانی کو پکڑنا چاہیے اور سرخ ہو جانا چاہیے۔ اگر ایسا نہیں ہوتا ہے، تو یہ خلل ایک زندہ بچ جانے والا اتپریورتی ہے - لہذا آپ کے ٹیسٹ درحقیقت اس رویے کو محفوظ نہیں کر رہے ہیں۔
اتپریورتن سکور = اتپریورتن ہلاک / مکمل اتپریورتن۔ 90% لائن کوریج والے پیکج میں 40% کا میوٹیشن سکور ہو سکتا ہے۔ اس سے ظاہر ہوتا ہے کہ لائنیں کام کر رہی ہیں لیکن رویے کی تصدیق نہیں ہوئی ہے۔ اتپریورتن سکور فیصد کی کوریج کے مقابلے میں معیار کا ایک بہت زیادہ ایماندارانہ پیمانہ ہے۔
ٹپ: خودکار میوٹیشن ٹولز ہیں (جاوا کے لیے PIT/Pitest، JavaScript/TypeScript کے لیے Stryker، NET کے لیے Stryker.NET، Python کے لیے mutmut)۔ یہ خود بخود سیکڑوں تغیرات پیدا اور جانچتے ہیں۔ اگر آپ کے پاس کوئی ٹول نہیں ہے، یہاں تک کہ دستی "بریک دی کوڈ ٹیسٹ" کا طریقہ بھی اہم کاموں کے لیے انمول ہے۔
چھدم اعتماد کے تین چہرے اور اس کا تریاق
چھدم اعتماد کی شکل
علامت
تریاق
دعوے کے بغیر ٹیسٹ کریں۔
کوڈ کام کرتا ہے، کسی بھی چیز کی توثیق نہیں ہوتی ہے۔
ہر امتحان میں سچا دعویٰ۔ اتپریورتن کے ساتھ ٹیسٹ
خود تصدیق ٹیسٹ
متوقع = کوڈ کا آؤٹ پٹ
متوقع قدر کا آزادانہ طور پر حساب لگائیں۔
معمولی دعویٰ
"نال نہیں"، "200 واپس آئے"
کاروباری اصول/اصل نتیجہ کی توثیق کریں۔
ہائی اسکوپ فریبیسی
90٪ لائنیں، کم تحفظ
میوٹیشن سکور دیکھیں
نازک ٹیسٹ رواداری
"پھر پھنس گیا، پاس"
بنیادی وجہ + تعییناتی جانچ
AI کو بطور "ریڈ ٹیم" استعمال کرنا
AI چھدم اعتماد پیدا کر سکتا ہے اور اسے شکار کرنے میں ایک طاقتور اتحادی بن سکتا ہے۔ اپنے ٹیسٹوں کے خلاف AI کو ریڈ ٹیم کے طور پر استعمال کریں: پوچھیں "لکھیں کوڈ جو ان ٹیسٹوں کو پاس کرتا ہے لیکن غلط ہے" یا "کوئی ایسی بغاوت تلاش کریں جو ان ٹیسٹوں کو بیوقوف بنائے۔" اگر AI کو آپ کے ٹیسٹوں میں خامیاں ملتی ہیں، تو وہ خامیاں حقیقی خطرات ہیں۔
احتیاط: AI سے مت پوچھیں "کیا میرے ٹیسٹ کا معیار اچھا ہے؟" اور یقین دہانی کے طور پر جواب "ہاں، بہت اچھا" لیں۔ AI مہربان ہوتا ہے۔ اس کے بجائے، AI کو ایک ٹھوس کام کے لیے چیلنج کریں: "ایک ایسا بگ پیدا کریں جو ان ٹیسٹوں کو پاس کرے۔" اگر یہ اسے پیدا کرسکتا ہے تو، آپ کے ٹیسٹ اس غلطی سے اندھے ہیں۔
مساوی تغیرات اور سکور کی حدود
اتپریورتن کی جانچ طاقتور ہے، لیکن اس میں ایک کیچ ہے: کچھ تغیرات کوڈ کے رویے کو بالکل تبدیل نہیں کرتے ہیں۔ ان کو مساوی اتپریورتن کہا جاتا ہے (مساوی اتپریورتی - خراب شدہ کوڈ، اتپریورتن جو اصل کے طور پر بالکل وہی نتیجہ پیدا کرتی ہے)۔ مثال کے طور پر، کسی متغیر کی ابتدائی قدر کو تبدیل کرنا جو کبھی استعمال نہیں ہوتا ہے، آؤٹ پٹ کو متاثر نہیں کرتا ہے۔ کوئی ٹیسٹ اسے پکڑ نہیں سکتا اور نہ ہی پکڑنا چاہیے۔ لہذا، ایک 100% اتپریورتن سکور اکثر عملی طور پر ناقابل حصول ہوتا ہے اور یہ مقصد نہیں ہوتا ہے۔ مساوی اتپریورتنوں کو ہاتھ سے نکالنا محنتی ہے۔ اس لیے اتپریورتن سکور کو امتحان کے مطلق اسکور کے طور پر نہ پڑھیں، بلکہ "کیا میرے ٹیسٹ واقعی حفاظت کرتے ہیں؟" کے ایماندار اشارے کے طور پر پڑھیں۔
عملی نقطہ نظر یہ ہے: پورے کوڈ بیس میں میوٹیشن ٹیسٹنگ کو مسلسل چلانے کے بجائے، اسے ان ماڈیولز پر چلائیں جن میں سب سے زیادہ خطرہ اور انتہائی پیچیدہ کاروباری اصول ہوں۔ ان ماڈیولز میں ایک ایک کر کے بقایا تغیرات کا جائزہ لیں۔ اگر یہ ایک حقیقی فرق ہے تو، ایک ٹیسٹ شامل کریں؛ اگر یہ مساوی تغیر ہے تو اسے جواز کے ساتھ نشان زد کریں اور پاس کریں۔ AI اس بات کا اندازہ کرنے کے لیے ابتدائی اسکریننگ انجام دے سکتا ہے کہ آیا زندہ رہنے والا اتپریورتن برابر ہے؛ لیکن حتمی فیصلہ آپ کے ذریعہ کیا جاتا ہے جو جانتے ہیں کہ کوڈ کیا کرتا ہے۔
احتیاط: میوٹیشن ٹیسٹنگ کمپیوٹیشنل طور پر مہنگا ہے (تمام متعلقہ ٹیسٹ ہر میوٹیشن کے لیے دوبارہ چلائے جاتے ہیں)۔ لہذا ایک عام اور معقول حکمت عملی یہ ہے کہ اسے ہر انضمام کے بجائے ہفتہ وار یا پہلے سے جاری ہونے والے اہم ماڈیولز کی گہری جانچ کے طور پر شیڈول کیا جائے۔
کمزور فوری / مضبوط اشارہ
کمزور: "کیا میرے ٹیسٹ کافی ہیں؟"
مضبوط: "اس فنکشن اور ٹیسٹ سوٹ کے لیے ایک ریڈ ٹیم کے طور پر کام کریں۔ (1) کوڈ میں 8 میوٹیشنز تیار کریں جو ختم کیے جاسکتے ہیں (آپریٹر متبادل، باؤنڈری شفٹ، کنڈیشن انورسیشن، ریٹرن ویلیو متبادل)۔ (2) ہر میوٹیشن کے لیے، اس بات کی نشاندہی کریں کہ موجودہ ٹیسٹوں میں سے کون سا اسے پکڑے گا اور کون نہیں کرے گا۔ (3) اس کے لیے ایک نیا ٹیسٹ لکھے گا، جو کہ ایک نیا ٹیسٹ لکھے گا۔ (4) یہ بھی دکھائیں کہ کیا آپ ایک کوڈ کی مثال پیش کر سکتے ہیں جو ان تمام ٹیسٹوں کو پاس کرتا ہے لیکن کاروباری ضابطے کی خلاف ورزی کرتا ہے: [پیسٹ]۔
طاقتور فوری؛ یہ AI کو ایک ٹیسٹ بریکنگ ایگزامینر کے طور پر رکھتا ہے، نہ کہ تعریف کرنے والی مشین۔
چار کاپی کرنے کے قابل ٹیمپلیٹس
1) دستی اتپریورتن کنٹرول:
اس کوڈ کے لیے 8 اہم تغیرات (معمولی جان بوجھ کر رکاوٹیں) پیدا کریں: ریاضی کے آپریٹر کا متبادل، موازنہ کی حد (> بمقابلہ >=)، منطقی الٹا، واپسی/مستقل متبادل، حالت کو چھوڑنا۔ ہر میوٹیشن کے لیے، پیش گوئی کریں کہ کون سا دستیاب ٹیسٹ اسے پکڑے گا یا نہیں۔ کوڈ + ٹیسٹ: [پیسٹ کریں]
2) زندہ بچ جانے والے تغیر کو مارنا:
مندرجہ ذیل اتپریورتن ٹیسٹ رپورٹ میں زندہ بچ جانے والے (غیر پکڑے گئے) تغیرات شامل ہیں: [فہرست/رپورٹ]۔ ہر ایک کے لیے، ایک کم سے کم ٹیسٹ لکھیں جو اس میوٹیشن کو ختم کر دے گا (اس طرح ٹوٹنے پر کوڈ سرخ ہو جائے گا)۔ ٹیسٹ کس رویے کی تصدیق کرتا ہے اس پر تبصرہ کریں۔
3) سرخ ٹیم - خون کا ٹیسٹ:
کیا آپ کوڈ لکھ سکتے ہیں جو درج ذیل تمام ٹیسٹوں کو پاس کرتا ہے، لیکن درج ذیل کاروباری اصول کی خلاف ورزی کرتا ہے: [بزنس رول]۔ اگر ایسا ہے تو، ان ٹیسٹوں میں کون سی خامی اس کی اجازت دیتی ہے؟ ٹیسٹ شامل کریں جو اس خامی کو بند کردے گا۔ ٹیسٹ: [پیسٹ]
4) ٹیسٹ کے معیار کا معائنہ:
معیار کے لیے اس ٹیسٹ سویٹ کو چیک کریں۔ ہر ٹیسٹ کے لیے ٹک کریں:- کیا کوئی سچا دعویٰ ہے یا یہ پروپس ہے؟- کیا متوقع قدر آزاد، کوڈ سے اخذ کی گئی ہے؟- کیا یہ کاروباری اصول کی تصدیق کرتا ہے یا کوئی معمولی چیز؟ آخر میں ایک اندازے کے مطابق "ٹرو اسسٹ سکور" اور 3 کمزور ترین ٹیسٹ دیں۔ ٹیسٹ: [پیسٹ]
تین چھوٹے مقدمات
کیس 1 - کوریج 92%، میوٹیشن سکور 38%۔ ایک ٹیم اعلی کوریج پر انحصار کرتی تھی۔ جب اسٹرائیکر کے ساتھ میوٹیشن ٹیسٹنگ چلائی گئی تو اسکور 38% تھا: زیادہ تر میوٹیشنز بچ گئے۔ یہ اس بات کا ثبوت تھا کہ ٹیسٹ لائنیں نہیں چلا رہے تھے اور رویے کی تصدیق نہیں کر رہے تھے۔ ٹیم نے معیار کی جانچ میں تین ہفتے لگائے۔ اتپریورتن سکور بڑھ کر 81% ہو گیا، اور اگلی ریلیز میں ان بیفڈ اپ ٹیسٹوں کے ذریعے حساب کی دو حقیقی غلطیاں پکڑی گئیں۔
کیس 2 - AI نے ٹیسٹ کو دھوکہ دیا۔ "ریڈ ٹیم" ٹیمپلیٹ کے ساتھ، ایک ماہر نے AI سے کوڈ کے لیے پوچھا جس نے موجودہ ٹیسٹ پاس کیے لیکن ڈسکاؤنٹ کے اصول کی خلاف ورزی کی۔ AI نے کوڈ لکھا جو ہمیشہ صفر کی رعایت دیتا ہے - اور تمام ٹیسٹ سبز رہے کیونکہ کوئی بھی ٹیسٹ رعایت کی اصل قیمت کی تصدیق نہیں کر رہا تھا۔ خلا دیکھا گیا، حقیقی دعوے شامل کیے گئے۔
کیس 3 - تعریف کا جال۔ ایک جونیئر ٹیسٹر نے AI سے پوچھا، "کیا میرے ٹیسٹ اچھے ہیں؟" اور "بہت جامع" کا جواب سن کر تسلی ہوئی۔ اس کے سینئر ساتھی نے "ٹیسٹ کوالٹی آڈٹ" ٹیمپلیٹ کا استعمال کرتے ہوئے وہی ٹیسٹ آڈٹ کیے تھے۔ معلوم ہوا کہ 20 میں سے 12 ٹیسٹ سجاوٹ کے تھے (بغیر دعویٰ یا ردی کے)۔ صحیح سوال صحیح جواب لایا۔
عام غلطیاں
- معیار کے لئے گنجائش کو غلط کرنا۔ اونچی قطار کی کوریج پر انحصار کرنا اور اتپریورتن سکور کو بالکل نہیں دیکھنا۔
- AI کی تعریف پر بھروسہ کرنا۔ پوچھنا "کیا آپ کے ٹیسٹ اچھے ہیں؟" اور مثبت جواب کو یقین دہانی سمجھنا۔
- کوڈ سے متوقع قدر اخذ کرنا۔ خود تصدیقی ٹیسٹ جو غلط کوڈ کی تصدیق کرتے ہیں۔
- معمولی باتوں سے مطمئن رہیں۔ وہ چیک جو اصل اصول کی توثیق نہیں کرتے، جیسے "نوٹ نہیں"، "200 واپس آئے"۔
- زندہ رہنے والے تغیرات کو نظر انداز کرنا۔ میوٹیشن رپورٹ میں جو نہیں پکڑا گیا اسے نظر انداز کرنا۔
- اہم کوڈ کو دستی طور پر تبدیل کرنے کی کوشش بھی نہیں کر رہا ہے۔ اگر ٹول دستیاب نہ ہو تو "بریک دی کوڈ اور ٹیسٹ" مرحلہ کو چھوڑنا۔
خلاصہ میں
سیوڈو ٹرسٹ یہ مان رہا ہے کہ سافٹ ویئر درست ہے کیونکہ ٹیسٹ سبز ہیں۔ جبکہ ٹیسٹ کسی چیز کی تصدیق نہیں کر سکتے ہیں۔ اس کی پیمائش کے لیے سونے کا معیار میوٹیشن ٹیسٹنگ ہے: جان بوجھ کر کوڈ کو توڑنا اور پیمائش کرنا کہ آیا ٹیسٹ اسے پکڑتے ہیں۔ اتپریورتن سکور فیصد کی کوریج کے مقابلے میں معیار کا ایک بہت زیادہ ایماندارانہ پیمانہ ہے۔ AI دونوں چھدم اعتماد پیدا کرتا ہے اور اس کا شکار کرنے میں ایک طاقتور سرخ ٹیم بن جاتا ہے — پوچھیں "ایک ایسا بگ پیدا کریں جو ان ٹیسٹوں کو پاس کرے۔" اپنے ٹیسٹوں کی جانچ کریں: سچا دعوی، آزاد متوقع قدر، کاروباری اصول کی توثیق، اور ہلاک شدہ تغیرات۔
درخواست کا کام
ایک فنکشن درآمد کریں جس میں کاروباری اصول اور اس کے ٹیسٹ آپ کے اپنے پروجیکٹ سے ہوں۔ اگر ممکن ہو تو، ایک میوٹیشن ٹول چلائیں (اسٹرائیکر/پیٹسٹ/مٹمٹ) اور میوٹیشن سکور کی پیمائش کریں۔ اگر کوئی ٹول نہیں ہے تو، "دستی تبدیلی کنٹرول" ٹیمپلیٹ کے ساتھ کم از کم 8 میوٹیشنز بنائیں اور انہیں دستی طور پر آزمائیں۔ ہر زندہ بچ جانے والے اتپریورتن کے لیے، "کِل سروائیونگ میوٹیشن" ٹیمپلیٹ کے ساتھ ایک نیا ٹیسٹ لکھیں۔ آخر میں، "ریڈ ٹیم" پیٹرن کے ساتھ، دیکھیں کہ آیا AI کوڈ تیار کر سکتا ہے جو آپ کے ٹیسٹوں کو بیوقوف بناتا ہے۔ اپنے ابتدائی اور اختتامی اتپریورتن سکور کی اطلاع دیں (یا کیچ/موٹیشن کی کل شرح)۔
چیک لسٹ
- میں نے ٹیسٹ کے معیار کو میوٹیشن سکور سے جانچا، کوریج سے نہیں۔
- میں نے اہم کوڈ کے لیے میوٹیشن ٹیسٹنگ (یا تو ٹول کے ذریعے یا دستی طور پر) چلائی۔
- میں نے ہر بچ جانے والے تغیر کے لیے نئے ٹیسٹ لکھے۔
- میں نے AI کو ریڈ ٹیم کے طور پر استعمال کیا اور اپنے ٹیسٹوں میں خامیاں تلاش کیں۔
- میں نے AI کی "آپ کے ٹیسٹ اچھے ہیں" کی تعریف کو یقین دہانی کے طور پر نہیں لیا۔
- میں نے چیک کیا کہ ہر ٹیسٹ اصل دعویٰ، آزاد متوقع قدر، اور کاروباری اصول کی تصدیق کرتا ہے۔