উন্নয়ন এবং কিউএর মধ্যে দীর্ঘ বিলম্বের ব্যয়

18

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

আমি আমার কোড কমপ্লিটের অনুলিপিটিতে ফিরতে থাকি, একটি "হার্ড ডেটা" স্নিপেট খুঁজছি যা দেখায় যে ত্রুটিগুলি স্থির করার ব্যয়টি তত বেশি বাড়ায় তত দ্রুততর বৃদ্ধি পায়। কেউ কি আমাকে কিছু স্টাডিতে নির্দেশ করতে পারেন যা এই ধারণার ব্যাক আপ করে? আমি সেই শক্তিগুলিকে বোঝানোর চেষ্টা করছি যে তারা কি মনে করে QA বাধা অনেক বেশি ব্যয়বহুল।

development-process qa

— নীল এন
সূত্র

এটি "প্রযুক্তিগত debtণ" এর একটি রূপ।

— ব্রায়ান

3

@ ব্রায়ান - দয়া করে আমি ভুল হলে আমাকে সংশোধন করুন তবে আইএমও এটি টিডির পক্ষে উপযুক্ত নয় কারণ সেখানে প্রতি সেউতে কোনও debtণ নেই। এটি প্রক্রিয়াটি ধীর করে এবং "পরে করা হবে" নয়

— পিএইচডি

7

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

— ব্রায়ান

@ ব্রায়ান - যথাযথভাবে উল্লেখ এবং স্বীকৃত :)

— পিএইচডি

1

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

— টায়না

10

আপনার কোনও রেফারেন্স দরকার নেই, আইএমএইচও। এখানে আপনি যা করতে পারেন (বরং করা উচিত ):

বিলম্বের ব্যয় মাপুন! আসুন ধরে নেওয়া যাক বৈশিষ্ট্য (গুলি) পরীক্ষা করতে এটি 1 সপ্তাহ সময় নেয়। একটি 2-3 সপ্তাহের বিলম্ব বোঝায় যে বৈশিষ্ট্যটি কমপক্ষে 4 র্থ সপ্তাহ পর্যন্ত উপলব্ধ হবে না। এবং এটিও 100% সাফল্য ধরে নিয়েছে। অন্য সপ্তাহের একটি স্থির সময় যুক্ত করুন যাতে প্রায় 5 সপ্তাহের বিলম্ব হয়।

এখন সম্ভব হলে প্রকল্প / বৈশিষ্ট্যটির প্রত্যাশিত সময়সীমার অ্যাক্সেস পান। ক্লায়েন্ট কখন এটি আশা করে? পিছলে যাবে? যদি তা না হয়, তবে অন্যরা কি পরিণতি হিসাবে পিছলে যাবে? তাহলে আর কতটা 'মুক্তি' ফলস্বরূপ বিলম্বিত হবে?

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

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

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

ভাগ্যের জন্তু! (পাং উদ্দেশ্য :)

— পিএইচডি
সূত্র

6

আমি সত্যিই মনে করি না যে কোড কমপ্লিটটি এখানে আপনার জন্য সঠিক সংস্থান। এটি কোনও কোড সমস্যা নয়, এটি একটি প্রক্রিয়া সমস্যা এবং সম্ভবত পরিচালনার সমস্যা।

যদি আপনার প্রক্রিয়াটির অংশটি বিশেষত দুর্বল হয় তবে থিওরি অফ কন্ট্রাক্টস বের করার সময় এসেছে :

সীমাবদ্ধতা চিহ্নিত করুন।

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

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

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

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

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

এবং যদি এর কোনওটিই যদি কাজ না করে ... তবে সম্ভবত আপনি একটি অকার্যকর সংস্থায় রয়েছেন, খুব দেরী হওয়ার আগে বেরিয়ে যান!

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

— Aaronaught
সূত্র

দুর্দান্ত উত্তর। ()) এর অধীনে আরও একটি বিকল্প সন্ধান করার জন্য, বিকাশকারীদের পরীক্ষার অটোমেশন, প্রক্রিয়া অটোমেশন ইত্যাদির সাহায্যে কিউএ সহায়তা করতে সক্ষম হওয়া উচিত Q

— ক্রিস পিটম্যান

4

29 এবং 30 পৃষ্ঠাগুলিতে আপনার সন্ধান করা ডেটা থাকতে পারে, যদিও ফলোআপের প্রয়োজন হতে পারে।

