স্ক্র্যাম গাইড কেন পরীক্ষক নেই?


14

আমি scrum.org থেকে স্ক্র্যাম গাইড পড়ছি এবং এটিতে বলা হয়েছে:

উন্নয়ন দলগুলিতে পরীক্ষা বা ব্যবসায় বিশ্লেষণের মতো নির্দিষ্ট ডোমেনগুলিকে উত্সর্গীকৃত উপ-দল থাকে না।

এর আক্ষরিক অনুবাদে এর অর্থ হ'ল কোনও পরীক্ষার্থী নেই যা বিভ্রান্ত করছে। কীভাবে তারা এই পরামর্শ দিতে পারে?


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

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

উত্তর:


25

এর অর্থ হল:

  1. পরীক্ষকরা বিকাশকারী দলে একীভূত হয় - বিকাশকারীদের পরীক্ষার পাশাপাশি পরীক্ষার জন্য সরঞ্জাম তৈরির সরঞ্জাম।

    বা:

  2. দলটি টেস্ট চালিত বিকাশের অনুশীলন করে - যেমন তারা সিস্টেমটি ব্যবহার করে এমন স্বয়ংক্রিয় পরীক্ষাগুলি লেখেন।

এর যে কোনওটির অর্থ এই যে পৃথক পরীক্ষামূলক দলের প্রয়োজন নেই।


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

4
@ ম্যাক্সুড: আমি বলব যে টিডিডি ম্যানুয়াল পরীক্ষাকে অতিমাত্রায় পরিণত করে না। যদি কোনও সমস্যা হয়ে যায় তবে আপনি এটি সমাধান করুন; আপনি এড়ানো শুরু করবেন না।
মাইকেল বর্গওয়ার্ট

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

7
@ ম্যাক্সুড: পরীক্ষকগণের উচিত, আমার মতে, ইউনিট পরীক্ষাগুলি স্পর্শ করা উচিত নয়। তাদের বিকাশকারীদের সহযোগিতায় গ্রহণযোগ্যতা পরীক্ষায় কাজ করা উচিত, এবং ম্যানুয়াল / জিইউআই পরীক্ষার জন্য দায়বদ্ধ হওয়া উচিত। ইউনিট পরীক্ষাটি এমন স্তরে রয়েছে যা কেবল বিকাশকারীদের জন্য আকর্ষণীয়। পরীক্ষার পিরামিড ( ব্লগস.এগিলিফ্যাক্স.কম / ২০১০ / ০২ / ২০১১ / ইনভারটিং-the -testing- pyramid ) এর প্রতিক্রিয়াও রয়েছে, ইউনিট-টেস্টিং = বিকাশকারী, গ্রহণযোগ্যতা পরীক্ষা = ভাগ করা, জিইউআই পরীক্ষা = পরীক্ষক।
মার্টিয়ার্ট

12

এর আক্ষরিক অনুবাদে এর অর্থ হ'ল কোনও পরীক্ষক নেই যা বিভ্রান্ত করছে ... তারা কীভাবে এটিকে পরামর্শ দিবে?

হ্যাঁ, তারা ঠিক তাদের পরামর্শ দেয়। অন্য কথায় - বিকাশকারীরা পরীক্ষক এবং পরীক্ষকরা বিকাশকারী।

ধারণাটি হ'ল কোডের মালিকানা এবং গুণমানকে বাড়ানো ।

এর অর্থ এই নয় যে কোডটি পরীক্ষা করা হয় না, তবে এটি লেখার সাথে জড়িত ব্যক্তিরা এটির পরীক্ষার সাথে জড়িত - দায়িত্বগুলির কোনও বিচ্ছেদ নেই।

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


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

1
@ মারজানভেনেমা - একজন এ কী লিখেছেন তা ব্যক্তি বি দ্বারা পরীক্ষা করা যেতে পারে, বা কোনও কোড লেখার আগে স্বয়ংক্রিয় পরীক্ষাগুলি লেখা যেতে পারে।
ওডে

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

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

2
QA এবং বিকাশ দুটি পৃথক দক্ষতা সেট (এবং বেতন স্কেল) সহ দুটি স্বতন্ত্র ভূমিকা। চমৎকার কিউএর জন্য ফোকাস এবং বিশেষজ্ঞের একটি স্তর প্রয়োজন যা যদি কেউ বিকাশকারী এবং কিউএ হিসাবে দ্বৈত দায়িত্ব পালন করে তবে তা ঘটবে না।
26 ই

