অন্যের মানের নিশ্চয়তার (কিউএ) জন্য সম্পূর্ণ নকল ব্যবস্থা তৈরি করা কি একটি খারাপ অভ্যাস?

Question

কর্মক্ষেত্রে আমাদের বেশ জটিল সিস্টেম রয়েছে। আসুন এই সিস্টেমটিকে, সিস্টেম_এ বলি। আমাদের কিউএ টিম আরেকটি সিস্টেম তৈরি করেছে, সিস্টেম_এ পরীক্ষা করার জন্য এই সিস্টেমটিকে সিস্টেম_বি নামে কল করুন।

সিস্টেম_বি ব্যবহারের পদ্ধতিটি নীচে রয়েছে। আমরা ইনপুট তৈরি করি (নিজেই সিস্টেম_বি ব্যবহার করে), ইন, সিস্টেম_বি এর মাধ্যমে এই জাতীয় ইনপুটগুলি প্রক্রিয়াজাত করি এবং আউটপুটগুলি তৈরি করি, ও_বি। প্রক্রিয়াটি নিম্নরূপ:

System_B(IN) -> O_B।

তারপরে আমরা সিস্টেম_এর নিজস্ব আউটপুটগুলি তৈরি করতে ও_এ:

System_A(IN) -> O_A।

যে কোনও সময়, এটি ধরে নেওয়া হয় যে O_B প্রত্যাশিত আউটপুট, এবং O_A হল পর্যবেক্ষণ / প্রকৃত আউটপুট। বোঝানো হয়েছে যে ও_বি হ'ল "সোনার" উত্স (সত্য)। তবে, আমরা সমস্যার সংমিশ্রণে চলে এসেছি।

• O_A ভুল, O_B ঠিক আছে
• O_A ঠিক আছে, O_B ঠিক আছে
• O_A ভুল, O_B ভুল
• O_A ঠিক আছে, O_B ভুল

O_B সর্বদা সঠিক বলে ধরে নেওয়া হয় (বা কী আশা করা হয়েছে) কে সঠিক তা নির্ধারণ করে? ঠিক আছে, দেখা যাচ্ছে যে O_B কখনও কখনও (বা প্রায়শই) মানুষের তদন্ত এবং বিশ্লেষণে ভুল হয়। জিনিসগুলি এই প্রক্রিয়াটি ব্যবহার করে কিউএ পাস করবে এবং প্রকৃত ব্যবহারকারীরা অভিযোগ করবে এবং আমরা ফিরে গিয়েছিলাম যে ও_বি সব পরে ভুল ছিল।

প্রশ্নটি হ'ল: বাস্তব সিস্টেমটি পরীক্ষা করার জন্য "টেস্ট সিস্টেম" তৈরি করা কি খারাপ অভ্যাস?

• পিচ্ছিল opeাল কি? তাহলে, আমরা কি পরীক্ষা করতে পারি না যে "টেস্ট সিস্টেম" পরীক্ষা করার জন্য আমাদের আরও একটি সিস্টেমের দরকার?
• ব্যয়টি অবশ্যই স্পষ্টভাবে নিষিদ্ধ, কারণ বিকাশকারীদের এখন কমপক্ষে 2 কোড বেসগুলি শিখতে হবে, সম্ভবত সিস্টেম_এর জটিলতা সিস্টেম_এ এর চেয়ে বড়। সংস্থার কাছে সিস্টেম_বি এর আশেপাশে থাকা কতটা ভাল বা খারাপ তা আমরা কীভাবে প্রমাণ করব?
• সিস্টেম_বি তৈরির মূল "বাধ্যতামূলক" কারণগুলির একটি ছিল "স্বয়ংক্রিয়" পরীক্ষা করা " এখন আমরা খুব গর্বিত যে আমরা সম্পূর্ণ স্বয়ংক্রিয়ভাবে আছি (কারণ সিস্টেম_বি আউটপুট উত্পন্ন করতে নিজেই ব্যবহার করার প্রক্রিয়াটি বুটস্ট্র্যাপ করতে ইনপুট জেনারেট করে)। তবে আমি মনে করি আমরা অবিশ্বাস্য উপায়ে আরও ক্ষতি এবং আরও জটিলতা প্রবর্তন করেছি। কিউএর কাজটি কি সম্পূর্ণ স্বয়ংক্রিয়ভাবে পরিচালিত হবে? সমান্তরাল ব্যবস্থা তৈরির ন্যায্যতা কি সেই কারণেই যথেষ্ট?
• আমার আসল উদ্বেগটি এটি, যদিও আমরা সকলেই জানি সিস্টেম_বি ভুল (বেশিরভাগ সময়)। যদি সিস্টেম_বি ইনপুট প্রক্রিয়াকরণে এত ভাল এবং এর আউটপুট স্বর্ণের উত্স হয় তবে কেন সিস্টেম_একে সিস্টেম_এ প্রতিস্থাপন করবেন না? এটির জন্য, কর্মস্থলে কেউ সন্তোষজনক প্রতিক্রিয়া সরবরাহ করতে সক্ষম নয়।

