স্ক্র্যাম স্প্রিন্টে কীভাবে পরীক্ষার উপযুক্ত হবে এবং স্ক্রমে কীভাবে ব্যবহারকারী গল্প লিখতে হবে

Question

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

1. একটি স্প্রিন্টে 5 গল্প বলুন যখন আপনি পরীক্ষার জন্য প্রকাশ করবেন? ডেভ দ্বারা বা সমস্ত গল্প শেষ হওয়ার পরে কোনও গল্পটি শেষ হওয়ার সাথে সাথে তবে স্প্রিন্ট শেষ হওয়ার আগে পরীক্ষা দেওয়ার জন্য প্রয়োজনীয় সময় দেয়।
2. বিএ যদি ব্যবহারকারীর গল্প লেখেন তবে তার বিশদটি কী হওয়া উচিত। Ditionতিহ্যগতভাবে সমস্ত UI লেআউট, আচরণ, পাঠ্য ইত্যাদি চূড়ান্ত করতে একটি নির্দিষ্ট লিখতে দীর্ঘ সময় লাগে। আমি অনুমান করি যে আমার প্রশ্নটি এমন গল্পগুলি কীভাবে প্রয়োগ করা যায় যা পরীক্ষামূলক এবং পরীক্ষামূলক write
3. আমাদের পরীক্ষার দলটি প্রযুক্তিগত নয়। স্ক্রামের জন্য স্বয়ংক্রিয় ইউআই টেস্টিং করা কতটা গুরুত্বপূর্ণ। ইউআই ডাব্লুপিএফ উপর ভিত্তি করে।

চতুর পদ্ধতি (টিডিডি, কোড রিভিউ, রিফ্যাক্টরিং ইত্যাদি) ব্যবহার করে আমার কাছে শক্ত বিকাশের অভিজ্ঞতা আছে তবে স্ক্রমে নতুন।

সম্পাদনা: পুনরাবৃত্তির দ্বারা আমার অর্থ 100 টি প্রয়োজনীয়তা সম্পন্ন না হওয়া পর্যন্ত অপেক্ষা করার চেয়ে 30, 35, 35 প্রয়োজনীয়তা সম্পন্ন করার পরে যদি 100 টি প্রয়োজনীয়তা থাকে তবে আমরা পরীক্ষার জন্য ছেড়ে দিতে পারি।

Comments

We have a waterfall/iterative SDLC.এ সম্পর্কে বিস্তারিত বলুন। জলপ্রপাতটি সংজ্ঞা অনুসারে একটি অনুক্রমিক প্রক্রিয়া, পুনরাবৃত্তি নয়। যদিও সেখানে পরিবর্তিত জলপ্রপাত রয়েছে (যেমন সশিমি মডেল বা জল-সহ-উপ-প্রকল্পগুলি), সেগুলি সবই ক্রমিক। আপনি কি আপনার বর্তমান অনুক্রমিক প্রক্রিয়া থেকে পুনরাবৃত্ত প্রক্রিয়াগুলির দিকে যাওয়ার চেষ্টা করছেন?

— টমাসের মালিক

@ প্রতীক কীভাবে আপনার পক্ষে জিনিসগুলি কার্যকর হয়েছে? আপনি কিউএ টিমের সাথে আরও ভাল সহযোগিতা করার ব্যবস্থা করেছিলেন?

— ফ্লোপ

Answer 1

টেস্টিং যদি উন্নয়ন থেকে পৃথক হয় তবে আপনার দুটি - পৃথক - স্ক্রাম দল রয়েছে। এক হাতে অন্য হাতে কাজ করা খারাপ ধারণা।

আপনার বিকাশকারীদের অবশ্যই তাদের নিজস্ব পরীক্ষা লিখতে হবে , এই অন্যান্য দল থেকে পৃথক। আপনাকে অবশ্যই এই অন্যান্য "পরীক্ষা" দলটিকে আপনার গ্রাহক হিসাবে আচরণ করবে।

একটি স্প্রিন্টে ... আপনি কখন পরীক্ষার জন্য প্রকাশ করবেন?

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

আমি অনুমান করি যে আমার প্রশ্নটি এমন গল্পগুলি কীভাবে প্রয়োগ করা যায় যা পরীক্ষামূলক এবং পরীক্ষামূলক write

দলে দলে পরিবর্তিত হয়। বিএ উন্নয়ন দলের অংশ। সঠিক পরিমাণের বিশদ পাওয়ার জন্য আপনাকে এটিকে একটি দল হিসাবে (বিএ প্লাস বিকাশকারী) হিসাবে কাজ করতে হবে। বিএ থেকে দলের বাকি সদস্যদের কাছে সঠিক তথ্য পাওয়ার জন্য এটি একটি দলের প্রচেষ্টা।

