সফ্টওয়্যার টেস্টিং আসলে পেশাদার প্রকল্পগুলিতে করা হয়?


25

আমি বেশ কয়েকটি সংস্থায় অনেক প্রকল্পের সাথে জড়িত ছিলাম কারণ আমি দীর্ঘদিন ধরে বিকাশকারী এবং আমি ঠিকাদার।

আমি অনুমান করি যে 20% এরও কম প্রকল্পগুলি পদ্ধতিগতভাবে পরীক্ষিত। পদ্ধতিগতভাবে পরীক্ষিত হওয়ার সাথে সাথে আমার অর্থ অ্যাডহক ছাড়াই কোনও পরীক্ষার কোনও পরিকল্পনা পরীক্ষা নয়।

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

দুটি প্রশ্ন

  1. এই সমস্যা সম্পর্কে আপনার শতাংশ অনুমান কি?
  2. সফটওয়্যার পরীক্ষা সংক্রান্ত আপনার পেশাদার অভিজ্ঞতা কী?

অতিরিক্ত নোট

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


দুর্দান্ত প্রশ্ন, সংস্কার করার জন্য সময় দেওয়ার জন্য ধন্যবাদ!

@ মার্ক ট্র্যাপ: ধন্যবাদ আমি মনে করি এটি একেবারে মৌলিক তবে আমি আরও কিছু জিজ্ঞাসা করতে পারি (পূর্ববর্তী প্রশ্নগুলির ভিত্তিতে)
রবার্ট কোরিতনিক

উত্তর:


8

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

তারা বলেছে যে এখনও কিছু প্রকল্প রয়েছে যা অতিরিক্ত মাত্রায় পরীক্ষা করা হয়েছে এবং সেগুলি যথেষ্ট পরীক্ষা করা হয়নি, তবে এগুলি সংখ্যালঘু।


আমি আমার প্রশ্নটি কিছুটা সম্পাদনা করেছি। আপনি কি আপনার অনুমান সরবরাহ করতে পারেন?
রবার্ট কোরিটনিক

আমি জড়িত প্রায় সমস্ত প্রকল্প (80% +) পদ্ধতিগতভাবে পরীক্ষা করা হয়েছিল, কিন্তু তারপরে আমি প্রায় ব্যতিক্রমী কর্পোরেট মিশন সমালোচনামূলক প্রয়োগ করেছি।
মার্টিন ব্রাউন

আমি ফার্মাসিউটিক্যাল কর্পোরেশনের হয়ে কাজ করি। আমি বলব যে 80% অ্যাপ্লিকেশনগুলি পেশাদার পরীক্ষক এবং বিকাশকারীদের দ্বারা পরীক্ষা করা হয়। এই 20% হ'ল কম ঝুঁকিযুক্ত অ্যাপ্লিকেশনগুলির মতো আইপ্যাডে প্রচারমূলক উপস্থাপনা। তবে এটি কেউ অ্যাড-হক দ্বারাও পরীক্ষা করেছে।
yoosiba

5

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


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

এই অফশোর দল কে? আপনি কি তাদের একটি প্রতিদান দিতে হবে?
মার্টিন ব্রাউন

সাধারণত বড় বড় সংস্থাগুলির অন্যান্য দেশে (বেশিরভাগ এশিয়াতে) গবেষণা ও উন্নয়ন কেন্দ্র থাকে। যেখানে অফশোর উন্নয়ন হয়। অফশোর বিকাশের উদ্দেশ্য হ'ল উন্নয়ন ব্যয় হ্রাস করা (এর কিছু অংশ)।
নিপুনা

2

আমি গত 15 বছরে যে তিনটি সংস্থার জন্য কাজ করেছি তাদের সকলের ইউনিট পরীক্ষা ছিল যা স্বয়ংক্রিয়ভাবে চালিত হয়েছিল।

এই দুটি প্রতিষ্ঠানের মধ্যে আমি তাদের চালু করার জন্য চাপ দিয়েছি।


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

@ রবার্ট: আমি সাধারণ অনুমান দেওয়ার মতো পর্যাপ্ত চাকরির আশ্বাস পাচ্ছি না। আমি যা জানি তা থেকে জিনিসগুলি আরও ভাল হয়ে উঠছে। তবে তারপরে, আমি যে তিনটি মামলায় আপনাকে বলেছি তার মধ্যে
দু'টিতে

তবে আপনি অন্যান্য সংস্থার অন্যান্য বিকাশকারীদের সাথে কথা বলছেন, তাই না?
রবার্ট কোরিটনিক

2