এই বিষয়ে যে কোনও গাইডেন্স প্রশংসা করা হয়।

Comments

আপনি সিস্টেম সি ভুলে গেছেন : যদি কে এবং বি অসম্মতি প্রকাশ করে তবে কোনটি সঠিক তা সিদ্ধান্ত নেয় one

— রবার্ট হার্ভে

আরও গুরুতর দ্রষ্ট্রে, স্পেস শাটলে পাঁচটি জাহাজের কম্পিউটার ছিল: 3 টি ফ্লাইট সফটওয়্যারটি চালাচ্ছিল, এটি যাচাই করে যাচাই করে যে তারা সকলেই সম্মত হয় তা নিশ্চিত করে, এবং পঞ্চম এক চলমান সফ্টওয়্যার একই স্পেস ব্যবহার করে লিখিত ছিল তবে ভিন্ন বিক্রেতাকে, কেবল ক্ষেত্রে। অভাবনীয় ঘটেছে। আপনি এই স্তরের কঠোরতায় যাওয়ার সিদ্ধান্ত নেন বা না করেন এটি সম্পূর্ণ আপনার উপর নির্ভর করে তবে এর নজির রয়েছে pre

— রবার্ট হার্ভে

আপনি একটি জিনিস জানেন, যা হ'ল যখনই সিস্টেম_এ এবং সিস্টেম_বি একে অপরের সাথে একমত না হন, তাদের মধ্যে একটিতে বাগ রয়েছে। এটি আপনাকে উভয় সিস্টেমে কিছু বাগ খুঁজে পেতে সহায়তা করবে। যদি সিস্টেম_এ শুধুমাত্র "গুরুত্বপূর্ণ" হয় তবে এটি সিস্টেম_এ-তে কিছু বাগ খুঁজে পেতে সহায়তা করেছিল, কেবল সমস্তই নয়। এটি আনুষ্ঠানিক যাচাইকরণের পিছনে একই ধারণা।

— ব্যবহারকারী 253751

আপনার প্রশ্ন থেকে পরিষ্কার নয় এমন কিছু: সিস্টেম এ এবং বি একই কোডবেস বা বিভিন্ন কোডবেসগুলি চালায়? যদি দ্বিতীয়টি হয়, তবে তারা দ্বিমত পোষণ করলে আপনাকে উভয়কেই ভুল বিবেচনা করতে হবে এবং যে কারণগুলি তারা বিভিন্ন উত্তর দিয়েছে তা সনাক্ত করতে হবে।

— kdgregory

