একটি ভাল বাগ ডাটাবেস বজায় রাখার পদক্ষেপ

Question

ত্রুটিযুক্ত ডাটাবেস বজায় রাখা প্রতিটি প্রকল্পের জন্য গুরুত্বপূর্ণ। আমি বাগ ডেটাবেসে নিম্নলিখিতগুলি সংরক্ষণ করতে ব্যবহার করি

• ইস্যু তারিখের সময়
• কাকে দায়িত্ব দেওয়া হয়েছে
• তা সমাধান হয়েছে কিনা
• যদি সমাধান হয় তবে সমাধানের তারিখের সময়

এগুলি কি একটি ভাল বাগ ডাটাবেস বজায় রাখতে যথেষ্ট?

Comments

এটি কি বাগ ট্র্যাকিং ডাটাবেস?

— ইউসুবভ

কৌতূহলের বাইরে, আপনি কি আপনার প্রকল্পগুলিতে বাগ ট্র্যাকিংয়ের জন্য আপনার নিজের বাগ ট্র্যাকিং ডাটাবেসটি লেখার পরিকল্পনা করছেন? যদি হ্যাঁ, আপনি ইতিমধ্যে এটি করে এমন এক টন নিখরচায় পণ্য ব্যবহার করেছেন?

— ডিএক্সএম

Answer 1

একটি ভাল বাগ ডাটাবেসের অনুসরণ থাকতে পারে

// তারিখ সম্পর্কিত

• বাগের তারিখের সময়
• প্রত্যাশিত স্থির / সমাধানের তারিখের সময়
• যদি সমাধান হয় তবে সমাধানের তারিখের সময়

// নিযুক্ত + করা হয়েছে

• দ্বারা নির্ধারিত (দ্বারা সনাক্ত)
• নির্ধারিত

// বাগ আচরণ

• পর্যবেক্ষণ (বগি) আচরণ
• স্ক্রিন শট (সম্ভব)
• বাগ পুনরুত্পাদন করার জন্য পদক্ষেপগুলি সম্পূর্ণ করুন
• প্রত্যাশিত আচরণ

// অগ্রাধিকার

• বাগের অগ্রাধিকার

// লিঙ্ক, স্থিতি এবং অন্যান্য

• সম্পর্কিত বাগের লিঙ্ক
• বাগের স্থিতি
• তা সমাধান হয়েছে কিনা
• যদি সমাধান হয় তবে ব্যাখ্যা দিয়ে কীভাবে সমাধান হবে

সম্পাদনা: আমিও সুপারিশ করতে চাই

• কোন সংশোধন / শাখায় বাগটি আবিষ্কার করা হয়েছিল
• কোন সংশোধন / শাখায় বাগটি ঠিক করা হয়েছে

সম্পাদনা: আমি @ জগাফিনের মন্তব্য পছন্দ করি

• ওন্ট ফিক্স, বাগ নয়, ডুপ্লিকেট, সলভ করা

সম্পাদনা: একটি ভাল বাগ ডাটাবেস সিস্টেমও বজায় রাখে

• দায়িত্ব অ্যাসাইনমেন্ট ম্যাট্রিক্স

Comments

আপনি সমাধানটির

— ধরণটি

@ জাগাফিন, চমৎকার মন্তব্য। আমি আপনার মন্তব্যের প্রতি আমার উত্তর সম্পাদনা করেছি।

— মোঃ মাহবুবুর রহমান

Answer 2

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

