یہ مضمون ان لوگوں کے لیے دلچسپی کا باعث ہو گا جنہیں، ہماری طرح، صحیح ٹیسٹنگ ماہر کی تلاش کے مسئلے کا سامنا کرنا پڑا ہے۔
عجیب بات یہ ہے کہ جیسے جیسے ہماری جمہوریہ میں آئی ٹی کمپنیوں کی تعداد بڑھتی ہے، اہل پروگرامرز کی تعداد بڑھتی ہے، ٹیسٹرز کی نہیں۔ بہت سے لوگ اس پیشے میں داخل ہونے کے خواہشمند ہیں، لیکن بہت کم لوگ اس کا مقصد سمجھتے ہیں۔

میں تمام IT کمپنیوں کے لیے بات نہیں کر سکتا، لیکن ہم نے QA/QC کا کردار اپنے کوالٹی ایشورنس ماہرین کو تفویض کر دیا ہے۔ وہ ترقیاتی ٹیم کا حصہ ہیں اور تحقیق سے لے کر نئے ورژن کے اجراء تک ترقی کے تمام مراحل میں حصہ لیتے ہیں۔
ٹیم کے ایک ٹیسٹر کو، یہاں تک کہ منصوبہ بندی کے مرحلے کے دوران، صارف کی کہانی کی قبولیت کے لیے تمام فعال اور غیر فعال تقاضوں پر غور کرنا چاہیے۔ انہیں پروڈکٹ کی آپریشنل خصوصیات کے بارے میں اتنا ہی علم ہونا چاہیے جتنا کہ پروگرامرز، اگر بہتر نہ ہوں، اور ٹیم کو منصوبہ بندی کے مرحلے کے دوران بھی غلط فیصلے کرنے سے بچنے میں مدد کریں۔ ایک ٹیسٹر کو اس بات کی واضح سمجھ ہونی چاہیے کہ کس طرح عمل میں لایا جا رہا فعالیت کام کرے گا اور کیا نقصانات پیدا ہو سکتے ہیں۔ ہمارے ٹیسٹرز خود ٹیسٹ پلان اور ٹیسٹ کیسز بناتے ہیں، ساتھ ہی تمام ضروری ٹیسٹ سیٹ اپ تیار کرتے ہیں۔ بندر پر کلک کرنے والے کی طرح تیار کردہ تفصیلات کے خلاف جانچ کرنا ہمارا اختیار نہیں ہے۔ ٹیم کے اندر کام کرتے ہوئے، انہیں ایک قابل پروڈکٹ فراہم کرنے میں مدد کرنی چاہیے اور اگر کچھ غلط ہو جائے تو فوری طور پر الارم بجائیں۔
ٹیسٹرز کی تلاش میں ہمیں کیا سامنا کرنا پڑا
متعدد ریزیوموں کا جائزہ لینے کے دوران، ایسا لگتا تھا کہ ہمارے لیے صحیح تجربہ رکھنے والے ماہرین موجود ہیں، اور ہماری ٹیم کے لیے ٹیسٹر کی تلاش میں کوئی حرج نہیں ہوگا۔ تاہم، ذاتی ملاقاتوں کے دوران، ہم نے تیزی سے ایسے امیدواروں کا سامنا کیا جو درحقیقت انفارمیشن ٹیکنالوجی کی دنیا سے بالکل ناواقف تھے (مثال کے طور پر، وہ براؤزر ویب سرور کے تعامل کے اصولوں، سیکورٹی کی بنیادی باتیں، رشتہ دار اور غیر متعلقہ ڈیٹا بیس کی وضاحت نہیں کر سکے، یا ورچوئلائزیشن یا کنٹینرائزیشن کی کوئی سمجھ نہیں رکھتے تھے)، پھر بھی وہ اپنے آپ کو QA کی سطح پر سمجھتے تھے۔ درجنوں انٹرویوز کرنے کے بعد، ہم نے نتیجہ اخذ کیا کہ خطے میں موزوں ماہرین کی تعداد نہ ہونے کے برابر تھی۔
اس کے بعد، میں آپ کو بتاؤں گا کہ ہم نے کیا اقدامات کیے اور ان کوالٹی فائٹرز کو تلاش کرنے کے لیے کیا غلطیاں کیں جن کا طویل انتظار تھا۔
ہم نے کس طرح صورتحال کو ٹھیک کرنے کی کوشش کی۔
سورسنگ ریڈی میڈ ماہرین کے ساتھ جدوجہد کرنے کے بعد، ہم نے قریبی علاقوں کو نشانہ بنانا شروع کیا:
- ہم نے "چھوڑنے والوں" کے گروہ میں سے، ان لوگوں کی شناخت کے لیے تشخیصی طریقوں کو لاگو کرنے کی کوشش کی جن سے ہم مضبوط ماہرین تیار کر سکتے ہیں۔
ہم نے ممکنہ امیدواروں کے ایک گروپ سے تقریباً ایک ہی سطح کے علم کے ساتھ کاموں کو مکمل کرنے کے لیے کہا۔ ان کے سوچنے کے عمل کو دیکھ کر، ہم نے سب سے زیادہ امید افزا امیدوار کی شناخت کرنے کی کوشش کی۔
دیگر چیزوں کے علاوہ، ہم نے توجہ، ٹیکنالوجی کی صلاحیتوں کو سمجھنے، اور کثیر الثقافتی کی خصوصیات کو جانچنے کے لیے کام تیار کیے ہیں:
- پیشے کے بارے میں موجودہ دستے کی سمجھ کو وسیع کرنے کے لیے ہم نے ٹیسٹرز کے لیے ملاقاتیں کیں۔
میں آپ کو ان میں سے ہر ایک کے بارے میں تھوڑا سا بتاؤں گا۔
Ufa سافٹ ویئر QA اور ٹیسٹنگ میٹ اپ #1 ہماری پہلی کوشش تھی کہ پیشے کے بارے میں پرجوش لوگوں کو اکٹھا کیا جائے اور ساتھ ہی اس بات کا تعین کیا جائے کہ آیا سامعین اس میں دلچسپی لیں گے جو ہم بتانا چاہتے ہیں۔ اگر آپ پہلے ہی ٹیسٹر بننے کا فیصلہ کر چکے ہیں تو ہماری پیشکشیں بنیادی طور پر شروع کرنے کے لیے بہترین جگہ پر مرکوز ہیں۔ ہم نئے آنے والوں کی آنکھیں کھولنے اور جانچ کے لیے زیادہ پختہ انداز اختیار کرنے میں مدد کرنا چاہتے تھے۔ ہم نے پیشے میں شروع کرنے کے لیے امتحان دینے والوں کو جو اقدامات کرنے کی ضرورت ہے، معیار کی تعریف اور اسے حقیقی دنیا کی ترتیبات میں کیسے حاصل کیا جائے، اور خودکار ٹیسٹنگ کے تصور اور اس کے عملی اطلاق پر تبادلہ خیال کیا۔

