হাই সেখানে!
একটি সিস্টেম QA ভূমিকা বাস্তবায়নের মাধ্যমে আমি কীভাবে আমাদের রিলিজ প্রবাহকে 20% উন্নত করতে পেরেছি তা শেয়ার করতে পেরে আমি রোমাঞ্চিত।
প্রদত্ত যে আমার কোম্পানি একটি সাধারণ পণ্য কোম্পানি, দলগুলি পণ্য দ্বারা নয় বরং উপাদান দ্বারা বিভক্ত। এর জন্য ধন্যবাদ, একদিকে, আমরা জ্ঞানের "ধারকদের" সাথে শক্তিশালী দল গঠন করতে পেরেছি। কিন্তু অন্যদিকে, ইউনিটের মধ্যে ভূমিকা তুলনামূলকভাবে বিচ্ছিন্ন, এবং কঠিন দক্ষতা এবং দক্ষতার বিভিন্ন সেট তাদের সীমাবদ্ধতা আরোপ করে। উদাহরণস্বরূপ, আমি কখনও কখনও একটি পরীক্ষককে ব্যাকএন্ড দল থেকে ফ্রন্টএন্ডে বা এর বিপরীতে সরাতে হবে৷
এটি এই সত্যের দিকে পরিচালিত করেছিল যে QA টিমের মধ্যে কার্যকর অর্কেস্ট্রেশন এবং ক্রস-টিম মিথস্ক্রিয়া পরিচালনার প্রশ্ন ছিল। যা, অবশ্যই, শেষ পর্যন্ত মুক্তি প্রবাহ প্রভাবিত.
পরিবর্তনের আগে রিলিজ প্রবাহ
পরিবর্তনের আগে, আমাদের রিলিজ প্রবাহ দেখতে এইরকম ছিল:
- একটি ব্যবসায়িক প্রয়োজনীয়তা স্পেসিফিকেশন (BRS) হল একটি নথি যা একটি ব্যবসার মধ্যে একটি নির্দিষ্ট বৈশিষ্ট্য, সিস্টেম, পণ্য বা প্রকল্পের জন্য বিশদ চাহিদা, প্রত্যাশা এবং স্পেসিফিকেশন রূপরেখা দেয়। এটি ব্যবসায়িক স্টেকহোল্ডার এবং উন্নয়ন বা বাস্তবায়ন দলগুলির মধ্যে একটি সেতু হিসাবে কাজ করে, যা অর্জন করতে হবে এবং এটি কীভাবে সামগ্রিক ব্যবসায়িক লক্ষ্যগুলির সাথে সারিবদ্ধ তা একটি পরিষ্কার বোঝার নিশ্চিত করে৷ এতে ব্যবহারকারীরা কীভাবে বৈশিষ্ট্যটির সাথে ইন্টারঅ্যাক্ট করবে তা বর্ণনা করে এমন বিশদ পরিস্থিতি থাকা উচিত৷ বৈশিষ্ট্যের মালিককে (FO) ব্যবসার প্রয়োজনীয়তা তৈরি করার দায়িত্ব দেওয়া হয়।
- একটি সফ্টওয়্যার রিকোয়ারমেন্ট স্পেসিফিকেশন (এসআরএস) হল একটি বিস্তৃত নথি যা একটি সফ্টওয়্যার সিস্টেম কী সম্পন্ন করবে তার বিশদ বিবরণ রূপরেখা দেয়। উদাহরণস্বরূপ, কিভাবে এবং কোন কমান্ডগুলি ইন্টারঅ্যাক্ট করে, কোন প্রোটোকল দ্বারা এবং কোন ডেটা প্রেরণ করা হবে। যদি ফিচারটিতে কাজ করা দল একটি গ্রাফিকাল ইন্টারফেস ব্যবহার করে, SRS-এর মধ্যে সেই বৈশিষ্ট্যের লেআউটগুলি অন্তর্ভুক্ত করা উচিত যা তৈরি করা হচ্ছে। ফিচার আর্কিটেক্ট SRS লেখার জন্য দায়ী।
- কোয়ালিটি অ্যাকশন প্ল্যান (QAP) – একটি বৈশিষ্ট্যের মালিক একটি বৈশিষ্ট্য গ্রহণ করার আগে পরীক্ষা করে দেখেন। নথিগুলি বর্ণনা করার পরে, আমরা বৈশিষ্ট্যটি বাস্তবায়ন করতে এগিয়ে যাই। যখন প্রথম দলটি বৈশিষ্ট্যটির তার অংশের বিকাশ এবং পরীক্ষা শেষ করে, তখন এটি দ্বিতীয় দলে স্থানান্তরিত হয়। দ্বিতীয় দল ইন্টিগ্রেশন/ডেভেলপমেন্ট/পরীক্ষা করে এবং পরবর্তী ইউনিটে পাস করে। এবং তাই যতক্ষণ না ফিচার ডেভেলপমেন্টে অংশগ্রহণকারী সমস্ত কম্পোনেন্ট দল এই প্রবাহের মধ্য দিয়ে যায়। FO বৈশিষ্ট্যটি যাচাই করে এবং এটি রিলিজে পাঠানো হয়।
রিলিজ প্রবাহ সমস্যা
সুতরাং, সবকিছু ঠিক আছে বলে মনে হচ্ছে - নথি, অ্যাপ্লিকেশন, গ্রহণযোগ্যতা কেস। যাইহোক, আমরা এই প্রক্রিয়ায় নিম্নলিখিত অসুবিধার সম্মুখীন হয়েছি:
QA এর পক্ষ থেকে সমস্যা:
- প্রয়োজনীয়তা পরীক্ষা শুধুমাত্র উন্নয়ন পরে শুরু হয়. ডেভেলপারদের দ্বারা ইতিমধ্যেই বাস্তবায়িত করা কাজগুলি, তাদের প্রয়োজনীয়তা সহ, QA টিমের কাছে হস্তান্তর করা হয়৷ কিন্তু, আমরা জানি, প্রয়োজনীয়তার মধ্যে ত্রুটি থাকতে পারে।
- একটি বাগের জন্য দায়ী দলটিকে খুঁজে পেতে বেশ কিছুটা সময় লাগে কারণ এটি সর্বদা পরিষ্কার নয় যে কোন কেসগুলি ইতিমধ্যে অন্যান্য দল দ্বারা পরীক্ষা করা হয়েছে।
- পরীক্ষা নিদর্শন কোন পুনঃব্যবহার. একটি বৈশিষ্ট্য পরীক্ষা করার অংশ হিসাবে, QA দলগুলি একই ধরনের পরীক্ষার ডেটা সেট প্রস্তুত করে। কিন্তু দলগুলির বিচ্ছিন্নতা এবং সংকীর্ণ বিশেষীকরণের কারণে, তারা একে অপরের কাছে এই ডেটা প্রেরণ করতে পারেনি।
FO এর পক্ষ থেকে সমস্যা:
- অনেক বৈশিষ্ট্যের কারণে, QAP লিখতে অনেক সময় লাগে।
- বৈশিষ্ট্যটির বৈধতা সমস্ত দল দ্বারা বিকাশের পরে ঘটে। আমাদের ক্ষেত্রে, এটি অনেক ইন্টিগ্রেশন সমস্যার কারণে রিলিজ প্রবাহকে উল্লেখযোগ্যভাবে দীর্ঘায়িত করে।
- পণ্যের জটিলতা এবং দলগুলির মধ্যে একীকরণের পরিমাণের কারণে পরীক্ষার পরিবেশের প্রস্তুতিও সুনির্দিষ্ট। বিভিন্ন দল একই সাথে তাদের উপাদান পরীক্ষা করছে, ডেটা ম্যাশ করা, পরিবর্তন করা বা মুছে ফেলার ঝুঁকি বাড়াচ্ছে।
আপডেট করা রিলিজ প্রবাহে সিস্টেম QA
QA টিমের মধ্যে কার্যকর ক্রস-টিম মিথস্ক্রিয়া সহজতর করতে এবং রিলিজ প্রবাহ কমাতে, আমরা সিস্টেম QA এর ভূমিকা চালু করেছি।
এটি এফও-এর সাথে গ্রহণযোগ্যতা কেস লেখার আকারে কাজের চাপ কমাতে সাহায্য করেছে এবং পরীক্ষার পরিস্থিতি লেখার গতি বাড়িয়েছে, পরবর্তী দলে পাস করার আগে বৈশিষ্ট্য উপাদানটির মধ্যবর্তী পরীক্ষা চালু করতে এবং পরীক্ষার প্রস্তুতির সময়সাপেক্ষ কাজটি স্থানান্তর করতে সহায়তা করেছে। সিস্টেম QA-এর পরিবেশ, একীকরণ এবং পরীক্ষার ডেটার জন্য দলগুলির সমস্ত সূক্ষ্মতা এবং প্রয়োজনীয়তা বিবেচনা করে।
সিস্টেম QA প্রতিটি বৈশিষ্ট্য এবং সামগ্রিকভাবে পণ্যের জন্য প্রযুক্তিগত এবং ব্যবসায়ের প্রয়োজনীয়তার মধ্যে একটি লিঙ্ক হয়ে উঠেছে।
সিস্টেম QA-এর জন্য অনবোর্ডিং
সম্পূর্ণ রিলিজ চক্র বোঝার জন্য, প্রতিটি দলে একটি নির্দিষ্ট রিলিজ চক্র কীভাবে কাজ করে তা সিস্টেম QAs-কে বুঝতে হবে। অনবোর্ডিং সাধারণত তিন মাস স্থায়ী হয় কারণ সিস্টেম QA তাদের নির্দিষ্ট রিলিজ চক্র বুঝতে প্রতিটি দলে 2-3 সপ্তাহ ব্যয় করে।
নতুন প্রক্রিয়ার ফলাফল
আমরা এখন বৈশিষ্ট্যের মালিক এবং স্থপতিদের কাছ থেকে BRS/SRS প্রয়োজনীয়তা পরীক্ষা করছি। প্রারম্ভিক বাগ সনাক্তকরণ ব্যবসার জন্য খরচ সঞ্চয় বাড়ে.
আমরা একটি ক্রস-টিম QA স্পেস স্থাপন করেছি, যেখানে প্রতিটি বৈশিষ্ট্যের সাথে পরীক্ষার আর্টিফ্যাক্ট সংযুক্ত থাকে - ব্যবসার প্রয়োজনীয়তা, প্রযুক্তিগত প্রয়োজনীয়তা, গ্রহণযোগ্যতার ক্ষেত্রে, অন্যান্য দলের ক্ষেত্রে, পরীক্ষার ডেটা। এটি উল্লেখযোগ্যভাবে সমস্ত QA দলকে একক প্রসঙ্গে থাকতে এবং কার্যকরভাবে ডেটা পুনঃব্যবহার করতে সাহায্য করেছে৷
বাগগুলির স্থানীয়করণের প্রক্রিয়াকে ত্বরান্বিত করেছে কারণ সিস্টেম QA-তে সমস্ত দলের পরীক্ষার কেস রয়েছে৷
যেহেতু সিস্টেম QA প্রতিটি দলের জন্য গ্রহণযোগ্যতা কেস লিখছে, এটি পরীক্ষার মান দ্রুত বাড়ানো এবং উন্নত করার জন্য একটি চমৎকার ইঙ্গিত।
ইন্টিগ্রেশন প্রক্রিয়াটি বেদনাদায়ক হয়ে উঠেছে কারণ বৈশিষ্ট্যটি প্রতিটি কমান্ডের পরে গ্রহণযোগ্যতার ক্ষেত্রে যাচাই করা হয়।
FO থেকে লোডের একটি উল্লেখযোগ্য অংশ সরানোর পরে, বৈশিষ্ট্যগুলির গ্রহণযোগ্যতা এবং পরীক্ষার ডেটা সহ একটি ইন্টিগ্রেশন স্ট্যান্ডের প্রস্তুতি ত্বরান্বিত হয়েছে।
সামগ্রিকভাবে, মুক্তির প্রবাহকে 15-20% ত্বরান্বিত করেছে এবং ইন্টিগ্রেশন বাগগুলির সংখ্যা প্রায় অর্ধেক কমিয়েছে যেহেতু এখন থেকে আমরা BRS এবং SRS প্রয়োজনীয়তা লেখার পর্যায়ে এবং বৈশিষ্ট্য বিকাশের কাঠামোর মধ্যে টিম ইন্টিগ্রেশনের সময় উভয়কেই ধরতে পারি।
সুখী এবং উত্পাদনশীল পরীক্ষা!
