আপনার প্রকল্পের সাথে মেলে এমন একটি যুক্তিসঙ্গত কৌশলের মধ্যে বিভিন্ন পরীক্ষার ধরনকে কীভাবে একত্রিত করা যায় তা আবিষ্কার করুন।
ফিরে আসার জন্য স্বাগতম! শেষ নিবন্ধটি বিভিন্ন পরীক্ষার ধরনগুলির সাথে কীভাবে যোগাযোগ করতে হবে এবং সেগুলিতে কী রয়েছে সে সম্পর্কে প্রচুর ভিত্তি স্থাপন করেছে এবং পরীক্ষার প্রকারের সংজ্ঞাগুলি স্পষ্ট করেছে৷ এই ছোট মেম ইমেজ মনে আছে? আপনি হয়তো ভাবছেন যে আপনি যে সমস্ত পরীক্ষার ধরন সম্পর্কে শিখেছেন তা একসাথে কাজ করতে পারে।
পরবর্তী, আপনি ঠিক যে শিখবেন. এই নিবন্ধটি কীভাবে এই পরীক্ষার ধরনগুলিকে যুক্তিসঙ্গত কৌশলগুলির সাথে একত্রিত করতে হয় এবং আপনার প্রকল্পের সাথে মেলে এমন একটি বেছে নিতে হয় তার একটি ভূমিকা দেয়৷
আপনি তাদের অর্থ আরও ভালভাবে উপলব্ধি করতে কৌশলগুলিকে কয়েকটি আকারের সাথে তুলনা করতে পারেন। এখানে নিজ নিজ মাপ এবং বিকাশের সুযোগ সহ কৌশলগুলির একটি তালিকা রয়েছে৷
আসুন কৌশলগুলি ঘনিষ্ঠভাবে দেখে নেওয়া যাক এবং তাদের নামের পিছনে অর্থ শিখি।
পরীক্ষার লক্ষ্য নির্ধারণ করুন: আপনি এই পরীক্ষাগুলি দিয়ে কী অর্জন করতে চান?
আপনি একটি ভাল কৌশল তৈরি করা শুরু করার আগে, আপনার পরীক্ষার লক্ষ্য বের করুন। আপনি কখন বিবেচনা করেন যে আপনার আবেদন পর্যাপ্তভাবে পরীক্ষা করা হয়েছে?
উচ্চ পরীক্ষার কভারেজ অর্জন করা প্রায়ই ডেভেলপারদের চূড়ান্ত লক্ষ্য হিসাবে দেখা হয় যখন এটি পরীক্ষার ক্ষেত্রে আসে। কিন্তু এটা কি সর্বদা সর্বোত্তম পন্থা? একটি পরীক্ষার কৌশল নির্ধারণ করার সময় বিবেচনা করার জন্য আরেকটি গুরুত্বপূর্ণ বিষয় থাকতে পারে—আপনার ব্যবহারকারীদের চাহিদা পূরণ করা।
একজন বিকাশকারী হিসাবে, আপনি আরও অনেক অ্যাপ্লিকেশন এবং ডিভাইস ব্যবহার করেন৷ এই ক্ষেত্রে, আপনি সেই ব্যবহারকারী যিনি "শুধু কাজ" করার জন্য এই সমস্ত সিস্টেমের উপর নির্ভর করেন। পরিবর্তে, আপনি তাদের অ্যাপ্লিকেশন এবং ডিভাইসগুলিকে কার্যকর করার জন্য তাদের যথাসাধ্য করার জন্য অসংখ্য বিকাশকারীদের উপর নির্ভর করেন৷ এটিকে ফিরিয়ে আনতে, একজন বিকাশকারী হিসাবে, আপনিও এই বিশ্বাসের সাথে বেঁচে থাকার চেষ্টা করেন। তাই আপনার প্রথম লক্ষ্য সবসময় কাজ করা সফ্টওয়্যার পাঠানো এবং আপনার ব্যবহারকারীদের পরিবেশন করা উচিত। এটি অ্যাপ্লিকেশনের গুণমান নিশ্চিত করতে আপনার লেখা পরীক্ষা পর্যন্ত প্রসারিত। কেন্ট সি ডডস তার স্ট্যাটিক বনাম ইউনিট বনাম ইন্টিগ্রেশন বনাম E2E টেস্টিং ফর ফ্রন্টেন্ড অ্যাপস পোস্টে এটিকে খুব ভালোভাবে তুলে ধরেছেন:
আপনার সফ্টওয়্যার ব্যবহার করার পদ্ধতিতে আপনার পরীক্ষাগুলি যত বেশি সাদৃশ্যপূর্ণ, তারা আপনাকে তত বেশি আত্মবিশ্বাস দিতে পারে।
কেন্ট সি ডডস দ্বারা
কেন্ট এটিকে পরীক্ষায় আস্থা অর্জন হিসাবে বর্ণনা করেছেন। মানানসই একটি টেস্টিং টাইপ বেছে নিয়ে আপনি ব্যবহারকারীদের যত কাছাকাছি যাবেন, তত বেশি আপনি আপনার পরীক্ষাগুলোকে বৈধ ফলাফলের জন্য বিশ্বাস করতে পারবেন। অন্য কথায়, আপনি যত উপরে পিরামিড আরোহণ করবেন, তত বেশি আত্মবিশ্বাসী হবেন। কিন্তু অপেক্ষা করুন, পিরামিড কি?
পরীক্ষার কৌশল নির্ধারণ করা: কীভাবে একটি পরীক্ষার কৌশল বেছে নেওয়া যায়
প্রথম পদক্ষেপ হিসাবে, প্রয়োজনীয়তার কোন অংশগুলি পূরণ হয়েছে তা নিশ্চিত করতে আপনাকে পরীক্ষা করতে হবে তা নির্ধারণ করুন। কোন পরীক্ষার ধরনগুলি ব্যবহার করতে হবে তা খুঁজে বের করুন এবং একটি দক্ষ খরচ কাঠামো বজায় রাখার সময় আপনি সবচেয়ে বেশি আত্মবিশ্বাস অর্জন করতে পারেন বিস্তারিত কোন স্তরে। অনেক ডেভেলপার সাদৃশ্য ব্যবহার করে এই বিষয়ে যোগাযোগ করে। সুপরিচিত ক্লাসিক থেকে শুরু করে এখানে সবচেয়ে সাধারণ।
ক্লাসিক: টেস্ট পিরামিড
যত তাড়াতাড়ি আপনি পরীক্ষার কৌশলগুলি সন্ধান করা শুরু করবেন, আপনি সম্ভবত প্রথম সাদৃশ্য হিসাবে পরীক্ষা অটোমেশন পিরামিড জুড়ে আসবেন। মাইক কোহন তার "সাকসিডিং উইথ এজিল" বইয়ে এই ধারণাটি চালু করেছেন। পরবর্তীতে, মার্টিন ফাউলার তার ব্যবহারিক পরীক্ষা পিরামিড নিবন্ধে ধারণাটি প্রসারিত করেন। আপনি নিম্নলিখিত হিসাবে পিরামিডকে দৃশ্যত উপস্থাপন করতে পারেন:
এই অঙ্কনে দেখানো হয়েছে, পরীক্ষার পিরামিড তিনটি স্তর নিয়ে গঠিত:
ইউনিট আপনি এই পরীক্ষাগুলি পিরামিডের বেস লেয়ারে খুঁজে পান কারণ এগুলি কার্যকর করা দ্রুত এবং বজায় রাখা সহজ। তারা বিচ্ছিন্ন এবং সবচেয়ে ছোট পরীক্ষা ইউনিট লক্ষ্য করে. উদাহরণস্বরূপ, একটি খুব ছোট পণ্যের জন্য একটি সাধারণ ইউনিট পরীক্ষা দেখুন।
মিশ্রণ . এই পরীক্ষাগুলি পিরামিডের মাঝখানে, কারণ তাদের একটি গ্রহণযোগ্য সম্পাদনের গতি রয়েছে তবে ইউনিট পরীক্ষাগুলি যা করতে পারে তার চেয়ে আপনাকে ব্যবহারকারীর কাছাকাছি নিয়ে আসে। ইন্টিগ্রেশন পরীক্ষার একটি উদাহরণ হল একটি API পরীক্ষা । আপনি এই ধরনের হিসাবে উপাদান পরীক্ষা শ্রেণীবদ্ধ করতে পারেন.
E2E পরীক্ষা (যাকে UI পরীক্ষাও বলা হয়)। এই পরীক্ষাগুলি একজন প্রকৃত ব্যবহারকারী এবং তাদের মিথস্ক্রিয়াকে অনুকরণ করে। এই ধরনের পরীক্ষাগুলি চালানোর জন্য আরও সময় প্রয়োজন এবং এইভাবে আরও ব্যয়বহুল। তারা পিরামিডের শীর্ষে রয়েছে।
আস্থা বনাম সম্পদ
সংক্ষেপে আগে আচ্ছাদিত হিসাবে, স্তরগুলির ক্রম কোন কাকতালীয় নয়। তারা অগ্রাধিকার এবং সংশ্লিষ্ট খরচ দেখায়. এটি আপনাকে প্রতিটি স্তরের জন্য কতগুলি পরীক্ষা লিখতে হবে তার একটি পরিষ্কার চিত্র দেয়। আপনি ইতিমধ্যে পরীক্ষার প্রকারের সংজ্ঞাতে এটি দেখেছেন।
যেহেতু E2E পরীক্ষাগুলি আপনার ব্যবহারকারীদের সবচেয়ে কাছের, তারা আপনাকে সবচেয়ে বেশি আত্মবিশ্বাস দেয় যে আপনার অ্যাপ্লিকেশনটি উদ্দেশ্য অনুযায়ী কাজ করছে। যাইহোক, তাদের একটি সম্পূর্ণ অ্যাপ্লিকেশন স্ট্যাক এবং একটি সিমুলেটেড ব্যবহারকারীর প্রয়োজন, তাই, তারা সম্ভাব্যভাবে সবচেয়ে ব্যয়বহুল। সুতরাং আত্মবিশ্বাসটি আপনার পরীক্ষা চালানোর জন্য প্রয়োজনীয় সংস্থানগুলির সাথে সরাসরি প্রতিযোগিতায় রয়েছে।
পিরামিড এই সমস্যার সমাধান করার চেষ্টা করে যাতে আপনি ইউনিট পরীক্ষায় আরও বেশি ফোকাস করেন এবং E2E পরীক্ষা দ্বারা আচ্ছাদিত ক্ষেত্রে কঠোরভাবে অগ্রাধিকার দেন। উদাহরণস্বরূপ, আপনার সবচেয়ে গুরুত্বপূর্ণ ব্যবহারকারীর যাত্রা বা ত্রুটির জন্য সবচেয়ে ঝুঁকিপূর্ণ স্থান। মার্টিন ফাউলার যেমন জোর দিয়েছেন, কোহনের পিরামিডের দুটি সবচেয়ে প্রয়োজনীয় পয়েন্ট নিম্নরূপ:
- বিভিন্ন গ্রানুলিটি সহ পরীক্ষা লিখুন।
- আপনি যত বেশি উচ্চ স্তর পাবেন, তত কম পরীক্ষা করা উচিত।
পিরামিড বিবর্তিত! পরীক্ষার পিরামিডের অভিযোজন
বেশ কয়েক বছর ধরেই পিরামিডকে ঘিরে আলোচনা চলছে। পিরামিডটি পরীক্ষার কৌশলগুলিকে অতি সরলীকরণ করে বলে মনে হয়, প্রচুর পরীক্ষার ধরন ছেড়ে দেয় এবং বাস্তব-বিশ্বের সমস্ত প্রকল্পের সাথে আর খাপ খায় না। অতএব, এটা বিভ্রান্তিকর হতে পারে. পিরামিড কি আকৃতির বাইরে পড়ে গেছে? গুইলারমো রাউচের এটি সম্পর্কে একটি মতামত রয়েছে:
পরীক্ষা লিখুন। অনেক বেশি না. বেশিরভাগই ইন্টিগ্রেশন।
Guillermo Rauch দ্বারা
এটি এই বিষয়ে সর্বাধিক উদ্ধৃত উদ্ধৃতিগুলির মধ্যে একটি, তাই আসুন এটিকে ভেঙে দেওয়া যাক:
- "পরীক্ষা লিখুন"। এটি কেবল বিশ্বাস তৈরি করে না, বরং এটি রক্ষণাবেক্ষণে সময় বাঁচায়।
- "অনেক বেশি না". 100% কভারেজ সবসময় ভাল হয় না কারণ তখন আপনার পরীক্ষার অগ্রাধিকার দেওয়া হয় না এবং প্রচুর রক্ষণাবেক্ষণ করা হবে।
- "বেশিরভাগই ইন্টিগ্রেশন"। এখানে আবার একীকরণ পরীক্ষার উপর জোর দেওয়া হয়েছে: যুক্তিসঙ্গত সম্পাদনের সময় বজায় রেখে আপনাকে দৈনিক উচ্চ আত্মবিশ্বাসের স্তর দিয়ে তাদের সবচেয়ে বেশি ব্যবসায়িক মূল্য রয়েছে।
এটি আপনাকে পরীক্ষার পিরামিড সম্পর্কে আবার ভাবতে এবং আপনার ফোকাসকে ইন্টিগ্রেশন টেস্টিং-এ স্থানান্তরিত করে। গত কয়েক বছরে, অনেক অভিযোজন প্রস্তাব করা হয়েছে, তাই আসুন সবচেয়ে সাধারণের দিকে তাকাই।
পরীক্ষা হীরা
প্রথম অভিযোজন ইউনিট পরীক্ষার উপর অতিরিক্ত জোর দেয়, যেমনটি পরীক্ষা পিরামিডে দেখা যায়। কল্পনা করুন যে আপনি ইউনিট পরীক্ষায় 100% কভারেজ পৌঁছেছেন। যাইহোক, পরের বার আপনি যখন রিফ্যাক্টর করবেন, আপনাকে এই ইউনিট পরীক্ষাগুলির অনেকগুলি আপডেট করতে হবে এবং আপনি সেগুলি এড়িয়ে যেতে প্রলুব্ধ হতে পারেন। তাই তারা নষ্ট হয়ে যায়।
ফলস্বরূপ, এবং একত্রীকরণ পরীক্ষার উপর উচ্চতর ফোকাসের সাথে, নিম্নলিখিত আকৃতি দেখা দিতে পারে:
একটি পিরামিড একটি হীরাতে বিকশিত হয়। আপনি আগের তিনটি স্তর দেখতে পারেন, কিন্তু একটি ভিন্ন আকারের সঙ্গে, এবং ইউনিট স্তর কাটা হয়েছে:
- ইউনিট ইউনিট পরীক্ষা লিখুন যেভাবে আপনি তাদের আগে সংজ্ঞায়িত করেছেন। যাইহোক, কারণ তারা ক্ষয় করার প্রবণতা রাখে, অগ্রাধিকার দেয় এবং শুধুমাত্র সবচেয়ে জটিল ক্ষেত্রে কভার করে।
- মিশ্রণ . ইন্টিগ্রেশন পরীক্ষা আপনি জানেন, একক ইউনিটের সমন্বয় পরীক্ষা করা।
- E2E । এই স্তরটি পরীক্ষার পিরামিডের অনুরূপ UI পরীক্ষা পরিচালনা করে। সবচেয়ে জটিল পরীক্ষার ক্ষেত্রে শুধুমাত্র E2E পরীক্ষা লেখার যত্ন নিন।
মৌচাক পরীক্ষা করা হচ্ছে
আরও একটি অভিযোজন রয়েছে, যা স্পটিফাই দ্বারা প্রবর্তিত হয়েছে, যা টেস্ট ডায়মন্ডের মতো কিন্তু মাইক্রোসার্ভিসেস-ভিত্তিক সফ্টওয়্যার সিস্টেমের জন্য আরও বিশেষায়িত। টেস্টিং মধুচক্র হল একটি মাইক্রোসার্ভিসেস-ভিত্তিক সফ্টওয়্যার সিস্টেমের জন্য লেখার জন্য গ্রানুলারিটি, সুযোগ এবং পরীক্ষার সংখ্যার জন্য আরেকটি ভিজ্যুয়াল সাদৃশ্য। তাদের ছোট আকারের কারণে, একটি মাইক্রোসার্ভিসের মধ্যে সবচেয়ে গুরুত্বপূর্ণ জটিলতাটি নিজেই পরিষেবার মধ্যে নয়, তবে এটি কীভাবে অন্যদের সাথে যোগাযোগ করে তাতে। সুতরাং একটি মাইক্রোসার্ভিসের জন্য একটি পরীক্ষার কৌশল প্রাথমিকভাবে ইন্টিগ্রেশন পরীক্ষার উপর ফোকাস করা উচিত।
এই আকৃতিটি আমাদের একটি মৌচাকের কথা মনে করিয়ে দেয়, এইভাবে নাম। এটিতে নিম্নলিখিত স্তর রয়েছে:
- সমন্বিত পরীক্ষা । স্পটিফাইয়ের নিবন্ধটি এই স্তরটিকে সংজ্ঞায়িত করতে জেবি রেইনসবার্গারের একটি উদ্ধৃতি ব্যবহার করে: "একটি পরীক্ষা যা অন্য সিস্টেমের সঠিকতার উপর ভিত্তি করে পাস বা ব্যর্থ হবে।" এই ধরনের পরীক্ষাগুলির বাহ্যিক নির্ভরতা রয়েছে যা আপনাকে বিবেচনা করতে হবে, এবং বিপরীতে, আপনার সিস্টেম এমন একটি নির্ভরতা হতে পারে যা অন্যান্য সিস্টেমকে ভেঙে দেয়। অন্যান্য উপমায় E2E পরীক্ষাগুলির মতো, এই পরীক্ষাগুলি সাবধানে ব্যবহার করুন, শুধুমাত্র সবচেয়ে প্রয়োজনীয় ক্ষেত্রে।
- ইন্টিগ্রেশন পরীক্ষা । অন্যান্য অভিযোজনগুলির মতো, আপনার এই স্তরটিতে ফোকাস করা উচিত। এটিতে পরীক্ষা রয়েছে যা আরও বিচ্ছিন্ন ফ্যাশনে আপনার পরিষেবার সঠিকতা যাচাই করে, তবে এখনও অন্যান্য পরিষেবাগুলির সাথে একত্রিত হয়৷ এর মানে হল পরীক্ষাগুলি কিছু অন্যান্য সিস্টেমকেও অন্তর্ভুক্ত করবে এবং ইন্টারঅ্যাকশন পয়েন্টগুলিতে ফোকাস করবে, উদাহরণস্বরূপ, API পরীক্ষার মাধ্যমে।
- বাস্তবায়ন বিস্তারিত পরীক্ষা . এই পরীক্ষাগুলি ইউনিট পরীক্ষার অনুরূপ-পরীক্ষা যা কোডের এমন অংশগুলিতে ফোকাস করে যা স্বাভাবিকভাবে বিচ্ছিন্ন এবং এইভাবে তাদের নিজস্ব অভ্যন্তরীণ জটিলতা রয়েছে।
আপনি যদি এই পরীক্ষার কৌশল সম্পর্কে আরও জানতে চান, মার্টিন ফাউলারের মৌচাকের সাথে পরীক্ষার পিরামিডের তুলনা করে এমন পোস্টটি এবং Spotify-এর মূল নিবন্ধটি দেখুন।
টেস্টিং ট্রফি
আপনি ইতিমধ্যেই ইন্টিগ্রেশন পরীক্ষায় একটি পুনরাবৃত্তি ফোকাস দেখতে পারেন। যাইহোক, আগের প্রবন্ধে আপনি যে আরেকটি ধরণ দেখেছেন তা তত্ত্বে পরীক্ষা করা নয় তবে এটি এখনও একটি গুরুত্বপূর্ণ দিক যা আপনাকে একটি পরীক্ষার কৌশলে বিবেচনা করা উচিত। পরীক্ষার পিরামিড থেকে স্ট্যাটিক বিশ্লেষণ অনুপস্থিত এবং আপনি এখন পর্যন্ত দেখা বেশিরভাগ অভিযোজনে। টেস্টিং ট্রফি অভিযোজন রয়েছে যা একীকরণ পরীক্ষায় ফোকাস বজায় রাখার সময় স্ট্যাটিক বিশ্লেষণকে বিবেচনায় নেয়। টেস্টিং ট্রফিটি গুইলারমো রাউচের পূর্বের উদ্ধৃতি থেকে উদ্ভূত হয়েছিল এবং কেন্ট সি ডডস দ্বারা বিকাশিত হয়েছিল:
টেস্টিং ট্রফি হল একটি সাদৃশ্য যা পরীক্ষার গ্রানুলারিটিকে কিছুটা ভিন্নভাবে চিত্রিত করে। এটির চারটি স্তর রয়েছে:
- স্ট্যাটিক বিশ্লেষণ । এটি এই সাদৃশ্যে একটি গুরুত্বপূর্ণ ভূমিকা পালন করে এবং আপনাকে টাইপো, শৈলীর ভুল এবং অন্যান্য বাগগুলিকে শুধুমাত্র ইতিমধ্যেই বর্ণিত ডিবাগিং পদক্ষেপগুলি চালানোর মাধ্যমে ধরতে দেয়৷
- ইউনিট পরীক্ষা । তারা নিশ্চিত করে যে আপনার ক্ষুদ্রতম ইউনিটটি যথাযথভাবে পরীক্ষা করা হয়েছে, কিন্তু পরীক্ষার ট্রফি তাদের পরীক্ষা পিরামিডের মতো একই পরিমাণে জোর দেবে না।
- মিশ্রণ . এটি প্রধান ফোকাস কারণ এটি অন্যান্য অভিযোজনের মতো সর্বোত্তম উপায়ে খরচ এবং উচ্চতর আত্মবিশ্বাসের ভারসাম্য বজায় রাখে।
- UI পরীক্ষা । E2E এবং ভিজ্যুয়াল পরীক্ষা সহ, তারা টেস্টিং ট্রফির শীর্ষে রয়েছে, টেস্ট পিরামিডে তাদের ভূমিকার মতো।
টেস্টিং ট্রফি সম্পর্কে আরও পড়তে, এই বিষয়ে কেন্ট সি ডডসের ব্লগ পোস্টটি দেখুন।
আরও কিছু UI-কেন্দ্রিক পন্থা
এটি সবই ভাল এবং ভাল তবে আপনি আপনার কৌশলটিকে "পিরামিড", "মধুচক্র" বা "হীরা" যেভাবেই বলুন না কেন, এখনও কিছু অনুপস্থিত রয়েছে। যদিও পরীক্ষা অটোমেশন মূল্যবান, এটা মনে রাখা গুরুত্বপূর্ণ যে ম্যানুয়াল টেস্টিং এখনও অপরিহার্য। স্বয়ংক্রিয় পরীক্ষার রুটিন কাজগুলি কমানো উচিত এবং মানের নিশ্চয়তা ইঞ্জিনিয়ারদের গুরুত্বপূর্ণ ক্ষেত্রগুলিতে ফোকাস করার জন্য মুক্ত করা উচিত। ম্যানুয়াল টেস্টিং প্রতিস্থাপনের পরিবর্তে, অটোমেশন এর পরিপূরক হওয়া উচিত। সর্বোত্তম ফলাফলের জন্য অটোমেশনের সাথে ম্যানুয়াল টেস্টিংকে সংহত করার একটি উপায় আছে কি?
বরফ শঙ্কু পরীক্ষা করা এবং কাঁকড়া পরীক্ষা করা
প্রকৃতপক্ষে পরীক্ষার পিরামিডের দুটি অভিযোজন রয়েছে যা পরীক্ষার এই UI-কেন্দ্রিক উপায়গুলিতে আরও ফোকাস করে। উভয়েরই উচ্চ আত্মবিশ্বাসের সুবিধা রয়েছে, তবে ধীরগতির পরীক্ষা সম্পাদনের কারণে স্বাভাবিকভাবেই বেশি ব্যয়বহুল।
প্রথমটি, পরীক্ষার বরফ শঙ্কু, দেখতে পিরামিডের বিপরীতে। ম্যানুয়াল টেস্টিং স্টেপ ছাড়া, এটি টেস্টিং পিৎজা নামেও পরিচিত।
বরফ শঙ্কু ম্যানুয়াল বা UI পরীক্ষার উপর বড় ফোকাস এবং ইউনিট পরীক্ষার উপর সবচেয়ে কম ফোকাস আছে। এটি প্রায়শই এমন প্রকল্পগুলিতে রূপ নেয় যেখানে বিকাশকারীরা পরীক্ষার কৌশল নিয়ে শুধুমাত্র কয়েকটি চিন্তাভাবনা নিয়ে কাজ শুরু করে। বরফ কোড একটি বিরোধী প্যাটার্ন হিসাবে বিবেচিত এবং সঠিকভাবে তাই. সম্পদ এবং ম্যানুয়াল কাজের পরিপ্রেক্ষিতে এটি ব্যয়বহুল।
টেস্ট ক্র্যাব টেস্ট বরফের শঙ্কুর মতই, কিন্তু E2E এবং ভিজ্যুয়াল টেস্টিং এর উপর আরো জোর দিয়ে:
এই পরীক্ষার কৌশলটিতে আরও একটি দিক রয়েছে: এটি যাচাই করে যে আপনার অ্যাপ্লিকেশন ফাংশন এবং ভাল দেখাচ্ছে। টেস্টিং ক্র্যাব ভিজ্যুয়াল পরীক্ষার গুরুত্ব তুলে ধরে, যা পূর্ববর্তী নিবন্ধে সংজ্ঞায়িত করা হয়েছে। ইন্টিগ্রেশন টেস্টিং, কম্পোনেন্ট এবং এপিআই টেস্টিং-এ বিভক্ত, আরও পটভূমিতে চলে যায় এবং ইউনিট টেস্টিং এখানে আরও বেশি গৌণ ভূমিকা পালন করে। টেস্টিং ক্র্যাবের এই নিবন্ধে আপনি এই পরীক্ষার কৌশল সম্পর্কে আরও বিশদ জানতে পারেন।
আরও ব্যয়বহুল হওয়া সত্ত্বেও, এই দুটি পরীক্ষার কৌশলগুলির তাদের জায়গা রয়েছে: উদাহরণস্বরূপ, ছোট প্রকল্পগুলিতে যেখানে কম পরীক্ষা প্রয়োজন, বা কম জটিলতা কভার করা প্রয়োজন। এই ক্ষেত্রে, ইন্টিগ্রেশন টেস্টিং-এর উপর ফোকাস করে একটি পূর্ণ-বিকশিত পরীক্ষার কৌশল ওভার-ইঞ্জিনিয়ার করা হতে পারে।
যদিও এই দুটি পরীক্ষার কৌশল আরও ব্যয়বহুল, তবে তাদের জায়গা রয়েছে, উদাহরণস্বরূপ, ছোট প্রকল্পগুলিতে যেগুলির জন্য কম পরীক্ষা প্রয়োজন এবং অনেক জটিলতা কভার করার প্রয়োজন নেই৷ এই ক্ষেত্রে, ইন্টিগ্রেশন পরীক্ষার উপর দৃষ্টি নিবদ্ধ একটি পূর্ণ স্কেল পরীক্ষার কৌশল অপ্রয়োজনীয়ভাবে জটিল হতে পারে।
ব্যবহারিক পরামর্শ: এর কৌশল!
আপনি এখন সবচেয়ে সাধারণ পরীক্ষার কৌশল সম্পর্কে শিখেছেন। আপনি ক্লাসিক দিয়ে শুরু করেছেন—পরীক্ষা পিরামিড—এবং এর অনেক অভিযোজন জানতে পেরেছেন। এখন আপনাকে আপনার পণ্যের জন্য তাদের মূল্যায়ন করতে হবে এবং আপনার প্রকল্পের জন্য কোনটি সেরা হবে তা নির্ধারণ করতে হবে। এই প্রশ্নের উত্তর সবার প্রিয় " এটা নির্ভর করে " দিয়ে শুরু করা উচিত। যে এটা কোনো কম সঠিক না যদিও.
বর্ণিতদের থেকে সবচেয়ে উপযুক্ত পরীক্ষার কৌশল বেছে নেওয়া—এবং এমনকি যেগুলি বাদ দেওয়া হয়েছে—আপনার আবেদনের উপর নির্ভর করে৷ এটা আপনার স্থাপত্য, আপনার প্রয়োজনীয়তা, এবং শেষ কিন্তু অন্তত নয়, আপনার ব্যবহারকারীদের এবং তাদের প্রয়োজনীয়তা স্থির করা উচিত। এই সব অ্যাপ্লিকেশন থেকে অ্যাপ্লিকেশন ভিন্ন হতে পারে. এটা সম্পূর্ণ স্বাভাবিক। মনে রাখবেন যে আপনার সবচেয়ে গুরুত্বপূর্ণ লক্ষ্য হল আপনার ব্যবহারকারীদের পরিবেশন করা, পাঠ্যপুস্তকের সংজ্ঞা নয়।
প্রায়শই, বাস্তব-বিশ্বের পরীক্ষাগুলি পৃথকভাবে পৃথক করা এবং সংজ্ঞায়িত করা কঠিন। এমনকি মার্টিন ফাউলার নিজেও ভিন্ন ভিন্ন সংজ্ঞার ইতিবাচক দিকটির উপর জোর দিয়েছেন, যেমন ইউনিট পরীক্ষার ক্ষেত্রে। জাস্টিন সির্লস তার টুইটে সঠিকভাবে বলেছেন:
[...] অভিব্যক্তিপূর্ণ পরীক্ষা লিখুন যা স্পষ্ট সীমানা স্থাপন করে, দ্রুত এবং নির্ভরযোগ্যভাবে চালায় এবং শুধুমাত্র দরকারী কারণে ব্যর্থ হয়।
জাস্টিন সির্লস দ্বারা
সেই পরীক্ষাগুলিতে ফোকাস করুন যা ব্যবহারকারীদের সম্মুখীন হতে পারে এমন প্রকৃত ত্রুটিগুলি রিপোর্ট করে এবং আপনার লক্ষ্য থেকে বিভ্রান্ত হবেন না। পরীক্ষাগুলি ব্যবহারকারীর সুবিধার জন্য ডিজাইন করা উচিত, শুধুমাত্র 100% কভারেজ প্রদান করা নয় বা কোন শতাংশ পরীক্ষার ধরন লিখতে হবে তা নিয়ে বিতর্ক করা উচিত নয়।
আপনার ব্যবহারকারীরা সম্মুখীন হতে পারে এবং আপনার লক্ষ্য থেকে বিভ্রান্ত না হতে পারে এমন বাস্তব জীবনের ত্রুটিগুলি রিপোর্ট করে এমন পরীক্ষাগুলিতে ফোকাস করুন৷ পরীক্ষাগুলি ব্যবহারকারীর সুবিধার জন্য ডিজাইন করা উচিত, শুধুমাত্র 100% কভারেজ প্রদান না করে বা কোন নির্দিষ্ট পরীক্ষার ধরণের কত শতাংশ লিখতে হবে তা নিয়ে বিতর্ক তৈরি করা উচিত নয়।