প্রোগ্রামাররা কি খারাপ পরীক্ষক?


36

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

সফটওয়্যারটির উপর জোয়েল - শীর্ষ পাঁচটি (ভুল) কারণগুলির জন্য আপনার পরীক্ষক নেই (জোর আমার)

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

এবং এই প্রশ্নে , সর্বাধিক জনপ্রিয় একটি উত্তর বলে (আবার, আমার জোর):

বিকাশকারীরা পরীক্ষক হতে পারেন, তবে তাদের পরীক্ষক হওয়া উচিত নয়। বিকাশকারীরা অনিচ্ছাকৃতভাবে / অবিচ্ছিন্নভাবে অ্যাপ্লিকেশনটিকে এমনভাবে ব্যবহার করতে এড়াতে ঝোঁকেন যে এটি ভেঙে যেতে পারে। কারণ এটি তারা লিখেছিল এবং বেশিরভাগ ক্ষেত্রে এটি ব্যবহার করা উচিত সেভাবে পরীক্ষা করে।

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

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


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

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

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

3
আমরা খারাপ পরীক্ষক নই! এটি আমার পিসিতে কাজ করেছে! ;-)
জোরিস টিমারম্যানস

2
@ ম্যাডকিথভি হা! এটি আমার JIRA (ইস্যু ট্র্যাকার) অবতার;)
ইয়ানিস

উত্তর:


39

প্রশ্নটি সিস্টেম টেস্টিং সম্পর্কে বিশেষত জিজ্ঞাসা করছে বলে মনে হচ্ছে , তাই আমি এই উত্তরটির পুরো অংশটিই উল্লেখ করছি।

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

প্রোগ্রামাররা কেন পরীক্ষায় খারাপ হয়:

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

প্রোগ্রামাররা কেন পরীক্ষায় ভাল:

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

প্রোগ্রামাররা কেন খারাপ পরীক্ষক:

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

4
নোট করুন যে প্রোগ্রামারদের যৌক্তিক চিন্তাভাবনা একটি ভাল পরীক্ষক হওয়ার জন্য ক্ষতিকারক হতে পারে। আপনি কতবার দেখেছেন যে কোনও প্রোগ্রামার "তবে এটি অসম্ভব!" যখন খুঁজে পাওয়া বাগের মুখোমুখি? কেবল এটি অনুসন্ধান করার জন্য যে তারা তর্ককে "অসম্ভব" করে তুলেছে তাদের যুক্তিতে গুরুতর কিছু মিস করেছেন।
জরিস টিমারম্যানস

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

3
+1 একটি দুর্দান্ত, সুষম উত্তর এছাড়াও স্বয়ংক্রিয় ইউনিট এবং কিউএ দ্বারা সিস্টেম পরীক্ষার সাথে প্রোগ্রামারদের দ্বারা লিখিত ইন্টিগ্রেশন পরীক্ষার মধ্যে সংমিশ্রণ কেন সর্বোত্তম সমন্বয় explains
ড্যানি ভারোদ

1
"মানসিকতা মূলত পৃথক" এর জন্য +1। সম্পর্কিত (তবে আলাদা) দক্ষতার সেট সহ এগুলি সর্বোপরি ভিন্ন ভিন্ন ভূমিকা।
joshin4colours

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

19

আমি মনে করি প্রোগ্রামাররা তাদের নিজস্ব কোড পরীক্ষা করতে খারাপ ।

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


1
আমার দুই সেন্ট. বিকাশকারীরা সাধারণত কেবলমাত্র সর্বশেষ পরিবর্তনগুলি, শেষ ফিক্স, শেষ বৈশিষ্ট্য পরীক্ষা করে থাকেন, তারা করেছিলেন (আমি করেছি) এবং কিছু ক্ষেত্রে তারা (আমরা) কিছুটা অন্ধ বা অন্যান্য বৈশিষ্ট্য পরীক্ষা করতে অলস।
Andrea Girardi

11