2

এর মূল অংশটি হ'ল কোডারের দায়িত্ব হ'ল কোড তৈরি করা যা কাজ করে এবং প্রয়োজনীয়তা পূরণ করে। এটির জন্য একটি নির্দিষ্ট মানসিকতা দরকার - "আমি যে কোডটি লিখছি তা এটি করার কথা বলে।"

কোডারের দায়িত্বগুলি মিশ্রিত করার অর্থ কোডারকে এখন অন্যান্য ক্রিয়াকলাপের জন্য অন্যান্য মানসিকতায় প্রবেশ করা প্রয়োজন, তবে কোডার হিসাবে একজনের পক্ষে সেই মানসিকতা থেকে সম্পূর্ণ নিজেকে তালাক দেওয়া অসম্ভব কঠিন।

পরীক্ষকের দায়িত্ব বাগ এবং স্থানগুলি সন্ধান করা যেখানে কার্যকারিতা প্রয়োজনীয় কার্যকারিতা থেকে ডাইভার্ট করে। এটির জন্য "কোডটি ভেঙে গেছে এবং আমি কীভাবে তা খুঁজে বের করব of" এর মানসিকতার প্রয়োজন।

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

কোডার সেই অন্য যে কোনও একটিতে কাজ করার জন্য, যুক্তিসঙ্গত সম্ভাবনা রয়েছে যে মানসিকতাগুলি দ্বন্দ্ব করবে এবং কোডার সাব-পার করে দেবে:

  • কোডার / কিউএ - "কোডটি নিখুঁতভাবে কাজ করে এবং আমি এটি ভেঙে যেতে পারে এমন ভাবতে পারে এমন প্রতিটি সম্ভাব্য পদ্ধতি পরিচালনা করার জন্য আমি ইতিমধ্যে কোড করে রেখেছি।"
  • কোডার / বিএ - "কোডটি আমি যেভাবে চাই তা কাজ করা উচিত এবং গ্রাহক ভাবেন নি যে এগুলিকে যুক্ত করতে ঝরঝরে জিনিস হবে be

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

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


1

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


"ক্লায়েন্টও পরীক্ষার সাথে জড়িত থাকতে পারে" - হ্যাঁ, ঠিক আছে, অন্যথায় আপনার কাছে একটি জলপ্রপাত প্রকল্প রয়েছে যেখানে সম্পন্ন হওয়ার সংজ্ঞাটি "আমরা প্রকল্পের শেষে পৌঁছেছি" is তা চটজলদি নয়।
রবিন গ্রিন 16

1

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

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


1

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

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

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


1

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

আমার কাছে, স্ক্রাম সম্পর্কে এই বিবৃতিটির অর্থ হ'ল আপনার একক দল হিসাবে সম্পূর্ণ বিতরণ পাইপলাইনটি সম্পর্কে চিন্তা করা উচিত। একই দলের অংশ হওয়া কয়েকটি বিষয় সম্পর্কে পরামর্শ দেয়:

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

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

সম্ভাব্য লক্ষণগুলি আপনি সত্যিই বিতরণকারী দলের অংশ হিসাবে পরীক্ষকদের সাথে চিকিত্সা নাও করতে পারেন, এমনকি আপনি যদি ভাবেন যে:

  1. পরীক্ষকদের একটি "কিউএ স্ট্যান্ডআপ" আছে (হ্যাঁ, আমি এটি দেখেছি)।
  2. পরীক্ষার্থীদের একটি পৃথক পরিচালন কাঠামো রয়েছে।
  3. আপনার একটি QA সীসা আছে।
  4. আপনি শেষ থেকে শেষের পরীক্ষাগুলিতে প্রচুর নির্ভর করে।
  5. টেস্টগুলি নিম্নলিখিত স্প্রিন্টে লিখিত হয়।
  6. সর্বাধিক পরীক্ষাটি স্প্রিন্টের শেষ দিনে ঘটে।

এগুলি বিষয়গত এবং অগত্যা ভুল নয়। এগুলি যদিও আমার মতে লাল পতাকা।

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

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