কেন পরীক্ষক এবং প্রোগ্রামার একে অপরের পছন্দ করেন না? [বন্ধ]


18

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

এটি কি আমার দ্বারা সঠিক সিদ্ধান্ত নেওয়া হয়েছে, এটি কেন এবং এই ধরনের সমস্যাগুলি এড়াতে আমরা কী করতে পারি?


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

উত্তর:


50

আমি মনে করি এটি সাধারণীকরণ ও সরলকরণেরও বেশি।

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

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

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

সম্পাদন করা

আরও মনে রাখবেন, আমি মনে করি যে দুজনের মধ্যে সম্পর্ককে সমর্থন করার জন্য দেবের চেয়ে আরও বেশি পরীক্ষক রয়েছে।

দেবের জীবনকে আরও উন্নত বা খারাপ করা আমাদের পক্ষে আরও সহজ, তবে লক্ষ্যটি কেবল "বাগগুলি খুঁজে পাওয়া" নয়, সম্ভাব্য সমাধানগুলি সন্ধান করা। তাহলে আমি পারবো না, তবে আমি পারবো না, এবং আমি যাকে বাগ নিয়োগ পরার সঙ্গে কাজ করবে যে সময়ে একটি সমাধান খুঁজে বের করা। তবে যদি এটি একটি সহজ সমাধান হয় তবে আমি এমন একটি সম্ভাব্য সংশোধন যা আমি বিশ্বাস করি তা সরবরাহ করব যা বিভিন্ন প্রয়োজনীয়তা এবং আমি লিখব এমন পরিণতিতে রিগ্রেশন টেস্ট পূরণ করবে।


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

3
@ মারক মান: আমি মনে করি সময় নষ্ট করার বিষয়ে আমাদের একটি ভিন্ন দৃষ্টিভঙ্গি রয়েছে: একটি QA দৃষ্টিকোণ থেকে, অন্য কারও কাজের মানের জন্য দায়বদ্ধ হওয়া একটি আকর্ষণীয় পরিস্থিতি। আমি যখন বিবেচনা করি যে কখনও কখনও কিউএ-তে এমন লোক থাকে যা দেব দলের কিছু লোকের দ্বিগুণ বিকাশকারী হয় ... হতাশা হ'তে পারে এবং আপনি চিন্তাভাবনা শেষ করেন "কেবল এটি লিখুন, এবং এটি কাজ করবে I এটি আবার পরীক্ষা করার সমস্যা এবং একই বাগ বা পুনরায় উত্থাপনের সমস্যাটি আবার কাটাতে চাই না "" এছাড়াও, যদি আমি কারও কাজ / দিনকে আরও সহজ করে তুলতে সহায়তা করতে পারি তবে আমি একজন সুখী মানুষ।
স্টিভেন এভার্স

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

28

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

সমস্যাগুলি কেন পপ আপ?

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

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


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

16

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

এটিকে প্রশমিত করার উপায়গুলি হ'ল বিকাশকারী এবং পরীক্ষকরা সমাপ্ত পণ্যটিকে পুরো টিমের আউটপুট হিসাবে দেখায় (পরীক্ষকগণ এবং বিকাশকারীগণ সহ) এবং তাদের বুঝতে দেয় যে পরীক্ষাটি একা একা দোষ-অনুসন্ধানের মিশন নয় তবে এর একটি গুরুত্বপূর্ণ অংশ উন্নয়ন প্রক্রিয়া। এবং যদি বিকাশকারীরা টেস্টিংকে সত্যিকারের কাজ বলে মনে করেন না , বা এটি সহজ, তাদের পরীক্ষা ম্যাট্রিক লিখতে, শত শত পরীক্ষার কেস কার্যকর করতে, প্রতিটি একক পদক্ষেপ এবং প্রতিটি ফলাফল নথিতে নথী করুন have


2
একমত। প্রথম দিন থেকেই পরীক্ষকদের উন্নয়নের অংশ হিসাবে তৈরি করা (পরিকল্পনা এবং ডিজাইনের সময় পরীক্ষা করা) অনেকগুলি ঘর্ষণ এড়াতে সহায়তা করে।
মার্টিন উইকম্যান