এবং আপনার প্রকৃত প্রশ্নটির জন্য ("এটি কি একটি খারাপ অভ্যাস"): কেবলমাত্র যদি আপনার ক্রিয়াকলাপগুলিকে ডাবল-চেক করার কোনও কারণ নেই। এবং সাধারণ ব্যবসায়িক ব্যবহারে, এমনটি হয় না। আপনি যদি স্পেস শাটল চালাচ্ছেন, যেমন রবার্ট হার্ভে উল্লেখ করেছেন, আছে। এবং কিছু অ্যাপ্লিকেশন রয়েছে যেমন স্টক ট্রেডিং বা আবহাওয়ার পূর্বাভাস, যেখানে আপনার দুটি সিস্টেম থাকতে পারে যা দ্বিমত পোষণ করে এবং সেগুলি উভয়ই বৈধ (যদি প্রয়োজনীয়ভাবে "সঠিক" না হয়)।

— kdgregory

Answer 1

• O_A ভুল, O_B ঠিক আছে

ফিক্স এ

• O_A ঠিক আছে, O_B ভুল

ঠিক করুন খ

• O_A ঠিক আছে, O_B ঠিক আছে

আশা করি, তারাও একমত।

• O_A ভুল, O_B ভুল

আশা করি, তারা রাজি নয় তাই আপনি এটি সম্পর্কে কিছু করতে জানবেন know

কোনও প্রক্রিয়া সব কিছু ধরে না। অবশ্যই, আপনি আপনার কোড দ্বিগুণ করেছেন তবে এটি 2 ইন ও (2 এন) এর মতো ভাবেন। ইন্টিগ্রেশন পরীক্ষার সমস্ত উপায় অটোমেটেড কিউএ একটি দুর্দান্ত জিনিস। ম্যানুয়াল টেস্টিং উদ্ভাবনের উপর একটি টান। বিশেষ করে ক্রস কাটিং পরিবর্তনগুলি যা সম্পূর্ণ পরীক্ষার দাবি করবে। এছাড়াও, যেহেতু আপনি বিভিন্ন প্রোগ্রামার একই জিনিস প্রয়োগ করবেন, তাই আপনি তাদের রেস করতে পারেন।

বিভিন্ন বাগ পাওয়ার প্রতিক্রিয়া বাড়ানোর জন্য আলাদা লোক হওয়া উচিত। আমি সিস্টেম এ থেকে মোকাবেলা করে সিস্টেম বি তৈরি করার পরামর্শ দিচ্ছি না যা আপনাকে দেয় তা একটি রেজিস্ট্রেশন পরীক্ষা। নতুনের সাথে তুলনা করার জন্য আপনি ও_এর পুরানো অনুলিপিগুলি কেবল সংরক্ষণ করে একই জিনিসটি পেতে পারেন।

প্রশ্নটি হ'ল: বাস্তব সিস্টেমটি পরীক্ষা করার জন্য "টেস্ট সিস্টেম" তৈরি করা কি খারাপ অভ্যাস?

যদি তা হয় তবে সমস্ত পরীক্ষা খারাপ।

• পিচ্ছিল opeাল কি? তাহলে, আমরা কি পরীক্ষা করতে পারি না যে "টেস্ট সিস্টেম" পরীক্ষা করার জন্য আমাদের আরও একটি সিস্টেমের দরকার?

হ্যাঁ, আমরা তর্ক করতে পারি। আমরা এই 3 য় সিস্টেম, system_A কল করব। : P: P

• ব্যয়টি অবশ্যই স্পষ্টভাবে নিষিদ্ধ, কারণ বিকাশকারীদের এখন কমপক্ষে 2 কোড বেসগুলি শিখতে হবে, সম্ভবত সিস্টেম_এর জটিলতা সিস্টেম_এ এর চেয়ে বড়। সংস্থার কাছে সিস্টেম_বি এর আশেপাশে থাকা কতটা ভাল বা খারাপ তা আমরা কীভাবে প্রমাণ করব?

সংখ্যার মতো খুশি গ্রাহক যা আমাদের এনআরপি বন্দুক নিয়ে খেলতে দেয়। আপনি ম্যানুয়াল পরীক্ষার ব্যয় থেকে নিজেকে মুক্ত করেছেন। আপনি এমন কিছু তৈরি করেছেন যার ত্রুটি প্রতিটি সময় এটির দ্বারা ধরা পড়লে তার কার্যকারিতা প্রমাণিত হবে। বাগের দেরি রিপোর্টের তুলনায় প্রারম্ভিক ব্যয়টি খুব কম দামে ধরা পড়ে।

