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

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

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

• সমস্যা যত তাড়াতাড়ি সম্ভব শনাক্ত করে।
• দ্রুত এক্সিকিউট করে।
• কোনও কিছু ঠিক করতে হলে, তা স্পষ্ট করে জানায়।

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

android skills add testing-setup

টেস্টিং পিরামিড

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

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

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

বাগ সংক্রান্ত খরচ কমানো

ভালো টেস্টিং স্ট্র্যাটেজি ডেভেলপারদের প্রোডাক্টিভিটি সর্বাধিক করে তোলে এবং বাগ খুঁজে বের করার খরচ কমিয়ে দেয়।

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

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

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

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

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

পরীক্ষার একটি স্কেলেবল স্ট্র্যাটেজি

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

• ইউনিট টেস্ট
• ইন্টিগ্রেশন টেস্ট
• এন্ড-টু-এন্ড টেস্ট।

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

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

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

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

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

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

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

মনে রাখবেন, পরীক্ষার বিভাগ পরীক্ষার ধরন নির্ধারণ করে না এবং প্রতিটি বিভাগে সব ফিচার পরীক্ষা করতে হবে না।

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

টেস্ট পরিকাঠামো

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

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

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

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