10

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

আমার সফ্টওয়্যারটি মালিকানাধীন হার্ডওয়্যারের সাথে খুব বেশি বেঁধে রয়েছে যাতে একবারে অনেক দিক থেকে বাগগুলি আসতে পারে।

"আমি যখন একটি বোতাম টিপেছিলাম তখন আপনার সফ্টওয়্যার ক্র্যাশ হয়েছিল" তার চেয়ে বেশি কি আমার কাছ থেকে প্রত্যাশা করা উচিত বা আমার কী হওয়া উচিত তা নিজেই চিহ্নিত করা উচিত?

সম্পাদনা করুন:

আমার এক সহকর্মী উল্লেখ করেছিলেন যে আমরা সম্ভবত এখানে সমস্ত বিকাশকারী যাতে ফলাফল কিছুটা পক্ষপাতদুষ্ট হতে পারে

testing bug qa reporting

— এরিক
সূত্র

1

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

— ক্রিসফ্লেচার

আসলেই নয়, টেস্টিংও করা উচিত। QA করা উচিত QA।

— mattnz

1

আপনার পণ্যটিতে যুক্তি যুক্ত করার কথা বিবেচনা করুন যা আপনাকে ব্যবহারকারীর গৃহীত পদক্ষেপগুলি পুনরায় সন্ধান করতে সহায়তা করে এবং একটি QA- বোতাম রয়েছে যা বাগ রিপোর্টারকে সহজেই আপনার পণ্য থেকে বলা তথ্য বের করতে এবং বাগ রিপোর্টে যুক্ত করতে দেয়।

কমপক্ষে প্রকৃত পরিস্থিতির স্ক্রীনশট বেশিরভাগ সময় ত্রুটিটি পুনরুত্পাদন করতে সহায়তা করে। (উপরে লগিং মন্তব্য দেখুন)। ইউজার্সএনপ উন্নত বাগ রিপোর্টিং এবং যোগাযোগের সময় সাশ্রয়ের জন্য একটি সরঞ্জাম।

— গ্রেগর

31

কিউএর সর্বদা চেষ্টা করা উচিত এবং আপনার পক্ষে ততগুলি সম্ভব পুনরুত্পাদন করা সহজ করা উচিত এবং বাগের বিবরণে নেওয়া পদক্ষেপগুলি থাকা উচিত।

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

এছাড়াও, আপনি তথ্যগুলি ফিল্টার করতে পারেন - বিভিন্ন সিস্টেমে প্রচুর বাগ থাকতে পারে যা আপনি জানেন যে সমস্ত কোডের একটি ক্ষেত্রের সাথে লিঙ্কযুক্ত রয়েছে - যদি QA কিছু রিপোর্ট না করে (কারণ তারা তাদের পুনরুত্পাদন করতে পারে না) ) তাহলে এই তথ্য আপনার কাছে পাবেন না।

— PhillC
সূত্র

... a full description of what they did to cause the bug। কীভাবে রেপো থেকে আলাদা?

— স্টিভেন এভার্স

13

@ এসএনআরফাস: সংজ্ঞা অনুসারে পুনরুত্পাদনযোগ্য Rep আপনি যদি কোনও বাগ খুঁজে পান তবে পরে এটি পুনরুত্পাদন করতে না পারেন তবে কী কারণে এটি ঘটেছে তা সন্ধান করতে আপনি সেই সময়ে কী করছেন তা জানার পক্ষে এটি এখনও সহায়ক।

— ব্লুরাজা - ড্যানি পিফ্লুঘুফুট

3

@ এসএনআরফাস: The software crashedবনাম The software crashed editing foowidgetsবনাম

The software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached)

। শেষ বিবরণ সুস্পষ্ট নাও হতে পারে তবে প্রথমটির পরিবর্তে দ্বিতীয় বিবরণ থাকা অবশ্যই সহায়ক is

— দেনিথ

