কোডিং এবং একই স্প্রিন্টে পরীক্ষা করা


22

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

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

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

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

আমি নিশ্চিত আমি এই দ্বিধাজনিত প্রথম ব্যক্তি নই।

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


2
আপনি এই দ্বিধা নিয়ে প্রথম ব্যক্তি নন। আপনি একটি পাইপলাইন ব্যবহার করতে পারেন: বর্তমান স্প্রিন্টে পরীক্ষার দলটি আগের স্প্রিন্টের সময় কার্যকর করা বৈশিষ্ট্যগুলি পরীক্ষা করে।
জর্জিও

2
প্রধানমন্ত্রীর অত্যাচার একটি ভালো জিনিস তাদের পথ শব্দসমূহ করতে দলের হাফ-আর্সেড তত্পর
মশা


8
@ মার্ক রিচম্যান: জলপ্রপাত? জলপ্রপাতে আপনার কাছে 1-2 সপ্তাহের বিকাশ চক্র নেই। আমি মনে করি তিনি কী সম্পর্কে কথা বলছেন সে সম্পর্কে তার কোনও ধারণা নেই।
জর্জিও

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

উত্তর:


13

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

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

আপনি করতে পারেন এমন অনেকগুলি বিষয় রয়েছে:

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

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

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


8

অপরিহার্য সমস্যাটি হ'ল আপনার কাছে এমন প্রোগ্রামার রয়েছে যাঁরা কোডিং করেন তবে পরীক্ষা করেন না এবং পরীক্ষকরা যারা পরীক্ষা করেন তবে কোড নয়।

এই সমস্যাটি সমাধান করুন এবং আপনার এই সমস্যাটি হবে না, এবং একটি যুক্তিযুক্ত আরও দক্ষ দল।

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

যা ঘটেছিল তা হ'ল:

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

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

  • যখন পরীক্ষাগুলিদের প্রয়োজন কী আরও ভাল বুঝতে পেরে কিছু পরীক্ষা স্বয়ংক্রিয় হয় ted

  • কিছু লোক বিচলিত হল।

  • গল্পগুলি গড়ে দ্রুত পৌঁছে যায় কারণ কোড-কমিট-পুল-পরীক্ষার চক্রটি প্রায় তাত্ক্ষণিক হয়ে উঠেছে

অবশ্যই, এটি কেবল আমার অজানা অভিজ্ঞতা, তবে আপনি যদি নিজে পারেন তবে চেষ্টা করতেই পারেন।

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

এটি একটি যোগাযোগ সমস্যা, একটি চতুর সমস্যা নয়। একটি চতুর পদ্ধতি অবলম্বন সহজভাবে এটি স্পষ্ট করে তোলে। সিলোড দলগুলি হ'ল একটি অ্যান্টি-প্যাটার্ন ম্যানেজমেন্ট পরিচালনা , সুতরাং এই ক্ষেত্রে চতুর অ-অভিযোজনযোগ্যতা আলিঙ্গন!


2
এই সংস্থাটি "বিকাশকারী" এবং "পরীক্ষকগণ" এর জন্য স্পষ্ট সীমানা এবং ভূমিকা তৈরি করেছে এবং দু'জনের দেখা হবে;)
মার্ক রিচম্যান

সুতরাং, নিয়ম পরিবর্তন!
Sklivvz

3
@ মার্করিচম্যান আমার অতীতের একটি চাকরিতে "বিকাশকারী" এবং "পরীক্ষক" র ভূমিকাতেও স্পষ্ট সীমানা ছিল, কিন্তু সেই সংস্থা তাদের যোগাযোগের জন্য ব্লক দেখাবে না (কী লম্পট ধারণা বিটিডব্লু!); আমি "এসাইন্ট টেস্টার" এর সাথে জুটিতে স্প্রিন্ট করা স্মরণ করছি এবং এটি দুর্দান্ত হয়েছে। আপনার সংস্থা কি কেবল ভূমিকাগুলি আলাদা করে দেয় বা অতিরিক্তভাবে এই ভূমিকাগুলি সম্পাদনকারী প্রকৌশলীদের মধ্যে কোনও যোগাযোগ / সহযোগিতার বাধা সেট করে?
gnat

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

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

4

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

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

  • স্প্রিন্ট সময়:

    1. দলটি নতুন বৈশিষ্ট্যটির নকশা এবং আসল কোড বেসের উপর প্রভাব ফেলেছে।

    2. বিকাশকারীরা ইউনিট পরীক্ষাগুলি লিখেন যা নিশ্চিত করে যে অর্ডারটি প্রত্যাশা অনুযায়ী কাজ করছে এবং একই সাথে প্রকৃত কোডটি লিখে দেয়।

    3. নতুন বৈশিষ্ট্যটি ভেবেচিন্তে পরীক্ষা করা হয়েছে যাতে এটি কোনও ক্ষতি না করে (রিগ্রেশন টেস্টিং) এবং এটি প্রত্যাশা অনুযায়ী কাজ করছে (ইউনিট পরীক্ষা)।

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

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

