د QA یوه لویه برخه د ځایی کولو نیمګړتیا ده. یقینا، د ازموینې ډیزاین تخنیکونه موږ سره د ازموینې سناریو غوره کولو کې مرسته کوي او شیان ډیر اغیزمن کوي. مګر په حقیقت کې د عیب ځایی کول څه شی ، او موږ څنګه کولی شو دا لږ دردناک کړو؟ دی راځئ چې د اساساتو سره پیل وکړو سیمه ایز کول د جاسوس لوبولو په څیر دي: "چیرې او کله شیان غلط شوي؟" د مناسب ځایی کولو پرته، یو عیب کولی شي په ګرم کچالو بدل شي چې د مخکینۍ برخې، شاته کولو، او هر پرمختیایي ټیم ترمنځ وغورځول شي. وخت ضایع کیږي، او په بالقوه توګه حتی شرایط. د عیب ځایی کولو په اړه فکر وکړئ لکه څنګه چې د لیبرینت حرکت کول ، د غوښتنلیک غوښتنې او لاګونو سره ستاسو د سوت بال په توګه. مګر ایا دا به اسانه نه وي چې د دې لابراتوار نقشه ولرئ، حتی یو خاکسار، د دې پر ځای چې د سوت په شاوخوا کې ودریږي؟ دا هغه ځای دی چې د غوښتنلیک جوړښت راځي. د غوښتنلیک جوړښت څه شی دی؟ دا څنګه د سیسټم بیلابیل برخې یوځای کار کوي. زموږ د لابراتوار استعار په شرایطو کې، دا دا ده چې څنګه یوه برخه له بلې سره نښلوي، کوم چې د تیریدو لارې چیرته ځي. زه دوه اصلي جوړښتونه توپیر کوم: د پیرودونکي سرور او پس منظر. د پیرودونکي سرور جوړښت موږ ته ښیې چې پیرودونکي او سرور څنګه متقابل عمل کوي. د شالید جوړښت دا ټاکي چې بیکینډ د پیرودونکي غوښتنې څنګه اداره کوي. د مراجعینو سرور جوړښت په اړه یو څو ټکي عموما دوه ډوله دي: پتلی پیرودونکي ګنده مشتري ډول تاثیر کوي چې پیرودونکي څومره معلومات ساتي او پخپله پروسس کوي. د دې تنظیم کولو لپاره نورې لارې شتون لري ، مګر زه به هغه څه ته ودریږم چې ما واقعیا ورسره کار کړی دی. ډیری ګرځنده او ویب ایپس پتلي پیرودونکي دي. ټول معلومات په سرور کې زیرمه شوي، او د پیرودونکي غوښتنلیک د معلوماتو غوښتنه کوي یا د پروسس کولو غوښتنه کوي. راجستر کول، ننوتل، د خبرتیاو ګډون کول - دا ټول سرور ته زنګونه دي. په سرور کې ټول پروسس د پیرودونکي څخه پټ دی. د غوښتنې په ځواب کې، پیرودونکي د ډیټابیس څخه راټول شوي او پروسس شوي معلومات ترلاسه کوي یا دا تاییدوي چې غوښتنه په بریالیتوب سره بشپړه شوې. په موټ پیرودونکي غوښتنلیکونو کې، پیرودونکي پخپله ډیری پروسس کوي: ډیټابیس ته د معلوماتو اضافه کول، د راپورونو تولید، د پیسو حساب کول، او د اسنادو جوړول. دوی ډیری وختونه په محلي توګه نصب شوي، مګر تل نه. د موټ پیرودونکو مثالونو کې آفلاین لوبې، AutoCAD، او د 1C ځینې نسخې شاملې دي. اوس، راځئ چې د پس منظر جوړښت وپلټئ دوه عام چلندونه دي: Monolithic کوچني خدمتونه کله چې نږدې هرڅه په یو ځای کې پروسس کیږي، دا یو واحد دی. که چیرې د پروسس کولو غوښتنې په سیسټم کې نورو خدماتو ته واستول شي، نو تاسو احتمال لرئ د مایکرو سرویس جوړښت سره معامله وکړئ. په یو واحد جوړښت کې، د نیمګړتیا سرچینې په ګوته کول ستونزمن کیدی شي، ځکه چې مختلف ټیمونه او خدمات معمولا ورته کوډبیس شریکوي، پدې معنی چې بدلونونه غیر متوقع پایلې لري. په دوهم حالت کې، خدمتونه جلا شوي، هر یو د خپل کوډبیس سره، پدې معنی چې په یو خدمت کې بدلونونه په نورو لږ اغیز لري. سازماني جوړښت او د مسؤلیت ساحې سرلیک ډارونکی ښکاري، مګر دا یوازې تاسو ته وایي چې څوک څه کوي، او څوک د لابراتوار د کومې برخې لپاره مسؤل دی (اپلیکیشن). تصور وکړئ چې موږ یو لوی شرکت لرو: یو بانک، یو بازار، د خوړو رسولو خدمت - تاسو یې نوم کړئ. څومره چې زموږ غوښتنلیک لوی او ډیر پیچلی وي ، هومره ډیر خلک پدې کار کوي. او هرڅومره چې خلک شتون ولري ، هومره تاسو اړتیا لرئ دوی په ټیمونو وویشئ ، هر یو د دوی د پراختیا ساحې لپاره مسؤل وي. د مثال په توګه، یو ټیم ممکن پرمختګونه اداره کړي، پداسې حال کې چې بل د تادیاتو مسولیت لري. که زموږ غوښتنلیک مختلف خدمتونه وړاندې کوي، ټیمونه ممکن د انفرادي خدماتو لپاره مسؤل وي، لکه د بریښنایی اسنادو مدیریت، محاسبه، یا دولتي تدارکات. تاسو اړتیا نلرئ چې هر څه او هرڅوک وپیژنئ، مګر که چیرې داسې اسناد شتون ولري چې دا په ګوته کوي چې کوم ټیم د کومې سیمې لپاره مسؤل دی، دا غوره ده چې دا په نښه کړئ. دا ټول یوځای کول په لاس کې نقشه، سوت په تیاره کې، راځئ چې خپل لیبرینت ته لاړ شو او د نیمګړتیا سرچینه ولټوو. راځئ چې یو څو سناریوګانې تصور کړو. سناریو ۱ دا انځور کړئ: موږ د خبرو اترو کلب لپاره یوه ویب پاڼه ازموینه کوو. موږ د ټولګي مهالویش ګورو، د راتلونکو غونډو په اړه لوستل کوو، کله چې په یو وخت کې، موږ ټایپو وینو. اوس، موږ څنګه معلومه کړو چې دا له کوم ځای څخه سرچینه اخلي؟ اجازه راکړئ چې جرات پیل شي! موږ devTools خلاصوو، پاڼه تازه کوو، او غوښتنې او ځوابونه ګورو. څرنګه چې موږ یو پتلی پیرودونکی لرو، موږ خپل ټایپو په یو ځواب کې پیدا کوو - دا د شاته پای څخه راغلی. اوس، موږ لاګونه پرانیزو او د بیک انډ غوښتنې یا ځواب پروسس کولو لټون کوو - دا زموږ د جادو بال څخه سوت دی. موږ کولی شو د غوښتنې او ځواب څخه د هر ډول معلوماتو په کارولو سره لاګونه وپلټئ، مګر دا غوره ده چې ځانګړي ارزښتونه وکاروئ: غوښتنه xiid، د غوښتنې څخه ID، د تلیفون شمیره، او داسې نور. موږ داخله پیدا کړه او وګورو: ایا موږ د ټولګي معلومات د ډیټابیس یا بل خدمت څخه ترلاسه کړي؟ که معلومات د ډیټابیس څخه راغلي وي، موږ کولی شو مسله تخنیکي مالتړ ته وسپارو ترڅو په ډیټابیس کې د ټایپو حل کړي. که معلومات د بل خدمت څخه راغلي وي، موږ کولی شو نیمګړتیا دوی ته انتقال کړو. مبارک شه! موږ خپل لومړی لیبرین فتح کړ: عیب ځایی شوی او راپور شوی. سناریو 2 اوس انځور چې موږ د راجستریشن فورمه ازموینه کوو. موږ یو بریښنالیک، ځینې ډاټا، او یو جوړ شوی پاسورډ داخلوو. موږ د راجسټریشن تڼۍ کلیک کوو او په ناڅاپي ډول یوه تېروتنه ترلاسه کوو. دا زموږ د جادو بال خلاصولو وخت دی! موږ په devTools کې زموږ د محبوب شبکې ټب ته سر ورښکاره کوو او ګورو چې څه غلط شوي: موږ ټول مرحلې تکرار کوو او د سرور ځواب ګورو. د غوښتنې په ځواب کې، موږ د خالي ځواب بدن سره 400 کوډ ترلاسه کوو. ایا موږ باید وتښتو او د فرنټ اینډ په وړاندې عیب ثبت کړو؟ مګر موږ لاهم نه پوهیږو چې واقعیا څه غلط شوي او څه باید سم شي. ډیری وختونه د 400 تېروتنه واقع کیږي کله چې د پیرودونکي لیږل شوي او هغه څه چې سرور یې تمه لري توپیر شتون لري. د دې لپاره ډیری دلیلونه کیدی شي، په شمول: په دنده کې زاړه اسناد بدلونونه پرته له اسنادو جوړ شوي ټایپونه راځئ چې د پیرودونکي غوښتنه وګورو که موږ اسناد ولرو، په لاسي ډول لیکل شوي یا په Swagger یا OpenAPI کې تولید شوي، راځئ چې دا د تصدیق کولو لپاره وکاروو: موږ ټول اړین پیرامیټونه لیږو د پیرامیټر ارزښتونه د سم ډیټا ډولونه لري (د مثال په توګه د انټ پیرامیټونو لپاره شمیرې ارزښتونه) موږ نور څنګه کولی شو غوښتنه وګورو؟ حتی که موږ اسناد ونه لرو، موږ کولی شو تصدیق وکړو: د نحو موافقت (د بیلګې په توګه، که غوښتنه د JSON بڼه کې لیږل کیږي، دا باید د JSON نحو تعقیب کړي) د پیرامیټرو په نومونو کې ټایپونه (د مثال په توګه، د "پیسو" پرځای "پیسې"، د "بدن" پر ځای "ډوبي") د لاتیني حروفو په منځ کې سیریلیک توري (د مثال په توګه، "نوم" د سیریلیک "e" سره لیکل شوی) هرڅه سم دي؟ بیا دا وخت دی چې د لابراتوار له لارې خپل سفر ته دوام ورکړو ترڅو ځواب ومومئ. موږ خپله نقشه اخلو او په لاګونو کې " ښکته کیږو". د ننوتلو تحلیل دلته، دوه سناریوګانې ممکن دي: د غوښتنې پروسس کولو پرمهال یوه تېروتنه ثبت شوې هیڅ تېروتنه نه ده ثبت شوې، مګر غوښتنې ثبت شوي په وروستي حالت کې، موږ باید د مایکروسافټ لابراتوار له لارې خپل سفر ته دوام ورکړو او د هغه ځای په لټه کې شو چیرې چې زموږ غوښتنه پروسس شوې وه. د غلطۍ لاګ په موندلو سره، موږ به پوه شو چې ریښتیا څه غلط شوي، پدې معنی چې زموږ ځایی کول او زموږ سفر بشپړ شوی! ټول هغه څه چې پاتې دي د نیمګړتیا راپور لپاره لاندې معلومات راټولول دي: د بیرته ستنیدو غوښتنه د تېروتنې log وړاندیز شوی اصلاح پایله د نیمګړتیا ځایی کول کیدی شي ننګونې وي. ځینې وختونه به تاسو دیوال سره ټکر وکړئ: هغه لاګ چې تاسو یې تعقیب کوئ د خطا لامل نه کیږي یا شیان ډیر مغشوشوي. په داسې شرایطو کې، زه معمولا یو څو ګامونه شاته اخلم یا له پیل څخه پیل کوم. د لابراتوار سپړنه ممکن ډیر وخت ونیسي. سفر ممکن ستونزمن وي، او له خطر څخه ډک وي: د ځینو غوښتنو پروسس کولی شي پیچلي وي او ډیری مختلف خدماتو ته غوښتنې واستول شي. ځینې وختونه دا معنی لري چې کار ساده کړئ او د لیبرینت معمارانو - پراختیا کونکو سره اړیکه ونیسئ.
