কখনো software টেস্ট করেননি? এবার নিজের AI দিয়ে বানানো app যেভাবে টেস্ট করবেন
QA-র কোনো অভিজ্ঞতা ছাড়াই একটি AI দিয়ে বানানো app টেস্ট করার একটি বাস্তব গাইড। কোথায় ক্লিক করবেন, কোনটা ইচ্ছে করে ভাঙবেন, আর শেয়ার করার মতো যথেষ্ট ভালো হয়েছে কি না কীভাবে বুঝবেন।
আপনি AI দিয়ে একটা app বানিয়েছেন। happy path-এ এটা কাজ করছে — আপনি নিজের নাম টাইপ করেন, বোতামে ক্লিক করেন, সাকসেস স্ক্রিন দেখেন। এখন কী? আপনার তিনজন বিটা ইউজারের কাছে পাঠানোর জন্য কি এটা প্রস্তুত? আপনার টিমের কাছে? আপনার কাস্টমারদের কাছে?
আপনার যদি software-এর ব্যাকগ্রাউন্ড না থাকে, তাহলে টেস্টিং মনে হয় সেই ধরনের কাজগুলোর একটা যা “আসল ডেভেলপাররা” করেন — framework, assertion আর CI pipeline দিয়ে। ভালো খবর: বেশিরভাগ টেস্টিং আসলে ওটা নয়। বেশিরভাগ টেস্টিং, বিশেষ করে যখন আপনি ছোট আর নতুন কিছু শিপ করছেন, তা হলো একজন মানুষ উদ্দেশ্য নিয়ে ঘুরে ঘুরে ক্লিক করা। ওটা আপনি পারবেন। এই লেখাটা সেই কাজটা ইচ্ছে করে করার বিষয়ে, যাতে আপনার ইউজাররা বাগ খুঁজে পাওয়ার আগেই আপনি সেগুলো খুঁজে পান।
লক্ষ্যটা হলো না যে আপনি প্রো-দের মতো আপনার AI দিয়ে বানানো app টেস্ট করবেন। লক্ষ্যটা হলো এমন একজন প্যারানয়েড বন্ধুর মতো টেস্ট করা, যে সত্যিকারভাবে চায় এটা কাজ করুক।
দুই-লিস্টের কৌশল
কিছুতে ক্লিক করার আগে একটা ফাঁকা ডকে দশ মিনিট বসে দুটো লিস্ট লিখুন।
লিস্ট A — happy path-গুলো। একজন ইউজার এই app দিয়ে যা যা করার কথা, তেমন তিন-চারটে জিনিস কী? সাধারণ একটা SaaS-এর জন্য সেটা হতে পারে: সাইন আপ করা, প্রথম প্রজেক্ট তৈরি করা, একজন টিমমেটকে ইনভাইট করা, একটা রেজাল্ট এক্সপোর্ট করা। ডিরেক্টরি-ধরনের একটা app-এর জন্য: সার্চ করা, ফিল্টার করা, একটা লিস্টিংয়ে ক্লিক করা, সেটা সেভ করা। তিন-চারটে আসল ফ্লো, সহজ ভাষায়।
লিস্ট B — unhappy path-গুলো। ইউজার যদি প্রায়-ঠিক কিন্তু একদম ঠিক নয় এমন কিছু করে? টাইপো-সহ নিজের ইমেইল টাইপ করে। ফ্লো-এর মাঝখানে ব্যাক বোতাম চাপে। দুটো ট্যাব খুলে দুটোতেই একই জিনিস এডিট করে। একটা ফাঁকা ফর্ম সাবমিট করে। একটা Word ডকের কন্টেন্ট — ফরম্যাটিং সমেত — কোনো টেক্সট ফিল্ডে পেস্ট করে। ল্যাপটপ বন্ধ করে দশ মিনিট পর আবার খোলে। সিস্টেমে আগে থেকেই আছে এমন একটা ইমেইল অ্যাড্রেস দিয়ে একজন টিমমেটকে ইনভাইট করার চেষ্টা করে।
happy-path লিস্টটাই হলো আপনার AI app builder যেটার জন্য অপটিমাইজ করেছে। কোড লেখার সময় AI মনে মনে এটাই টেস্ট করেছে। unhappy-path লিস্টটাই হলো যেখানে বাগগুলো লুকিয়ে থাকে, কারণ প্রায় কেউই — না AI, না আপনি যখন প্রম্পট দিচ্ছিলেন — ওই কেসগুলো নিয়ে ভাবছিল না।
আপনি যখন আসলেই টেস্ট করবেন, প্রথমে লিস্ট A ধরে এগিয়ে নিশ্চিত হন যে বেসিক জিনিসগুলো কাজ করছে। তারপর আপনার বেশিরভাগ সময় লিস্ট B-তে দিন। লিস্ট B-তেই আসল মূল্য। লিস্ট B-তেই আপনি বুঝতে পারেন, জিনিসপত্র যখন উল্টোপাল্টা হয় তখন আপনি app-টাকে আসলে কী করতে চান — যা প্রায়ই AI builder-এর সঙ্গে একটা স্পষ্ট করে নেওয়ার আলাপ ঘটায় (“ফর্ম যখন আধাআধি ভরা থাকে, তখন কি সতর্ক করবে নাকি অটোসেভ করবে?”)।
ইচ্ছে করে ভাঙার মতো তিনটে জিনিস
লিস্ট দুটো হয়ে গেলে, এই তিনটে ক্যাটাগরি AI দিয়ে বানানো app-এর বেশিরভাগ আসল বাগ ধরে ফেলে।
ফাঁকা আর অদ্ভুত ইনপুট। ফর্মটা কিছু না ভরে সাবমিট করুন। একটা মাত্র ফিল্ড ভরে সাবমিট করুন। ৫০০ অক্ষরের একটা নাম সাবমিট করুন। ইমোজি দিয়ে একটা নাম সাবমিট করুন। নাম আশা করে এমন একটা ফিল্ডে একটা URL পেস্ট করুন। ইমেইল ফিল্ডে “test” দিয়ে, “test@” দিয়ে, “test@example” দিয়ে, আর “a@b.co” অ্যাড্রেস দিয়ে চেষ্টা করুন — এটা কি বৈধ ছোট ইমেইল গ্রহণ করে? AI app builder প্রায়ই validation যোগ করে, কিন্তু সেই validation দুই দিকেই ভুল হতে পারে — খুব কড়া (আসল ইউজারকে রিজেক্ট করে) কিংবা খুব ঢিলে (আবর্জনা গ্রহণ করে)।
পেছনে আর পাশে যাওয়া। আপনি যদি বাধ্য ট্যুর গ্রুপের মতো সাজানো পথে হাঁটেন, তাহলে বেশিরভাগ app ঠিকঠাক চলে। কেউ একটু ঘুরে দেখতে শুরু করলেই সেগুলো ভেঙে পড়ে। ব্যাক বোতামে ক্লিক করুন। আবার ফরওয়ার্ডে ক্লিক করুন। ফ্লো-এর মাঝখানে পেজ রিফ্রেশ করুন। একই পেজ দুটো ট্যাবে খুলে দুটোতেই এডিট করুন। লগ আউট করে আবার লগ ইন করুন। “undo” বোতাম থাকলে পরপর তিনবার ক্লিক করুন। এগুলো এজ কেস নয়। এগুলোই হলো আসল মানুষ যেভাবে software ব্যবহার করে।
পরবর্তী ডেটা। আপনার app যা বানায় সেটা বানান। একটা প্রজেক্ট, একটা পোস্ট, একটা রেকর্ড, যা-ই হোক। তারপর কাল আবার ফিরে আসুন। সেটা কি এখনো আছে? ফরম্যাটিং টিকে আছে? আপনি যদি এডিট করেন, এডিটটা কি সেভ হয়? আপনি যদি ডিলিট করেন, সেটা কি সত্যিই গায়েব হয়ে যায়, নাকি রিফ্রেশ করলে আবার ফিরে আসে? AI app builder প্রায়ই “create” ফ্লো-টা নিখুঁত করে, কিন্তু ভুলে যায় যে আপনি যা কিছু তৈরি করেন তা টিকে থাকতে হবে আর পরেও এডিটযোগ্য হতে হবে।
“যথেষ্ট ভালো” দেখতে কেমন
আপনি কখনোই আপনার AI দিয়ে বানানো app নিখুঁত করে টেস্ট করতে পারবেন না। Software বড্ড জট-পাকানো আর আপনার সময় বড্ড মূল্যবান। প্রশ্নটা “এটা কি নিখুঁত” নয় — প্রশ্নটা হলো “যাদের সামনে এটা পরের ধাপে রাখব, তাদের জন্য কি এটা যথেষ্ট ভালো”।
এখানে একটা মোটামুটি স্তরবিন্যাস, যা আপনি ধার নিতে পারেন।
ডেমো করার মতো যথেষ্ট ভালো: happy path ক্র্যাশ না করে কাজ করে। বোতামগুলো যেখানে যাওয়ার কথা সেখানে যায়। কিছু কেটে বাদ না দিয়ে আপনি একটা স্ক্রিন রেকর্ডিং দেখাতে পারেন।
বন্ধুসুলভ ইউজারদের জন্য যথেষ্ট ভালো: unhappy path-গুলো ডেটা হারায় না। ফর্ম নীরবে ফেল না করে কী ভুল হয়েছে তা বলে দেয়। পেজ রিফ্রেশ করলে জিনিস ভেঙে পড়ে না। আপনাকে সাহায্যের জন্য মেসেজ না দিয়েই তিনজন বন্ধু এটা ব্যবহার করতে পারে।
পেইং ইউজারদের জন্য যথেষ্ট ভালো: app সেইসব ইউজার সামলায় যাদের আপনি কখনো দেখেননি। তাদের ব্রাউজার, তাদের ডেটা, তাদের অভ্যাস। কোথায় কিছু ভাঙছে তা দেখার একটা উপায় আপনার আছে (বেসিক error tracking-ই যথেষ্ট — আপনার কোনো ফ্যান্সি ড্যাশবোর্ড লাগবে না)। যারা ইতিমধ্যে ব্যবহার করছে তাদের ভেঙে না দিয়েই আপনি ফিক্স করে রিডিপ্লয় করতে পারেন।
বেশিরভাগ বিল্ডার “বন্ধুসুলভ ইউজার” লেভেলে শিপ করে আর তারপর ফিডব্যাক আসতে থাকলে আপগ্রেড করে। এটাই ঠিক। ভুলটা হলো মাঝের ধাপটা বাদ দিয়ে “ডেমো করার মতো যথেষ্ট ভালো” থেকে সোজা “পেইং ইউজারদের জন্য যথেষ্ট ভালো”-তে লাফ দেওয়ার চেষ্টা। বন্ধুসুলভ ইউজাররা সেইসব জিনিস খুঁজে পায় যা আসল ইউজাররাও পেত — কিন্তু তারা সেগুলো নিয়ে রেগে যায় না। এই ফারাকটা কাজে লাগান।
কখন AI-কে আপনার হয়ে টেস্ট করতে বলবেন
আপনার AI app builder টেস্টিংয়ে সাহায্য করতে পারে, কিন্তু আপনি কী চান সে ব্যাপারে আপনাকে নির্দিষ্ট হতে হবে। “Add tests” একটা খারাপ প্রম্পট। এটা এমন কোড জেনারেট করবে যা টেস্টের মতো দেখায় আর সম্ভবত পাসও করে, অথচ আপনি যা নিয়ে চিন্তিত তার কিছুই আসলে চেক করে না। ওই অটোজেনারেটেড টেস্টগুলোর বেশিরভাগই নিশ্চিত করে যে ১+১ এখনো ২।
বরং একটা ভালো প্রম্পট: “আমি একটু আগে ফাঁকা ইমেইল ফিল্ড দিয়ে signup ফর্মটা সাবমিট করার চেষ্টা করেছি আর সেটা ক্র্যাশ করেছে। কোথায় এটা হ্যান্ডেল করা হচ্ছে খুঁজে বের করো আর এমন একটা চেক যোগ করো যা বদলে একটা বন্ধুসুলভ এরর দেখায়।” নির্দিষ্ট বাগ, নির্দিষ্ট ফিক্স, নির্দিষ্ট ফলাফল। AI এই কাজে ভালো। এটা “আমার app-টা যেন বাগ-মুক্ত থাকে তা নিশ্চিত করো”-তে খারাপ, কারণ ওটা কোনো টাস্ক নয় — ওটা একটা শখ।
AI builder-রা আরও যে কাজে ভালো তা হলো আপনার বাগটা রিপ্লে করা। আপনি কী করেছিলেন, কী আশা করেছিলেন আর কী ঘটল — এই তিনটে বর্ণনা করলে builder সাধারণত কোডের ভেতর দিয়ে খুঁজে একটা ফিক্স প্রস্তাব করতে পারে। আপনার যে শৃঙ্খলাটা দরকার, তা হলো ওই তিনটে জিনিস স্পষ্ট করে লিখে রাখার শৃঙ্খলা। শুরুর দিকের বেশিরভাগ বাগ রিপোর্ট হলো “এটা কাজ করছে না”-এর কোনো না কোনো রূপ। বেশিরভাগ ফিক্সযোগ্য বাগ রিপোর্ট হলো “আমি X-এ ক্লিক করেছি, Y আশা করেছি, Z পেয়েছি”।
টেস্টিং মানে শুধু ক্লিক নয়, পড়াও
শেষ একটা কথা। আপনার AI দিয়ে বানানো app-এর প্রতিটি লাইন কোড বুঝতে পারলে তবেই ভালো টেস্ট করতে পারবেন — তা নয়। কিন্তু অন্তত চোখ বুলিয়ে নেওয়া উচিত। AI একটু আগে যে ফাইলটা বদলেছে সেটা খুলুন। এটা যে ফাংশনটা যোগ করেছে সেটা পড়ুন। প্রতিটা কীওয়ার্ডের মানে জানার দরকার নেই — দরকার এটুকু জানা যে ফাংশনটা আপনি যা বলেছিলেন তা-ই করছে বলে মনে হচ্ছে কি না।
AI দিয়ে বানানো অনেক বাগ আসলে “কোড ভাঙা” নয়। সেগুলো হলো “কোড আপনার চাওয়া থেকে একটু আলাদা কিছু করছে”। একটা ফিল্ড ভুল জায়গায় সেভ হয়। একটা বোতাম একটা জিনিস আপডেট করে কিন্তু সংশ্লিষ্ট জিনিসটা করে না। একটা “delete” বোতাম ডিলিট না করে লুকিয়ে রাখে। যা সত্যিই বানানো হয়েছে তা না পড়লে এগুলো আপনি ধরতে পারবেন না।
কোডকে এমন কিছু হিসেবে দেখুন যা আপনি অডিট করতে পারেন, লিখতে হবে এমন কিছু হিসেবে নয়। বিশ্বাস করা যায় এমন একটা AI দিয়ে বানানো app আর শুধু কাজ করুক এই আশায় থাকা একটার মধ্যে এটাই পার্থক্য।
সহজ সংস্করণ
আর কিছু মনে না থাকলেও এটুকু মনে রাখুন: দুটো লিস্ট লিখুন, ইচ্ছে করে জিনিস ভাঙুন, আর সিদ্ধান্ত নিন কোন “যথেষ্ট ভালো” লেভেলে আপনি শিপ করছেন। একটা AI দিয়ে বানানো app-এর বেশিরভাগ বাগ সূক্ষ্ম নয়। সেগুলো সেই unhappy-path লিস্টে বসে আছে, যেটা কেউ লিখে রাখার কষ্ট করেনি।
একটু হোমওয়ার্ক চাইলে: আপনার বানানো একটা app বেছে নিন আর চারটে জিনিস চেষ্টা করুন — একটা ফাঁকা ফর্ম সাবমিট করুন, ফ্লো-এর মাঝখানে রিফ্রেশ চাপুন, একটা রেকর্ড এডিট করে কাল সেটা চেক করুন, আর একজন বন্ধুকে আপনি না দেখে এটা ব্যবহার করতে বলুন। যা কিছু ভাঙে সেটাই আপনার আসল বাগ লিস্ট। বাকি সব শুধু গড়িমসি।