এমন কোনও সংস্থায় এটি ইউনিট টেস্টিং বাস্তবায়ন করছে


19

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

বিকাশকারীদের কাছ থেকে প্রতিক্রিয়াটি হ'ল:

  • আমরা জানি টেস্টিং মূল্যবান
  • তবে, আপনি সর্বদা চশমা পরিবর্তন করে যাচ্ছেন তাই এটি সময় নষ্ট হবে
  • এবং, আপনার সময়সীমা এতটাই সংকীর্ণ যেভাবেই হোক আমাদের পরীক্ষা করার মতো পর্যাপ্ত সময় নেই

সিইওর কাছ থেকে দেওয়া মতামতটি হ'ল:

  • আমি চাই যে আমাদের সংস্থাটি স্বয়ংক্রিয় পরীক্ষণ করুক, তবে কীভাবে এটি করা যায় তা আমি জানি না
  • বড় স্পেসিফিকেশন ডকুমেন্ট লেখার জন্য আমাদের কাছে সময় নেই

কীভাবে বিকাশকারীরা এখন চশমা পান? মুখের শব্দ বা পাওয়ারপয়েন্ট স্লাইড। স্পষ্টতই, এটি একটি বড় সমস্যা। আমার পরামর্শটি হ'ল:

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

ঠিক আছে, আপনি যদি এমন কোনও সংস্থায় ছিলেন যা এই পরিস্থিতিতে ছিল, আপনি কীভাবে সমস্যাটি সমাধান করলেন? এই পদ্ধতির কি যুক্তিযুক্ত বলে মনে হচ্ছে?


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

@ জেমস - ব্যবসায়ের পরিবর্তনের প্রয়োজন, তাই সফ্টওয়্যার ইঞ্জিনিয়ারিং যতটা পরিবর্তন পরিচালনা করতে পারে। আমার কাছে সিইও যা বলেছেন তা পুরোপুরি যুক্তিসঙ্গত।
মার্ক বুথ

@ মারকবুথ সেখানে পরিবর্তন এসেছে এবং অবিরাম প্রবাহের অবস্থা রয়েছে। প্রশ্নটি আবার পড়ুন। এই সংস্থাটি এটি তৈরি করছে এটি এগিয়ে যায়।
জেমস

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

উত্তর:


17

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

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

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

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

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


1
আর ডাউনটোটের কারণ ...?
পিয়েটার টারিক

1
"আরও চতুর পদ্ধতির দিকে এগিয়ে যাওয়ার জন্য" +1, এটি আমাকে মনে করিয়ে দেয় "জলের উপর দিয়ে হাঁটা এবং একটি স্পেসিফিকেশন থেকে সফ্টওয়্যার বিকাশ করা সহজ তবেই যদি উভয় হিমায়িত হয়।" - এডওয়ার্ড ভি বেরার্ড
মার্ক বুথ

@ পিটার টরোক ধন্যবাদ ... প্রাসঙ্গিক গ্রহণযোগ্যতা পরীক্ষার তথ্যের জন্য আপনার কোনও লিঙ্ক আছে?
পিট সাপোর্টমোনিকা

@ পিট, আপনার প্রকল্পগুলি, অ্যাপ্লিকেশনগুলির ধরণের সম্পর্কে আরও কিছু না জেনে আরও নির্দিষ্ট হওয়া শক্ত Quick দ্রুত গুগলিং যদিও কিছু প্রতিশ্রুতিবদ্ধ লিঙ্কগুলি দেখায়।
পিটার টারিক

8

রূপান্তরটি নিয়ে আমার অভিজ্ঞতা

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

সম্প্রতি আমি টেস্ট চালিত বিকাশ ব্যবহার করতে উত্সাহিত করেছি এবং আমি এটি সম্পূর্ণ প্রকাশ পেয়েছি। আমি এখন দৃ firm়ভাবে নিশ্চিত হয়েছি যে ইউনিট-টেস্ট না লেখার আমার কাছে সময় নেই

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

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

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

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

নতুন ল্যাবটিতে, আমি সাধারণত আমার ডেস্কে অফ-লাইনটি বিকাশ করে কার্যকারিতা যুক্ত করতে পারি, কেবল তাত্ক্ষণিকভাবে প্রয়োজনীয় জিনিসগুলি উপহাস করে এবং তারপরেই কেবলমাত্র অল্প সময়ের জন্য ল্যাবটিতে ব্যয় করা হয়, বাকী সমস্ত সমস্যা সমাধান না করে ing লাইন।

আমার উপদেশ

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

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

পরিবর্তে আমি ছোট শুরু এবং বয় স্কাউট বিধিটি ব্যবহার করার পরামর্শ দেব :

আপনি যতটা খুঁজে পেয়েছেন তার চেয়ে ক্যাম্পগ্রাউন্ড ক্লিনারটি সর্বদা ছেড়ে যান।

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

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

আপনি যা এড়াতে চান তা বিকাশকারী প্রচেষ্টার লেখার পুরো পরীক্ষার অপচয় করে যা কখনই প্রয়োজন হয় না ( YAGNI পরীক্ষার কোডের পাশাপাশি প্রডাকশন কোড * 8 'এর মতো কাজ করে), আর কখনও ব্যবহৃত হবে না এবং লোককে হতাশায় পরিণত করবে না পরীক্ষাগুলি সব পরে অকেজো যে ভেবে।

সারসংক্ষেপ

ছোট শুরু করুন, ক্রমবর্ধমান পরীক্ষাগুলির উপর আস্থা তৈরি করুন এবং কখন এবং কোথায় আপনার দলকে সবচেয়ে বেশি উপকৃত করবেন তা পরীক্ষার বিকাশ থেকে ব্যবসায়িক মূল্য অর্জন করুন।


2

প্রথমে করণীয় হ'ল পরীক্ষার দিকে মনোনিবেশ না করে সামগ্রিক প্রক্রিয়াটি সঠিকভাবে চালানো। কোনও কিছুর পরীক্ষা করার দরকার নেই যদি এটি পুরোপুরি বুঝতে না পারে তবে এটি করার কথা কি!

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

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

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

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


1

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.