ولې موږ د ازموینو لپاره هیکاتون نیولی؟

دا مقاله به د هغو کسانو لپاره په زړه پورې وي چې زموږ په څیر د ازموینې په برخه کې د مناسب متخصص غوره کولو ستونزې سره مخ دي.

په حیرانتیا سره، زموږ په جمهوریت کې د معلوماتي ټیکنالوژۍ شرکتونو شمیر زیاتوالي سره، یوازې د وړ پروګرام کونکو شمیر زیاتیږي، مګر د ازموینو نه. ډیری خلک لیواله دي چې دې مسلک ته راشي، مګر ډیری یې په معنی نه پوهیږي.

زه د ټولو IT شرکتونو لپاره خبرې نشم کولی، مګر موږ د کیفیت متخصصینو ته د QA/QC رول ګمارلی دی. دوی د پراختیایی ټیم برخه ده او د پراختیا په ټولو مرحلو کې برخه اخلي ، له څیړنې څخه د نوي نسخې خوشې کولو پورې.

په ټیم کې یو ټیسټر، حتی د پالن کولو په مرحله کې، باید د کاروونکي کیسه منلو لپاره د ټولو فعال او غیر فعال اړتیاوو په اړه فکر وکړي. هغه باید د محصول عملیاتي ځانګړتیاوو او همدارنګه د پروګرام کونکو، او حتی ښه پوه شي، او د ټیم سره مرسته وکړي چې حتی د پالن کولو په مرحله کې غلط پریکړې ونه کړي. ټیسټر باید روښانه پوهه ولري چې پلي شوي فعالیت به څنګه کار وکړي او کوم زیانونه شتون لري. زموږ ازموینه کونکي پخپله د ازموینې پلانونه او د ازموینې قضیې رامینځته کوي ، او همدارنګه د ازموینې ټول اړین بنچونه چمتو کوي. د چمتو شوي مشخصاتو سره سم ازموینه لکه د بندر کلیکر زموږ اختیار ندی. په ټیم کې کار کول، هغه باید د وړ محصول په خوشې کولو کې مرسته وکړي او په وخت کې الارم غږ کړي که چیرې یو څه غلط شي.

هغه څه چې موږ ورسره مخ شو کله چې د ازموینو په لټه کې شو

د ډیری بیا پیلونو د مطالعې په مرحله کې، داسې بریښي چې زموږ لپاره مناسب تجربه لرونکي متخصصین شتون لري او زموږ د ټیم لپاره د آزموینې په غوره کولو کې به کومه ستونزه نه وي. مګر، د شخصي غونډو په جریان کې، موږ په زیاتیدونکي توګه د هغو کاندیدانو سره مخ شو چې په حقیقت کې د معلوماتي ټیکنالوژۍ نړۍ څخه خورا لیرې وو (د مثال په توګه، دوی نشي کولی د براوزر او ویب سرور ترمنځ د متقابل عمل اصول، د امنیت اساسات، اړونده او غیر اړونده ډیټابیسونه، دوی د مجازی کولو او کانټینر کولو په اړه هیڅ نظر نه درلود) مګر په ورته وخت کې د لوړ QA په کچه خپل ځانونه ارزول. د لسګونو مرکو له ترسره کولو وروسته، موږ دې پایلې ته ورسیدو چې په سیمه کې زموږ لپاره د مناسبو متخصصینو شمیر کم دی.

بل، زه به تاسو ته ووایم چې موږ کوم ګامونه اخیستي او کومې تېروتنې مو په لاره اچولي ترڅو د کیفیت لپاره د اوږدې مودې انتظار شوي جنګیالي ومومئ.

موږ څنګه هڅه وکړه چې وضعیت سم کړو

د چمتو شوي متخصصینو سورس کولو سره ځانونه ستړي کړي، موږ نږدې سیمې په نښه کول پیل کړل:

1. موږ هڅه وکړه چې د ارزونې طرزالعملونه پلي کړو ترڅو د ډیری "پریږدو" خلکو په منځ کې وپیژنو، هغه څوک چې موږ کولی شو پیاوړي متخصصین جوړ کړو.

   موږ د احتمالي کاندیدانو یوې ډلې څخه وغوښتل چې د دندو بشپړولو لپاره نږدې ورته پوهه ولري. د دوی د فکر پروسې په نظر کې نیولو سره، موږ هڅه وکړه چې ترټولو ژمن نوماند وپیژنو.

   په ځانګړې توګه، موږ د دندو سره د پاملرنې، د ټکنالوجۍ د وړتیاوو درک او د څو کلتوري ځانګړتیاوو د آزموینې لپاره راغلي یو:

   
   

