ارے حبر!
ہمارے پاس ایک نیا اہم موضوع ہے - آئی ٹی مصنوعات کی اعلیٰ معیار کی ترقی۔ HighLoad++ میں ہم اکثر اس بارے میں بات کرتے ہیں کہ کس طرح مصروف خدمات کو تیز کیا جائے، اور Frontend Conf میں ہم ایک اچھے صارف انٹرفیس کے بارے میں بات کرتے ہیں جو سست نہیں ہوتا ہے۔ ہمارے پاس باقاعدگی سے جانچ کے بارے میں عنوانات ہوتے ہیں، اور مختلف عملوں کو یکجا کرنے کے بارے میں DevOpsConf، بشمول ٹیسٹنگ۔ لیکن عام طور پر معیار کو کیا کہا جا سکتا ہے، اور اس پر جامع طریقے سے کیسے کام کیا جائے - نہیں.
آئیے اسے ٹھیک کرتے ہیں۔ - ہم ترقی کے ہر مرحلے پر صارف کے لیے حتمی مصنوعات کے معیار کے بارے میں سوچنے کا کلچر تیار کریں گے۔ اپنی ذمہ داری کے شعبے پر توجہ نہ دینے کی عادت، اور معیار کو نہ صرف ٹیسٹرز کے ساتھ جوڑنا۔
کٹ کے نیچے ہم پروگرام کمیٹی کے سربراہ، Tinkoff.Business میں ٹیسٹنگ کے سربراہ، روسی بولنے والی QA کمیونٹی کے خالق سے بات کریں گے۔ Anastasia Aseeva-Nguyen QA صنعت کی حالت اور نئی کانفرنس کے مشن کے بارے میں۔
- Nastia ہیلو. براہ کرم ہمیں اپنے بارے میں بتائیں۔
Анастасия: میں ایک بینک میں جانچ کی قیادت کرتا ہوں اور ایک بہت بڑی ٹیم کے لیے ذمہ دار ہوں — ہم 90 سے زیادہ لوگ ہیں۔ ہمارے پاس ایک اہم کاروباری لائن ہے؛ ہم قانونی اداروں کے ماحولیاتی نظام کے ذمہ دار ہیں۔
میں نے میکانکس اور ریاضی کی تعلیم حاصل کی اور شروع میں پروگرامر بننا چاہتا تھا۔ لیکن جب مجھے ایک دلچسپ پیشکش موصول ہوئی تو میں نے خود کو ٹیسٹر کے طور پر آزمانے کا فیصلہ کیا۔ عجیب بات یہ ہے کہ یہ میری کالنگ نکلی۔ اب میں اس انڈسٹری میں اپنے تمام کام دیکھ رہا ہوں۔
میں کوالٹی ایشورنس ڈسپلن کا پرجوش پیروکار ہوں۔ میں اس بات کی پرواہ کرتا ہوں کہ کون سی مصنوعات بنائی جاتی ہیں، کمپنی میں، ٹیم میں، اور اصولی طور پر، ترقی کے عمل میں معیار کے ساتھ کیسا سلوک کیا جاتا ہے۔
یہ مجھ پر عیاں ہے۔ اس سمت میں کمیونٹی کافی بالغ نہیں ہےکم از کم روس میں۔ ہم ہمیشہ یہ نہیں سمجھتے کہ معیار کی یقین دہانی صرف تقاضوں کی تعمیل کے لیے درخواست کی جانچ کی حقیقت نہیں ہے۔ میں اس صورتحال کو بدلنا چاہوں گا۔
- آپ کوالٹی ایشورنس اور ٹیسٹنگ کے الفاظ استعمال کرتے ہیں۔ اوسط شخص کی نظر میں، یہ دونوں اصطلاحات اکثر اوورلیپ ہوجاتی ہیں۔ اگر آپ گہری کھدائی کرتے ہیں تو وہ کیسے مختلف ہوں گے؟
Anastasia: بلکہ وہ مختلف نہیں ہیں۔ ٹیسٹنگ کوالٹی ایشورنس ڈسپلن کا حصہ ہے، یہ ایک براہ راست سرگرمی ہے - یہ حقیقت ہے کہ میں کسی چیز کی جانچ کر رہا ہوں۔ درحقیقت جانچ کی بہت سی اقسام ہیں، اور مختلف قسم کے لوگ مختلف قسم کی جانچ کے ذمہ دار ہیں۔ لیکن یہاں روس میں، جب آؤٹ سورسرز کی ایک لہر نمودار ہوئی جو کمپنیوں کو ٹیسٹرز فراہم کرتے ہیں، ٹیسٹنگ کو ایک ہی قسم تک محدود کر دیا گیا۔
زیادہ تر معاملات میں، وہ صرف فنکشنل ٹیسٹنگ تک ہی محدود ہیں: وہ چیک کرتے ہیں کہ ڈویلپرز نے جو کوڈ کیا ہے وہ تصریح کے مطابق ہے اور بس۔
— براہ کرم ہمیں بتائیں کہ کوالٹی اشورینس کے اور کون سے مضامین ہیں؟ یہاں جانچ کے علاوہ اور کیا شامل ہے؟
Анастасия: کوالٹی اشورینس، سب سے پہلے اور سب سے اہم، ایک کوالٹی پروڈکٹ بنانے کے بارے میں ہے۔ یعنی، ہم اپنے آپ سے پوچھتے ہیں کہ ہماری پروڈکٹ میں کون سے معیار کے اوصاف ہونے چاہئیں۔ اس کے مطابق، اگر ہم اس کو سمجھتے ہیں، تو ہم موازنہ کر سکتے ہیں کہ ان معیار کی صفات کو کون متاثر کرتا ہے۔ کوئی فرق نہیں پڑتا، ڈویلپر، پروجیکٹ مینیجر یا پروڈکٹ ماہر وہ شخص ہے جو کسی پروڈکٹ کی ترقی، اس کے بیک لاگ اور اس کی حکمت عملی کو متاثر کرتا ہے۔
ٹیسٹر اپنے کردار سے زیادہ واقف ہو جاتا ہے۔ وہ سمجھتا ہے کہ اس کا کام نہ صرف تقاضوں کی تعمیل کے لیے جانچ کرنا ہے، بلکہ تقاضوں کی جانچ کرنا، پروڈکٹ کے ماہر سے حاصل کردہ فارمولیشنز پر سوال اٹھانا، اور کلائنٹ کی تمام مضمر ضروریات اور توقعات کو ظاہر کرنا ہے۔ جب ہم اپنے گاہک کو نئی فعالیت فراہم کرتے ہیں، تو ہمیں ان کی توقعات پر پورا اترنا اور ان کے درد کو دور کرنا چاہیے۔ اگر ہم معیار کے تمام اوصاف کے بارے میں سوچتے ہیں، تو کلائنٹ مطمئن ہو جائے گا اور سمجھے گا کہ وہ کمپنی جس کا پروڈکٹ وہ استعمال کرتا ہے واقعی اس کے مفادات کا خیال رکھتا ہے اور "صرف ایک خصوصیت جاری کرنا" کے اصول پر کام نہیں کر رہا ہے۔
- ایسا لگتا ہے کہ جو آپ نے ابھی بیان کیا ہے وہ پروڈکٹ کے ماہر کا کام ہے۔ یہ، اصولی طور پر، جانچ کے بارے میں نہیں ہے اور معیار کے بارے میں نہیں ہے - یہ عام طور پر پروڈکٹ مینجمنٹ کے بارے میں ہے، نہیں؟
Анастасия: بشمول۔ کوالٹی ایشورنس کوئی نظم و ضبط نہیں ہے جس کے لیے ایک مخصوص شخص ذمہ دار ہے۔ اب جانچ میں ایک مقبول سمت ہے، جسے ایک نقطہ نظر کہا جاتا ہے۔ فرتیلی جانچ. اس کی تعریف واضح طور پر بتاتی ہے کہ یہ جانچ کے لیے ایک ٹیم اپروچ ہے، جس میں طرز عمل کا ایک مخصوص سیٹ شامل ہے۔ پوری ٹیم اس نقطہ نظر کو نافذ کرنے کی ذمہ دار ہے؛ ٹیم میں ٹیسٹر کا ہونا بھی ضروری نہیں ہے۔ پوری ٹیم گاہک کو قدر کی فراہمی اور اس بات کو یقینی بنانے پر مرکوز ہے کہ قدر گاہک کی توقعات پر پورا اترے۔
- یہ پتہ چلتا ہے کہ معیار ارد گرد کی ہر چیز پر ایک فریم ورک مسلط کرتے ہوئے، ارد گرد کے تقریباً تمام شعبوں کو آپس میں جوڑتا ہے؟
Анастасия: ٹھیک ہے۔ جب ہم اس حقیقت کے بارے میں سوچتے ہیں کہ ہم ایک معیاری پروڈکٹ بنانا چاہتے ہیں، تو ہم معیار کی مختلف صفات کے بارے میں سوچنا شروع کر دیتے ہیں۔ مثال کے طور پر، یہ کیسے چیک کریں کہ ہم نے واقعی وہ فیچر بنایا ہے جس کی ہمارے کلائنٹ کو ضرورت ہے۔
یہ وہ جگہ ہے جہاں اس قسم کی جانچ آتی ہے: یو اے ٹی (صارف کی قبولیت کی جانچ)۔ بدقسمتی سے، روس میں شاذ و نادر ہی اس پر عمل کیا جاتا ہے، لیکن بعض اوقات آخری کلائنٹ کے ڈیمو کے طور پر SCRUM ٹیموں میں موجود ہوتا ہے۔ یہ غیر ملکی کمپنیوں میں جانچ کی کافی عام قسم ہے۔ تمام صارفین کے لیے فعالیت کھولنے سے پہلے، ہم سب سے پہلے UAT کرتے ہیں، یعنی ہم آخری صارف کو ٹیسٹ کرنے اور فوری طور پر فیڈ بیک فراہم کرنے کے لیے مدعو کرتے ہیں کہ آیا پروڈکٹ واقعی توقعات پر پورا اترتی ہے اور درد کو دور کرتی ہے۔ اس کے بعد ہی دیگر تمام کلائنٹس کی اسکیلنگ ہوتی ہے۔
یعنی، ہم کاروبار پر، آخری کلائنٹ پر توجہ مرکوز کرتے ہیں، لیکن ایک ہی وقت میں ٹیکنالوجی کے بارے میں مت بھولنا. مصنوعات کا معیار بھی ٹیکنالوجی پر بہت زیادہ منحصر ہے۔ اگر ہمارا فن تعمیر خراب ہے تو ہم فیچرز کو فوری طور پر جاری کرنے اور کسٹمر کی توقعات کو پورا کرنے کے قابل نہیں ہوں گے۔ پیمانہ بنانے کی کوشش کرتے وقت بہت سارے کیڑے ہو سکتے ہیں، یا ری فیکٹر کرنے کی کوشش کرتے وقت، ہم کسی چیز کو توڑ سکتے ہیں۔ یہ سب صارفین کی اطمینان کو متاثر کرے گا۔
اس نقطہ نظر سے، فن تعمیر اس طرح ہونا چاہئے کہ ہم صاف کوڈ لکھ سکیں جو ہمیں تیزی سے تبدیلیاں کرنے کی اجازت دے اور خوف نہ ہو کہ ہم سب کچھ توڑ دیں گے۔ اس بات کو یقینی بنانے کے لیے کہ نظر ثانی کی تکرار کئی مہینوں تک نہ پھیلے کیونکہ ہمارے پاس بہت زیادہ میراث ہے، ہمیں طویل آزمائشی مراحل کرنے کی ضرورت ہے۔
- مجموعی طور پر، ڈویلپرز، آرکیٹیکٹس، پروڈکٹ سائنسدان، پروڈکٹ مینیجر، اور ٹیسٹرز خود پہلے سے شامل ہیں۔ معیار کی یقین دہانی کے عمل میں اور کون شامل ہے؟
Анастасия: اب تصور کریں کہ ہم نے پہلے ہی اس خصوصیت کو کلائنٹ تک پہنچا دیا ہے۔ ظاہر ہے، پروڈکٹ کے معیار پر نظر رکھنے کی ضرورت ہے یہاں تک کہ جب یہ پہلے سے پروڈکشن میں ہو۔ اس مرحلے پر، غیر واضح منظرناموں کے ساتھ حالات، نام نہاد کیڑے، ظاہر ہو سکتے ہیں۔
پہلا سوال یہ ہے کہ پروڈکٹ کو جاری کرنے کے بعد ہم ان کیڑوں سے کیسے نمٹتے ہیں؟ ہم، مثال کے طور پر، دباؤ پر کیسے رد عمل ظاہر کرتے ہیں؟ اگر صفحہ کو لوڈ ہونے میں 30 سیکنڈ سے زیادہ وقت لگتا ہے تو کلائنٹ بہت خوش نہیں ہوگا۔
یہ وہ جگہ ہے جہاں استحصال کھیل میں آتا ہے، یا جیسا کہ وہ اسے اب کہتے ہیں۔ DevOps. درحقیقت، یہ وہ لوگ ہیں جو پروڈکٹ کو چلانے کے ذمہ دار ہیں جب یہ پہلے سے پروڈکشن میں ہے۔ اس میں مختلف قسم کی نگرانی شامل ہے۔ یہاں تک کہ جانچ کی ایک ذیلی قسم بھی ہے - پیداوار پر جانچ، جب ہم خود کو اجازت دیتے ہیں کہ ریلیز سے پہلے کسی چیز کی جانچ نہ کریں اور اسے فوری طور پر پروڈکشن پر ٹیسٹ کریں۔ یہ بنیادی ڈھانچے کو منظم کرنے کے نقطہ نظر سے سرگرمیوں کا ایک سلسلہ ہے جو آپ کو کسی واقعے کا فوری جواب دینے، اس پر اثر انداز ہونے اور اسے درست کرنے کی اجازت دیتا ہے۔
انفراسٹرکچر بھی اہم ہے۔ اکثر ایسے حالات ہوتے ہیں جب، ٹیسٹ کے دوران، یہ یقینی بنانا ناممکن ہوتا ہے کہ ہمارے پاس واقعی وہ سب کچھ ہے جو ہم کلائنٹ کو دینا چاہتے ہیں۔ ہم اسے پیداوار میں لے جاتے ہیں اور غیر واضح حالات کو پکڑنا شروع کر دیتے ہیں۔ اور سب اس لیے کہ ٹیسٹ میں بنیادی ڈھانچہ پیداوار کے بنیادی ڈھانچے سے مطابقت نہیں رکھتا۔ یہ ایک نئی قسم کی جانچ کی طرف جاتا ہے - بنیادی ڈھانچے کی جانچ. ان میں مختلف کنفیگریشنز، سیٹنگز، ڈیٹا بیس کی منتقلی وغیرہ شامل ہیں۔
یہ سوال پیدا کرتا ہے - شاید ٹیم کو بنیادی ڈھانچے کو کوڈ کے طور پر استعمال کرنے کی ضرورت ہے۔
مجھے یقین ہے کہ بنیادی ڈھانچہ مصنوعات کے معیار کو براہ راست متاثر کرتا ہے۔
مجھے امید ہے کہ کانفرنس میں ایک حقیقی کیس کے ساتھ رپورٹ آئے گی۔ اگر آپ ہمیں اپنے تجربے سے یہ بتانے کے لیے تیار ہیں کہ کوڈ کے بطور بنیادی ڈھانچہ معیار کو کیسے متاثر کرتا ہے تو ہمیں لکھیں۔ بنیادی ڈھانچہ بطور کوڈ تمام ترتیبات کو چیک کرنا اور ان چیزوں کی جانچ کرنا آسان بناتا ہے جو بصورت دیگر ممکن نہیں ہیں۔ لہذا، آپریشن ایک معیاری مصنوعات کی ترقی کے عمل میں بھی شامل ہے.
- تجزیات اور دستاویزات کے بارے میں کیا خیال ہے؟
Анастасия: یہ انٹرپرائز سسٹمز پر زیادہ لاگو ہوتا ہے۔ جب ہم انٹرپرائز کے بارے میں بات کرتے ہیں تو، تجزیہ کار اور نظام کے تجزیہ کار جیسے لوگ فوری طور پر ذہن میں آتے ہیں۔ انہیں بعض اوقات تکنیکی مصنفین کہا جاتا ہے۔ انہیں تصریح لکھنے اور اسے مکمل کرنے کا کام ملتا ہے، مثال کے طور پر، ایک مہینے کے لیے۔
یہ بار بار ثابت ہوا ہے کہ اس طرح کی دستاویزات لکھنے سے بہت طویل ترقی کی تکرار اور بہتری کی طویل تکرار ہوتی ہے، کیونکہ جانچ کے عمل کے دوران کیڑے کی نشاندہی کی جاتی ہے اور واپسی شروع ہوتی ہے۔ نتیجے کے طور پر، بہت سارے لوپس ہیں جو ترقی کی لاگت میں اضافہ کرتے ہیں. اس کے علاوہ، یہ کمزوریوں کو متعارف کر سکتا ہے. ایسا لگتا ہے کہ ہم نے حوالہ کوڈ لکھا ہے، لیکن پھر ہم نے ایسی تبدیلیاں کیں جو بالکل سوچے سمجھے فن تعمیر کو توڑ دیتی ہیں۔
نتیجے کے طور پر، نتیجہ ایک بہت اعلی معیار کی مصنوعات نہیں ہے، کیونکہ پیچ پہلے ہی فن تعمیر میں ظاہر ہو چکے ہیں، کچھ جگہوں پر کوڈ کافی حد تک ٹیسٹوں کے ذریعہ احاطہ نہیں کرتا ہے، کیونکہ ڈیڈ لائن ختم ہو رہی ہے، تمام کیڑے کو تیزی سے بند کرنے کی ضرورت ہے. اور سب اس لیے کہ اصل تصریح میں ان تمام نکات کو مدنظر نہیں رکھا گیا جن پر عمل درآمد کی ضرورت ہے۔
ڈویلپرز کیڑے نہیں ہیں اور جان بوجھ کر غلطیوں کے ساتھ کوڈ نہیں لکھتے ہیں۔
اگر ہم نے ابتدائی طور پر ایک تصریح کے ذریعے سوچا ہوتا جس میں تمام ضروری نکات کا احاطہ کیا گیا ہوتا تو ہر چیز کو ضرورت کے مطابق لاگو کیا جاتا۔ لیکن یہ یوٹوپیا ہے۔
ایک کامل 100 صفحات کی تفصیلات لکھنا شاید ناممکن ہے۔ اس لیے دستاویزات لکھنے کے متبادل طریقوں کے بارے میں سوچنے کی ضرورت ہے۔, وضاحتیں، کام کے بیانات جو ہمیں اس بات کو یقینی بنانے کے قریب لے جائیں گے کہ ڈویلپر بالکل وہی کرتا ہے جس کی ضرورت ہے۔
یہ وہ جگہ ہے جہاں فرتیلی نقطہ نظر ذہن میں آتے ہیں — قبولیت کے معیار کے ساتھ صارف کی کہانیاں۔ یہ ان ٹیموں پر زیادہ لاگو ہوتا ہے جو چھوٹی تکرار میں ترقی کرتی ہیں۔
- استعمال کی جانچ، مصنوعات کے استعمال، ڈیزائن کے بارے میں کیا خیال ہے؟
Анастасия: یہ ایک بہت اہم نکتہ ہے، کیونکہ ٹیم میں ڈیزائنرز موجود ہیں۔ اکثر، ڈیزائنرز کو ایک خدمت کے طور پر استعمال کیا جاتا ہے - یا تو ایک ڈیزائن ڈیپارٹمنٹ یا آؤٹ سورس ڈیزائنر کے ذریعے۔ اکثر ایسے حالات ہوتے ہیں جہاں ایسا لگتا ہے کہ ڈیزائنر نے پروڈکٹ سائنسدان کی بات سنی اور وہی کیا جو وہ سمجھتا تھا۔ لیکن جب ہم تکرار شروع کرتے ہیں، تو پتہ چلتا ہے کہ اصل میں جو کیا گیا تھا وہ نہیں تھا جس کی توقع کی گئی تھی: ڈیزائنر کچھ بھول گیا، اس نے رویے کے بارے میں پوری طرح سے نہیں سوچا، کیونکہ وہ ٹیم میں نہیں تھا اور نہ ہی سیاق و سباق میں، یا سامنے۔ -end ڈویلپر نے اس کی ترتیب کو پوری طرح سے نہیں سمجھا۔ اس میں کئی تکراریں صرف اس لیے لگ سکتی ہیں کیونکہ فرنٹ اینڈ ڈویلپر کی ڈیزائن کو سمجھنے میں کوئی مسئلہ ہے۔
اس کے علاوہ ایک مسئلہ اور ہے۔ ڈیزائن کے نظام اب مقبولیت حاصل کر رہے ہیں. وہ ہائپ پر ہیں، لیکن ان سے ہونے والے فوائد پوری طرح سے واضح نہیں ہیں۔
مجھے اس رائے کا سامنا ہے کہ ڈیزائن سسٹمز، ایک طرف، ترقی کو آسان بناتے ہیں، لیکن دوسری طرف، وہ انٹرفیس پر بہت سی پابندیاں عائد کرتے ہیں۔
نتیجے کے طور پر، ہم وہ خصوصیت نہیں بناتے جو کلائنٹ چاہتا ہے، بلکہ وہ جو ہمارے لیے آسان ہے، کیونکہ ہمارے پاس پہلے سے ہی کچھ کیوبز ہیں جن سے ہم اسے بنا سکتے ہیں۔
میرے خیال میں اس موضوع پر توجہ دینا اور یہ سوچنا ضروری ہے کہ کیا ڈیزائن کے کام کو آسان بنانے کی کوشش کرتے ہوئے ہم درحقیقت کلائنٹ کے درد کو حل کر رہے ہیں۔
- کوالٹی ایشورنس سے متعلق موضوعات کی ایک حیران کن تعداد موجود ہے۔ کیا روس میں کوئی کانفرنس ہے جہاں ان سب پر بات ہو سکے؟
Анастасия: ٹیسٹنگ سے متعلق سب سے پرانی کانفرنس ہے، جو اس سال 25ویں بار منعقد ہوگی اور اسے کوالٹی ایشورنس کانفرنس SQA ڈےز کہا جاتا ہے۔ یہ بنیادی طور پر فنکشنل ٹیسٹرز کے لیے ٹولز اور مخصوص جانچ کے طریقوں پر بحث کرتا ہے۔ ایک اصول کے طور پر، SQA Days کی رپورٹس خود ٹیسٹرز کی ذمہ داری کے علاقے میں مخصوص علاقوں کا گہرائی سے جائزہ لیتی ہیں، لیکن پیچیدہ سرگرمیوں کا نہیں۔
اس سے مختلف ٹولز اور اپروچز کو سمجھنے میں بہت مدد ملتی ہے، ڈیٹا بیس، APIs وغیرہ کی جانچ کیسے کی جائے۔ لیکن ایک ہی وقت میں، ایک طرف، یہ ایک بہتر پروڈکٹ کی تخلیق میں صرف جانچ سے زیادہ شامل ہونے کی ترغیب نہیں دیتا ہے۔ دوسری طرف، ٹیسٹرز پروڈکٹ کے عالمی مقصد اور اس کے کاروباری جزو کے بارے میں سوچنے کے عمل میں زیادہ شامل نہیں ہوتے ہیں۔
میں ایک بڑا شعبہ چلاتا ہوں اور بہت سارے انٹرویوز کرتا ہوں، جو واقعی صنعت کی مجموعی حالت کے بارے میں بصیرت فراہم کرتے ہیں۔ ایک اصول کے طور پر، ہمارے لوگ انٹرپرائز میں کام کرتے ہیں، اور ان کے پاس ذمہ داری کا واضح علاقہ ہے۔ غیر ملکی پراجیکٹس میں کام کرنے والے ساتھی مختلف قسم کی جانچ استعمال کرتے ہیں: وہ خود لوڈ ٹیسٹنگ، کارکردگی کی جانچ، اور یہاں تک کہ بعض اوقات سیکیورٹی ٹیسٹنگ بھی کر سکتے ہیں، کیونکہ وہ واقعی پروڈکٹ کے معیار کو یقینی بنانے میں ٹیم کی مدد کرتے ہیں۔
میں چاہوں گا کہ روس کے لوگ بھی اس حقیقت کے بارے میں سوچنا شروع کریں کہ انڈسٹری فنکشنل ٹیسٹنگ کے ساتھ ختم نہیں ہوتی ہے۔
— اس مقصد کے لیے، ہم ایک نئی کانفرنس، QualityConf کا انعقاد کر رہے ہیں، جو ایک لازمی نظم و ضبط کے طور پر معیار کے لیے وقف ہے۔ ہمیں اس خیال کے بارے میں مزید بتائیں، کانفرنس کا بنیادی مقصد کیا ہے؟
Анастасия: ہم لوگوں کی ایک کمیونٹی بنانا چاہتے ہیں جو معیاری مصنوعات بنانے میں دلچسپی رکھتے ہوں۔ ایک ایسا پلیٹ فارم پیش کریں جہاں وہ آ سکیں، رپورٹیں سن سکیں اور کانفرنس کو اس بات کی مخصوص سمجھ کے ساتھ چھوڑ دیں کہ انہیں معیار کو بہتر بنانے کے لیے کیا تبدیل کرنے کی ضرورت ہے۔
آج کل میں اکثر مشورے سے ایک درخواست سنتا ہوں کہ جب ٹیسٹنگ اور کوالٹی میں مسائل ہوں تو کیا کرنا چاہیے۔ جب آپ ٹیموں کے ساتھ بات چیت کرنا شروع کرتے ہیں، تو آپ دیکھتے ہیں کہ مسئلہ خود ٹیسٹرز کے ساتھ نہیں ہے، بلکہ طریقہ کار کو ترتیب دینے کے ساتھ ہے۔ مثال کے طور پر، جب ڈویلپرز کو یقین ہے کہ وہ صرف کوڈ لکھنے کے ذمہ دار ہیں، تو ان کی ذمہ داری بالکل اسی وقت ختم ہو جاتی ہے جب وہ اس کام کو جانچ میں منتقل کرتے ہیں۔
ہر کوئی اس حقیقت کے بارے میں نہیں سوچتا ہے کہ خراب فن تعمیر کے ساتھ ناقص لکھا ہوا، کم معیار کا کوڈ اس منصوبے کے لیے بڑی پریشانیوں کا خطرہ ہے۔ وہ غلطیوں کی قیمت کے بارے میں نہیں سوچتے ہیں، کہ کیڑے جو پیداوار میں ختم ہوتے ہیں کمپنی اور ٹیم کے لیے بڑے اخراجات کا باعث بن سکتے ہیں۔ اس بارے میں سوچنے کا کوئی کلچر نہیں ہے۔ میں چاہتا ہوں کہ ہم اسے کانفرنس میں تقسیم کرنا شروع کریں۔
میں سمجھتا ہوں کہ یہ اختراع نہیں ہے۔ معیار کے 14 اصولوں کے مصنف ایڈورڈ ڈیمنگ نے پچھلی صدی میں غلطی کی قیمت کے بارے میں لکھا تھا۔ کوالٹی اشورینس ایک نظم و ضبط کے طور پر اس کتاب پر مبنی ہے، لیکن بدقسمتی سے، جدید ترقی اسے بھول جاتی ہے۔
- کیا آپ ٹیسٹنگ اور ٹولز کے بارے میں براہ راست موضوعات کو چھونے کا ارادہ رکھتے ہیں؟
Анастасия: میں تسلیم کرتا ہوں کہ آلات کے بارے میں رپورٹس ہوں گی۔ کافی عالمگیر ٹولز ہیں جن کی مدد سے کمپنیاں اور ٹیمیں پروڈکٹ کو متاثر کر سکتی ہیں۔
تمام رپورٹس کو عالمی سطح پر ایک مشترکہ مشن کے ذریعے متحد کیا جائے گا: سامعین کو یہ بتانا کہ اس نقطہ نظر، ٹول، طریقہ، عمل، جانچ کی قسم کی مدد سے، ہم نے پروڈکٹ کے معیار کو متاثر کیا ہے اور کلائنٹ کی زندگی کو بہتر بنایا ہے۔
ہمارے پاس یقینی طور پر کسی آلے کی خاطر کسی ٹول کے بارے میں رپورٹس نہیں ہوں گی۔ پروگرام میں شامل تمام رپورٹس کو ایک مشترکہ مقصد کے ساتھ متحد کیا جائے گا۔
- آپ جس کے بارے میں بات کر رہے ہیں اس میں کون دلچسپی لے گا، آپ کس کو کانفرنس کے مہمانوں کے طور پر دیکھتے ہیں؟
Анастасия: ہمارے پاس ان ڈویلپرز کے لیے رپورٹس ہوں گی جو اپنے پروجیکٹ، پروڈکٹ، سسٹم کی قسمت کا خیال رکھتے ہیں۔ اسی طرح، یہ ٹیسٹرز کے لیے دلچسپی کا باعث ہوگا اور، یہ مجھے لگتا ہے، خاص طور پر مینیجرز کے لیے۔ مینیجرز سے، میری مراد وہ لوگ ہیں جو فیصلے کرتے ہیں اور کسی پروڈکٹ، سسٹم، ٹیم کی تقدیر اور ترقی کو دوسری چیزوں کے ساتھ متاثر کر سکتے ہیں۔
یہ وہ لوگ ہیں جو سوچتے ہیں کہ کسی پروڈکٹ یا سسٹم کے معیار کو کیسے بہتر بنایا جائے۔ ہماری کانفرنس میں، وہ اقدامات کے مختلف سیٹوں کے بارے میں جانیں گے اور یہ سمجھنے کے قابل ہوں گے کہ اب ان میں کیا غلط ہے اور کن چیزوں کو تبدیل کرنے کی ضرورت ہے۔
میرے خیال میں اہم معیار یہ سمجھنا ہے کہ معیار میں کچھ غلط ہے اور اس پر اثر انداز ہونا چاہتے ہیں۔ ہم شاید ان لوگوں تک نہیں پہنچ پائیں گے جو سمجھتے ہیں کہ یہ پہلی بار ہوگا۔
- کیا آپ کو لگتا ہے کہ پوری صنعت صرف جانچ کے بارے میں نہیں بلکہ معیار کی ثقافت کے بارے میں بات کرنے کے لئے تیار ہے؟
Анастасия: مجھے یقین ہے کہ میں بالغ ہو گیا ہوں۔ اب بہت سی کمپنیاں واٹر فال کے روایتی انداز سے ہٹ کر Agile کی طرف جا رہی ہیں۔ کلائنٹ پر توجہ مرکوز ہے، ٹیموں میں لوگ واقعی ایک معیاری مصنوعات بنانے کے بارے میں سوچنا شروع کر رہے ہیں. یہاں تک کہ انٹرپرائز کمپنیاں بھی معیار کو بہتر بنانے پر توجہ مرکوز کر رہی ہیں۔
کمیونٹی میں پیدا ہونے والی درخواستوں کی تعداد کو دیکھتے ہوئے، مجھے یقین ہے کہ اب وقت آگیا ہے۔ بلاشبہ، مجھے یقین نہیں ہے کہ یہ ایک بڑے پیمانے پر انقلاب ہوگا، لیکن میں چاہوں گا کہ یہ انقلاب ہوش میں آئے۔
- متفق! ہم ثقافت کو ابھاریں گے اور شعور بدلیں گے۔
آئی ٹی مصنوعات کی اعلیٰ معیار کی ترقی پر کانفرنس جگہ لے جائے گا 7 جون کو ماسکو میں. آپ جانتے ہیں کہ کون سے مراحل ایک اعلیٰ معیار کی پروڈکٹ کو بناتے ہیں، ہمارے پاس پروڈکشن میں کیڑے کا کامیابی سے مقابلہ کرنے کے کیسز ہیں، ہم نے اپنی پریکٹس میں مقبول طریقوں کا تجربہ کیا ہے - ہمیں آپ کے تجربے کی ضرورت ہے۔ اس کے درخواستیں یکم مئی تک، اور پروگرام کمیٹی کانفرنس کی مجموعی سالمیت کے لیے تھیم پر توجہ مرکوز کرنے میں مدد کرے گی۔
سے جڑیں۔ ، جس میں ہم معیار کے مسائل اور کانفرنس پر تبادلہ خیال کرتے ہیں، سبسکرائب کریں۔ پروگرام کی خبروں سے باخبر رہنے کے لیے۔
ماخذ: www.habr.com