সিস্টেম পরীক্ষার জন্য সফ্টওয়্যার প্রকাশ করার সময় নতুন বৈশিষ্ট্যগুলি যুক্ত না করে বাগগুলি ঠিক করা কি সঠিক?


10

এই প্রশ্নটি অভিজ্ঞ পরীক্ষক বা পরীক্ষার লিডগুলির কাছে। এটি একটি সফ্টওয়্যার প্রকল্পের একটি দৃশ্য:

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

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

যদি এটি সাধারণ পরীক্ষার নীতি হয় তবে আপনি কি একমত হতে পারেন? পরীক্ষা দলের উদ্বেগ বৈধ কি। আপনার প্রকল্পে আপনি বাস্তবে এটির মুখোমুখি হয়েছেন?


ব্রাঞ্চিংয়ের পদ্ধতির বিষয়ে এটি কোনও খারাপ নিবন্ধ নয়: nvie.com/posts/a-successful-git-branching-model , আপনি সম্ভবত হটফিক্স শাখাগুলির বিভাগে বিশেষভাবে আগ্রহী হতে পারেন যা কেবলমাত্র এই কারণে বিদ্যমান।
জ্ঞান ওরফে গ্যারি বুইন

হুবহু ... এই নতুন বৈশিষ্ট্যগুলি একটি পৃথক শাখায় থাকা উচিত যখন গ্রহণযোগ্যতার জন্য বাগ ফিক্সগুলি টেস্ট দল যা পরীক্ষা করে দেখায়
রিগ

উত্তর:


5

পরিবর্তে আমি এটিই বলব যে নতুন বৈশিষ্ট্যগুলির প্রতিটি প্রকাশ একটি পৃথক শাখায় হওয়া উচিত। এটি বিকাশ এবং রিলিজগুলি ডিকপল করতে দেয়।


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

4
@ প্রতীক: দেব দলের দৃষ্টিকোণ থেকে এটি একটি "মুক্তি"। কোডটি এমন অবস্থায় রয়েছে যে তারা "সম্পন্ন" হিসাবে বিবেচনা করে এবং বাহ্যিক চোখ দ্বারা দেখার জন্য প্রস্তুত।

4

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

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

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

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


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

2

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

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

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

আমরা যা করি তা হ'ল প্রতিটি রিগ্রেশন টেস্ট কেসের কোড কভারেজ করা। কেবলমাত্র সেই রিগ্রেশন টেস্ট কেসগুলি চালিত হয় যা বৈশিষ্ট্যের কোড পরিবর্তন দ্বারা প্রভাবিত হবে। অবশ্যই, কোনও গ্রাহকের মুক্তির জন্য, সম্পূর্ণ রিগ্রেশন স্যুট চালিত হয়।


0

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

এটি বলার পরেও, পরীক্ষকরা 'সেটেরিস পারিবাস' (সমস্ত 'অন্যান্য' জিনিস সমান হওয়ার) জন্য টেস্টগুলি পরীক্ষা করতে চান এটি বোধগম্য (অগত্যা ন্যায়সঙ্গত নয়) is

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


0

উভয় দলকে মার্জ করে আপনি এই (সাধারণ) সমস্যাটি সমাধান করতে পারেন।

উন্নয়ন টিমের মধ্যে পরীক্ষকগণ, বৈশিষ্ট্যগুলি যেমন উত্পাদিত হয় ততগুলি পরীক্ষাগুলি বেশিরভাগ দলকে আউটপুটটির গুণমান বাড়িয়ে তুলতে সহায়তা করে।

আমি আপনাকে পরামর্শ দিচ্ছি আপনার কাছ থেকে এই চমৎকার ব্লগ পোস্ট পড়তে হেনরিক Kniberg ব্যাখ্যা Kaban । আপনি স্ক্রাম প্রক্রিয়াতে অনেক ধারণা পাবেন ( হেনরিক ক্লিবার্গের একটি বিনামূল্যে বই )।

তিনি নিজের ব্লগে একটি চমৎকার কানবান ভিএস স্ক্রাম নিবন্ধ লিখেছিলেন ।

উপভোগ করুন।


0

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


0

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

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

আপনার উত্স নিয়ন্ত্রণ সিস্টেমকে বিতরণকৃত পণ্যতে পরিবর্তন বিবেচনা করুন। এটি এ জাতীয় রিলিজ সরবরাহ করা আরও সহজ করে তুলবে।


0

"এটি যদি সাধারণ পরীক্ষার নীতি হয় তবে আপনি কি একমত হতে পারেন?

Yes

পরীক্ষা দলের উদ্বেগ বৈধ কি

Yes

আপনি কি আপনার প্রকল্পে বাস্তবে এটির মুখোমুখি হয়েছেন? "

Yes

:

and Yes Merging is the downside of it 

কার দায়িত্ব এটি আপনি জিজ্ঞাসা করেননি তবে এটি কনফিগারেশন পরিচালকের দায়িত্ব। এই স্ট্রিম কৌশলটি তার সিএমপিতে থাকা উচিত। অন্যথায় তাকে গুলি করে দিন। আমি মনে করি পিয়েরে 303 থেকে প্রাপ্ত প্রতিক্রিয়াটি খুব ভাল তবে অবশ্যই প্রযুক্তিগতভাবে (যেমন সিলাবল মুক্তির কথা ভাবা ...) এবং সাংগঠনিকভাবে অবশ্যই সম্ভব।


0

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

এখানে সঠিক উত্তর নেই তবে কয়েকটি বিষয় যা আপনার বিবেচনা করা উচিত:

  • এই বাগ রিলিজগুলি (নতুন কার্যকারিতা ছাড়াই) ব্যবহারকারীদের কাছে যেতে পারে? যদি তাই হয় তবে হ্যাঁ, এটি অবশ্যই ব্রাঞ্চ এবং পরীক্ষা করা উচিত এবং প্রত্যেককে এটি ওভারহেড হিসাবে গ্রহণ করতে হবে।

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

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

  • এখানে সংস্করণ নিয়ন্ত্রণ ব্যবহারের আরও ভাল উপায় আছে কি? মার্কুরিয়ালের মতো কিছু (দেখুন http://hginit.com/ - এটি পড়ুন, এটি ভাল) বা অন্য বিতরণকৃত সংস্করণ নিয়ন্ত্রণ সিস্টেম শাখাগুলি এবং আলাদা উপায়ে মার্জ হয়ে যায় এবং আপনাকে সমস্যার সমাধান করার অনুমতি দিতে পারে। সত্যিই, এটি একবার দেখুন কারণ আমি মনে করি এটি আপনার সমস্যার উত্তর হতে পারে।

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


0

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

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

আপনি যদি প্রথমে আপনার বাগগুলি ঠিক করেন তবে আপনার যুক্ত করা নতুন বৈশিষ্ট্যগুলির একটি শক্তিশালী ভিত্তি থাকবে।

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

সর্বদা নতুন বৈশিষ্ট্য যুক্ত করার আগে বাগগুলি ঠিক করার চেষ্টা করুন!


0

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

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