@ ডেইনথ: যথেষ্ট ফর্সা। সম্ভবত আমি একটি সম্পূর্ণ বিবরণের শব্দার্থক শব্দে খুব দূরে getting

— স্টিভেন এভার্স

আপনার ত্রুটিযুক্ত ট্র্যাকারে ব্যবহারের জন্য "ক্লোজড ডিড / পুনরুত্পাদন করা যায়নি" উপলব্ধ (সেখানে এবং গ্রহণযোগ্য) রয়েছে তা নিশ্চিত করুন।

— mattnz

13

দেখে মনে হচ্ছে আপনার কিউএ বিভাগটি খুব বেশি অনুসন্ধানী পরীক্ষা করছে (যেমন। তাদের ভাল পরীক্ষার পরিকল্পনা নেই)।

অনুসন্ধানের পরীক্ষা ভাল, এবং সমস্যার ক্ষেত্রগুলি সনাক্ত করে, তবে সেখান থেকে তাদের সম্পাদন করার জন্য পুনরুত্পাদনযোগ্য টেস্ট কেসগুলি (অর্থাত্ একটি পরীক্ষা পরিকল্পনা) সংজ্ঞায়িত করা উচিত যা নির্দিষ্ট বাগগুলি প্রকাশ করবে।

একটি সঠিক তিরস্কারের প্রয়োজনীয়তার বিভিন্ন কারণ রয়েছে (কেবল ভাল নয়, তবে প্রয়োজনীয়):

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

সুতরাং, স্টিভজেটিটি নোট হিসাবে: এটিকে কোনও তিরস্কার হিসাবে বন্ধ করুন এবং কাজে ফিরে আসুন।

— স্টিভেন ইভার্স
সূত্র

3

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

— maple_shaft

3

@ ম্যাপেল_শ্যাফ্ট এটি সত্য - আমি আশা করি না QA থেকে প্রতিটি বাগ 100% প্রজননযোগ্য হবে be স্ক্রিন রেকর্ডিং একটি আকর্ষণীয় বিকল্প এবং স্পষ্টভাবে আরও বিবেচনা বহন করে, কারণ এটি পরীক্ষকের কাঁধে দেখার সুযোগ ছাড়াই আরও নমনীয়তার সুযোগ দেয়।

— মাইকেল কে

2

@ ম্যাপেল_শ্যাফ্ট: আমি সম্মত, এবং এমটিএম এর অন্তর্নির্মিত রয়েছে। এই ক্ষেত্রে যদিও, এরিক কী পাচ্ছেন তার মধ্যে একটি গুরুত্বপূর্ণ পার্থক্য রয়েছে ("একটি ক্র্যাশ হয়েছিল") এবং সর্বোত্তম কেস দৃশ্যটি কী (ইভেন্ট লগস + অ্যাপ্লিকেশন লগগুলি + ভিডিও + অ্যাকশন রেকর্ডিং + ইন্টেলিট্রেস + আইটেমযুক্ত রেপ্রো)। আইএমও / ই কিউএর কাজ শেষ হয় না যখন নীল পর্দা ঘটে - এবং সর্বদা সম্ভব না হলেও এমন কি, প্রথম বারের মতো তাদের উত্পাদনের চেষ্টা করা উচিত।

— স্টিভেন এভার্স

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

— maple_shaft

@ ম্যাপেল_শ্যাফ্ট: আমি যেখানে কাজ করি, আমি কিউএ থেকে দেবে স্থানান্তরিত হওয়ার আগে আমরা ইতিমধ্যে বেশিরভাগ কাজ করছিলাম (আপনার 400000 পরীক্ষার ক্ষেত্রে ভিডিওটি এইচডিডি স্পেসের ক্র্যাপলোড নেয়)।

— স্টিভেন এভার্স

7

বাগটি যদি ধারাবাহিকভাবে পুনরুত্পাদন করা না যায় তবে কিউএ কীভাবে জানবে যে এটি স্থির ছিল কিনা?

— Kyralessa
সূত্র