গত 9 বছরে, আমি কেবলমাত্র গ্রহণযোগ্যতা / রিগ্রেশন পরীক্ষাগুলি পূরণ করেছি। সেখানে কয়েকটি ইউনিট পরীক্ষা ছিল।


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

2

হ্যাঁ।

পরীক্ষার পরিমাণ অ্যাপ্লিকেশনটির প্রয়োজনীয় নির্ভরযোগ্যতার সাথে সাথে প্রোগ্রামার সংস্কৃতির পরিপক্কতার অনুপাতে।

ওয়েব সাইট বেশ প্রায়ই হাঁটছে বাগ গর্ত (ছিন্ন লিঙ্কগুলি হয় একটি ত্রুটি)।

ভিডিও গেমগুলি প্রায়ই বগি হয়।

উইন্ডোজ (শেষ পর্যন্ত) মোটামুটি নির্ভরযোগ্য।

রাউটারগুলি খুব নির্ভরযোগ্য

হাসপাতালের মনিটররা "ভাঙবেন না"

নোট করুন যে ব্যর্থতার রাজস্ব খরচও নির্ভরযোগ্যতার সাথে সম্পর্কিত lated


2
আমি আপনার সাথে দৃ strongly়ভাবে একমত নই - আপনি কখনও রাউটার ব্যর্থ হতে দেখেন নি? এক্সবক্স, প্লেস্টেশন এবং Wii গেমস লক-আপ করে? উইন্ডোজে কখনও কোনও নীল-পর্দা আছে বা 'অ্যাপ্লিকেশন সাড়া দিচ্ছে না'?
জেবিআরউইলকিনসন

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

1

10 বছরে আমি কখনও আনুষ্ঠানিক কোড টেস্টিং সহ কোনও প্রকল্পে কাজ করি নি।

আমার বর্তমান চাকরিতে আমাদের কেবল কার্যকরী পরীক্ষা আছে।

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

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


আপনার সদর্থক উত্তরের জন্য আপনাকে ধন্যবাদ। আপনার অনুমানগুলি কী (আমার সম্পাদিত প্রশ্নটি পরীক্ষা করুন)?
রবার্ট কোরিটনিক

ইতালির জন্য আমার অনুমান আনুষ্ঠানিক কোড পরীক্ষার 10% এর নিচে। সম্ভবত প্রায় মিশন-সমালোচনামূলক কোড।
উইজার্ড 79

আমি আয়ারল্যান্ড, ইংল্যান্ড, স্কটল্যান্ড এবং স্লোভেনিয়ায় কাজ করেছি এবং মনে হচ্ছে ইতালি এর চেয়ে আলাদা নয়।
রবার্ট কোরিটনিক

1

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

আমরা তৈরি প্রতিটি অ্যাপ্লিকেশনটিতে আমরা পদ্ধতিগত পরীক্ষার প্রয়োগ করি। সম্ভবত, পরীক্ষার মানের মান পর্যন্ত নয়, তবে আমরা তাদের নিয়োগ করি।


এই পরীক্ষাগুলি স্বয়ংক্রিয় বা ম্যানুয়াল হবে? আমি আমার প্রশ্নটি কিছুটা সম্পাদনা করেছি। আপনি কি পেশাদার বাজারে সফটওয়্যার পরীক্ষার আপনার অনুমান সরবরাহ করতে পারেন?
রবার্ট কোরিটনিক

আমাদের পরীক্ষার বেশিরভাগটি ম্যানুয়ালি করা হয়।
শামীম হাফিজ

1

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

এটি বলেছিল, আমি মনে করি না যে ঝুঁকি ব্যবস্থাপনার পরিকল্পনাই আনুষ্ঠানিকভাবে পরীক্ষার অভাবের কারণ। আমি মনে করি এটি নন-টেকনিক্যাল ম্যানেজাররা এটির যে মূল্য দেয় তা না বোঝার এবং এটির ব্যয় দেখতে কেবল তার বেশি ফলাফল।


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

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

2
আমি আরও আশ্চর্য হয়েছি যে যদি সেই পরিসংখ্যানগুলি বিশাল প্রকল্পগুলিতে (যেমন অপারেটিং সিস্টেমগুলি) বেশি কার্যকর না হয় যা সেগুলি তৈরি করা হয়েছিল এবং আমাদের বেশিরভাগই জীবিকার জন্য তৈরি করা CRUD টাইপ অ্যাপগুলিতে অনুবাদ করে না।
জনএফএক্স