• সিস্টেম_বি তৈরির মূল "বাধ্যতামূলক" কারণগুলির একটি ছিল "স্বয়ংক্রিয়" পরীক্ষা করা " এখন আমরা খুব গর্বিত যে আমরা সম্পূর্ণ স্বয়ংক্রিয়ভাবে আছি (কারণ সিস্টেম_বি আউটপুট উত্পন্ন করতে নিজেই ব্যবহার করার প্রক্রিয়াটি বুটস্ট্র্যাপ করতে ইনপুট জেনারেট করে)। তবে আমি মনে করি আমরা অবিশ্বাস্য উপায়ে আরও ক্ষতি এবং আরও জটিলতা প্রবর্তন করেছি। কিউএর কাজটি কি সম্পূর্ণ স্বয়ংক্রিয়ভাবে পরিচালিত হবে? সমান্তরাল ব্যবস্থা তৈরির ন্যায্যতা কি সেই কারণেই যথেষ্ট?

সিস্টেম_বি এর জটিলতা সিস্টেম_এ থেকে বিস্ময়করভাবে বিচ্ছিন্ন। সিস্টেম_এতে বৈশিষ্ট্যগুলি যুক্ত করা কোনও কঠিন নয় কারণ সিস্টেম_বি রয়েছে। এটি প্রকৃত পক্ষে সহজ কারণ সিস্টেম_বি তাদের দ্রুত যাওয়ার আস্থা দেয়।

• আমার আসল উদ্বেগটি এটি, যদিও আমরা সকলেই জানি সিস্টেম_বি ভুল (বেশিরভাগ সময়)। যদি সিস্টেম_বি ইনপুট প্রক্রিয়াকরণে এত ভাল এবং এর আউটপুট স্বর্ণের উত্স হয় তবে কেন সিস্টেম_একে সিস্টেম_এ প্রতিস্থাপন করবেন না? এটির জন্য, কর্মস্থলে কেউ সন্তোষজনক প্রতিক্রিয়া সরবরাহ করতে সক্ষম নয়।

এটি কি টাইপো? সিস্টেম_বি প্রায়শই ভুল হয় তাই আপনি সিস্টেম_এ প্রতিস্থাপনের জন্য সোনার মানটি ব্যবহার করতে চান?

আমি ধরে নিচ্ছি আপনার বোঝানো সিস্টেম_এ প্রায়শই ভুল is কোনটি বেশিরভাগ ক্ষেত্রে ভুল তা আসলেই আসে না। যার যে কোনও একটি ভুল যা কাজের প্রয়োজন। এই সিস্টেমগুলি সঠিক এবং ভুল সিদ্ধান্ত নেয় না, বিকাশকারীরা করেন। পরীক্ষাটি যা করে তা হ'ল একটি মতবিরোধ তৈরি হয় যার অর্থ কিছু সঠিক নয়। এটি কী তা বিকাশকারীরা খুঁজে বের করে। মনে রাখবেন, এখানে কোনও স্বর্ণের মান উত্পাদিত হচ্ছে না। কেবল চুক্তি বা মতবিরোধ আছে। মতবিরোধ দাবি করে যে কাজ করা উচিত। সেই কাজের অংশটি কোথায় খুঁজে বের করা হচ্ছে।

Answer 2

আপনার যখন উত্পাদনের এমন কোনও সিস্টেম থাকে যা গ্রাহকরা আসলে ব্যবহার করেন, বাগফিক্সগুলি যাচাই করার জন্য একটি QA সিস্টেম থাকা এবং নতুন কার্যকারিতা চূড়ান্তভাবে আবশ্যক। মানের দিক থেকে, এটি যতটা সম্ভব উত্পাদন ব্যবস্থার প্রতিলিপি হিসাবে কাছাকাছি হওয়া উচিত। এই পদ্ধতিতে, আপনি যদি নিশ্চিত করেন যে উত্পাদন ব্যবস্থা এবং এর কিউএ সিস্টেমটি অভিন্ন, অন্যটিতে কী কাজ করে, অন্যটির সাথে কাজ করা উচিত। যদি এটি না হয়, তবে সিস্টেমগুলি অভিন্ন নয়, ইনপুটগুলি অভিন্ন ছিল না, এবং / অথবা ফলাফলগুলি ভুল ব্যাখ্যা করা হয়েছিল।

