সিস্টেমটি বাস্তবায়নের চেয়ে আমরা কার্যকরী পরীক্ষা বাস্তবায়নের জন্য বেশি সময় ব্যয় করছি, এটাই কি স্বাভাবিক?


12

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

পরিচালকের নীতি হ'ল আমরা যুক্ত প্রতিটি একক কার্যকারিতা পরীক্ষা করা, এমনকি যদি ব্যবসায়িক সমালোচনা না হয় (যেমন একটি নতুন সিআরইউডি)।

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

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

দ্রষ্টব্য: আমরা চিকিত্সা সফ্টওয়্যার বা নাসা সফ্টওয়্যার বা এর মতো গুরুত্বপূর্ণ কিছু বিকাশ করছি না।


14
আমাদের পরীক্ষা নেই। আমরা সত্যের পরে জিনিসগুলি স্থির করতে প্রচুর পরিমাণে সময় ব্যয় করি। "আপনি এখন আমাকে দিতে পারেন, বা আপনি আমাকে পরে দিতে পারেন।" এটি পরে এবং এটি সুন্দর নয়।
মেটালমাইকস্টার

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


উত্তর:


16

কার্যকরী পরীক্ষা খুব গুরুত্বপূর্ণ। হ্যাঁ, তারা লিখতে সময় নেয় তবে আপনি যদি সঠিক কার্যকরী পরীক্ষাগুলি লিখছেন তবে সেগুলি এর চেয়ে বেশি মূল্যবান হবে।

কোনও অ্যাপ্লিকেশনটিতে স্বয়ংক্রিয় কার্যকরী পরীক্ষা করার কয়েকটি ভাল কারণ রয়েছে।

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

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

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

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


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

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

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

@ ডেনসিয়র ~ অবশ্যই, কেস পরীক্ষা করতে QA 5min সময় লাগে তবে এটি পরীক্ষা করতে কম্পিউটারকে একটি সেকেন্ডের চেয়ে কম সময় লাগে। আপনার জিজ্ঞাসা করা উচিত "হাত দিয়ে পরীক্ষা করতে 5 মিনিট লাগে এমন কিছু লিখতে 2 দিন কেন লাগে"? আবার আপনার সরঞ্জামগুলি দেখুন। সম্ভবত কিউএও কিছু টেস্ট কেস লিখতে হবে? সমস্যাটি আপনার সিস্টেমে পরীক্ষার কেসগুলি লিখছে না, test পরীক্ষাগুলির ক্ষেত্রে এটি কীভাবে লেখা হচ্ছে।
টায়না

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

7

2 বারের বেশি ... আমার কাছে কিছুটা মনে হচ্ছে। আপনি এর কারণগুলি বিশ্লেষণ করতে চাইতে পারেন, সেগুলি অন্তর্ভুক্ত করতে পারে:

  • পরীক্ষার তৈরি এবং রক্ষণাবেক্ষণের জন্য খারাপ সরঞ্জাম সমর্থন

  • ওয়েব পরিষেবাদির চুক্তিগুলি নকশায় পর্যাপ্ত বর্ণিত নয়। বিকাশকারীদের পরীক্ষার সময় চুক্তিগুলি সম্পাদন করতে হবে যা সাধারণত সময় সাশ্রয়ীকরণ প্রান্তিককরণ প্রক্রিয়া।

আপনার বিকাশকারীদের সাথে কথা বলুন।

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


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

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

4

সিস্টেমটি কার্যকর করার চেয়ে কার্যকরী পরীক্ষা বাস্তবায়নের জন্য বেশি সময় ব্যয় করা কি স্বাভাবিক?

একেবারে। সত্যই ভাল পরীক্ষা লিখতে সম্ভবত বেশিরভাগ (ভাল) দোকানে বেশিরভাগ সময় লাগতে পারে।
সুতরাং একটি 2-1 অনুপাত ঠিক আছে। স্বল্প অভিজ্ঞ বিকাশকারীরা নিজেরাই পরীক্ষার জন্য প্রায়শই সময় নেন না।


2

হ্রাস করার বিধান রয়েছে। ধরে নিই যে আপনি প্রথমে ঝুঁকিপূর্ণ কোডের জন্য পরীক্ষা লেখেন, পরবর্তী পরীক্ষার দ্বারা উত্পন্ন মান সময়ের সাথে সাথে হ্রাস পাবে।

ইউনিট পরীক্ষাগুলি কোড হয়, সুতরাং এগুলিতে বাগগুলি থাকবে (অন্য সমস্ত কোডের মতো)। এই বাগগুলি ঠিক করতে সময় লাগে।

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


1

এটি গুণ সম্পর্কে।

আপনার যদি বাজারটি পাওয়া দরকার - আপনি যত তাড়াতাড়ি সম্ভব আপনার অ্যাপ্লিকেশনটি বিকাশ করবেন। এমনকি আপনার মোটে স্বয়ংক্রিয় পরীক্ষাও করা যাবে না =) তবে আপনি আপনার অ্যাপ্লিকেশনটি আপনার প্রতিযোগীদের আগে আপনার শ্রাবণীর কাছে দেবেন।

তবে যদি আপনি জানেন যে আপনার শ্রাবণটি দূরে যাবে না আপনি তাদের হতাশ করতে না পেরে কিছু করতে পারবেন। প্রতিটি বাগের টিকিট আপনার খ্যাতি কমিয়ে আনবে। কল্পনা করুন যে একটি বাগ আপনার সুনামের 50 শতাংশ সরিয়ে ফেলবে, পরেরটি - অন্য 25 শতাংশ এবং এর মধ্যে একটি। তাহলে কি অনেক বেশি পরীক্ষা করা যায়?


ভাল আমি সত্যিই নিশ্চিত নই যে এই মুহুর্তে আমরা আসলে টিকিট হ্রাস করছি। সম্ভবত আমরা কিউএ টিকিট কমিয়েছি (তবে খুব বেশি নয়) তবে কার্যক্ষম পরীক্ষাগুলি বিকাশের সময় সফ্টওয়্যার এনজিনিয়ারদের 2/3 সময় দেওয়ার ব্যয়কে ন্যায্য করার জন্য এই পরীক্ষার মাধ্যমে পাওয়া বাগের হার যথেষ্ট পরিমাণে (আমার দৃষ্টিকোণের চেয়ে বেশি) নয়।
পাবলো লাসকানো

0

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

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

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

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