কীভাবে ক্লায়েন্টকে বাড়ির কিউএ টেস্টিংয়ে কিছু করতে উত্সাহিত করবেন?


14

আপডেট / স্পষ্টকরণ আমার ক্লায়েন্ট তাদের বাড়ির অভ্যন্তরীণ পরীক্ষার প্রয়োজনীয়তা বুঝতে পারে এবং সে / তারা সর্বদা শপথ করে যে তারা "আরও ভাল" করবে (অর্থাত্ কিছু করবে) তবে তা ঘটে না। বাইরের পরীক্ষার জন্য তাদের কাছে বাজেট নেই। আমি অনুমান করি যে আমি "প্রাথমিক পরীক্ষা, প্রায়শই পরীক্ষা, লক্ষ্য মেশিনের নীতি সম্পর্কে পরীক্ষা করতে পারি" সে সম্পর্কে কী জিজ্ঞাসা করছি (অস্পষ্টভাবে, আমি স্বীকার করি)?

প্রশ্ন: কীভাবে ব্যবহারকারীদের প্রযোজনা প্রকল্পগুলিতে "টেস্ট-যেমন-তেমন" যেতে হবে না, তা নতুন প্রকাশের সাথে স্পষ্টভাবে পরীক্ষা করার এবং সমস্যাগুলির প্রতিবেদন করতে সময় দেওয়ার জন্য উত্সাহিত করবেন to

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