اس کے بعد ہم نے دو اور ملاقاتیں کیں، جن میں 1-2 ماہ کا وقفہ تھا۔ شرکاء کی تعداد دوگنی ہوگئی۔ "Ufa Software QA اور ٹیسٹنگ میٹ اپ #2" میں، ہم نے موضوع کی گہرائی تک رسائی حاصل کی۔ ہم نے بگ ٹریکنگ سسٹمز، UI/UX ٹیسٹنگ، Docker، Ansible کا احاطہ کیا اور ڈویلپرز اور ٹیسٹرز کے درمیان ممکنہ تنازعات اور انہیں حل کرنے کے طریقہ پر تبادلہ خیال کیا۔ہمارا تیسرا میٹ اپ، "Ufa سافٹ ویئر QA اور ٹیسٹنگ میٹ اپ #3" بالواسطہ طور پر ٹیسٹرز کے کام سے متعلق تھا، لیکن پروگرامرز کو ان کی تکنیکی اور تنظیمی ذمہ داریوں کی یاد دلانے کے لیے مفید تھا: لوڈ ٹیسٹنگ، e2e ٹیسٹنگ، خودکار جانچ میں سیلینیم، اور ویب ایپلیکیشن کی کمزوریاں۔
اس سارے عرصے میں، ہم اپنے ایونٹس سے نشریات کے لیے مناسب روشنی اور آواز بنانے کا طریقہ سیکھ رہے ہیں:
→
→
→ - اور آخر میں، ہم نے ٹیسٹرز کے لیے ہیکاتھون منعقد کرنے کی کوشش کرنے کا فیصلہ کیا۔
ٹیسٹرز کے لیے ہیکاتھون کیسے تیار اور منعقد کیا گیا۔
شروع کرنے کے لیے، ہم نے یہ سمجھنے کی کوشش کی کہ یہ "حیوان" کیا ہے اور یہ عام طور پر کیسے چلایا جاتا ہے۔ جیسا کہ یہ نکلا، روس میں اس قسم کے واقعات اکثر منعقد نہیں ہوتے تھے، اور خیالات کے لیے کوئی دوسرا ذریعہ نہیں تھا۔ دوم، ہم فوری طور پر بہت سارے وسائل کی سرمایہ کاری نہیں کرنا چاہتے تھے جو ایک مشکوک اقدام کی طرح لگتا تھا۔ لہٰذا، ہم نے مختصر منی ہیکاتھنز کو منظم کرنے کا فیصلہ کیا، پورے QA سائیکل کو کور کرنے کے بجائے انفرادی مراحل پر توجہ مرکوز کرتے ہوئے۔
ہمارا بنیادی چیلنج مقامی ٹیسٹرز کے درمیان واضح ٹیسٹ نقشے بنانے میں مشق کی کمی ہے۔ وہ صارف کی کہانیوں کو نافذ کرنے اور فنکشنل اور غیر فنکشنل تقاضوں، UI/UX، سیکورٹی، پروڈکشن، اور چوٹی کے بوجھ کے لیے ڈویلپر کے موافق قبولیت کا معیار بنانے سے پہلے تحقیق کے لیے وقت نہیں دیتے ہیں۔ اس لیے، اپنی پہلی کوشش کے لیے، ہم نے ان کے کام کے سب سے زیادہ دلچسپ اور تخلیقی حصے کو تلاش کرنے کا فیصلہ کیا ہے — پراجیکٹ سے پہلے کی تحقیق کے دوران تقاضوں کا تجزیہ اور وضع کرنا۔
ہم نے شرکاء کی ممکنہ تعداد کا اندازہ لگایا اور فیصلہ کیا کہ ہمیں MVP ریلیز کے لیے کم از کم 5 بیک لاگز، 5 پروڈکٹس، اور 5 افراد کی ضرورت ہے جو پروڈکٹ کے مالکان کے طور پر کام کریں گے، کاروباری ضروریات کو سمجھیں گے، اور رکاوٹوں پر فیصلے کریں گے۔
ہمیں جو ملا وہ یہاں ہے: .
مرکزی خیال ایسے موضوعات کے ساتھ آنا تھا جو شرکاء کے روزمرہ کے کام سے حتی الامکان ہٹائے گئے تھے اور انہیں فینسی کی تخلیقی پروازوں کی گنجائش فراہم کی گئی تھی۔