আমি বিশ্বাস করি যে আপনার আসল সমস্যাগুলি নিম্নলিখিত:

  • ব্যাপ্তি । একটি স্প্রিন্ট আপনার দলকে এবং কেবল আপনার দলকেই উদ্বেগ দেয়, আপনার প্রকৃত QA নয় যা কোনও পণ্যের মালিক হিসাবে বেশি কাজ করে।

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


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

@ মার্করিচম্যান প্রতি ঘন্টা তারা আপনাকে কোডবেজে টাইপ করার জন্য আপনাকে অর্থ প্রদান করে যে তারা আপনাকে যে ঘন্টার জন্য অর্থ দেয় কেবল তা নয়, কোডবেজ থেকে আজেবাজে কথা বলতে সমস্ত ঘন্টা সময় নেয়।
M

4

সমস্ত বা বেশিরভাগ কোডিং স্প্রিন্টের শেষ না হওয়া পর্যন্ত করা হয়?

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

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

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


1
আমি QA তাদের পরীক্ষার পিছনে একটি স্প্রিন্ট হতে অভ্যস্ত। এখানকার লোকেরা পুরো এসডিএলসি প্রতি দুই সপ্তাহে সম্পূর্ণ দেখতে চান । আমি কীভাবে সম্ভব তা দেখছি না।
মার্ক রিচম্যান

5
@ মার্করিচম্যান - কেন নয়? পরিকল্পনার জন্য 1 দিন, কোডিংয়ের জন্য 5 দিন এবং ইউনিট পরীক্ষার জন্য 4 দিন, ডকুমেন্টেশন, বাগ ফিক্সগুলি এবং পরবর্তী স্প্রিন্টের জন্য নকশা। চ্যালেঞ্জটি সত্যিই এটি করা হচ্ছে না, তবে একটি সংখ্যক কাজ ভালভাবে করার জন্য একটি সংস্থা হিসাবে যথেষ্ট শৃঙ্খলাবদ্ধ হওয়া।
টেলাস্টিন

1
কারণ আমি কোডিং করছি এমন 5 দিনের দিকে তারা মনোনিবেশ করবে না, তবে অন্য 5 দিন আমি নই। আমি অবশ্যই কোডিংয়ের সাথে অন্য 5 দিন পূরণ করব, তবে যেহেতু তারা কোডিংয়ের সমস্ত কাজ "স্যুপ-টু-বাদাম" সম্পূর্ণ (টেস্টিং সহ) সম্পূর্ণ করতে চায়, তাই এটি সময়ের পদার্থবিজ্ঞানের তীরের সাথে সামঞ্জস্যপূর্ণ নয় :)
মার্ক রিচম্যান

1
@মার্কিচম্যান - ভাল, তবে অন্য যেসব কোডিং কোডিং করছে না তার সবকটির দিকে ইঙ্গিত করা সহজ হওয়া উচিত যা আপনাকে আসলে করার দরকার হয়
টেলাস্টিন

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

1

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

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

থাম্বের মোটামুটি নিয়ম হিসাবে, 5 থেকে 15 পণ্য ব্যাকলগ আইটেমগুলিকে একটি স্প্রিন্টে আনার প্রত্যাশা করুন। এটি আপনাকে প্রতিটি পণ্যের ব্যাকলগ আইটেমের আকার কত বড় হওয়া উচিত তার একটি ধারণা দেয়। এটি স্প্রিন্টের মধ্যে কাজ 'সম্পন্ন' করার একটি দুর্দান্ত সুযোগ দেয়।

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


0

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


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

0

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

কোনও ফাংশন (...) এর একটি পার্শ্ব প্রতিক্রিয়া বলে মনে করা হয় যদি, কোনও মান ফেরত দেওয়ার পাশাপাশি এটির (...) বাইরের বিশ্বের সাথে (...) পর্যবেক্ষণযোগ্য ইন্টারঅ্যাকশন হয়।

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

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

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

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

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

ইউআইটিকে "বিদেশী অঞ্চল" হিসাবে দেখানো আসলে একটি সঠিক দৃষ্টিভঙ্গি, যেহেতু আপনার দ্বারা সরবরাহ করা হয়নি এমন একটি লাইব্রেরির যুক্তি পরীক্ষা করার দরকার নেই এবং সম্ভবত আশ্চর্যরূপে এটি বাস্তবের দৃষ্টিভঙ্গি: আপনি কি সত্যই সত্যই কি? কখনও কল করার পরীক্ষা করা প্রত্যাশা করে যে কলিং উদাহরণস্বরূপ MyWidget.draw()আপনি যা প্রত্যাশা করেন তা একক পিক্সেলের মাত্রায়?

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

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