টিডিডি কীভাবে উন্নত মানের এবং / অথবা উন্নয়নের গতি [বন্ধ] এর কেস স্টাডিজ সন্ধান করছে


14

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


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

1
এছাড়াও টিডিডি আপনাকে প্রক্রিয়ায় খুব তাড়াতাড়ি সংজ্ঞায়িত করতে দেয় যখন আপনি সমস্ত পরীক্ষাগুলি উত্তীর্ণ হতে হবে কারণ আপনি সম্পন্ন হবেন ।


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

উত্তর:


8

আইবিএম এবং মাইক্রোসফ্টের 4 টি প্রকল্পের একটি গবেষণা। সালে প্রকাশিত Emperical সফটওয়্যার ইঞ্জিনিয়ারিং জার্নাল।

গবেষণামূলক স্টাডিজ দেখায় টেস্ট চালিত বিকাশ মান উন্নত করে

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

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

দলগুলি দলগুলি দ্বারা মিনিট থেকে মিনিট কর্মপ্রবাহ হিসাবে ব্যবহৃত টডিডি অনুশীলনের পাশাপাশি কার্য-স্তরের কর্মপ্রবাহ হিসাবে বর্ণনা করে ...


6

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


4

অবশ্যই এটি পরীক্ষা করে দেখুন: টিডিডি কার্যকর প্রমাণিত! অথবা এটা?

... যখন ফিল হ্যাক ঘোষণা করেছিলেন যে গবেষণা টিডিডি কার্যকারিতা সমর্থন করে আমি লিঙ্কযুক্ত প্রতিবেদনটি আসলে কী ছিল তা দেখার চেয়ে আগ্রহী হওয়ার চেয়ে কিছুটা বেশি ছিল না । ফিল বিমূর্ত থেকে উদ্ধৃতি।

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

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

সুতরাং, কৌতূহলী ধরণের হওয়া এবং যেহেতু টিডিডি এমন কিছু যা আমি নিজেই কোনও দিন নিজেকে গ্রহণ করতে চাইব কিনা তা দেখার জন্য আমি নজর রাখছি, আমি রিপোর্টে গিয়েছিলাম ...

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

টিডিডি তেমন কার্যকর না হওয়ার বিষয়ে লেখকের অনেকগুলি ভাল বক্তব্য রয়েছে (মৃত্যুর জন্য হাইওপ থাকা সত্ত্বেও ইমো)


আমি নিশ্চিত নই যে লিঙ্কযুক্ত সামগ্রীর সদৃশ না করে কীভাবে আমি লিঙ্কের চেয়ে বেশি পোস্ট করতে পারি? ওপি যা জিজ্ঞাসা করে তা সরবরাহ করে: টিডিডির উপর একটি কেস স্টাডি এবং সেই স্টাডিটির একটি পর্যালোচনা।
stijn

4

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

আমার অভিজ্ঞতায় টিডিডি-র স্বয়ংক্রিয় পরীক্ষাগুলি সোনার কারণ তারা বীমা সরবরাহ করে এবং বিপুল পরিমাণে ম্যানুয়াল পরীক্ষার অপসারণ করে

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

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

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


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

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

@AndresF। আপনি সঠিক; উত্তর সম্পাদিত
স্টিভেন এ লো।

2

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

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

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


2

আমি 2 বছর ধরে টিডিডি ব্যবহার করে কাজ করছি এবং আমি যেখানে কাজ করেছি তখন আমরা সকলেই ম্যানেজার সহ ব্যবহার করতে নারাজ ছিলাম। শীঘ্রই এটি সঠিক জিনিস হয়ে উঠেছে। আমরা শীঘ্রই যে সুবিধাগুলি লক্ষ্য করেছি তা হ'ল

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

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

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

আমি সাধারণত নিম্নলিখিতগুলি করি:

  • আমি আমার ইউনিটগুলি খুব ছোট রাখি
  • কেবলমাত্র 1 জোর দিয়েছিলেন o কোনও রুশ রুলেট।
  • আমি একটি ইতিবাচক-নেতিবাচক এবং ব্যতিক্রম দৃশ্যের পরীক্ষা করি

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

আমি আসা করি এটা সাহায্য করবে

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