প্রোগ্রামাররা অবশ্যই সিস্টেমের কিছু অংশ পরীক্ষা করার জন্য সঠিক ব্যক্তি - এমন স্থানে তারা কেবলমাত্র এটি কার্যকরভাবে কার্যকর করতে সক্ষম হতে পারে।

এক জায়গার প্রোগ্রামাররা টেস্টিংয়ে খুব খারাপ হওয়ার প্রবণতা হ'ল পুরো "সাধারণ ব্যবহারকারীর মতো ইউআই ব্যবহার করুন" বিট - তারা সাধারণ ব্যবহারকারী নন এবং তাদের মতো আচরণ করেন না। উদাহরণ স্বরূপ:

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

সুতরাং, সাধারণ ব্যবহারকারীরা প্রচুর কাজ প্রোগ্রামারদের করেন না। আপনি ইউএটি-র জন্য পুরোপুরি ডেভ দলে নির্ভর করতে পারবেন না।


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

1

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

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

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

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


1

আমার অভিজ্ঞতা থেকে, হ্যাঁ, প্রোগ্রামাররা খারাপ পরীক্ষক। অনেক সময় আমি অন্যকে এবং নিজে যেতে দেখেছি "হু, তবে আমি পরীক্ষা করে দেখার আগে পরীক্ষা করেছিলাম!" যখন পরীক্ষক আপনার মুখোমুখি হন তখন আপনার সামনে বাগ প্রজনন করে।

কেন? ঠিক আছে, আমি কেন তা নিশ্চিত তা জানি না তবে এটি হ'ল কারণ আমরা স্টাফটি কাজ করতে চাই। অথবা আমরা ইতিমধ্যে এটি বা সেই বৈশিষ্ট্যটি পরীক্ষা করেই এগিয়ে যেতে চাই।

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

প্রশ্নের মতোই, পরীক্ষার অর্থ স্বয়ংক্রিয় কিছুই নয় তবে প্রোগ্রামটি ব্যবহার করে প্রকৃতপক্ষে পরীক্ষা করা।


1

পরীক্ষার বিভিন্ন স্তর। "নিম্ন স্তরের" পরীক্ষাটি বিকাশকারীদের দ্বারা করা এবং অবশ্যই করা যেতে পারে। আমি ইউনিট টেস্টিগ এ মনে করি।

অন্যদিকে, "উচ্চ স্তরের" পরীক্ষা নিখুঁতভাবে অন্য জিনিস। সাধারণভাবে আমি মনে করি বিকাশকারীরা খারাপ পরীক্ষক, কারণ তারা দক্ষতা মিস করে না, তবে এটি ভাবার জন্য খুব শক্ত উপায় এবং কিছু সময়ের মধ্যে কাজ করার উপায় because

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


0

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

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

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


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

0

প্রোগ্রামাররা কোড লেখার আগে পরীক্ষাগুলি সংজ্ঞায়িত করার সময় সূক্ষ্ম সংজ্ঞা পরীক্ষা করে থাকে। অনুশীলনের সাথে তারা আরও উন্নত হয়।

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

ম্যানুয়াল টেস্টিং করতে প্রোগ্রামার ব্যবহার করা কেবল নির্বোধ। ম্যানুয়াল টেস্টিং তার নিজের উপর যথেষ্ট নির্বোধ; প্রোগ্রামারদের তৈরি করা অত্যন্ত চূড়ান্ত। এটি ব্যয়বহুল এবং সক্ষম প্রোগ্রামারদের তাড়িয়ে দেয়।


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

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

@ ড্যানি: টিডিডি সহ, আপনার ব্যর্থ পরীক্ষার প্রতিক্রিয়া হিসাবে কেবল শাখা বা পদ্ধতি লিখতে হবে এবং আপনি ব্যর্থ পরীক্ষার পাস করার জন্য প্রয়োজনীয় কোডটি লিখেছেন।
কেভিন ক্লিন

আমি টিডিডির পদ্ধতি জানি, আমি কেবল সিদ্ধান্তে একমত নই।
ড্যানি ভারোদ

0

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

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

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

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