হ্যাঁ এটি আরেকটি সমস্যা যা আমি উল্লেখ করি নি তবে অনেকগুলি চালাচ্ছি। আমি একটি বাগ রিপোর্ট পাই, পরিবর্তনগুলি করে বাগটি বন্ধ করে দিন। কিউএ তখন ঘনিষ্ঠতা অনুমোদন করে। কয়েক সপ্তাহ পরে, সমস্যাটি স্থির হয়নি বলে আবার খোলে। "সফ্টওয়্যার ক্র্যাশ হয়েছে" হিসাবে আমারও প্রচুর সমস্যা রয়েছে, যা প্রতিটি সম্ভাব্য বাগের বৃহত গলে যাওয়া পাত্র হয়ে যায়

— এরিক

6

হ্যাঁ, তাদের কাছ থেকে আরও আশা করা উচিত। তারা বলতে সক্ষম হবে:

1. প্রোগ্রাম নতুন উদাহরণ শুরু
2. আমি বোতাম টিপুন
৩. ফর্ম # 1 তে টেস্ট NAME ফিল্ডে "পরীক্ষার পাঠ্য" প্রবেশ করানো হয়েছে
৪. চাপানো বোতাম বি
৫. পর্যবেক্ষণ করা হয়েছে যে প্রোগ্রামটি এই বার্তাটির সাথে ক্র্যাশ হয়েছে (সংযুক্ত স্ক্রিনশটটি দেখুন)।

তারা যা বলবে তার সবই যদি "এটি ক্র্যাশ" হয় তবে সেগুলি খুব ভাল নয়। এমনকি উপরের পদক্ষেপগুলি যদি 100% প্রজননযোগ্য না হয় তবে একবারে কোনও প্যাটার্ন সনাক্ত হওয়ার পরে এই ক্র্যাশগুলির একটি বৃহত পরিমাণের নমুনা কারণ সঙ্কুচিত করতে সহায়তা করতে পারে।

— FrustratedWithFormsDesigner
সূত্র

5

আমার পরামর্শটি হ'ল সেই বাগগুলি পড়ুন এবং তাদের একটি ভাল পুরানো চিন্তাভাবনা দিন। যদি আপনি কোনও সম্ভাব্য কারণটি সনাক্ত করতে না পারেন তবে আপাতত তাদের সম্পর্কে ভুলে যান।

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

এই "1000 এ 1" বাগ সহ, কিউএর কিছুটা তাদের পুনরুত্পাদন করার চেষ্টা করা উচিত। যদি তাদের সাফল্য না হয় তবে তাদের বাগটি নথি করা উচিত, তারপরে আরও কিছু চেষ্টা করুন।

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

বাগটিতে যতটা সম্ভব তথ্য অন্তর্ভুক্ত করা উচিত। পরীক্ষক ইস্যুটির সীসা-আপ সম্পর্কে যা কিছু মনে করতে পারে তা বেদনাদায়ক বিশদে লিখে দেওয়া উচিত। যে কোনও ক্র্যাশ লগ, ডাটাবেস স্ন্যাপশট, বা প্রাসঙ্গিক স্ক্রিনশটগুলি পাশাপাশি সংযুক্ত করা উচিত।

বাগটি যদি কখনও পুনরুত্পাদন করা না হয়, দুর্দান্ত! এটি ডাটাবেসে থাকার ক্ষতি করে না। যদি প্রোগ্রামটি প্রকাশিত হয় এবং কোনও ব্যবহারকারী পরে অনুরূপ বাগ রিপোর্ট করে তবে আপনি তাদের অভিজ্ঞতাটি প্রতিবেদনে যা আছে তার সাথে তুলনা করতে পারেন এবং কোনও মিল খুঁজে পেতে পারেন।

