কখন পরীক্ষা বন্ধ করবেন কীভাবে জানবেন?

Question

আমি জানি এটি খুব খুব প্রাথমিক প্রশ্ন। কিছু সফ্টওয়্যার অ্যাপ্লিকেশনগুলির জন্য একটি অ্যাপ্লিকেশনটির জন্য বড় আকারের প্রায় অসীম পরীক্ষার কেস রয়েছে। এই সমস্ত পরীক্ষার কেস পরীক্ষা করা ব্যবহারিক নয়। কখন কীভাবে পরীক্ষা বন্ধ করা যায় তা আমরা কীভাবে সিদ্ধান্ত নেব? ("যখন অর্থ শেষ হয়" ব্যতীত)।

Comments

যখন এটি ব্যর্থ ..

— জাভিয়ের

আমার মনে হয় আপনি মাইকেল বোলটনের ব্লগ পোস্টটি পরীক্ষা করার জন্য হিউরিস্টিক্স বন্ধ করার বিষয়ে ব্লগ পোস্টটি পড়তে দরকারী: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/ আপনি কিছুটিকে চিনতে পারেন এই থ্রেডে হিউরিস্টিকরা পরামর্শ দিয়েছে।

— পরীক্ষামূলক

আমার অভিজ্ঞতায় পেরেটো নীতি প্রয়োগ করে এটি যথেষ্ট হয়েছে ।

— আমির রেজায়ে

Answer 1

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

কিছু মডিউল এবং নির্দিষ্ট ফাংশনগুলিতে বাগগুলি "গুচ্ছ" থাকে: আপনি যে মুহূর্তে একটি বাগ খুঁজে পান, আপনি জানেন যে আরও বাগের জন্য আপনাকে আরও এটি দেখতে হবে। বাগগুলি খুঁজে পেতে, আপনি ব্ল্যাকবক্স টেস্টিং, হোয়াইটবক্স টেস্টিং এবং মিউটেশন টেস্টিংয়ের কৌশলগুলি ব্যবহার করতে পারেন । যতক্ষণ আপনি বাগগুলি সন্ধান করছেন ততক্ষণ আপনি জানেন যে আপনার পরীক্ষার প্রক্রিয়াটি কাজ করছে!

আপনার অগ্রগতিটি কল্পনা করতে আপনার দলটি প্রতিদিন যে পরিমাণ বাগ খুঁজে পেয়েছে তার চার্ট করুন। যদি চার্টটি নীচে opালু হয়ে যায়, তবে আপনি জানেন যে আপনার দলটি যে কৌশলগুলি ব্যবহার করছে তা সেগুলি আর খুঁজে পাবে না। অবশ্যই, যদি আপনি বিশ্বাস করেন যে আপনার কৌশলগুলি সমান নয়, তবে দয়া করে মাইয়ার্স বইটি পড়ুন নীতিগুলি প্রয়োগ করুন।

এখন, এমন একটি সম্ভাবনা রয়েছে যে আপনি সম্ভবত নতুন প্যাচ বাগের অভাব অনুভব করতে পারেন এবং আপনি যদি আরও কিছুটা পরীক্ষা চালিয়ে যান তবে বাগগুলি খুঁজে পাওয়ার হার অনেক বেড়ে যেত। তবে আপনি যদি বিশ্বাস করেন যে আপনার কৌশলগুলি সুদৃ sound় হয় তবে এটি অসম্ভাব্য।

Comments

নতুন বাগগুলি খুঁজে পাওয়ার হার বাহ্যিক কারণগুলির উপর অত্যন্ত নির্ভরশীল এবং দুঃখের বিষয় - কিছু প্রকল্প পরিচালকরা এটি খেলবে। কেম কনার পরীক্ষার দলকে সিনেমাগুলিতে প্রেরণের জন্য উদাহরণ উল্লেখ করেছেন যাতে বাগ আবিষ্কারের হার হ্রাস পায় এবং প্রধানমন্ত্রী পাঠাতে পারেন।