আমি 30 পৃষ্ঠায় এই বাক্যে উল্লিখিত গবেষণাটি খতিয়ে দেখব:

কয়েক ডজন সংস্থায় দেখা গেছে যে কোনও প্রকল্পের পরে কেবল ত্রুটিগুলি সংশোধন করার দিকে মনোনিবেশ করা দু'জন বা তার বেশি (ম্যাককনেল ২০০৪) এর কারণগুলির দ্বারা উন্নয়ন ব্যয় এবং সময়সূচি হ্রাস করতে পারে।

বিটিডব্লিউ, এটি আপনার প্রশ্ন যা আমাকে পুনরায় রিফ্রেশ করার জন্য বইটি আবার তুলতে বাধ্য করেছে :-)

— Krzysztof Kozielczyk
সূত্র

3

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

— ওয়ার্নিকা

1

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

— Krzysztof Kozielczyk

আপনি ঠিক বলেছেন, সম্পাদনায় আপনি যে ডেটা যুক্ত করেছেন তা প্রাসঙ্গিক হতে পারে।

— ওয়ারোনিকা

3

আপনি যা বর্ণনা করছেন তা হ'ল একটি প্রক্রিয়াতে বাধা। চর্বিবিজ্ঞানের তত্ত্বটি বলে যে একটি প্রক্রিয়াটিতে সর্বদা বাধা থাকবে তবে এর তীব্রতা ব্যাপকভাবে পরিবর্তিত হতে পারে। কিউএ যদি অতিরিক্ত অতিরিক্ত ভাড়া নেয়, তবে বিকাশ হয়তো বাধা হয়ে দাঁড়াবে।

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

সেই দৃশ্যে, বিলম্বের ব্যয় হ'ল বিকাশকারীর বেতনের ব্যয়, কারণ তার কাজ নষ্ট হবে।

আমি যে কারণে ব্যয় এবং প্রক্রিয়াটি দ্বারা তৈরি করা মূল্য নয় তার দিক দিয়ে তর্ক করার কারণটি কেবলমাত্র এটির চেয়ে ভাল হলেও কোনও প্রক্রিয়ার মান ডকুমেন্ট করা শক্ত because

— ডেভিড
সূত্র

3

আমি আমার কোড কমপ্লিটের অনুলিপিটিতে ফিরতে থাকি, একটি "হার্ড ডেটা" স্নিপেট খুঁজছি যা দেখায় যে ত্রুটিগুলি স্থির করার ব্যয়টি তত বেশি বাড়ায় তত দ্রুততর বৃদ্ধি পায়। কেউ কি আমাকে কিছু স্টাডিতে নির্দেশ করতে পারেন যা এই ধারণার ব্যাক আপ করে?

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

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( এখানে থেকে টেবিল )

চতুর সফ্টওয়্যার বিকাশের পদ্ধতির অন্যতম লক্ষ্য হ'ল এই স্বতন্ত্র স্তরগুলি সরিয়ে নেওয়া এবং এই ব্যয়গুলি হ্রাস করা। জলপ্রপাতের জন্য অন্যান্য পদ্ধতি ব্যবহার করার সময় পরিসংখ্যানগুলি প্রয়োগ হয় না।

— ডেভ হিলিয়ার
সূত্র

2

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

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

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

এছাড়াও আপনি পরিচালক হিসাবে, আমি বলতে পারি যে টেস্টের কাজটি আপনার ত্রুটিগুলি খুঁজে পাওয়া যায় না, তাদের কাজটি হ'ল কোনও ত্রুটি রয়েছে তা খুঁজে পাওয়া - যদি আপনি তাদের ত্রুটিগুলি খুঁজে পাওয়ার প্রত্যাশা করেন, তবে আপনি সম্ভবত আপনার কাজটি ভালভাবে করেননি।

আপনি কীভাবে এটি কাছে যান সে সম্পর্কে সতর্ক থাকুন। যদি আপনার সমস্যার সমাধান না হয় তবে আপনি সম্ভবত দ্বিতীয়টি থেকে বেরিয়ে আসবেন।

— mattnz
সূত্র

'' "টেস্টিং বিভাগের কাজটি ত্রুটিগুলি খুঁজে পাওয়া নয় Their তাদের কাজটি হ'ল কোনও ত্রুটি নেই are" "এটি একটি দুর্দান্ত স্নিপেট। আমি কি তার সাথে উদ্ধৃতি দিতে পারি?

— sleske