আমার অভিজ্ঞতায়, জাইস্টেট বাগগুলি নিম্নলিখিত পরীক্ষার পরিকল্পনাগুলি থেকে পাওয়া যায় না। কখনও কখনও আপনাকে কিছু সপ্তাহের জন্য জিনিসগুলি স্টুতে দিতে হয় যাতে চাঁদ এবং তারাগুলি একত্রিত করে যা একটি বাজে বাগের কারণ হয়। যদি QA কিছু গোয়েন্দা কাজ করতে পারে এবং কিছু সম্ভাব্য কারণ খুঁজে পেতে পারে, তবে তাদের পিছনে একটি থাপ্পর দিন। তবে মাঝে মাঝে কে কে জানে?

— যাজক
সূত্র

"ডাটাবেসে এটি থাকার ক্ষতি করে না"

— ফিলি

4

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

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

— কার্ল বিলেফেল্ট
সূত্র

2

আপনার যদি বোঝাতে চাওয়া হয় যে QA- তে ত্রুটিগুলি পুনরুত্পাদন করার পদক্ষেপগুলি অন্তর্ভুক্ত করা উচিত যদি তারা পারেন তবে উত্তরটি হ্যাঁ। আপনার যদি বোঝানো হয় যে তারা কেবলমাত্র বাগগুলি রেকর্ড করতে পারে যা তারা পুনরুত্পাদন করতে সক্ষম হয়, তবে একেবারেই নয়। বাগগুলি বাগগুলি হয়, সেগুলি কেবলমাত্র একটি পূর্ণিমাতে মধ্যরাতে হয় বা আপনি যতবার তাকান ততবার হয়। কিছু বাগ অ-নিরস্তক (ক্লাসিক উদাহরণ অবিচ্ছিন্ন ভেরিয়েবল, যেখানে তোলা মানটি অর্ধ-এলোমেলো), এর অর্থ এই নয় যে সেগুলি রেকর্ড করা উচিত নয়, তদন্ত করা উচিত এবং যদি সম্ভব হয় তবে তা স্থির করা উচিত।

অ প্রজননযোগ্য বাগগুলির সাধারণত একটি নিম্ন অগ্রাধিকার থাকা উচিত তবে সেগুলি অবশ্যই রেকর্ড করা উচিত।

— jmoreno
সূত্র

1

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

আপনার সময়টি এর চেয়ে অনেক বেশি মূল্যবান।

— স্টিভ জেজ্টি
সূত্র

1

একটি বাগ রিপোর্ট থাকা উচিত:

ধাপ পুনর্গঠন কর
আসল আচরণ
প্রত্যাশিত আচরণ

উদাহরণ:

আমি ডাটাবেস থেকে সমস্ত সরবরাহকারীকে মুছে ফেলেছি (ব্যবহার করে DELETE * FROM tSuppliers), সরবরাহকারী ডায়ালগটি খুলেছি এবং সরবরাহকারী ড্রপ-ডাউন তালিকায় ক্লিক করেছি।
তালিকা নিম্নলিখিত বার্তা অন্তর্ভুক্ত: GUPOS ERROR #0000000: SOMETHING WENT WRONG!। আমি বার্তায় ক্লিক করলে অ্যাপ্লিকেশনটি স্ক্রীন এবং টাস্ক ম্যানেজার থেকে অদৃশ্য হয়ে যায়।
আমি প্রত্যাশা করলাম যে কোনও শূন্য তালিকা বা (সম্ভবত) কোনও বার্তা যেমন "সরবরাহকারী পাওয়া যায় না" see খালি তালিকায় বা বার্তায় ক্লিক করা কোনও প্রভাব ফেলবে না। অ্যাপ্লিকেশনটি অবশ্যই কোনও পরিস্থিতিতে সতর্কতা ছাড়াই অদৃশ্য হওয়া উচিত নয়।

সুতরাং, হ্যাঁ - এতে পুনরুত্পাদন করার পদক্ষেপগুলি থাকা উচিত। এটিকে অন্তর্ভুক্ত করার প্রয়োজনীয়তা তারা অনুভব করে না বলে মনে হয় যে তারা মনে করে যে তাদের কাজটি ত্রুটিগুলি চিহ্নিত করার পরিবর্তে "সফ্টওয়্যারটি ভেঙে ফেলা"।