— পরীক্ষামূলক

Answer 2

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

এটি একটি ভাল সিস্টেম পরীক্ষকের জন্য সত্যই একটি প্রশ্ন (এবং আমি একজন নই) তবে আমি এটির শট দেব।

আপনার প্রাথমিক পরিমাপটি পরীক্ষার কভারেজ হতে চলেছে: অ্যাপ্লিকেশনটির কতটা পরীক্ষামূলকভাবে করা হয়েছে (ইউনিট টেস্ট এবং কার্যকরীভাবে উভয়ই)।

আপনার প্রতিটি সম্ভাব্য ব্যবহারের কেস (এবং সেই ব্যবহারের ক্ষেত্রে প্যারামিটারগুলি) আসল ব্যবহারের সম্ভাবনা (তাই আপনি প্রান্তের কেসগুলি ফেলে দিতে পারেন), জটিলতা (সহজ জিনিসগুলি বাগগুলি ধারণের সম্ভাবনা কম, বা শক্ত ধারণের কম সম্ভাবনা কম) মূল্যায়ন করতে হবে বাগগুলি খুঁজে পেতে), পরীক্ষার জন্য ব্যয় (সময়ের নিরিখে) এবং সেই অঞ্চলে যদি কোনও ত্রুটির সম্ভাব্য প্রভাব খুঁজে পাওয়া যায় (এটি এখানে পারমাণবিক চুল্লি বনাম ব্লগিং প্ল্যাটফর্ম আসে) in

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

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

এটি প্ল্যাটফর্ম পরীক্ষায়ও প্রসারিত হতে পারে - আপনি যদি দুটি ডাটাবেস ব্যাক এন্ডস (বা একাধিক ব্রাউজার) সমর্থন করেন তবে একটিতে অর্ধেক অ্যাপ্লিকেশনটি পরীক্ষা করুন, অন্য অর্ধেকটি অন্যটিতে এবং তারপরে পরবর্তী রিলিজটি অদলবদল করুন।

(আমি মনে করি এটি স্ট্রাইপিং হিসাবে উল্লেখ করা হয় তবে সে সম্পর্কে আমাকে উদ্ধৃতি দেবেন না))

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

Answer 3

যখন সফ্টওয়্যারটির ব্যবহারের সাথে সম্পর্কিত ঝুঁকিটি গ্রহণযোগ্য স্তরে হ্রাস পেয়েছে।

Comments

ঠিক আছে যে সমস্যা বিবৃতি, শুধু reprassed, তাই না?

— মার্টিন উইকম্যান

@ মার্টিন: আপাতদৃষ্টিতে তা নয়। পরীক্ষার কেস 1 দিয়ে শুরু করা এবং পরীক্ষার কেস দিয়ে শেষ করা than এর পরিবর্তে এই উত্তরটি প্রশ্নকর্তাকে সর্বাধিক গুরুত্বপূর্ণ টেস্ট কেস দিয়ে শুরু করতে এবং যখন তারা আর মান যোগ না করে তখন শেষ করতে হবে।

দার্শনিক দিক থেকে সঠিক (এবং চিন্তাশীল) থাকাকালীন, আমি মনে করি যে ওপি কিছুটা হ্যান্ডস-ইন করছে।

— মার্টিন উইকম্যান

"গ্রহণযোগ্য" এর আগেই সংজ্ঞা দেওয়া যেতে পারে। এটি বেশ কিছুটা সাহায্য করে।

@ থরবজর্ন: "সংজ্ঞায়িত করা যায়"। হ্যাঁ কিন্তু কিভাবে? ওপি এটিই সন্ধান করছে।

— মার্টিন উইকম্যান

Answer 4

