পরীক্ষার কৌশল

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

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

• যত তাড়াতাড়ি সম্ভব সমস্যাগুলো চিহ্নিত করে।
• দ্রুত সম্পাদন করে।
• কখন কোনো কিছু মেরামত করা প্রয়োজন, তা সুস্পষ্ট ইঙ্গিত দেয়।

এই পৃষ্ঠাটি আপনাকে সিদ্ধান্ত নিতে সাহায্য করবে যে কী ধরনের পরীক্ষা প্রয়োগ করতে হবে, কোথায় সেগুলো চালাতে হবে এবং কত ঘন ঘন চালাতে হবে।

android skills add --skill testing-setup

পরীক্ষার পিরামিড

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

ফিডেলিটি বলতে টেস্ট রানটাইম এনভায়রনমেন্টের সাথে প্রোডাকশন এনভায়রনমেন্টের সাদৃশ্যকে বোঝায়।

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

একটি বাগের খরচ কমানো

একটি ভালো টেস্টিং কৌশল ডেভেলপারদের উৎপাদনশীলতা বাড়ায় এবং বাগ খুঁজে বের করার খরচ কমিয়ে আনে।

সম্ভবত একটি অদক্ষ কৌশলের উদাহরণ বিবেচনা করুন। এখানে, আকার অনুযায়ী টেস্টের সংখ্যা একটি পিরামিডের মতো বিন্যস্ত হয় না। এখানে অনেক বেশি বড় এন্ড-টু-এন্ড টেস্ট এবং খুব কম কম্পোনেন্ট UI টেস্ট রয়েছে:

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

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

• ইউনিট টেস্টের মাধ্যমে বাগ ধরা পড়লে, তা সাধারণত কয়েক মিনিটের মধ্যেই ঠিক হয়ে যায়, তাই এর খরচ কম।
• একটি এন্ড-টু-এন্ড টেস্টে একই বাগ খুঁজে বের করতে কয়েক দিন সময় লেগে যেতে পারে। এর ফলে দলের একাধিক সদস্য এতে জড়িত হতে পারেন, যা সামগ্রিক উৎপাদনশীলতা কমিয়ে দেয় এবং রিলিজ বিলম্বিত করতে পারে। এই বাগের কারণে হওয়া খরচও বেশি।

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

একটি পরিমাপযোগ্য পরীক্ষার কৌশল

ঐতিহ্যগতভাবে টেস্টিং পিরামিডকে ৩টি বিভাগে বিভক্ত করা হয়েছে:

• ইউনিট পরীক্ষা
• ইন্টিগ্রেশন পরীক্ষা
• এন্ড-টু-এন্ড টেস্ট।

তবে, এই ধারণাগুলোর কোনো সুনির্দিষ্ট সংজ্ঞা নেই, তাই দলগুলো তাদের বিভাগগুলোকে ভিন্নভাবে সংজ্ঞায়িত করতে চাইতে পারে, উদাহরণস্বরূপ ৫টি স্তর ব্যবহার করে:

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

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

পরীক্ষার বিভাগ নির্ধারণ করুন

একটি সাধারণ নিয়ম হিসাবে, আপনার পিরামিডের সর্বনিম্ন স্তরটি বিবেচনা করা উচিত যা দলকে সঠিক মাত্রার প্রতিক্রিয়া দিতে পারে।

উদাহরণস্বরূপ, এই ফিচারটির বাস্তবায়ন কীভাবে পরীক্ষা করা যায় তা বিবেচনা করুন: একটি সাইন-ইন ফ্লো-এর ইউআই। আপনাকে কী পরীক্ষা করতে হবে তার উপর নির্ভর করে আপনি বিভিন্ন ক্যাটাগরি বেছে নেবেন:

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

মনে রাখবেন যে, পরীক্ষার বিভাগ পরীক্ষার ধরন নির্ধারণ করে না এবং সব বৈশিষ্ট্য প্রতিটি বিভাগে পরীক্ষা করার প্রয়োজন নেই।

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

পরীক্ষার পরিকাঠামো

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

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

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

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