প্রোগ্রামারদের পরীক্ষাগুলি ডিজাইনের ক্ষেত্রে পরীক্ষকদের সহায়তা করা উচিত?


17

প্রোগ্রামারদের পরীক্ষাগুলি ডিজাইনের ক্ষেত্রে কতটা সাহায্য করা উচিত?

আমি মনে করি না যে তাদের মোটেই সহায়তা করা উচিত। আমার উদ্বেগ হ'ল যদি তারা পরীক্ষকদের তাদের নিজস্ব কোডের জন্য পরীক্ষার নকশা তৈরি করতে সহায়তা করে তবে তারা সেই কোড সম্পর্কে তাদের নিজস্ব পূর্বসংস্কার এবং অন্ধ দাগ দিয়ে পরীক্ষকদের 'সংক্রামিত' করবে।

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

আমার পরিচিত প্রত্যেকেরই এটির সাথে একমত নয় (এবং আমি তাদের নির্দিষ্ট কিছু নির্দিষ্ট বিষয় বুঝতে পারি)। অন্যেরা এ সম্পর্কে কী ভাবেন? সাহিত্যে এটি কি কোথাও আলোচনা হয়?

উত্তর:


12

আমি রাজী. প্রোগ্রামাররা পরীক্ষার্থীদের কার্যকরী চশমাগুলি বোঝার জন্য, গবেষণার জন্য সংস্থানগুলি আবিষ্কার করতে সহায়তা করতে পারে তবে কীভাবে পরীক্ষার কাছে যেতে হবে সে সম্পর্কে তাদের নিজস্ব ধারণা দিয়ে পরীক্ষকদের মনকে দূষিত করা উচিত নয়।


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

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

11

আমি মনে করি QA- এর রাজ্যে বিকাশকারী এবং পরীক্ষার্থীদের শান্তিপূর্ণভাবে সহাবস্থান করার সুযোগ রয়েছে। :)

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

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


6

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

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

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


এটি গ্রহণযোগ্য উত্তর হওয়া উচিত। পরিবর্তে, ওপি একটি উত্তর বেছে নিয়েছে যা "ডিভস এবং পরীক্ষক" এর সম্পর্ক সম্পর্কে তার কুসংস্কারকে সমর্থন করে।
ডক ব্রাউন

5

আমি যেভাবে দেখছি তা হল আমার কোড পরীক্ষা করা QA এর কাজ নয়। পরীক্ষকের কাজটি নিশ্চিত করা আমার কোডটি সেই কাজের জন্য সমস্ত প্রয়োজনীয়তা পূরণ করে।

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

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


5

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

আপনার কোডটি কাঁচা নিকাশী না হলে কোনও "দূষণ" ছিল না, এবং এটি সম্পূর্ণ ভিন্ন কারণে হবে।

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

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

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

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

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


3

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

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


3

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


2

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

লেখাগুলি পরীক্ষাগুলি সহায়ক বলে মনে করে তা হ'ল আমি যখন পরীক্ষাগুলি লিখি তখন বাগগুলি খুঁজে পাই। আমাকে আরও দৃust় কোড লিখতে সহায়তা করার জন্য আমি বিভিন্ন দৃষ্টিকোণে ভাবি। তবে এটি সত্য যে পরীক্ষার কভারেজটি সীমাবদ্ধ হতে পারে। এই ক্ষেত্রে, QAs সর্বদা আমাদের জানাতে পারে যে তারা কী coveredেকে রাখতে চায়। বা, আমরা ত্রুটি দেখলে আমরা আরও পরীক্ষাগুলি নিষ্ক্রিয় করতে পারি।


0

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

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

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