আমার দুটি সমস্যা আছে:

  1. বৈশিষ্ট্য সংজ্ঞাটি অন-দ্য ফ্লাইয়ে করা হয়, প্রায়শই ফোনে, পরিবর্তন, সংশোধন, বিপরীত সাপেক্ষে over (খানিকটা কেনেডি'র মতো "আমরা চাঁদে যাব এবং অন্যান্য জিনিসগুলি করব" - আমি সবসময় "অন্যান্য জিনিস" এর অংশটি দেখে আনন্দিত হয়েছি)

  2. কার্যত তাদের শেষের দিকে কোনও QA টেস্টিং করা হয় না।

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

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

এটি আপনার প্রত্যাশার মতো আমাকে প্রভাবিত করে: প্রতিক্রিয়া ব্যতীত কোনও বৈশিষ্ট্য সম্পূর্ণ কিনা তা আমি বলতে পারি না (দেখুন # 1), বা অন্য কোনও পরিণতি রয়েছে কিনা। এটি আমাকে কিছুটা অলস করে তুলছে।



3
যদি কোনও বাগটি এত ছোট হয় যে ব্যবহারকারীরা নিজেরাই ঠিক করেছেন কিনা সেদিকে খেয়াল রাখবেন না বলে আপনি কেন জেদ করছেন?
কামিল্ক

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

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

4
@ ডিজেচলিন - এটি মোটেও পরীক্ষা (এবং রিপোর্টিং) সম্পর্কে। এবং একজন বিকাশকারী কেবলমাত্র এতগুলি পরীক্ষা করতে পারে: আমি ব্যবহারকারীদের মতো এটি ব্যবহার করি না।
কোন দখল

উত্তর:


18

"রিয়েল" বিকাশকারীদের বিশদ সম্পর্কে তাদের কোনও আবেগজনক নিউরোসিসের মনোযোগ নেই

উপস্থাপনা : আপনি এখানে যে ধরণের ভাষা ব্যবহার করেছেন তা সাধারণত আমার জন্য একটি লাল পতাকা। যখন আমি লোকদের "প্রকৃত" বিকাশকারীদের সম্পর্কে (বা একমাত্র) "সঠিক" উপায় সম্পর্কে কথা বলতে শুনি তখন আমি সুরঙ্গ দৃষ্টিপ্রাপ্ত কার্গো- কাল্ট বিকাশকারীদের কথা ভাবতে শুরু করি ।

এখন, আমি বলছি না যে আপনি অবশ্যই এই বিকাশকারীদের মধ্যে একজন (আমার কাছে তা দৃ to় প্রমাণের পক্ষে যথেষ্ট প্রমাণ নেই) তবে আপনি যদি হন তবে আপনি এই উত্তরটি থেকে উপকৃত হতে পারেন।

উত্তর

মনে হচ্ছে আপনি এবং আপনার ক্লায়েন্ট বিভিন্ন জিনিসের জন্য অনুকূলিত হয়েছেন। এটি সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের একটি দুর্ভাগ্যজনক সত্য যা প্রায়শই ব্যবসায়ের প্রয়োজন এবং বিকাশকারীদের আকাঙ্ক্ষাগুলি অগত্যা লাইন করে না।

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

তবে, আপনার ক্লায়েন্ট কোনও সফ্টওয়্যার কারিগর নয়। আপনার ক্লায়েন্টটি পুরোপুরি আলাদা আলাদা অগ্রাধিকারের একটি ব্যবসা business এবং, কখনও কখনও, সেই অগ্রাধিকারগুলি আমরা সফ্টওয়্যার কারিগরদের কাছে হাস্যকর মনে হয় ... তবে এটি কেবল কারণ আমরা বিভিন্ন জিনিসের জন্য অপ্টিমাইজ করছি।

ব্যবসায়ের প্রায়শই বাজারে প্রারম্ভিক প্রকাশ এবং স্বল্প মেয়াদী ব্যয় সাশ্রয়ের মতো জিনিসের জন্য অনুকূলিতকরণ করতে চায়। এটি করার জন্য তাদের কিউএ, ব্যবহারকারীর অভিজ্ঞতা, দীর্ঘমেয়াদি ব্যয় সাশ্রয় এবং বিকাশকারীদের টিক দেয় এমন অন্যান্য জিনিসগুলির ত্যাগ করতে হতে পারে।

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

সুতরাং, আপনি যখন আপনার ক্লায়েন্টের কাছে QA ধারণাটি বিক্রি করার চেষ্টা করতে পারেন তখন আপনি আপনার সময় নষ্ট এবং তাদের সাথে আপনার সম্পর্ককে টানতে পারেন। সর্বোত্তম ক্ষেত্রে আপনি আপনার ধারণাগুলি চেষ্টা করার জন্য আগ্রহী কাউকে পাবেন (সম্ভাবনা নেই)। সবচেয়ে খারাপ ক্ষেত্রে আপনাকে পুরো কোম্পানিকে তার প্রণোদনা কাঠামোগুলি পুনরায় কাজ করতে বাধ্য করতে হবে যাতে QA এর মতো দীর্ঘমেয়াদী বিনিয়োগগুলি পুরস্কৃত হয়। উভয় ক্ষেত্রেই, আপনার সাফল্যের প্রতিক্রিয়া কম are


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

-1 হিসাবে, এটি একটি ভাল লিখিত পোস্ট হিসাবে, এটি কীভাবে আপনি এটি চালিয়ে যাবেন এই প্রশ্নটির সত্যই সমাধান করে না । উত্তরটি হ'ল আপনি এটি একেবারে অনুরূপভাবে করেন আপনি নিয়মিত বিকাশকারীদের পরীক্ষা করতে রাজি করেন: দেখান যে পরীক্ষাটি ঝুঁকি হ্রাস করতে সহায়তা করে। ক্লায়েন্ট ডেমোর মাঝখানে কম ঝুঁকি == কম উত্পাদন সমস্যা।
ডেভিড মনিকাকে

না - উপায় বন্ধ কিন্তু উত্তর দেওয়ার জন্য ধন্যবাদ।
11:41

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

কারিগর :-)
টনি লেই

10

আকর্ষণীয় প্রশ্নটি হল যখন আপনি অর্থ প্রদান করবেন, আপনার ক্লায়েন্ট তাদের নিজস্ব কোনও পরীক্ষা করে কিনা তা নয়।

  • আপনি যদি আপনার সময়ের ভিত্তিতে বেতন পান তবে কোনও সমস্যা নেই।
  • আপনি যদি অগ্রিম বেতন পান তবে কোনও সমস্যা নেই।
  • ক্লায়েন্ট যখন প্রকল্পটি "সম্পন্ন" হিসাবে ঘোষণা করে আপনি অর্থ প্রদান করেন তবে বড় সমস্যা।

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

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

ক্লায়েন্টের দ্বারা গৃহীত এ জাতীয় গ্রহণযোগ্যতা পরীক্ষা করা অন্য ধরণের পরীক্ষার থেকে পৃথক:

  • ইউনিট পরীক্ষা
  • সিস্টেম ইন্টিগ্রেশন পরীক্ষা
  • ব্যবহারযোগ্যতা পরীক্ষা
  • লোড পরীক্ষা
  • প্রাক রিলিজ পরীক্ষা

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

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

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

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

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

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


1
অর্থ ইস্যু নয় (আমি একজন মাসিক রিটেনারের উপর আছি - আমি কোড করি বা না দিই আমি বেতন পাই)। এটি কীভাবে তাদের অফিস সংস্কৃতিতে নগ্ন করা যায় ... বা এমন কিছু যা আমি পাই না।
11:41

2

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

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

  1. সহজ সরঞ্জামগুলি ব্যবহার করুন, এমনকি যদি সেই সরঞ্জামগুলি অপর্যাপ্ত এবং অনুপযুক্ত। উদাহরণস্বরূপ, বেসক্যাম্প একটি দুর্দান্ত ভয়ঙ্কর বাগ ট্র্যাকার (কারণ এটি প্রকল্প পরিচালনার জন্য), তবে লোকেরা এটি ব্যবহার করতে ইচ্ছুক।

  2. যেহেতু আমরা যে বাগ ট্র্যাকারগুলি ব্যবহার করছিলাম তারা চিত্রের অনুলিপি-পেস্ট সমর্থন করে না, তাই আমি আসলে একটি তুচ্ছ প্রোগ্রাম লিখেছিলাম যা বর্তমান ক্লিপবোর্ডের চিত্রটি ডিস্কে (গাইড হিসাবে) অনুলিপি করে, তারপরে গাইডটিকে ক্লিপবোর্ডে অনুলিপি করে। ন্যূনতম প্রশিক্ষণের পরে, কোনও ব্যবহারকারী প্রিন্ট স্ক্রিনটি হিট করে, একটি বোতামে ক্লিক করে এবং তারপরে বাগ জমা দেওয়ার সরঞ্জামটির ফাইল চয়নকারী ডায়ালগটিতে আটকানো দ্বারা ক্লিপবোর্ড চিত্রগুলি ইস্যুগুলিতে সংযুক্ত করতে পারে।

একটি স্ক্রিনশট (সম্ভবত টিকা সহ এমএস পেইন্টে সম্পাদিত) এবং 1-2 টি বাক্য বেশিরভাগ বৈশিষ্ট্য / বাগগুলি নির্দিষ্ট করতে যথেষ্ট।

এই উভয় পরামর্শই ঘর্ষণ পয়েন্টগুলিকে লক্ষ্য করে যা আমি অভিজ্ঞতা অর্জন করেছি এবং এই দুটি পরামর্শই 10 এরও বেশি ফ্যাক্টর দ্বারা রিপোর্টিং বৃদ্ধি করেছে তবে আপনার নিজের ঘর্ষণ পয়েন্টগুলিকে লক্ষ্য করতে হবে।


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

1

আপনার ক্লায়েন্টের জন্য পরীক্ষা সহজ করুন, তবে আপনার ক্লায়েন্টের পক্ষে উত্পাদনের অনির্ধারিত সংস্করণে কোনও নতুন বৈশিষ্ট্য ব্যবহার করা সত্যিই শক্ত করে তুলুন। এটি নিম্নলিখিত হিসাবে সম্পন্ন করা যেতে পারে:

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

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

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


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

আমি এটি 1 পয়েন্ট সম্বোধনের সুযোগ হিসাবেও ব্যবহার করব। গ্রাহকের কাছে একটি সম্পূর্ণ প্রক্রিয়া প্রস্তাব করুন যেখানে নন-প্রযোজনা পরিবেশে নতুন প্রয়োজনীয়তা লিখিত, সম্মত, পরীক্ষিত, তারপরে প্রকাশিত হয়।

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

@ টোম্যাটো: গ্রাহক যখন না বলে যে তিনি বৈশিষ্ট্যটি পরীক্ষা করেছেন ততক্ষণ আপনি কি পূর্ব-প্রকাশ সংস্করণ থেকে বৈশিষ্ট্যগুলি উত্পাদন সংস্করণে স্থানান্তর করতে কঠোরভাবে অস্বীকার করছেন? আপনার গ্রাহক কি তা অস্বীকার করার চেষ্টা করে?
ডক ব্রাউন

2
"স্পষ্টভাবে চিহ্নিত বিটা সংস্করণের জন্য +1: আপনি যদি পরীক্ষার সংস্করণটি গ্যারেশ বেগুনি রঙের হাতে তুলে দেন তবে মূল পর্দার শীর্ষে একটি বিশাল সবুজ ঝলকানো ব্যানার সহ চিৎকার করছে" টেস্ট সংস্করণ - উত্পাদন ব্যবহারের জন্য নয় - আনসার্ফ - আয়ার্জ! ", তারা এটি উপস্থাপনার জন্য বা এমন কোনও কোথাও ব্যবহার করবে না যেখানে কোনও ক্লায়েন্ট এটি দেখতে পারে। যতক্ষণ না তারা কিছুটা কার্যকর প্রতিক্রিয়া দেয় ততক্ষণ আপনি পরিষ্কার পরিচ্ছন্ন সংস্করণটি ধরে রাখতে পারেন (এটি যদি আপনার কাছে জিম্মি হিসাবে নেন তবে)।
খ্রিস্টান সেভেরিন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.