پانچ میں سے چار QA درخواست دہندگان یہ سیکھنا چاہتے ہیں کہ خودکار ٹیسٹ کے ساتھ کیسے کام کیا جائے۔ تمام کمپنیاں کام کے اوقات کے دوران دستی ٹیسٹرز کی ایسی خواہشات کو پورا نہیں کر سکتیں۔ Wrike نے ملازمین کے لیے آٹومیشن اسکول کا انعقاد کیا اور بہت سے لوگوں کی اس خواہش کو محسوس کیا۔ میں نے اس اسکول میں بطور QA طالب علم حصہ لیا تھا۔
میں نے سیکھا کہ سیلینیم کے ساتھ کیسے کام کرنا ہے اور اب آزادانہ طور پر ایک مخصوص تعداد میں آٹو ٹیسٹس کی حمایت کرتا ہوں جس میں عملی طور پر کوئی بیرونی مدد نہیں ہے۔ اور، ہمارے مشترکہ تجربے کے نتائج اور اپنے ذاتی نتائج کی بنیاد پر، میں آٹومیشن کے سب سے مثالی اسکول کا فارمولہ اخذ کرنے کی کوشش کروں گا۔
اسکول کو منظم کرنے میں Wrike کا تجربہ
جب آٹومیشن سکول کی ضرورت واضح ہو گئی، تو اس کی تنظیم آٹومیشن کے تکنیکی رہنما Stas Davydov کے پاس گئی۔ اس کے علاوہ اور کون بتا سکتا ہے کہ انہوں نے یہ اقدام کیوں کیا، کیا انہوں نے نتائج حاصل کیے اور کیا وہ وقت گزارے پر افسوس کرتے ہیں؟ آئیے اسے منزل دیں:
— 2016 میں، ہم نے آٹو ٹیسٹس کے لیے ایک نیا فریم ورک لکھا اور اسے بنایا تاکہ ٹیسٹ لکھنا آسان ہو جائے: عام مراحل ظاہر ہوئے، ساخت بہت زیادہ قابل فہم ہو گئی۔ ہم ایک آئیڈیا لے کر آئے ہیں: ہمیں ہر اس شخص کو شامل کرنے کی ضرورت ہے جو نئے ٹیسٹ لکھنا چاہتا ہے، اور اسے سمجھنے میں آسانی پیدا کرنے کے لیے، ہم نے لیکچرز کا ایک سلسلہ بنایا۔ ہم نے اجتماعی طور پر موضوعات کا ایک منصوبہ بنایا، مستقبل کے ہر لیکچرار نے اپنے لیے ایک ایک لیا اور اس پر ایک رپورٹ تیار کی۔
طلباء کو کیا مشکلات پیش آئیں؟
- بنیادی طور پر، بلاشبہ، فن تعمیر۔ ہمارے ٹیسٹوں کی ساخت کے بارے میں بہت سے سوالات تھے۔ تاثرات میں، اس موضوع پر بہت کچھ لکھا گیا اور ہمیں مزید تفصیل سے بیان کرنے کے لیے اضافی لیکچرز کا انعقاد کرنا پڑا۔
- کیا اسکول نے ادائیگی کی؟
- ہاں، ضرور۔ اس کا شکریہ، بہت سارے لوگ ٹیسٹ لکھنے میں شامل تھے، اور، اوسطا، ہسپتال میں، ہر کوئی بہتر طور پر سمجھنا شروع کر دیا کہ آٹو ٹیسٹ کیا ہیں، وہ کیسے لکھے جاتے ہیں اور کیسے شروع کیے جاتے ہیں. آٹومیشن انجینئرز پر بوجھ بھی کم ہو گیا ہے: اب ہمیں ٹیسٹوں کے تجزیہ میں مدد کے لیے کئی گنا کم درخواستیں موصول ہوتی ہیں، کیونکہ ٹیسٹرز اور ڈویلپرز نے تقریباً تمام حالات میں خود اس کا مقابلہ کرنا شروع کر دیا ہے۔ ٹھیک ہے، محکمے کے لیے کئی داخلی فوائد ہیں: ہم نے پریزنٹیشنز اور لیکچرز میں تجربہ حاصل کیا، جس کی بدولت کچھ آٹومیشن انجینئر پہلے ہی کانفرنسوں میں پریزنٹیشنز دینے میں کامیاب ہو چکے ہیں، اور نئے آنے والوں کو آن بورڈ کرنے کے لیے ویڈیوز اور پریزنٹیشنز کا ایک طاقتور سیٹ بھی ملا ہے۔
اپنی طرف سے، میں یہ شامل کروں گا کہ ہمارے محکموں کے درمیان رابطے کو ایک مضحکہ خیز حد تک آسان سطح تک آسان بنایا گیا ہے۔ مثال کے طور پر، اب مجھے عملی طور پر یہ سوچنے کی ضرورت نہیں ہے کہ کون سے معاملات اور ایٹم کی کس سطح پر خودکار ہونا ہے۔ نتیجے کے طور پر، تمام دلچسپی رکھنے والے فریق ٹیسٹ کی کوریج کا پورا خیال رکھ رہے ہیں، جو مسلسل بڑھ رہی ہے۔ کوئی بھی دوسرے سے ناممکن کا مطالبہ نہیں کرتا۔
عام طور پر، ٹیموں کے کام پر اثر یقینی طور پر مثبت ہے. شاید اس مضمون کو پڑھنے والے ساتھی بھی کچھ ایسا ہی کرنے کے بارے میں سوچ رہے ہوں؟ تب مشورہ آسان ہو جائے گا: یہ اس کے قابل ہے اگر خودکار ٹیسٹ آپ کے لیے ترجیح ہوں۔ اگلا، ہم ایک زیادہ پیچیدہ سوال کے بارے میں بات کریں گے: ان سب کو جتنا ممکن ہو درست طریقے سے کیسے ترتیب دیا جائے، تاکہ تمام فریقین کے اخراجات کم سے کم ہوں اور پیداوار زیادہ سے زیادہ ہو۔
آرگنائزنگ ٹپس
اسکول مفید تھا، لیکن، جیسا کہ Stas نے اعتراف کیا، کچھ مشکلات تھیں، جن کی وجہ سے اضافی لیکچرز کا بندوبست کرنا ضروری تھا۔ اور یہ حال ہی میں ایک طالب علم کے طور پر اپنے آپ سے لاعلمی میں اور خود کا موازنہ کر رہا تھا کہ میں نے اپنی رائے میں، ٹیسٹرز کو خودکار ٹیسٹوں کو سمجھنا سکھانے کا مثالی طریقہ بنانے کے لیے درج ذیل اقدامات مرتب کیے ہیں۔
مرحلہ 0۔ ایک لغت بنائیں
بلاشبہ، یہ قدم نہ صرف QA کے لیے ضروری ہے۔ تاہم، میں اسے واضح کرنا چاہتا ہوں: آٹومیشن کوڈ بیس کو پڑھنے کے قابل شکل میں رکھنا چاہیے۔ پروگرامنگ زبانیں - کم از کم نہیں۔ زبانیں، اور اس سے آپ اپنی غوطہ خوری شروع کر سکتے ہیں۔
یہاں عناصر کے ناموں کے ساتھ ٹاسک ویو کا اسکرین شاٹ ہے۔ آئیے تصور کریں کہ آپ ٹاسک ویو کو بلیک باکس کے طور پر جانچ رہے ہیں اور آپ نے اپنی زندگی میں کبھی سیلینیم نہیں دیکھا ہے۔ یہ کوڈ کیا کرتا ہے؟
(سپوئلر - ایڈمن کی جانب سے کام کو آرام کے ذریعے حذف کر دیا جاتا ہے، اور پھر ہم دیکھتے ہیں کہ اس سلسلے میں اس کا ریکارڈ موجود ہے۔)
یہ قدم ہی QAA اور QA زبانوں کو ایک دوسرے کے قریب لاتا ہے۔ آٹومیشن ٹیموں کے لیے رن کے نتائج کی وضاحت کرنا آسان ہے؛ دستی ٹیسٹرز کو کیسز بنانے پر کم محنت کرنی پڑتی ہے: انہیں کم تفصیل سے بنایا جا سکتا ہے۔ پھر بھی، سب ایک دوسرے کو سمجھتے ہیں۔ ہمیں اصل تربیت شروع ہونے سے پہلے ہی جیت مل گئی۔
مرحلہ 1۔ جملے دہرائیں۔
آئیے زبان کے ساتھ متوازی جاری رکھیں۔ جب ہم بچپن میں بولنا سیکھتے ہیں، تو ہم ایٹمولوجی اور سیمنٹکس سے شروع نہیں کرتے۔ ہم "ماں"، "ایک کھلونا خریدیں" کو دہراتے ہیں، لیکن فوری طور پر ان الفاظ کی پروٹو-انڈو-یورپی جڑوں میں نہیں جاتے ہیں۔ تو یہ یہاں ہے: آٹوٹیسٹ کی تکنیکی خصوصیات کی بہت گہرائیوں میں ڈوبنے کا کوئی فائدہ نہیں ہے بغیر کچھ لکھنے کی کوشش کریں جو کام کرے۔
یہ تھوڑا سا متضاد لگتا ہے، لیکن یہ کام کرتا ہے۔
پہلے سبق میں، یہ ایک بنیاد دینے کے قابل ہے کہ آٹو ٹیسٹس کو براہ راست کیسے لکھا جائے۔ ہم ترقی کے ماحول کو ترتیب دینے میں مدد کرتے ہیں (میرے معاملے میں، Intellij IDEA)، کم از کم زبان کے قواعد کی وضاحت کرتے ہیں جو موجودہ مراحل کو استعمال کرتے ہوئے موجودہ کلاس میں دوسرا طریقہ لکھنے کے لیے ضروری ہیں۔ ہم ان کے ساتھ ایک یا دو ٹیسٹ لکھتے ہیں اور انہیں ہوم ورک دیتے ہیں، جسے میں اس طرح فارمیٹ کروں گا: ایک شاخ ماسٹر سے الگ ہو گئی، لیکن اس سے کئی ٹیسٹ ہٹا دیے گئے ہیں۔ صرف ان کی تفصیل باقی ہے۔ ہم ٹیسٹرز سے ان ٹیسٹوں کو بحال کرنے کو کہتے ہیں (یقیناً شو ڈف کے ذریعے نہیں)۔
نتیجے کے طور پر، جس نے سب کچھ سنا اور کیا وہ اس قابل ہو جائے گا:
- ترقیاتی ماحول کے انٹرفیس کے ساتھ کام کرنا سیکھیں: برانچز، ہاٹکیز، کمٹ اور پشز بنانا؛
- زبان اور کلاسوں کے ڈھانچے کی بنیادی باتوں پر عبور حاصل کریں: انجیکشن کہاں داخل کرنا ہے اور کہاں سے درآمد کرنا ہے، تشریحات کی ضرورت کیوں ہے، اور مراحل کے علاوہ وہاں کس قسم کی علامتیں پائی جاتی ہیں؛
- عمل کے درمیان فرق کو سمجھیں، انتظار کریں اور چیک کریں، کہاں کیا استعمال کرنا ہے؛
- آٹو ٹیسٹس اور مینوئل چیک کے درمیان فرق کو دیکھیں: آٹو ٹیسٹس میں آپ انٹرفیس کے ذریعے کارروائیاں کرنے کے بجائے ایک یا دوسرے ہینڈلر کو کھینچ سکتے ہیں۔ مثال کے طور پر، ٹاسک ویو کھولنے، ان پٹ کو منتخب کرنے، ٹیکسٹ ٹائپ کرنے اور بھیجیں بٹن پر کلک کرنے کے بجائے براہ راست بیک اینڈ پر تبصرہ بھیجیں۔
- سوالات تیار کریں جن کا جواب اگلے مرحلے میں دیا جائے گا۔
آخری نکتہ بہت اہم ہے۔ یہ جوابات آسانی سے وقت سے پہلے دیے جا سکتے ہیں، لیکن یہ ایک اہم تدریسی اصول ہے کہ بغیر مرتب سوالات کے جوابات یاد نہیں رہتے اور جب ضرورت ہو تو استعمال نہیں کیے جاتے۔
یہ مثالی ہوگا اگر اس وقت QA ٹیم کے ایک آٹومیشن انجینئر نے اسے جنگ میں دو ٹیسٹ لکھنے کا کام تفویض کیا اور اسے اپنی برانچ میں ذیلی کام کرنے کی اجازت دی۔
کیا نہیں دینا ہے:
- ترقیاتی ماحول اور خود پروگرامنگ زبان کی فعالیت کے بارے میں زیادہ گہرائی سے علم، جس کی ضرورت صرف اس وقت ہوگی جب شاخوں کے ساتھ آزادانہ طور پر کام کریں۔ یہ یاد نہیں رہے گا، آپ کو اسے دو تین بار سمجھانا پڑے گا، لیکن ہم آٹومیشن انجینئرز کے وقت کی قدر کرتے ہیں، ٹھیک ہے؟ مثالیں: تنازعات کو حل کرنا، گٹ میں فائلیں شامل کرنا، شروع سے کلاسز بنانا، انحصار کے ساتھ کام کرنا؛
- xpath سے متعلق ہر چیز۔ سنجیدگی سے۔ آپ کو اس کے بارے میں الگ الگ، ایک بار اور بہت توجہ کے ساتھ بات کرنے کی ضرورت ہے۔
مرحلہ 2۔ گرامر کو قریب سے دیکھنا
آئیے مرحلہ نمبر 0 سے ٹاسک ویو اسکرین شاٹ یاد رکھیں۔ ہمارے پاس ایک قدم ہے جسے checkCommentWithTextExists کہتے ہیں۔ ہمارا ٹیسٹر پہلے ہی سمجھتا ہے کہ یہ قدم کیا کرتا ہے اور ہم اس قدم کے اندر دیکھ سکتے ہیں اور اسے تھوڑا سا گل سکتے ہیں۔
اور ہمارے اندر درج ذیل ہیں:
onCommentBlock(userName).comment(expectedText).should(displayed());جہاں onCommentBlock ہے۔
onCommonStreamPanel().commentBlock(userName);اب ہم یہ کہنا سیکھتے ہیں کہ "ایک کھلونا خریدو" نہیں بلکہ "ڈیٹسکی میر اسٹور سے ایک کھلونا خریدیں، جو اوپر سے تیسرے شیلف پر نیلی کیبنٹ میں واقع ہے۔" یہ وضاحت کرنا ضروری ہے کہ ہم بڑے عناصر سے ترتیب وار ایک عنصر کی طرف اشارہ کرتے ہیں (سٹریم -> کسی خاص شخص کے تبصروں کے ساتھ بلاک -> اس بلاک کا وہ حصہ جہاں مخصوص متن بیٹھتا ہے)۔
نہیں، ابھی بھی وقت نہیں آیا کہ xpath کے بارے میں بات کریں۔ صرف مختصراً یہ بتا دیں کہ یہ تمام ہدایات انہی کی طرف سے بیان کی گئی ہیں اور وراثت انہی سے چلی جاتی ہے۔ لیکن ہمیں ان تمام میچرز اور ویٹروں کے بارے میں بات کرنے کی ضرورت ہے؛ وہ خاص طور پر اس قدم سے متعلق ہیں اور یہ سمجھنے کے لیے ضروری ہیں کہ کیا ہو رہا ہے۔ لیکن اوورلوڈ نہ کریں: آپ کا طالب علم بعد میں خود مزید پیچیدہ دعووں کا مطالعہ کر سکتا ہے۔ زیادہ تر امکان، چاہیے، انتظار تک، ظاہر ()؛، موجود ()؛، نہیں ()؛ کافی ہونا چاہیے۔
ہوم ورک واضح ہے: ایک شاخ جس میں متعدد مراحل کے مندرجات کو ہٹا دیا گیا ہے جو ایک مخصوص تعداد میں ٹیسٹ کے لیے ضروری ہیں۔ ٹیسٹرز کو انہیں بحال کرنے دیں اور رن کو دوبارہ سبز ہونے دیں۔
مزید برآں، اگر ٹیسٹنگ ٹیم کے کام میں نہ صرف نئی خصوصیات ہیں، بلکہ کچھ بگ فکسز بھی ہیں، تو آپ اس سے فوری طور پر ان بگز کے لیے ٹیسٹ لکھنے اور انہیں جاری کرنے کے لیے کہہ سکتے ہیں۔ غالباً، تمام عناصر پہلے ہی بیان کیے جا چکے ہیں؛ صرف چند قدم غائب ہو سکتے ہیں۔ یہ کامل ورزش ہوگی۔
مرحلہ 3۔ مکمل وسرجن
ایک ٹیسٹر کے لیے جتنا ممکن ہو مکمل ہو جو اپنے براہ راست فرائض کی انجام دہی جاری رکھے گا۔ آخر میں، ہمیں xpath کے بارے میں بات کرنے کی ضرورت ہے۔
سب سے پہلے ہم یہ واضح کر دیتے ہیں کہ یہ تمام onCommentBlock اور تبصرہ انہی کے ذریعہ بیان کیا گیا ہے۔
کل:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"کہانی کی ترتیب بہت اہم ہے۔ سب سے پہلے، ہم کسی بھی موجودہ ایکس پاتھ کو لیتے ہیں اور یہ ظاہر کرتے ہیں کہ عناصر کے ٹیب میں کس طرح ایک اور صرف ایک عنصر شامل ہے۔ اگلا، ہم ساخت کے بارے میں بات کریں گے: کب آپ کو WebElement استعمال کرنے کی ضرورت ہے، اور جب آپ کو ایک نئے عنصر کے لیے علیحدہ فائل بنانے کی ضرورت ہے۔ یہ آپ کو وراثت کو بہتر طور پر سمجھنے کی اجازت دے گا۔
یہ واضح طور پر بیان کیا جانا چاہیے کہ ایک واحد عنصر پورا ٹاسک ویو ہے، اس میں ایک چائلڈ عنصر شامل ہے - پورا سلسلہ، جس میں چائلڈ عنصر شامل ہے - ایک الگ تبصرہ وغیرہ۔ چائلڈ عناصر صفحہ پر اور آٹوٹیسٹ فریم ورک کے ڈھانچے دونوں میں پیرنٹ عناصر کے اندر ہوتے ہیں۔
اس مقام پر، سامعین کو مضبوطی سے سمجھنا چاہیے تھا کہ وہ کیسے وراثت میں ہیں اور onCommentBlock پر ڈاٹ کے بعد کیا درج کیا جا سکتا ہے۔ اس مقام پر، ہم تمام آپریٹرز کی وضاحت کرتے ہیں: /, //, ., [] وغیرہ۔ ہم بوجھ میں استعمال کے بارے میں علم شامل کرتے ہیں۔ @class اور دیگر ضروری چیزیں۔
طلباء کو سمجھنا چاہئے کہ اس طرح xpath کا ترجمہ کیسے کیا جائے۔ مضبوط کرنے کے لئے - یہ صحیح ہے، ہوم ورک. ہم عناصر کی تفصیل کو حذف کرتے ہیں، انہیں ٹیسٹ کے کام کو بحال کرنے دیں۔
یہ خاص راستہ کیوں؟
ہمیں پیچیدہ علم والے شخص پر بوجھ نہیں ڈالنا چاہیے، لیکن ہمیں ایک ہی وقت میں ہر چیز کی وضاحت کرنی چاہیے، اور یہ ایک مشکل مخمصہ ہے۔ یہ راستہ ہمیں سب سے پہلے سامعین کو سوالات کرنے اور کچھ نہ سمجھنے اور اگلے ہی لمحے جواب دینے کی اجازت دے گا۔ اگر آپ پورے فن تعمیر کی بات کریں، تو جب تک اسٹیپس یا ایکس پاتھ کے موضوع کا تجزیہ کیا جائے گا، اس کے اہم ترین حصے اپنی نا سمجھی کی وجہ سے پہلے ہی بھول چکے ہوں گے۔
تاہم، آپ میں سے کچھ لوگ ممکنہ طور پر اس بارے میں اپنے تجربے کا اشتراک کرنے کے قابل ہوں گے کہ اس عمل کو مزید کس طرح بہتر بنایا جا سکتا ہے۔ مجھے تبصرے میں اسی طرح کی تجاویز پڑھ کر خوشی ہوگی!
ماخذ: www.habr.com