পরীক্ষকগণ কি রিলিজ অনুমোদন করবেন, বা কেবল পরীক্ষাগুলিতে রিপোর্ট করবেন?


20

পরীক্ষার্থীদের সাইনঅফ কর্তৃপক্ষ দেওয়ার অর্থ কী? একটি পরীক্ষা দল উচিত

  1. কেবল বৈশিষ্ট্য, সমস্যা ইত্যাদির পরীক্ষা করুন এবং কেবল পাস / ব্যর্থতার ভিত্তিতে রিপোর্ট করুন, ফলাফলগুলিতে কাজ করার জন্য এটি অন্যের হাতে ছেড়ে যায়, বা
  2. এই ফলাফলগুলির উপর ভিত্তি করে নিজেকে প্রকাশ করার ক্ষমতা কি আছে?

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


2
দয়া করে আপনার প্রশ্নটি পুনরায় লিখুন যাতে এটি কোনও পোল না হয়। আপনি যে সমস্যাটি সমাধান করার চেষ্টা করছেন তা কী?
এম ডুডলি

5
"উচিত" মূলত কোম্পানির সাংগঠনিক কাঠামোর উপর নির্ভর করে। যদি তারা উত্পাদনে পাওয়া বাগগুলিতে পরিমাপ করা হয় তবে বগী রিলিজ রাখতে সক্ষম হওয়া একটি প্রয়োজনীয় সরঞ্জাম।

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

5
আপনার যদি সমস্যা হয় যে পরীক্ষকরা সমস্যা সমাধানের পরিকল্পনা করা হয়নি তার ভিত্তিতে রিলিজ অনুমোদন করতে অস্বীকার করেছেন, আপনার যোগাযোগের সমস্যা রয়েছে (তারা জানেন না যে বিষয়গুলি সমাধানের পরিকল্পনা করা হয়নি) বা লোকজন সমস্যা (তারা নিজেরাই গুরুত্বপূর্ণ করে তুলছে; প্রকাশ করা শেষ পর্যন্ত ব্যবসায়ের সিদ্ধান্ত)।
জান হুডেক

উত্তর:


27

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

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

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

নতুন প্রয়োজনীয়তার পূর্ববর্তী ত্রুটি বা অনিচ্ছাকৃত ফলাফল সম্পর্কে রিপোর্ট করা ঠিক আছে, তবে এটি যদি সুযোগের বাইরে থাকে এবং অ-বিপর্যয়কর হয় তবে এটিকে একটি ব্লকিং সমস্যা হিসাবে চিহ্নিত করা সাধারণত গ্রহণযোগ্য নয়। পণ্যের মালিকদের কাছে অন্য সমস্ত কিছুর মতো অগ্রাধিকার দেওয়া ব্যাকলগে চলে যায়।


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

3
@ বার্টওয়ানআইগেনস্পেনা: পণ্যের মালিক / প্রকল্প পরিচালককে এ সম্পর্কে শেষ কথা থাকতে হবে। কারণ এমনকি গ্রহণযোগ্যতা পরীক্ষা প্রায়ই হবে স্ফীতির যদি হবে (আপনি এখন যদিও আমরা এটা দিয়ে কাজ করতে ওয়াই পেতে পারেন, অথবা আপনি যতক্ষণ না আমরা এটা ঠিক 2 আরও বেশি মাস অপেক্ষা করতে চাও বৈশিষ্ট্য এক্স চাও?) ও পণ্যের মালিক হতে যে আলোচনা করছে।
জানু হুডেক

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

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

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

6

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

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

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


6

পরীক্ষকদের মুক্তির জন্য সাইন-অফ কর্তৃপক্ষ (অর্থাত্ একটি ভেটো অধিকার) প্রদান করা বিকাশকারীদের সেই অধিকার দেওয়ার মতোই বোধগম্য।

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

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


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

1
ম্যাপেল_শ্যাফটের পয়েন্ট ছাড়াও আমি প্রায়শই এই বামদিকে চূড়ান্ত কলটি দেখতে পাই যার মধ্যে গ্রাহকের ভূমিকায় যতোটা ভয়ঙ্কর কিছু চিহ্নিত না হয়ে থাকে to এটি শেষ পর্যন্ত তাদের বিতরণযোগ্য এবং আপনার সঠিক তথ্য সরবরাহ করে তাদের ধরে নেওয়ার ঝুঁকি নিয়ে তাদের সঠিক দৃষ্টিভঙ্গি সম্ভবত রয়েছে।
বিল

5

'মুক্তি' বা 'মুক্তি না দেওয়ার' সিদ্ধান্তটি দিনের শেষে একটি ব্যবসায়িক সিদ্ধান্ত হয়, যেখানে কঠোর ঝুঁকি / পুরষ্কার বিশ্লেষণ করা প্রয়োজন।

যে কোনও সংস্থার পক্ষে পরীক্ষা দলকে এই দায়িত্ব নিতে বলা বা টেস্ট দলকে এই দায়িত্বটিতে সম্মতি জানাতে বলা পাগল।

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

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


3

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

আমি অসম্পূর্ণ মুক্তি প্রেরণ না করার জন্য পরীক্ষা দলকে বুঝতে এবং প্রশংসা করার সময়, এটি একটি "গ্রহণযোগ্য ঝুঁকি" কী তা নির্ধারণ করার জন্য শক্তিশালী পণ্যের মালিকানা প্রয়োজন।

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

সফ্টওয়্যারটি কখনই নিখুঁত হতে পারে না, যদি আপনি পরীক্ষার ছাঁটাইতে ভুগছেন তবে কোনও বড় প্রডাকশন সমস্যা না পাওয়া পর্যন্ত (যা সঠিকভাবে পরীক্ষা করা হবে না) এবং তাড়াহুড়ো না করা পর্যন্ত আপনি কখনই মুক্তি পাবেন না।


1
এটি একটি আসল সমস্যা তবে আমি নিশ্চিত নই যে এটি অপরিহার্যভাবে ওপি'র সমস্যা কিনা। আমার ব্যাখ্যাটি হ'ল পরীক্ষকরা কোনওভাবে নতুন প্রয়োজনীয়তার ব্যাখ্যা করছেন যা মূলত সংজ্ঞায়িত হয়নি।
ম্যাপেল_শ্যাফ্ট

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

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

আমার ক্ষেত্রে এটি আরও @ ম্যাপেল_শ্যাফটের ব্যাখ্যা; পরিষ্কারভাবে অসমর্থিত কেসগুলি হ্যান্ডেল করতে ব্যর্থতা হিসাবে রিপোর্ট করা হিসাবে সফ্টওয়্যারটি ভাঙ্গার উপায়গুলি খুঁজে পেতে এতটা বিচক্ষণ হওয়া নয়।
আর্নেস্ট ফ্রাইডম্যান-হিল

1
@ আর্নেস্টফ্রেডম্যান-হিল মনে হচ্ছে আপনি নেতিবাচক প্রয়োজনীয়তাগুলি বর্ণনা করছেন এবং এটি আপনার কার্যকরী প্রয়োজনীয়তার নথি থেকে অনুপস্থিত। একটি নেতিবাচক প্রয়োজনীয়তা একটি সিস্টেম কী করবে না সে সম্পর্কে একটি স্পষ্ট বিবৃতি এবং এটি নিয়মিত প্রয়োজনীয়তার মতো গ্রহণযোগ্য হতে পারে। এগুলি যদি ঘোষণা করা হয় তবে নেতিবাচক প্রয়োজনীয়তার বিরুদ্ধে তাদের পরীক্ষার মামলাগুলি বৈধ নয়।
ম্যাপেল_শ্যাফ্ট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.