ہم نے کیا غلطیاں کیں اور کیا بہتر کیا جا سکتا ہے؟
تشخیصی طریقوں کا استعمال، جو سیلز پیپل اور نچلے درجے کے مینیجرز کی خدمات حاصل کرنے میں بہت مقبول ہے، ہمارے وسائل پر بہت بڑا اثر تھا، لیکن اس نے ہمیں ہر امیدوار پر کافی توجہ دینے اور ان کی صلاحیتوں کا جائزہ لینے کی اجازت نہیں دی۔ مجموعی طور پر، اس قسم کا انتخاب کمپنی کی ایک منفی تصویر بناتا ہے، کیونکہ بہت سے لوگوں کو ناکافی رائے ملتی ہے اور اس کے نتیجے میں وہ اپنے اور دوسروں میں آجر کی من مانی کا تصور پیدا کرتے ہیں (آئی ٹی کمیونٹی میں بات چیت بہت زیادہ ترقی یافتہ ہے)۔ نتیجے کے طور پر، ہمارے پاس لفظی طور پر دو ممکنہ امیدوار رہ گئے جن کے امکانات بہت کم تھے۔
ملاقاتیں اچھی چیز ہیں۔ وہ تعاون کے لیے ایک وسیع بنیاد بناتے ہیں، اور شرکت کی مجموعی سطح بہتر ہوتی ہے۔ کمپنی مارکیٹ میں تیزی سے پہچانی جاتی ہے۔ تاہم، ایسے اقدامات کافی محنت طلب ہوتے ہیں۔ یہ سمجھنا ضروری ہے کہ میٹنگز چلانے کے لیے ہر سال تقریباً 700-800 آدمی گھنٹے درکار ہوں گے۔
ٹیسٹرز کے ہیکاتھون کے بارے میں، اس قسم کے ایونٹس ابھی بورنگ نہیں ہوئے ہیں، کیونکہ ڈیولپرز کے لیے ہیکاتھون کے برعکس، ان کا انعقاد بہت کم ہوتا ہے۔ اس آئیڈیا کا فائدہ یہ ہے کہ یہ بڑی مقدار میں عملی علم کو غیر بورنگ انداز میں شیئر کرنے کی اجازت دیتا ہے اور ہر شریک کی سطح کا کافی حد تک درست اندازہ لگانے کی اجازت دیتا ہے۔
ایونٹ کے نتائج کا تجزیہ کرنے کے بعد، ہمیں احساس ہوا کہ ہم نے بہت سی غلطیاں کی ہیں:
- سب سے ناقابل معافی غلطی یہ سوچ رہی تھی کہ 4-5 گھنٹے کافی ہوں گے۔ آخر میں، بیک لاگز کا صرف تعارف اور جائزہ لینے میں تقریباً 2 گھنٹے لگے۔
ابتدائی مرحلے میں پروڈکٹ کے مالکان کے ساتھ کام کرنے اور خود کو موضوع میں غرق کرنے میں اتنا ہی وقت لگا۔ لہذا، باقی وقت واضح طور پر ٹیسٹنگ روڈ میپس کو مکمل طور پر تیار کرنے کے لیے کافی نہیں تھا۔ - ہر نقشے پر تفصیلی رائے دینے کے لیے کافی وقت یا توانائی نہیں تھی کیونکہ یہ پہلے ہی رات کا وقت تھا۔ لہذا، ہم اس حصے میں واضح طور پر ناکام رہے، جس کا اصل مقصد ہیکاتھون کا سب سے قیمتی حصہ ہونا تھا۔
- ہم نے تمام شرکاء کے ساتھ صرف ووٹ دے کر، بہترین کام کے لیے فی ٹیم تین ووٹ مختص کر کے کام کے معیار کا جائزہ لینے کا فیصلہ کیا۔ شاید ایک جیوری بہتر ہوتا۔
ہم نے کیا حاصل کیا ہے؟
ہم نے اپنا مقصد جزوی طور پر حاصل کر لیا ہے، اور اب ہمارے پاس چار ڈیشنگ، خوبصورت لوگ ہمارے لیے کام کر رہے ہیں، جو چار ترقیاتی ٹیموں کے عقب میں ہیں۔ ہم نے ابھی تک ممکنہ مضبوط امیدواروں کا کوئی اہم پول یا شہر کی QA کمیونٹی میں کوئی قابل ذکر تبدیلیاں نہیں دیکھی ہیں۔ تاہم، کچھ بہتری آئی ہے، اور یہ حوصلہ افزا ہے۔
ماخذ: www.habr.com