3
কীটি হ'ল ত্রুটিগুলি খুঁজে বের করার থেকে প্রোগ্রামটির উন্নতি করার উপায়গুলি খুঁজে পেতে সহায়তা করার মনোভাবের উপায়টি পরিবর্তন করা । পরীক্ষক হিসাবে সহজেই এই ধারণায় জড়িয়ে থাকা সহজ যে ত্রুটিগুলি খুঁজে পাওয়া আপনার প্রাথমিক লক্ষ্য।
এডিএ-কিএ মার্ট-ওরা-y

@ এডিএ-কিএ মর্ট-ওরা-ওয়াই: ভাল কথা!
হতাশ

"কারণ" -> "কারণ"
পিটার মর্টেনসেন

8

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

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

আমি মনে করি ব্যক্তিত্বদের এড়িয়ে চলতে এবং টাস্কটি হস্তান্তর করার জন্য হাতের কাজটির দিকে মনোনিবেশ করা দীর্ঘস্থায়ী। যদি কোনও সংস্থা যথেষ্ট বড় হয় তবে ডাবল ব্লাইন্ড টেস্টিং দুর্দান্ত ধারণা is

একজন পরীক্ষক যিনি স্পষ্টতই সমস্যাগুলি প্রকাশ করতে পারেন এবং কোডার যারা সমাধানগুলি পরিষ্কারভাবে প্রয়োগ করেন তারা দুর্দান্ত দল।


5

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

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

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

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


5

প্রোগ্রামার এবং পরীক্ষকরা যখন একে অপরকে পছন্দ করেন না, প্রায়শই এটি কারণ তারা ভুল করে কল্পনা করে যে তাদের লক্ষ্যগুলি বিরোধ conflict


3

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

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

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


3

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

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

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

এছাড়াও কিছু বিকাশকারী কিউএ তলান করে। তবুও আমি কিউএর চেয়ে বরং গ্রাহকের চেয়ে ত্রুটি আবিষ্কার করতাম ....


2

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

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

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


2

বিকাশকারী হিসাবে, আমি পরীক্ষকদের সাথে আমার ভাগ্যের উত্তেজনা অনুভব করেছি।

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

এটি বলেছিল, ভাল পরীক্ষকরা তাদের ওজনের সোনার পক্ষে মূল্যবান - আমি তাত্ক্ষণিকভাবে একজন ভাল টেস্টারের জন্য লসি বিকাশকারীকে বাণিজ্য করব। একটি ভাল পরীক্ষক একটি মানের পণ্য সরবরাহ করার অংশীদার।

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


1

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


1

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

এই সমস্যাটি এড়ানোর একটি ভাল উপায় হ'ল 3 টি পক্ষ, বিকাশকারী, পরীক্ষক এবং কিছু মধ্যস্থতাকারী হয় কোনও ব্যবসায় বিশ্লেষক বা প্রকল্প পরিচালক যেভাবে বিভিন্ন সীমানা মামলা পরিচালনা করা উচিত through বিকাশকারী এবং পরীক্ষকদের মধ্যে মতবিরোধ দেখা দিলে কিছু ধরণের উদ্বোধন দেখা দিতে পারে consider


1

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

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

তারপরে 11 তম ঘন্টা একটি ব্যাচ ত্রুটি পাওয়ার আনন্দ আছে; নির্ধারিত সময়সীমা অবনতিশীল, আপনার চেইনটিতে আপনার তাত্ক্ষণিক ব্যবস্থাপকের কাছ থেকে চাপ আসবে এবং আপনি যে সমস্যার আগেই স্থির করেছেন তা সম্পর্কে আপনি একটি নতুন ত্রুটি পেয়েছেন এবং আপনাকে সত্যিকার অর্থে সময় নিতে হবে না প্রক্রিয়া মাধ্যমে এটি প্রমাণ।

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

খারাপ জুজু


1

এটি প্রায়শই তিনটি কারণ থেকে উদ্ভূত হয় -

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

1

আমি পরীক্ষক পছন্দ করি, তবে দুটি ক্ষেত্রে আমি দ্বন্দ্ব পেয়েছি।

  1. যখন পরিচালনা খেলোয়াড় খেলেন এবং একে অপরকে সরিয়ে রাখেন।

  2. যখন বিষয়গুলি প্রতিনিয়ত জমা দেওয়া হয় তবে বিশদটির অভাব হয়, যেমন "স্ক্রিন এক্স কাজ করে না"।


0

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.