— gkrogers
সূত্র

0

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

— java_mouse
সূত্র

0

অর্থ এখানে ঝুঁকিতে আছে। যে কোনও দলের সদস্য কেন একটি নিম্ন-সংজ্ঞায়িত, কম-সম্ভাবনা-সাফল্য টাস্ক তৈরি করতে সক্ষম হবেন যা একজন (আশায়) উচ্চ বেতনের বিকাশকারীকে বোঝা করে?

এটি পিকিং অর্ডার, শ্রেণিবিন্যাস, অহংকার, আমাদের বনাম সেগুলি বা এ জাতীয় কিছু নয়। এটি কেবল এমন ক্রিয়াকলাপগুলিতে বিনিয়োগ সম্পর্কে যা পণ্যটির মূল্য সংযোজন করে।

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

— bneely
সূত্র

-1

আপনার কিউএ দল সফল হয়

তাদের কাছে যান এবং তাদের কোনও ডকুমেন্ট পড়তে বলুন যে কোনও পেশাদার পরীক্ষককে তাদের মস্তিষ্কের ঠিক ভিতরে ছাপাতে হবে (আমি একবার পরীক্ষক ছিলাম এবং এখনও আমার মস্তিষ্কে এটি ছিল): কীভাবে বাগগুলি কার্যকরভাবে রিপোর্ট করা যায় ।

বিশেষত, "আমাকে কীভাবে আমাকে দেখানো যায়" বিভাগটিতে তাদের নির্দেশ করুন :

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

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

যদি তারা আপনাকে অভিযোগ করতে শুরু করে যে "বাগগুলি অনেকগুলি দিক থেকে একবারে আসতে পারে" , তাদের বলুন যে তারা আপনার আগে যা ভাবেন তার চেয়েও বেশি স্তন্যপান করেন। তাদের বলুন যে টেস্টিবিলিটি এমন একটি বৈশিষ্ট্য যা তাদের অন্যান্য প্রকল্পের বৈশিষ্ট্যের মধ্যে মূল্যায়ন করা উচিত এবং তাদের এই বৈশিষ্ট্যটি সঠিকভাবে অর্জন করার জন্য প্রচেষ্টা করা উচিত।

যখন কোনও পেশাদার পরীক্ষক এটির উপর দৃষ্টি নিবদ্ধ করে থাকেন তখন টেস্টিবিলিটি উন্নতিগুলি অনেকটা ম্যাজিকের মতো হতে পারে। আমি কয়েক মাস আগে নিজেই শিখেছি। আমাদের দলের সাথে কাজ করা কিউএ ইঞ্জিনিয়ার আমাকে আমাদের অ্যাপ্লিকেশনের কিছু উপাদানগুলির জন্য বিকাশের জন্য মুষ্টিমেয় টেস্টাবিলিটি অনুরোধ জানিয়েছেন। তিনি যে বিষয় সম্পর্কে জিজ্ঞাসা করেছিলেন সেগুলি আমার কাছে খুব সামান্যই বোধগম্য হয়েছিল তবে আমি কেবল তাকে ধরেই দিয়েছিলাম যে তিনি পেশাদার হিসাবে আরও ভাল জানেন। আমি শেষ করার পরপরই, তিনি এমন একটি সরঞ্জাম নিয়ে এসেছিলেন যা আকারের ক্রম দিয়ে পরীক্ষার প্রচেষ্টা হ্রাস করে । তিনি বলেছিলেন যে এর বেশিরভাগটি আমি প্রয়োগ করা এই গুপ্ত অনুরোধগুলির ভিত্তিতে তৈরি করেছিলাম, ফি ফিগার।

— মশা
সূত্র

কিউএর কি পুনরুত্পাদনযোগ্য পরিস্থিতি খুঁজে পাওয়া উচিত?

আপনার কিউএ দল সফল হয়