2. موږ د ازموینو لپاره ناستې ترسره کړې ترڅو د موجوده ټیم ترمینځ د مسلک د پوهیدو حدود پراخه کړي.

   زه به تاسو ته د هر یو په اړه لږ څه ووایم.

   د Ufa سافټویر QA او ټیسټینګ میټ اپ # 1 زموږ لومړۍ هڅه ده چې هغه کسان راټول کړو چې مسلک ته پاملرنه کوي او په ورته وخت کې پوهیږو چې ایا خلک به د هغه څه سره علاقه ولري چې موږ یې دوی ته رسول غواړو. اساسا ، زموږ راپورونه د دې په اړه و چې چیرې یې پیل کول غوره دي که تاسو پریکړه کړې چې ټیسټر شئ. له پیل کونکو سره مرسته وکړئ خپلې سترګې خلاصې کړئ او د لویانو په څیر ازموینې ته وګورئ. موږ د هغه ګامونو په اړه خبرې وکړې چې نوي ازموونکي باید مسلک کې د شاملیدو لپاره واخلي. د دې په اړه چې کیفیت څه شی دی او څنګه یې په ریښتیني شرایطو کې ترلاسه کولی شو. او همدارنګه، اتوماتیک ازموینه څه ده او چیرته چې دا د کارولو لپاره مناسبه ده.

   
   
   بیا، د 1-2 میاشتو وقفې سره، موږ دوه نورې ناستې ترسره کړې. هلته لا دمخه دوه چنده ګډون کوونکي وو. په "Ufa سافټویر QA او ټیسټینګ میټ اپ #2" کې موږ د موضوع ساحې ته ژور ډوب شو. دوی د بګ تعقیب سیسټمونو په اړه خبرې وکړې، UI/UX ازموینې، په ډاکر، ځواب ورکوونکي، او همدارنګه د پراختیا کونکي او ټیسټر ترمنځ د احتمالي شخړو او د حل کولو لارو په اړه یې خبرې وکړې.

   زموږ دریمه ناسته، "د Ufa سافټویر QA او ازموینې ناسته #3،" په غیر مستقیم ډول د ټیسټرانو کار پورې اړه لري، مګر په وخت سره پروګرام کونکو ته د دوی تخنیکي او سازماني دندو په یادولو کې ګټوره وه: د بار ازموینه، د e2e ازموینه، په اتوماتیک ازموینه کې سیلینیم، د ویب غوښتنلیک زیانمننې .

   دا ټول وخت موږ زده کوو چې څنګه د خپلو پیښو څخه په خپرونو کې نورمال رڼا او غږ رامینځته کړو:

   → په ازموینه کې لومړی ګامونه - د Ufa سافټویر QA او ازموینې ناسته #1
   → UI/UX ازموینه – د Ufa سافټویر QA او ازموینې ناسته #2
   → د امنیت ازموینه ، د بار ازموینه او اتومات ازموینه - د Ufa QA او ازموینې ناسته #3

3. او په پای کې موږ پریکړه وکړه چې هڅه وکړو د ازموینو لپاره هیکاتون ترسره کړو

موږ څنګه د ازموینو لپاره هیکاتون چمتو او ترسره کړ

د پیل کولو لپاره، موږ هڅه وکړه چې پوه شو چې دا څه ډول "حیوان" دی او دا څنګه معمولا ترسره کیږي. لکه څنګه چې دا معلومه شوه، د دې ډول پیښو ډیری وختونه د روسیې په فدراسیون کې ندي ترسره شوي، او د نظرونو پور اخیستلو لپاره هیڅ ځای شتون نلري. دوهم، زه نه غواړم سمدلاسه په یوه پیښه کې ډیری سرچینې پانګونه وکړم چې په لومړي نظر کې شکمن ښکاري. له همدې امله، موږ پریکړه وکړه چې موږ به لنډ کوچني هیکاتون ترسره کړو، نه د ټول QA کاري دورې لپاره، مګر د انفرادي مرحلو لپاره.

زموږ اصلي سر درد د روښانه ازموینې نقشې رامینځته کولو کې د ځایی ازموینو ترمینځ د تمرین نشتوالی دی. دوی د پلي کولو دمخه د کارونکي کیسې په څیړلو او د منلو معیارونو رامینځته کولو کې وخت نه لګوي چې د فعال او غیر فعال اړتیاو ، UI/UX ، امنیت ، کاري بارونو او لوړ بارونو لپاره پراختیا کونکو ته روښانه وي. له همدې امله، موږ پریکړه وکړه، د لومړي ځل لپاره، د دوی د کار ترټولو زړه پورې او تخلیقي برخې ته لاړ شو - د پروژې دمخه څیړنې په جریان کې د اړتیاو تحلیل او جوړښت.