স্ক্রামের জন্য স্বয়ংক্রিয় ইউআই টেস্টিং করা কতটা গুরুত্বপূর্ণ।

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

---

শেষের সারি. একটি স্বতন্ত্র "পরীক্ষা" দল এবং একটি বিএ যারা প্রতি সামান্য বিশদ বিবরণ লেখেন এটি স্ক্রমের জন্য অনুকূল সংগঠন নয়। স্ক্রামের অর্থ হল আপনার প্রতিষ্ঠানের পাশাপাশি আপনার প্রক্রিয়াগুলি নিয়ে আপনাকে পুনর্বিবেচনা করতে হবে।

Comments

After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. এটি কীভাবে আইট্রেটিভ জলপ্রপাতের চেয়ে আলাদা? এক্ষেত্রে স্প্রিন্টটি হ'ল একটি খুব ছোট জলপ্রপাত Iteration। এই ধরণের পদক্ষেপটি অগিল এবং স্ক্রাম আইএমওর সর্বশ্রেষ্ঠ শক্তিগুলির মধ্যে একটিকে পরাভূত করে, যে সমস্ত বিএ, বিকাশকারী এবং কিউএ একই দলে রয়েছেন এবং তারা সম্মিলিতভাবে যে স্প্রিন্টটি প্রকাশ করছে তার মালিকানা রয়েছে। এটি প্রকল্পগুলিতে ঘটে যাওয়া বাধাগুলি ভেঙে দেয়।

— maple_shaft

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

— টমাসের মালিক

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

— থমাস Owens

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

— থমাস Owns

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

— টমাস ওয়েন্স

Answer 2

আমি যে উত্তরগুলি দিতে যাচ্ছি সেগুলির বেশিরভাগই আইট্রেটিভ জলপ্রপাতের বিপরীতে সফটওয়্যার বিকাশের একটি চৌকস পদ্ধতির সাথে সম্পর্কিত। স্ক্রাম কেবল একটি জনপ্রিয় চতুর বাস্তবায়ন হিসাবে ঘটে।

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

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

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

Comments

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

— আন্দ্রেস এফ।

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

— ম্যাপেল_শ্যাফ্ট

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

— maple_shaft

@ ম্যাপেল_শ্যাফ্ট: এটি বলা সহজ তবে কিউএ তাদের পরীক্ষার মাঝামাঝি একটি মুক্তি পছন্দ করে না। এছাড়াও আমরা সিআই বিল্ডের সাথে প্রায়শই চেকইন করি তবে কেবলমাত্র চাহিদা অনুসারে মুক্তি দেওয়া হয়। বর্তমান পরীক্ষা দলটি স্বয়ংক্রিয় ইউআই পরীক্ষা লেখার পক্ষে সক্ষম নয়। তারা খাঁটি ম্যানুয়াল টেস্টিং করে। এটি আমার পক্ষে পরিবর্তন করা কঠিন হবে।

— সফদভেদ

@ প্রতীক আমি বুঝতে পারি যে আমাকে বিশ্বাস করা কতটা কঠিন। আমি ব্যথা জানি। সম্ভবত আপনি স্প্রিন্ট প্রসারিত করতে পারেন তবে স্প্রিন্ট অনুযায়ী পরীক্ষার পরিবেশে তিন বা চারটি রিলিজ থাকতে পারে? এইভাবে পরীক্ষার দল কোনও পরীক্ষার মামলার মাঝামাঝি দিনের জন্য ছেড়ে যেতে পারে এবং নিশ্চিত হতে পারে যে রাতারাতি পরিবেশের কোনও পরিবর্তন হয়নি।

— maple_shaft

Answer 3

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

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

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

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

3. আমার অভিজ্ঞতায়, স্বয়ংক্রিয় ইউআই টেস্টিং অত্যন্ত সময়সাপেক্ষ এবং অত্যন্ত ভঙ্গুর। আছে উপায় করতে যে WPF কিন্তু আমি সাবধানে যে ভাবে যাওয়ার আগে সুবিধা যেমন পরীক্ষার সংরক্ষণ খরচ চিন্তা করবে।

Answer 4

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

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

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

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

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

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

আশা করি ওটা তোমাকে সাহায্য করবে।

Answer 5

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

একটি স্প্রিন্টে 5 গল্প বলুন যখন আপনি পরীক্ষার জন্য প্রকাশ করবেন? ডেভ দ্বারা বা সমস্ত গল্প শেষ হওয়ার পরে কোনও গল্পটি শেষ হওয়ার সাথে সাথে তবে স্প্রিন্ট শেষ হওয়ার আগে পরীক্ষা দেওয়ার জন্য প্রয়োজনীয় সময় দেয়।

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

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

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

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

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