"প্রোগ্রাম টেস্টিংগুলি বাগের উপস্থিতি দেখানোর জন্য ব্যবহার করা যেতে পারে, তবে তাদের অনুপস্থিতিটি প্রদর্শন করতে কখনও হবে না!" - এড্জার ডিজকস্ট্রা

কোনও পরীক্ষা, স্বয়ংক্রিয় বা অন্য কোনও কাজ করার সময় মনে রাখা ভাল কিছু। আপনি কেবলমাত্র প্রমাণ করতে পারবেন যে আপনি আর কোনও বাগ খুঁজে পান নি, এমনও নয় যে আরও কিছু নেই।

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

মূলত, আপনি দুটি বড় জায়গায় beাকা থাকতে চান:

1. সফ্টওয়্যারটি বিডিডি পরীক্ষাগুলি পাস করে যা দেখায় যে এটি নির্দিষ্ট প্রয়োজনীয়তা পূরণ করে। এমনকি যদি এটি সত্য না হয় তবে সফ্টওয়্যারটিকে সম্পন্ন বলা যায় না।

2. সবচেয়ে জটিল, জটিল এবং অনিশ্চিত অংশগুলিতে আত্মবিশ্বাস দেওয়ার জন্য পর্যাপ্ত পরীক্ষা আছে? যদি এটি একটি মূল লুপ, বা এমন কিছু যা আপনাকে অনুকূল করতে বা হ্যাক করতে হয়েছিল: এটিতে একটি পরীক্ষা করুন। যদি এটি জটিল হয় এবং প্রচুর যৌক্তিক বিভাজন থাকে: এটিতে প্রচুর পরীক্ষা করা। যদি আপনি এটি পরীক্ষা করতে না পারেন, বা এটি ব্যবহারিকভাবে সরাসরি পরীক্ষার জন্য খুব গভীর এম্বেড করা হয়েছে: কোডটি পর্যালোচনা করা হয়েছে এবং কোডটি পরোক্ষভাবে হাতে হাতে পরীক্ষিত হয়েছে তা নিশ্চিত করুন।

Answer 5

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

Comments

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

— পরীক্ষামূলক

Answer 6

আপনি যদি ইউনিট পরীক্ষার কথা বলছেন এবং আপনি টিডিডি করছেন (পরীক্ষাগুলি প্রথমে লিখছেন) তবে এটি একটি নন-ইস্যু: বৈশিষ্ট্যগুলি সম্পন্ন হওয়ার পরে আপনি কেবল পরীক্ষা বন্ধ করে দেন।

ইনক্রিমেন্টাল টিডিডিতে আপনি একটি পরীক্ষা লিখে ফেলেন যা ব্যর্থ হয়, তারপরে ক্ষুদ্রতম কোড প্রয়োগ করুন যা এটি পাস করতে পারে, তারপরে রিফ্যাক্টর। পদ্ধতিটি বৈশিষ্ট্য সম্পূর্ণ না হওয়া পর্যন্ত এই পদ্ধতিতে পরীক্ষা যোগ করে চলুন।

এখানে একটি দুর্দান্ত উদাহরণ।

Answer 7

পরিসংখ্যানবিদরাও এই বিষয়টির দিকে নজর দিয়েছেন - আসলে ১৯ the০-৮০-এর দশকের প্রথম দিকে। কীভাবে বাগগুলি অনুসন্ধান করা হয় সে সম্পর্কে যথাযথ অনুমান দেওয়া হয়েছে তারা পরীক্ষার ডেটা থেকে বাগের সংখ্যা অনুমান করার চেষ্টা করে। এটি পরে কোনও ক্ষতির ক্রিয়াকে অনুকূলকরণের ভিত্তিতে কখন থামতে হবে তা নির্ধারণ করতে ব্যবহৃত হয়। বাস্তবে এটি কীভাবে করা যায় সে সম্পর্কিত আর কোড সহ এই ইস্যুতে যে কোনও একটি কাগজের সংক্ষিপ্ত চিকিত্সার জন্য উদাহরণস্বরূপ https://rpubs.com/hoehle/17920 দেখুন ।