আমি আপনার উভয়ের সাথে একমত এবং উভয় কেস দেখেছি। তবে আমি অবশ্যই রবার্ট বর্ণনা করছে এমন ক্ষতিকারক ব্যয়ের অংশটি আমার অংশ হিসাবে মনে হয়েছে, বিশেষত যখন কোনও বাগ সফ্টওয়্যারটিতে এত দিন ছিল যে এটি ঠিক করা থাকলে অন্যান্য বৈশিষ্ট্যগুলি প্রকৃতপক্ষে ভাঙ্গতে শুরু করবে। লোকেরা যথেষ্ট দীর্ঘ সমস্যা নিয়ে যথেষ্ট পরিমান কৌতুকপূর্ণ কোডিং সহ এবং দীর্ঘসময় ধরে থাকা বাগগুলি, 1 + 1 নয় 2 It's

1

আমার নমুনা থেকে শতাংশ কমানোর জন্য খুব ছোট, কিন্তু যাইহোক এখানে।

একটি হ'ল একটি কল্পিত চিপ + ফার্মওয়্যার সংস্থা, যা ধর্মান্ধ পরীক্ষা করেছিল। 24/7 দশটি ইনস্টলেশনগুলিতে স্বয়ংক্রিয় পরীক্ষা, সমান্তরালভাবে প্রতিটি পরীক্ষার দশক ইউনিট। সফ্টওয়্যার দলগুলি পরীক্ষার সফ্টওয়্যার বিকাশের জন্য নিবেদিত। হার্ডওয়্যার দলগুলি পরীক্ষাগুলি তৈরির জন্য উত্সর্গীকৃত। দশ প্রতিযোগীদের বিরুদ্ধে সামঞ্জস্যতা পরীক্ষা করা। হেক, এমনকি তারা চিপস ফাউন্ড্রি ছেড়ে চলে যাওয়ার সময় যেসব ফলকগুলি চালায় সেগুলির কয়েকটি বিকাশ এবং ডিবাগ করার জন্য একটি মিলিয়ন মিলিয়ন ডলার চিপ পরীক্ষক ইনস্টলেশনও কিনেছিল।

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

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


1

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

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

সুতরাং এটি কেবল বড় সংস্থাগুলিই নয় যে প্রচুর ফর্মাল টেস্টিং করে।

দ্রষ্টব্য - আমার 25+ বছরের চুক্তি প্রোগ্রামিং / পরামর্শের বছরে, আমি এমন অনেক সংস্থার পক্ষেও কাজ করেছি যা কার্যত কোনও আনুষ্ঠানিক পরীক্ষা করেনি। তাদের বেশিরভাগই আর আশেপাশে নেই।


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

0

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


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

@ রবার্ট: আমি আপনার প্রশ্নটি "সফটওয়্যার পরীক্ষার প্রাক্কলন" বুঝতে পারি না। আপনি কতটি সংস্থা পরীক্ষা সম্পর্কে আমার মতামত জিজ্ঞাসা করছেন? আমার প্রাক্কলনটি আমার নিজের চোখ দিয়ে যা দেখেছি তার উপর ভিত্তি করে 90% বা তার বেশি হতে পারে। টেস্টিং পেশাদার বিকাশের একটি সাধারণ অঙ্গ।
ব্রায়ান ওকলে

0

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

কিছু সংস্থার খুব বেশি অটোমেটেড টেস্টিং ছিল না, কারও কারও কাছে খুব বেশি ম্যানুয়াল টেস্টিং ছিল না, তবে তাদের কমপক্ষে একটি বা অন্যটি ছিল।


0

এটি গ্রাহকের প্রয়োজনের উপর নির্ভর করে। একটি চুক্তির পরিস্থিতিতে সম্ভবত গ্রহণযোগ্যতা পরীক্ষা রয়েছে। ইন-হাউস সাধারণত অল্প পরীক্ষার সহিত একটি স্লাপজব। গ্রাহক স্টাফ সাধারণত ঘন ঘন কার্যকারিতা মধ্যে খুব কভার কিন্তু প্রান্ত কাছাকাছি মোটামুটি।


0

সংক্ষিপ্ত উত্তর: হ্যাঁ

দীর্ঘ উত্তর:

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

  2. আমি উপরে উল্লিখিত কারণগুলির বিভিন্ন সংমিশ্রণ সহ বিভিন্ন প্রকল্পের মধ্য দিয়ে যাচ্ছি:

    • কোন আনুষ্ঠানিক ইউনিট পরীক্ষা, শুধুমাত্র সংহতকরণ পরীক্ষা এবং বেশিরভাগ অ্যাডহক পরীক্ষা

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

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

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