• DateTimeবাগ / ত্রুটি ইস্যু
• বাগের বর্ণনা - পুনরায় তৈরির পদক্ষেপ।
• পরিবেশ যেখানে এটি পাওয়া গেছে (দেব, কিউএ, কিউসি, স্টেজিং, প্রোড)
• ইস্যুর স্ক্রিন-শট
• কে এটি লগ করেছে (সনাক্ত করেছে)
• কাকে এটি বরাদ্দ করা হয়েছে (নির্ধারিত দ্বারা)
• বাগের তীব্রতা (নিম্ন, মাঝারি, উচ্চ)
• প্রত্যাশিত রেজোলিউশন DateTime
• রাষ্ট্রীয় বিবাহ (প্রস্তাবিত, প্রগতিতে, সমাধান, বন্ধ)
• বাগ বন্ধ থাকে DateTime- যখন কোনও বাগ সমাধান হয়ে যায় এবং বন্ধ হয়ে যায়
• পরীক্ষার জন্য নির্ধারিত (পরীক্ষিত)

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

Answer 3

বেশিরভাগ দরকারী ক্ষেত্রগুলি ইতিমধ্যে অন্যান্য জবাবগুলি দ্বারা আবৃত হয়েছে বলে মনে হয়, তবে আমার কাছে দরকারী মনে হয় এমন কিছু হ'ল:

• কোন সংশোধন / শাখায় বাগটি আবিষ্কার করা হয়েছিল।
• কোন সংশোধন / শাখায় এটি স্থির করা হয়েছে।

ত্রুটিটি কোন তারিখ / সময় আবিষ্কার হয়েছিল / ঠিক করা হয়েছিল তার চেয়ে এটি কিছুটা সুনির্দিষ্ট।

যদি আপনার সফ্টওয়্যারটি বেশ কয়েকটি প্ল্যাটফর্মগুলিতে (ওএস বা হার্ডওয়্যার) চলমান থাকে তবে আপনি এমন একটি ক্ষেত্রও চাইতে পারেন যা প্লাগফর্মগুলিকে তালিকাবদ্ধ করে যেখানে বাগটি ঘটে।

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

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

Answer 4

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

• খোলার তারিখ
• খোলা হয়েছে
• সমাধানের তারিখ
• সমাধান করা হয়েছে
• সময় অতিবাহিত
• কীভাবে সমাধান হয়েছিল
• প্রভৃতি

কাকে এবং কখন বাগটি পুনরায় নির্ধারণ করা হয়েছিল তা ট্র্যাক করার জন্য আপনার একই ধরণের টেবিলের প্রয়োজন হতে পারে, বিশেষত যদি আপনি কোনও বড় দলে কাজ করেন।

আমি আপনাকে বিদ্যমান সিস্টেমগুলি একবার দেখে নেওয়ার পরামর্শ দিচ্ছি। আইএমএইচও জিরা অন্যতম সেরা ইস্যু ট্র্যাকিং সিস্টেম। এটিতে খুব সমৃদ্ধ বৈশিষ্ট্য রয়েছে এবং আপনি সেগুলির কিছুটিকে নিজের সিস্টেমের জন্য গাইড হিসাবে ব্যবহার করতে পারেন।

Answer 5

বাগ ট্র্যাকিংয়ের প্রক্রিয়াটি ডেটা হিসাবে গুরুত্বপূর্ণ। নিম্নলিখিতগুলি সম্পর্কেও চিন্তা করার চেষ্টা করুন:

• ব্যবহারকারীরা কীভাবে বাগটি রিপোর্ট করবেন?
• ভান্ডারটিতে বাগটি প্রবেশ করে কে?
• বাগের উপস্থিতি কে নিশ্চিত করতে পারে?
• কে সমাধান করতে পারবেন বাগটি সমাধান হয়েছে?
• কে শেষ ব্যবহারকারীকে জানিয়ে দেয় যে বাগটি সমাধান হয়েছে?

একটি RACI চার্ট তৈরি করুন যাতে আপনার টিমের প্রত্যেকে (শেষ ব্যবহারকারীরা তাদের দায়িত্বগুলি জানে proper যথাযথ ডেটা এন্ট্রি কৌশল সহ এটি একত্রিত করুন এবং আপনি সামান্য অতিরিক্ত প্রচেষ্টা সহ আরও অনেক মান দেখতে পাবেন।