موږ د ګډون کونکو احتمالي شمیر اټکل وکړ او پریکړه یې وکړه چې موږ د MVP ریلیزونو لپاره لږترلږه 5 بیکلاګ ته اړتیا لرو، 5 محصولات او 5 خلک چې د محصول مالکینو په توګه عمل وکړي، د سوداګرۍ اړتیاوې روښانه کړي او د محدودیتونو په اړه پریکړې وکړي.

دلته هغه څه دي چې موږ یې ترلاسه کړل: د هیکاتون لپاره بیکلاګونه.

اصلي نظر دا و چې د هغو موضوعاتو سره راشي چې د امکان تر حده د ټولو ګډونوالو له ورځني کار څخه لرې شوي او دوی ته د تخیل تخلیقي الوتنې لپاره فرصت ورکول دي.

کومې تېروتنې مو وکړې او څه ښه کولای شو؟

د ارزونې طریقې کارول، د پلورونکو او ټیټ پوړو مدیرانو د ګمارلو په برخه کې خورا مشهور دي، ډیرې هڅې یې ترسره کړې، مګر موږ ته اجازه نه راکوي چې هر ګډون کونکي ته کافي پاملرنه وکړو او د هغه وړتیا و ارزوو. په عموم کې، دا انتخاب د شرکت منفي انځور رامینځته کوي، ځکه چې ډیری خلک ناکافي فیډبیک ترلاسه کوي او وروسته په خپل ځان او نورو کې د ګمارونکي د ظلم اغیز رامینځته کوي (د معلوماتي ټیکنالوژۍ په ټولنو کې اړیکې خورا پرمختللې دي). د پایلې په توګه، موږ په لفظي توګه دوه احتمالي نوماندان پاتې یو چې خورا لیرې راتلونکې لري.

ملاقاتونه یو ښه شی دی. د توضیحاتو لپاره پراخه اساس رامینځته شوی ، او د برخه اخیستونکو عمومي کچه لوړیږي. شرکت په بازار کې ورځ تر بلې د پیژندلو وړ کیږي. مګر د داسې کارونو د کار شدت لږ ندی. تاسو اړتیا لرئ په واضح ډول پوه شئ چې د غونډو ترسره کول به په کال کې نږدې 700-800 سړي ساعتونه ونیسي.

لکه څنګه چې د هیکاتون ازموینې لپاره. دا ډول پیښې لاهم ستړي شوي ندي ، ځکه چې د پراختیا کونکو لپاره د هیکاتون برعکس ، دوی خورا لږ ځله ترسره کیږي. د دې مفکورې ګټه دا ده چې په آرامۍ سره تاسو کولی شئ د عملي پوهې لوی مقدار تبادله کړئ او په سمه توګه د هر ګډون کونکي کچه وټاکئ.

د پیښې د پایلو له تحلیل وروسته، موږ پوهیږو چې موږ ډیرې غلطۍ کړې:

1. تر ټولو نه بښونکې تېروتنه دا وه چې باور ولرو چې 4-5 ساعته به زموږ لپاره کافي وي. د پایلې په توګه، یوازې د شالید سره پیژندنه او پیژندل نږدې 2 ساعته وخت نیسي.
   په لومړني مرحله کې د محصول مالکینو سره کار کول او د موضوع ساحې ته د ډوبولو وخت ورته وخت نیولی. نو پاتې وخت په څرګنده توګه د ازموینې نقشې د هراړخیز پرمختګ لپاره کافي نه و.
2. د هرې نقشې په اړه د مفصلو نظرونو لپاره کافي وخت او انرژي نه وه، ځکه چې شپه وه. له همدې امله، موږ په څرګنده توګه دا برخه ناکامه کړه، مګر په پیل کې د هیکاتون ترټولو ارزښتناکه موخه وه.
3. موږ پریکړه وکړه چې د پراختیا کیفیت د ټولو ګډونوالو د ساده رایو په واسطه و ارزوو، د هر ټیم لپاره 3 رایې تخصیص کړو، کوم چې دوی کولی شي د لوړ کیفیت کار لپاره ورکړي. ښایي دا به غوره وي چې یو قضاوت تنظیم کړئ.

څه لاسته راوړئ؟

موږ خپله ستونزه تر یوې اندازې حل کړې او اوس موږ 4 زړور، ښکلي سړي لرو چې زموږ لپاره کار کوي، د 4 پرمختیایي ټیمونو شاته پوښلي. د احتمالي قوي نوماندانو د پام وړ حوض او د ښار د QA ټولنې په کچه کې د پام وړ بدلونونه لاهم ندي لیدل شوي. مګر یو څه پرمختګ شتون لري او دا نشي کولی مګر خوشحاله شي.

سرچینه: www.habr.com