অবশ্যই একটি সমস্যা হ'ল বাগ আবিষ্কার প্রক্রিয়া সম্পর্কে সর্বদা অনুমান হবে। উদাহরণস্বরূপ, উপরের চিকিত্সায় এটি ধারণা করা হয় যে বাগগুলি একে অপরের থেকে পৃথকভাবে সন্ধান করা হয়। অনুশীলনে, একটি বড় বাগ ঠিক করা, যেমন, নতুন বাগ ইত্যাদি তৈরি করতে পারে তবে এটি একটি সূচনা দেয় এবং অন্ত্রের অনুভূতির পরিপূরক হয়।

Answer 8

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

Comments

এমনকি আপনি যদি অর্পণ করেন তবে এর অর্ধেক পরীক্ষা না করেও? এটি সফ্টওয়্যার বিকাশের সাথে ভুল wrong অসম্পূর্ণ পরীক্ষার সাথে আপনার আর জাহাজ করা উচিত নয় যে আপনি এর অর্ধেকটি কোড করে না।

— জন হপকিন্স

এটি পরীক্ষকটিতে কেবল একটি নির্দিষ্ট মনস্তাত্ত্বিক পদত্যাগ উত্পন্ন করবে। আমি ভাবতে যাচ্ছি "আমি যাই করুক না কেন, আমি এই জিনিসটিকে পুরোপুরি পরীক্ষা করতে পারছি না যেহেতু এটি জানুয়ারীর দশম তারিখে যেভাবেই চালানো হবে তাই আমি তখন পর্যন্ত যা করতে পারি তা করতে পারি"। আমাদের যেভাবে সফটওয়্যার তৈরি করা উচিত তা নয়?

— আরএসম্যান

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

— পরীক্ষামূলক

যদিও আমি সম্পূর্ণরূপে সম্মত হই: এটি পরীক্ষা না করা পর্যন্ত শেষ হয়নি। (আমি এই ধারণার সাথে একমত হতে পারি যে আমরা একটি পরীক্ষার পর্বের চেয়ে "ফিক্সিং ফেজ" শব্দটি ব্যবহার করা ভাল। "আমরা এখন সম্ভবত আর কোন পরীক্ষা করতে পারছি না", কেবল "এখন আর পরীক্ষা করা আমাদের পক্ষে মূল্যবান বলে মনে হচ্ছে"।

— testerab

Answer 9

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

Answer 10

এগুলি সমস্ত আত্মবিশ্বাসের বিষয়টিতে ফোটে। আপনি কি নিশ্চিত যে সিস্টেমটি যথেষ্ট পরীক্ষিত হয়েছে?

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

এখানে "সম্পন্ন-সূচকগুলি" সম্পর্কিত কয়েকটি পরীক্ষা রয়েছে:

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

আপনি যদি এই বিষয়গুলি পরীক্ষা করতে পারেন, তবে আপনি সম্ভবত বলতে পারেন যে আপনি যথেষ্ট পরীক্ষা করেছেন।

Answer 11

কখনই না, আমি মনে করি আপনি কোনও সিস্টেমে পরীক্ষা শেষ করবেন না .. এমন অনেকগুলি ভেরিয়েবল রয়েছে যা আপনি পরিচালনা করতে পারবেন না।

তবে, যেমনটি আমরা জানি, আপনি "চিরকালের জন্য" পরীক্ষা করতে পারবেন না, তাই আমি মনে করি সীমাটি মূলত এর উপর নির্ভর করে:

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

Answer 12

যখন মোতায়েনে সাইন আপ করতে হয় এমন লোকেরা সন্তুষ্ট হয়।

বা কোনও কোনও ক্ষেত্রে বেশিরভাগ দায়িত্বশীল পক্ষই সন্তুষ্ট।