وہ ٹیسٹر جس کے پاس 10 سرٹیفیکیشنز تھیں لیکن وہ ایک بگ بھی نہ ڈھونڈ سکا
آپ کے پاس ہر قسم کی سرٹیفیکیشن موجود ہے۔ ISTQB، ScrumMaster، کلاؤڈ، اور سیکیورٹی۔ آپ کا ریزیومے مخففوں (acronyms) سے بھرا ہوا ہے۔
لیکن آپ ایک بھی ایسا ٹیسٹ نہیں لکھ سکتے جو کوئی حقیقی بگ (bug) ڈھونڈ سکے۔
میں نے گزشتہ سہ ماہی میں ایک امیدوار کا انٹرویو لیا۔ وہ صرف نظریاتی باتیں کر رہا تھا۔ اس نے V-model اور shift-left کا ذکر کیا۔ جب میں نے اس سے وہ ایک ٹیسٹ دکھانے کو کہا جو اس نے لکھا ہو اور جس نے کوئی بگ پکڑا ہو، تو وہ خاموش رہا۔
اس نے کبھی ایسا ٹیسٹ نہیں لکھا تھا جس نے کسی چیز کو خراب (break) کیا ہو۔ اس نے صرف وہی ٹیسٹ لکھے جو پاس ہو گئے۔
سرٹیفیکیشنز آپ کی یادداشت کا امتحان لیتی ہیں۔ بگ آپ کی سوچ کا امتحان لیتے ہیں۔
سرٹیفیکیشنز آپ کو اصطلاحات اور ڈھانچہ فراہم کرتی ہیں۔ وہ آپ کو ریکروٹر کے اسکریننگ مرحلے سے گزرنے میں مدد دیتی ہیں۔ وہ آپ کو نقص (defects) تلاش کرنا نہیں سکھاتیں۔
امتحانی سوالات ایک نصاب (syllabus) پر مبنی ہوتے ہیں۔ حقیقی ایپلی کیشنز ایسا نہیں کرتیں۔ لاگ ان فارم کا کوئی نصاب نہیں ہوتا۔ اس میں عجیب و غریب 'ایج کیسز' (edge cases) ہوتے ہیں، جیسے سرور کی گھڑی کا چار منٹ پیچھے ہونا یا مخصوص ٹائمنگ کے مسائل۔
سرٹیفائیڈ ٹیسٹر ایک چیک لسٹ پر عمل کرتا ہے۔ وہ ضروریات (requirements) کی بنیاد پر ٹیسٹ لکھتا ہے اور انہیں پاس یا فیل کے طور پر نشان زد کرتا ہے۔
بگ ہنٹر (bug hunter) ٹیسٹنگ کو ایک تحقیقات کے طور پر لیتا ہے۔ وہ ایک مفروضے (hypothesis) سے آغاز کرتا ہے۔ وہ ایپلی کیشن کو غلط ثابت کرنے کی کوشش کرتا ہے۔
سوچ کے اس فرق کو دیکھیں۔
ایک معیاری ٹیسٹ 'ہیپی پاتھ' (happy path) کو چیک کرتا ہے:
- پروڈکٹس پر جائیں۔
- کارٹ میں شامل کریں۔
- کارڈ کی درست تفصیلات درج کریں۔
- آرڈر کی تصدیق کی توقع رکھیں۔
یہ ٹیسٹ ثابت کرتا ہے کہ فیچر کام کر رہا ہے جب سب کچھ مکمل طور پر درست ہو۔ یہ کبھی کوئی بگ نہیں ڈھونڈ پائے گا۔
ایک بگ ہنٹر کا ٹیسٹ مشکوک ہوتا ہے:
- کارڈ نمبر میں غلطی (typo) کے ساتھ درج کریں۔
- ایرر میسج (error message) کی توقع رکھیں۔
- چیک کریں کہ آرڈر کی تصدیق پھر بھی ظاہر نہ ہوئی ہو۔
دوسرا ٹیسٹ یہ فرض کرتا ہے کہ ایپلی کیشن فیل ہو جائے گی۔ یہ پوچھتا ہے: "یہ کہاں ٹوٹے گا (break ہوگا)؟"
بہت سے ٹیسٹرز کے تجربے میں کمی ہوتی ہے، ان کے ریزیومے میں نہیں۔ آپ نے دیکھا ہوگا کہ ٹیسٹ غلط ڈیٹا یا ڈاؤن انوائرمنٹ کی وجہ سے فیل ہو جاتے ہیں۔ آپ نے ٹیسٹ اس لیے فیل ہوتے نہیں دیکھے کیونکہ آپ نے لاجک (logic) میں کوئی نقص ڈھونڈ لیا ہو۔
نئے امتحانات کی تیاری کرنا چھوڑ دیں۔ ایسے ٹیسٹ لکھ کر اس خلا کو پُر کریں جو فیل ہونے کے لیے بنائے گئے ہوں۔
یہ مشق آزمائیں: کسی ایک فیچر کا انتخاب کریں۔ اسے توڑنے (break کرنے) کی کوشش میں ایک گھنٹہ صرف کریں۔
سرچ فیچر کے لیے:
- بے معنی (gibberish) کوئریز کا ٹیسٹ کریں۔
- SQL انجیکشن (SQL injection) کریکٹرز کا ٹیسٹ کریں۔
- خالی اسٹرنگز (empty strings) کا ٹیسٹ کریں۔
فائل اپ لوڈ کے لیے:
- بغیر ایکسٹینشن (extension) والی فائلوں کا ٹیسٹ کریں۔
- بہت بڑی فائل سائز کا ٹیسٹ کریں۔
- نقصان دہ (malicious) فائل ناموں کا ٹیسٹ کریں۔
میں نے ایک بار 95% کوریج والے ایک پیمنٹ سسٹم پر کام کیا تھا۔ ہر ٹیسٹ پاس ہو گیا۔ پھر، راؤنڈنگ ایرر (rounding error) کی وجہ سے پروڈکشن میں سسٹم کو مالی نقصان ہوا۔ ہمارے ٹیسٹ 'ہیپی پاتھ' (happy path) کو کور کر رہے تھے، لیکن کسی نے ریاضیاتی منطق (math logic) کو ٹیسٹ کرنے کا نہیں سوچا۔
اب، میں ہر ٹیسٹ ایک سوال سے شروع کرتا ہوں: "اس فیچر کے خاموشی سے فیل ہونے کے لیے کیا ہونا ضروری ہوگا؟"
پورٹ فولیو سائٹ نہ بنائیں۔ اپنا LinkedIn اپ ڈیٹ نہ کریں۔
ایک ایسا ٹیسٹ لکھیں جو فیل ہونے کے لیے ہی ڈیزائن کیا گیا ہو۔ اگر یہ پاس ہو جاتا ہے، تو آپ کے پاس حفاظت کی ضمانت ہے۔ اگر یہ فیل ہو جاتا ہے، تو آپ کو ایک بگ (bug) مل گیا۔
لکھیں کہ آپ نے کیا ٹیسٹ کیا، اسے کیسے ٹیسٹ کیا، اور آپ کو کیا ملا۔ یہی اس بات کا حقیقی ثبوت ہے کہ آپ سوچ سکتے ہیں۔
وہ کون سا ایک ٹیسٹ ہے جو آپ اس ہفتے یہ ثابت کرنے کے لیے لکھیں گے کہ آپ بگ (bugs) تلاش کر سکتے ہیں؟
اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi