টিকিটের মূল্যায়ন করার সময় পরীক্ষকের সময়টি কি অন্তর্ভুক্ত করা উচিত?


17

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

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

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


পরীক্ষকটি যে বিষয়গুলি খুঁজে পেয়েছে সেগুলি থেকে পুনরায় বিগফিক্সের জন্য সময় সম্পর্কে কী বলা যায়? এটি অনুমান করা সত্যিই শক্ত জিনিস :)।
ফ্র্যাঙ্ক পাফার

3
আপনার সংজ্ঞার অংশটি পরীক্ষা করা কি সম্পন্ন হয়, বা আমরা কোনও সম্পূর্ণ অন্যান্য দল / বিভাগের বিষয়ে কথা বলছি?
নভেম্বরে

2
পরীক্ষার প্রচেষ্টার পক্ষে "টিকিটের" জন্য ব্যয় করা বেশিরভাগ সময় ব্যয় করা পুরোপুরি সম্ভব। সুতরাং, আইএমও; হ্যাঁ.
গ্রিম দ্য ওপেনার

@ এনভয়েগ্ট টেস্টিং আমাদের করা সংজ্ঞার অংশ।
ট্রান্সমিট

উত্তর:


33

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

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

আপনার সহকর্মী হিসাবে, আমি এমন একটি সফল সংস্থা দেখিনি যা পরীক্ষার সময়টিকে বিবেচনায় নেয় না।

আপনার স্পষ্টতা অনুসারে সংযোজন: যদিও ডিভগুলি স্বয়ংক্রিয় পরীক্ষাগুলি, বিশেষত ইউনিট পরীক্ষাগুলি (ইন্টিগ্রেশন পরীক্ষাগুলি আরও ভাল করে) লিখলেও, তারা সঠিকভাবে পরীক্ষা করতে অপর্যাপ্ত।

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


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

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

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

1
অন্য টিকিটের জন্য +1, কোথায় জিনিস আটকে যায় তা জানার পক্ষে এটি আরও সহজ করে তোলে।
ম্যাথিউ এম।

1
@ স্টিভ জেসোপ প্রচুর জিনিস "হওয়া উচিত" :)
মার্শাল টাইগারাস

19

জোর দিয়ে, হ্যাঁ

পরীক্ষা করা উন্নয়ন প্রক্রিয়ার অংশ is আপনার দলটি যদি প্রকৃতপক্ষে সফ্টওয়্যারটি পরীক্ষা করতে সময় ব্যয় করে তবে পরীক্ষার জন্য ব্যয় করা সময়টি অনুমানের অংশ হওয়া দরকার।


5

এটি যদি তাত্পর্যপূর্ণ হয় তবে আমি মোট গল্পের পয়েন্টগুলির অংশ হিসাবে পরীক্ষার প্রচেষ্টাটি অন্তর্ভুক্ত করব। উদাহরণস্বরূপ, দেব প্রচেষ্টা সম্ভবত 1 দিন এবং 1 দিন পরীক্ষা করছে যাতে এটি 2 পয়েন্টের গল্প হবে।

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


2

টিকিট শেষ করার জন্য প্রয়োজনীয় সমস্ত কাজের হিসাব হিসেব করা উচিত। টেস্টিং যদি টিকিটের প্রয়োজনীয় অংশ হয় তবে তা অনুমানের মধ্যে অন্তর্ভুক্ত করা উচিত। টেস্টিং যদি আলাদা টিকিট হয় তবে তা করা উচিত নয়।

আপনি গল্পের পয়েন্টগুলি ব্যবহার শুরু করার পরে অবশ্যই এটি সমস্ত ঝাপসা হয়ে উঠতে পারে, যেহেতু কোনও দেব-মাত্র 5 এবং একটি ডিভ-কেবল 8 এর মধ্যে পার্থক্যটি কোনও দেব-ও-কিউ 5 বনাম একটি দেব-ও-কিউ 8 এর তুলনামূলকভাবে সমানুপাতিক হবে।

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


2

আপনি এর জবাব দিতে পারবেন না এই বিষয়টি আপনাকে দৃ strongly়ভাবে বোঝায় যে আপনি কেন অনুমান লিখছেন (বা কমপক্ষে আপনি কেন অনুমান লিখছেন তা আপনার সহকর্মীর সাথে একমত নন) don't অনুমানগুলির পরীক্ষার অন্তর্ভুক্ত হওয়া উচিত কি না এর চেয়ে এটি একটি বৃহত সমস্যা।

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

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

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

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


1

ব্যবহারকারী-গল্প / বৈশিষ্ট্য / টিকিটটি সত্যই সম্পন্ন করতে যে কাজগুলি করা দরকার তা সর্বদা অনুমান করুন। আমরা এটিকে ডোনডোন বলি

আমরা প্রস্তুত যখন আমরা প্রস্তুত প্রস্তুত

এর মধ্যে যেকোন ম্যানুয়াল এবং অনুসন্ধানের পরীক্ষা রয়েছে তবে ব্যবহারকারী-গ্রহণযোগ্যতা পরীক্ষাও রয়েছে।

একটি চৌকস দলের যে কোনও মুহুর্তে সমাপ্ত কাজের নতুন অংশ প্রকাশ করতে সক্ষম হওয়া উচিত। হিসাবে:

ওয়ার্কিং সফটওয়্যার অগ্রগতির প্রাথমিক পরিমাপ।

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

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


1

এখানে খুব গুরুত্বপূর্ণ কিছু: সমস্ত অনুমান অনুমিতি এবং বর্জন সহ হতে হবে

এর মধ্যে যা অন্তর্ভুক্ত রয়েছে তা নির্দিষ্ট করে অন্তর্ভুক্ত রয়েছে: কেবলমাত্র উন্নয়ন, ডিজাইন এবং বিকাশ, দেব এবং ইউনিট পরীক্ষা, গ্রহণযোগ্যতা পরীক্ষার কাভারেজ, অবকাঠামো তৈরি ইত্যাদি etc.

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

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


1

সময়ের অনুমান অন্তর্ভুক্ত করা উচিত কিন্তু আপনি পরীক্ষকগণ সময় অনুমান করা উচিত নয়, পরিবর্তে পরীক্ষকগণ তাদের সময় অনুমান করা উচিত

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


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

0

encapsulation

আমি সফটওয়্যার ডেভলপমেন্ট পয়েন্ট এবং ভাষার দিক থেকে এটির কাছে যাচ্ছি।

  • আপনি একটি বড় মেশিনে একটি ছোট কগ।
  • আপনার দলের বাইরে থেকে, আপনার টিকিটিং সিস্টেমটি আপনার দলে ইন্টারফেস / এপিআই হিসাবে কাজ করে
  • টিকিটিং সিস্টেম ব্যবহার করা ব্যবসায়িক ব্যবহারকারীরা বিকাশকারী নয়

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

সুতরাং ব্যবসায়ের ব্যবহারকারীদের দৃষ্টিকোণ থেকে প্রক্রিয়াটি দেখার জন্য, তারা সত্যিই কেবলমাত্র 2 টি জিনিস সম্পর্কে যত্নশীল।

  1. এটা কত খরচ হবে?
  2. আমরা কি এখনও শেষ করেছি?

আপনার দলের অভ্যন্তরীণ প্রক্রিয়া সম্পর্কে ব্যবসায় ব্যবহারকারীকে জানার সুযোগ দেওয়া খারাপ পরিচালনা; publicঅভ্যন্তরীণ অবস্থায় অ্যাক্সেস দেওয়ার অনুরূপ ।

আপনার দলের অভ্যন্তরীণ পরিস্থিতি রক্ষা করতে ব্যর্থতা, অন্যান্য সংস্থাগুলিকে আপনার সংস্থানগুলি পরিচালনা করার জন্য এবং আপনার অভ্যন্তরীণ অবস্থার সাথে জগাখিচির আমন্ত্রণ জানাচ্ছে।

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