এটি দ্বিগুণ হয়ে যায় সুতরাং যদি আপনার সিস্টেমটি মিশন সমালোচনামূলক এবং 24/7 উপলভ্য হওয়া প্রয়োজন। তারপরে আপনি কিউএ সিস্টেম না রাখার জন্য বিলাসিতা জোগাড় করতে পারবেন না, কারণ আপনাকে অবশ্যই উত্পাদন সিস্টেমের ডাউনটাইমটি একেবারে হ্রাস করতে হবে। এবং যদি এটি 24/7 সিস্টেম হয়, তবে উত্পাদন পদ্ধতির সঠিক প্রতিরূপ একটি খুব, খুব দৃ strong় সুপারিশ।

এখন, এই পদ্ধতির সুস্পষ্ট অপূর্ণতা হ'ল ব্যয়। এটি হার্ডওয়্যার ব্যয় দ্বিগুণ করে, এবং স্থাপনা এবং রক্ষণাবেক্ষণ ব্যয় বৃদ্ধি করে। এছাড়াও, উত্পাদন সিস্টেম থেকে QA- এ ডেটাগুলির একটানা প্রতিলিপি প্রয়োগ করা উচিত, যাতে সিস্টেমগুলি যে ডেটাগুলির সাথে কাজ করে তার পার্থক্যের কারণে আমরা বিভিন্ন ফলাফলের সম্ভাবনা হ্রাস করতে পারি।

উত্পাদনের সিস্টেমের সাথে তুলনামূলকভাবে QA সিস্টেমের কিছু উপাদানকে হ্রাস করে কিছু ভারসাম্য পাওয়া যায়, যাতে বেশিরভাগ কার্যকারিতা সঠিকভাবে পরীক্ষা করা যায়। এগুলি সাধারণত অপ্রয়োজনীয় সার্ভার, সার্ভারের আকার বা ওয়ার্ক স্টেশনগুলির সংখ্যা। যাইহোক, এটি আমার অভিজ্ঞতা যে কিছু বাগ সর্বদা হ্রাস করা অংশে হুবহু পাওয়া যায় এবং তারপরে উত্পাদন সিস্টেমে ন্যূনতম অনুমোদিত ডাউনটাইম বজায় রেখে সমস্যাটি পুনরুত্পাদন করা এবং সংশোধন বাস্তবায়ন করা দুঃস্বপ্ন।

Answer 3

যে কোনও সময় আপনি কোনও সিস্টেম পরীক্ষা করেন আপনার প্রত্যাশিত ফলাফলটি কী তা জানতে হবে।

সিস্টেমের এই প্রত্যাশিত ফলাফলটি উত্পন্ন করার সমস্যাটি অবশ্যই 'আমি কীভাবে সেই সিস্টেমটিকে পরীক্ষা করব' is

তবুও লোকেরা প্রত্যাশিত ফলাফলের সেট তৈরি করতে উদাহরণস্বরূপ স্প্রেডশিট ব্যবহার করা স্বাভাবিক নয় not

দিনের শেষে যদিও আপনাকে সিস্টেমের প্রয়োজনীয়তার ব্যাখ্যা করতে এবং ম্যানুয়ালি প্রত্যাশিত ফলাফল উত্পন্ন করতে একজন মানুষের প্রয়োজন। আপনার যদি কোনও সিস্টেম থাকে এবং কেবলমাত্র পার্থক্যগুলি পরীক্ষা করে দেখুন তবে আপনি নিজের পরীক্ষাটি এড়িয়ে যাচ্ছেন।