কেন প্রোগ্রামারদের পরীক্ষার প্রয়োজন?
পরবর্তী কয়েকটি স্তর প্রোগ্রামারদের যেভাবে প্রয়োজন তা পরীক্ষা করার জন্য নিবেদিত হবে । তবে প্রথমে, আসুন জেনে নেওয়া যাক পরীক্ষা কী এবং কেন এটি প্রয়োজন।
সফ্টওয়্যার সম্পর্কে, আমরা বলতে পারি যে পরীক্ষার কাজটি হল প্রোগ্রামটি পরীক্ষা করা:
- তার যা করতে হয় তা করে
- তার যা করা উচিত নয় তা করে না
দ্বিতীয় পয়েন্ট, যাইহোক, প্রথমটির চেয়ে কম গুরুত্বপূর্ণ নয়, তবে পরে আরও বেশি।
প্রথম পয়েন্ট দিয়ে শুরু করা যাক। "প্রোগ্রামটি যা করার কথা তা করে" এর অর্থ কী?
প্রথমত, কাউকে প্রোগ্রামের জন্য সমস্ত ব্যবহারের ক্ষেত্রে একটি তালিকা তৈরি করতে হবে। দ্বিতীয়ত, তারা বর্ণনা করতে হবে কিভাবে প্রোগ্রাম কাজ করা উচিত, কিভাবে ব্যবহারকারীর আচরণ করা উচিত, এবং কি ফলাফল প্রত্যাশিত। আপনি আর চালিয়ে যেতে পারবেন না।
আমরা "ব্যবহারকারীর কীভাবে আচরণ করা উচিত" লেখার সাথে সাথেই ভাল ডকুমেন্টেশন লেখার পুরো ধারণাটি ভেঙে পড়ে। মানুষ মেশিন নয়, তদুপরি, লোকেরা প্রায়শই সফ্টওয়্যারের সাথে তাদের পছন্দ মতো আচরণ করে । নির্দেশাবলী অধ্যয়ন করে কেউ প্রযুক্তির সাথে তাদের পরিচিতি শুরু করে না। এটা একটা বাস্তবতা।
অতএব, আমরা একটি নতুন তথ্য পেয়েছি: সফ্টওয়্যারটির বিশেষত্ব হল এটিতে অনেকগুলি ভিন্ন কাজের দৃশ্য রয়েছে৷ তাদের মধ্যে কিছু সুস্পষ্ট, অন্যগুলি নথিভুক্ত করা যেতে পারে, অন্যগুলি অনুমান করা যেতে পারে, অন্যগুলি অনুমান করা যেতে পারে এবং অন্য 50% এমনকি আপনার কাছে ঘটবে না।
প্রোগ্রামারের দৃষ্টিকোণ থেকে, বেশিরভাগ বাগগুলি মোটেই বাগ নয়। একটি ত্রুটি যখন একটি প্রোগ্রাম এটি উচিত বা প্রত্যাশিত হিসাবে কাজ না. এবং এমন অনেক পরিস্থিতি রয়েছে যখন প্রোগ্রামটি কীভাবে কাজ করা উচিত তা স্পষ্ট নয়, বা পরিস্থিতি যা একে অপরের সাথে বিরোধিতা করে ...
একটি অসীম সংখ্যক পরিস্থিতি রয়েছে এবং পণ্যটিতে সর্বদা এমন কিছু ঘটনা থাকবে যখন প্রোগ্রামটি আশানুরূপ আচরণ করে না (প্রোগ্রামার মাত্র কয়েক ডজন পরিস্থিতির জন্য কোড লিখেছিলেন)। অতএব, এটি যুক্তি দেওয়া যেতে পারে যে কোনও প্রোগ্রামে সর্বদা বাগ থাকে এবং যে কোনও পণ্য অবিরামভাবে উন্নত করা যেতে পারে ।
এর পরে, এটি সমস্ত সুবিধার জন্য নেমে আসে। প্রথমে, প্রোগ্রামার সবচেয়ে বড় বাগগুলি ঠিক করে, তারপরে ছোট বাগগুলি এবং আরও অনেক কিছু। এবং অবশেষে, একটি পর্যায়ে আসে যখন পণ্যের মালিক বিশ্বাস করেন যে এটিতে কাজ চালিয়ে যাওয়া অর্থনৈতিকভাবে সম্ভব নয়।
কিন্তু সেই ত্রুটিগুলিতে ফিরে আসি যেগুলিকে সবাই ত্রুটি হিসাবে স্বীকৃতি দেয়: প্রোগ্রামটি স্পষ্টতই কিছু ভুল করে, পড়ে গেছে, কিছু ভেঙে গেছে ইত্যাদি। এই ধরনের ত্রুটিগুলি শর্তসাপেক্ষে 3টি বিভাগে ভাগ করা যেতে পারে: বড়, মাঝারি এবং ছোট।
এবং প্রায়শই এটি ঘটে যে একজন প্রোগ্রামার মাঝারি বা এমনকি ছোট বাগগুলি ঠিক করার জন্য কাজ করছেন, যদিও প্রকল্পে এখনও অনেক গুরুতর সমস্যা রয়েছে। সে শুধু সেগুলি খুঁজে পায়নি , তাই সে সবচেয়ে বড় বিষয়ে কাজ করছে যার সম্পর্কে সে জানে৷
অতএব, যে কোনও প্রকল্পে পরীক্ষক থাকা উচিত। এই লোকেরা বিশেষভাবে বিভিন্ন কোণ থেকে পণ্য দেখতে শিখে. তাই আপনি প্রোগ্রামের আরো দৃশ্যকল্প দেখতে পারেন. তাদের কাজ হল ত্রুটিগুলি খুঁজে বের করা এবং সেগুলি লিখে রাখা (যাতে একই ত্রুটি একাধিকবার খুঁজে না পাওয়া যায়)।
পরীক্ষা একটি প্রক্রিয়া যা ত্রুটি খুঁজে বের করার লক্ষ্যে। এই বাগ খুঁজে পাওয়া উচিত, বর্ণনা এবং অগ্রাধিকার. ত্রুটিগুলির অগ্রাধিকার দেওয়ার পরেই আমরা একটি কার্যকর সফ্টওয়্যার উন্নতি প্রক্রিয়া সম্পর্কে কথা বলতে পারি।
মনে রাখবেন, একটি সমস্যা সমাধানের প্রথম ধাপ হল একটি সমস্যা আছে তা স্বীকার করা । আপনি যে ভুল সম্পর্কে জানেন না তা ঠিক করতে পারবেন না।
পরীক্ষা অটোমেশন
আমি মনে করি আমরা সবাই একমত যে পরীক্ষা করা গুরুত্বপূর্ণ, তাই আসুন প্রোগ্রামারদের মতো পরীক্ষা করা যাক। প্রোগ্রামাররা কিভাবে পরীক্ষা দেখেন? প্রোগ্রামাররা অন্য মানুষের কাজ স্বয়ংক্রিয় করে। অদৃশ্য হয়ে যাওয়া শেষ পেশা হবে প্রোগ্রামিং পেশা।
আমরা যে কোন প্রক্রিয়ার সম্মুখীন হই তা স্বয়ংক্রিয়ভাবে করি। তাই পরীক্ষা স্বয়ংক্রিয় হওয়া দরকার। এবং কিভাবে ত্রুটির জন্য অনুসন্ধান স্বয়ংক্রিয়? সংক্ষিপ্ত উত্তর: না। কিন্তু এখানে আবার সত্য যে আমরা প্রোগ্রামার আমাদের সাহায্য আসে.
সফ্টওয়্যার উন্নয়ন প্রক্রিয়া এটি ধ্রুবক পরিবর্তন গঠিত. শুধুমাত্র ক্রমাগত পরিবর্তন করার প্রক্রিয়ার মধ্যে, প্রোগ্রামাররা প্রায়শই এমন কিছু ভেঙে ফেলে যা সম্প্রতি পর্যন্ত ভাল কাজ করেছিল।
এবং পরীক্ষকরা, নতুন ত্রুটিগুলি সন্ধান করার পরিবর্তে, ক্রমাগত পরীক্ষা করতে বাধ্য হন যে আমরা এমন কিছু ভেঙেছি কিনা যা দীর্ঘদিন ধরে ভাল কাজ করছে। তথাকথিত রিগ্রেশন টেস্টিং। এটি এই ধরণের পরীক্ষা যা স্বয়ংক্রিয় হতে পারে এবং হওয়া উচিত।
এখানে সমস্ত সফ্টওয়্যার দুটি ভাগে ভাগ করা যেতে পারে:
- প্রোগ্রামটি ব্যক্তির সাথে যোগাযোগ করে
- প্রোগ্রাম অন্য প্রোগ্রামের সাথে যোগাযোগ করে
প্রথম বিকল্পটি স্বয়ংক্রিয় করা আরও কঠিন, এটির জন্য বিশেষ অটোমেটর পরীক্ষক প্রয়োজন, তাদের QA অটোমেশন বা সফ্টওয়্যার টেস্ট ইঞ্জিনিয়ারও বলা হয়।
কিন্তু দ্বিতীয় বিকল্পটি স্বাধীনভাবে স্বয়ংক্রিয় হতে পারে এবং করা উচিত। আপনার যদি এমন একটি সফ্টওয়্যার থাকে যা:
- ভাল কাজ করে
- ইতিমধ্যে পরীক্ষিত
- একটি পৃথক মডিউল বা লজিক্যাল ব্লক হিসাবে প্রয়োগ করা হয়
- পরিবর্তন করার পরিকল্পনা নেই
- অন্যান্য মডিউল বা প্রোগ্রাম এটির উপর নির্ভর করে
- কার্যকরী ব্যর্থতা ব্যয়বহুল
আমি এটির জন্য পরীক্ষা লিখতে সময় নেওয়ার পরামর্শ দিই যা এটির বর্তমান কার্যকারিতার মূল দিকগুলি ক্যাপচার করে। এটির জন্য আপনার কাজের সময়ের 5% বা প্রতি মাসে 1 দিন বরাদ্দ করা যুক্তিসঙ্গত হবে।
পরীক্ষার খাতিরে পরীক্ষা লিখতে হবে না।
কেউ আপনার পরীক্ষা সমর্থন করবে না. অন্য প্রোগ্রামার না, নিজেকে না. কেউ তা করে না। সমস্ত লিখিত পরীক্ষার 99% পরিত্যক্ত এবং/অথবা অক্ষম। পরীক্ষা-নিরীক্ষা লিখতে না পারলে লিখবেন না। আপনি তাদের ছাড়া একেবারে করতে না পারলেই লিখুন।
পরীক্ষার প্রকারভেদ
প্রতিটি প্রোগ্রামার, যদি সে বিশেষ প্রশিক্ষণ না নিয়ে থাকে, তবে পরীক্ষাটি কী তা তার নিজের ভাষায় বলতে সক্ষম হবে: প্রোগ্রামটি যা করা উচিত তা করে কিনা তা পরীক্ষা করা। যাইহোক, এই ক্ষেত্রের পেশাদাররা পরীক্ষার পুরো এলাকা (প্রকার) আলাদা করে।
সমস্ত পরীক্ষা সত্যিই সফ্টওয়্যারের নির্ভরযোগ্যতা এবং উপলব্ধতার চারপাশে ঘোরে, তবে পরীক্ষার দিকটি আরও ভালভাবে বোঝার জন্য, আসুন কয়েকটি উদাহরণ দেখি।
ধরা যাক আপনি একটি সাধারণ অনলাইন স্টোর পরীক্ষা করছেন। তারপর পরীক্ষার ক্ষেত্রগুলিকে নিম্নলিখিত প্রকারে ভাগ করা যেতে পারে: কর্মক্ষমতা পরীক্ষা, কার্যকরী পরীক্ষা, ইন্টিগ্রেশন পরীক্ষা এবং ইউনিট পরীক্ষা।
যদি সাইটের মালিক একটি গুরুতর বিজ্ঞাপন প্রচারাভিযান চালু করার সিদ্ধান্ত নেন, তবে একই সময়ে প্রচুর ব্যবহারকারী সাইটে আসবেন। এটি ভাল হতে পারে যে সাইটটি পড়বে না, তবে এর কিছু বিভাগ ধীর হতে পারে বা এমনকি কাজ বন্ধ করে দিতে পারে।
এটি যাতে না ঘটে তার জন্য, আপনাকে এই জাতীয় সমস্যাগুলি আগে থেকেই চিহ্নিত করতে হবে এবং সেগুলি দূর করার জন্য পদক্ষেপ নিতে হবে। এটি লোড টেস্টিং ব্যবহার করে করা হয় , বা এটিকে কর্মক্ষমতা পরীক্ষাও বলা হয়।
আপনি আপনার ব্যাকএন্ড API কীভাবে কাজ করে তা পরীক্ষা করতে এবং এর প্রতিটি ফাংশন পরীক্ষা করতে চাইতে পারেন: নিবন্ধন, লগইন, কার্টে যোগ, অর্থপ্রদান প্রক্রিয়াকরণ, ডাটাবেস লেখা ইত্যাদি। সবকিছুই TOR অনুযায়ী কাজ করা উচিত। এই ক্ষেত্রে, আপনাকে কার্যকরী পরীক্ষা করতে হবে ।
আপনার অনলাইন স্টোর সম্ভবত তৃতীয় পক্ষের পরিষেবাগুলির সাথে একত্রিত হয়েছে: চিঠি এবং এসএমএস পাঠানো, পেমেন্ট সিস্টেম, অনলাইন সহায়তা চ্যাট, ব্যবহারকারীদের কাছ থেকে প্রতিক্রিয়া সংগ্রহ করা, বিজ্ঞাপন সিস্টেম ইত্যাদি .
অবশেষে, জটিল পণ্যগুলি প্রায়শই স্বাধীন মডিউলগুলিতে বিভক্ত হয়। এই ধরনের মডিউল থেকে, আপনি চূড়ান্ত পণ্য একত্রিত করতে পারেন, যেমন একটি কনস্ট্রাক্টর থেকে। আপনি যদি এই জাতীয় মডিউল তৈরি করেন বা এই জাতীয় মডিউলগুলির সাথে ইন্টারঅ্যাক্ট করেন তবে আপনাকে ইউনিট পরীক্ষা করতে হবে ।
সংক্ষেপে, আমরা বলতে পারি যে সাইটের প্রতিটি পৃথক ফাংশন পরীক্ষা করার জন্য কার্যকরী পরীক্ষার প্রয়োজন। ইন্টিগ্রেশন - আপনার পণ্যের বড় মডিউল এবং সিস্টেমের মিথস্ক্রিয়া পরীক্ষা করার জন্য। মডুলার - একটি পৃথক মডিউল পরীক্ষা করতে, ভাল, কর্মক্ষমতা পরীক্ষা - লোডের অধীনে আপনার সাইটের অপারেশন পরীক্ষা করতে।
আরও বেশি ধরনের পরীক্ষা হতে পারে: পণ্য যত জটিল, তার বিকাশের আরও দিকগুলি নিয়ন্ত্রণ করা প্রয়োজন।
GO TO FULL VERSION