কেন / কেন বিকাশকারীদের তাদের নিজস্ব কাজ পরীক্ষা করতে দেয় না


81

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

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


6
আপনার প্রশ্নটি মনে হচ্ছে যে বিকাশকারীদের কোনও পরীক্ষা করা উচিত নয়। আমি নিশ্চিত করবো যে বিকাশকারীরা সফ্টওয়্যারটি এটি পরীক্ষা করে যাতে (পরীক্ষার সময় নষ্ট না করে) কাজ করে (কেবল সংকলন করে না) তা নিশ্চিত করার জন্য এটি পরীক্ষা করে।
dnolan

4
@ ডনোলান: আমি এখানে চূড়ান্ত পরীক্ষার কথা বলছি, কোডটি উত্পাদনের আগে পরীক্ষার কথা। অবশ্যই বিকাশকারী বিকাশের সময় পরীক্ষা করা উচিত।
পাইভি

কারণ এটি এখানেই শেষ হয়: ডিভোপ্রেসেস্টস.টাম্বলআর
মিশাল এম

এর কোনও
gnat

উত্তর:


103

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

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


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

কালো টুপি পরীক্ষকরা ...?
মতিন উলহাক

7
? কিভাবে এই কাজ করতে "ডেভেলপারগণ স্বাভাবিকভাবে বিকাশকারীর মানসিকতা নিয়ে কাজ" জন্য +1 কিভাবে এই বিরতি "" "। একটি ভাল পরীক্ষক সম্পর্কে চিন্তা হয়"
Wipqozn

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

127

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

'কীভাবে এটি কাজ করা উচিত' এর বিপরীতে 'এটি কীভাবে কাজ করে' তার মানসিকতা থেকে তাদের নিজেকে মুছে ফেলা বিকাশকারীদের কঠিন মনে হবে।

এর কারণে প্রোগ্রামটি পরীক্ষা করার জন্য উচ্চতর ডিগ্রি অবজেক্টভিটি সহ কাউকে পাওয়া ভাল, যেমন কিউএ বা টেস্ট ইঞ্জিনিয়ার্স


3
সম্মত, একজন বিকাশকারী তাদের প্রয়োগ "পরীক্ষা" করার জন্য ন্যূনতম প্রতিরোধের পথ গ্রহণ করবে, প্রান্তের মামলাগুলি খুব কমই দেখা হবে।
dnolan

68
@ ডোনোলান, এটি কেবল তাদের কোড "সুরক্ষা" নয়, কোডিংয়ের ক্ষেত্রে তারা যা ভাবেননি, তারা পরীক্ষার জন্য ভাবেন না।
StuperUser

4
বিকাশকারীরাও তাদের কাজের দিকনির্দেশনা দেওয়ার চেয়ে একই কুসংস্কারের সাথে পরীক্ষা করেন। পরীক্ষার্থীরা তাদের ভাগ করে নেওয়ার সম্ভাবনা কম।
এপ্রোগ্রামার

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

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

30

পরীক্ষকরা বিরতিতে টেস্ট করুন, সরল। শো স্টপারদের সত্যই খুঁজে পেতে এই ধরণের পক্ষপাতের প্রয়োজন।


15

বিকাশকারীদের তাদের কাজ পরীক্ষা করাতে হবে। এটি একটি অন্তর্নিহিত দায়িত্ব।

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

বিকাশকারীরা সাধারণত বাগ ধরার জন্য বিশাল গর্তযুক্ত জাল ব্যবহার করে। ফলস্বরূপ, ছোট বাগগুলি পালাতে পারে।


"বিকাশকারীদের তাদের কাজের পরীক্ষা করা উচিত It এটি একটি অন্তর্নিহিত দায়িত্ব" - আপনার কাজটি অন্য কারও দ্বারা পরীক্ষিত করার বিষয়টি হ'ল যে বাগ আপনি মিস করেছেন
সেগুলি

15

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


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

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

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

10

একটি উত্সর্গীকৃত পরীক্ষার দল থাকার কয়েকটি ভাল কারণ রয়েছে। প্রথমত, উপরে বর্ণিত হিসাবে, বিকাশকারীরা তাদের কোডটি কার্যকর করে তা পরীক্ষায় খুব ভাল, তবে এটি ভঙ্গ করে না।

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

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

কিউএ দলের সাথে কাজ করে এবং ছাড়াও, আমি আপনাকে বলতে পারি যে আমি তাদের 100% প্রশংসা করি এবং তারা বলবে যে তারা সফ্টওয়্যার দলের একটি মূল্যবান অংশ। আপনার যখন QA টিম থাকে, তখন এটি আপনার কোডটিকে এত সহজ করে দেয় যে খ / সি আপনি জানেন যে এটির পুরোপুরি পরীক্ষা করা হয়েছে এবং এর অর্থ হল আপনি সকাল 3 টা কম কল পেয়ে যাবেন।


ফলাফলের পর্যালোচনা করে এটি প্রয়োজনীয়তার সাথে মিলে যায় তা নিশ্চিত করার জন্য আমি QA সম্পর্কে মূল বিষয়টি পছন্দ করি। কমপক্ষে 2 জন লোক সম্মত হওয়া ভাল এটি এটি "উচিত" হিসাবে কাজ করে।
অ্যান্ডি উইসেন্ডেঞ্জার

জন্য +1 a testing teams knows what should have been written। এটা খুব সত্য।
সিভিএন

8

বিকাশকারীদের তাদের নিজস্ব কোড পরীক্ষা করা উচিত।

স্বতন্ত্র পরীক্ষকরা কেবল বিরতিতে পরীক্ষা করেন না, তারা কোডিং করার সময় বিকাশকারীরা যে অস্টেটেড এবং অপরিজ্ঞাত অনুমানগুলি পরীক্ষা করেন।


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

7

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

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

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


5

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

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

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


3

বিকাশকারী হিসাবে আপনি নিজের কোডের জন্য দায়বদ্ধ, আপনার এটি পরীক্ষা করা উচিত। Does the feature work as expected?উত্তরটি যদি হ্যাঁ হয় তবে আপনি শেষ করেছেন।

কেন আপনি পরীক্ষা-মামলা করবেন না?

  1. আপনি বিষয়নির্ভর , যেমন পাওয়া বাগগুলি আপনার (বা আপনার সহকর্মীরা) লিখেছেন।
  2. কেস-টেস্ট চালানো আপনার পক্ষে কোম্পানির পক্ষে অত্যন্ত ব্যয়বহুল । (আমি আশা করি).

2
এই ধারণাটি যে বিকাশকারীরা <আপনি এখানে করতে চান না টাস্কটি সন্নিবেশ করানো> খুব মূল্যবান আমার অভিজ্ঞতাটি বরং সংক্ষিপ্ত হতে পারে।
জেরেমি

3

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

আপনার প্রকল্প পরিকল্পনা ব্যবহারকারী পরীক্ষার জন্য না? আপনি যদি এটির পরীক্ষা ব্যবহারকারীদের পান তবে আপনি বাস্তবায়নের চেয়ে পূর্বের বাগগুলি ধরতে পারেন যা আমার পৃথিবীতে কোনও খারাপ জিনিস নয়।


3

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

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


হ্যাঁ, অন্যান্য বিকাশকারীদের কোডের পরীক্ষা করা অন্য সংস্থানকরা একটি ন্যূনতম / অস্থায়ী সমাধান। (ধরে নিলাম আপনার কাছে অবশ্যই একাধিক বিকাশকারী রয়েছে!)
তাও

3

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

পরীক্ষার জন্য কৌশল এবং দক্ষতা উভয়ই খুব আলাদা।

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


2

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


1
একেবারে। ওয়ার্কিং কোড পরিস্থিতিটির সঠিক কোড হিসাবে একই জিনিস নয়।
এইচএলজিইএম

2

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


হ্যাঁ, চমৎকার পয়েন্ট। ব্যবসায় বিশ্লেষণের প্রায়শই যে বাস্তবতার অভাব থাকে তার অর্থ হ'ল প্রয়োজনীয়তাগুলি প্রায়শই ভাঙ্গা বা অসম্পূর্ণ শুরু হয়, বিকাশকারীদের হয় প্রয়োজনীয় সময়কালে বার্ন করতে (সূক্ষ্ম, তবে সময় সাপেক্ষ) বা অনুমান করা (প্রায়শই ভুলগুলি যদি বিকাশকারী অনভিজ্ঞ থাকে তবে ডোমেইন).
বার্নার্ড ডাই

2

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

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

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

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

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


2

উপরের মন্তব্যগুলি দুর্দান্ত পয়েন্ট উত্থাপন করে।

পূর্বে উল্লিখিত না হওয়া অতিরিক্ত একটি হ'ল পৃথক পৃথক টেস্ট কোড থাকা প্রয়োজনীয়তাগুলির অতিরিক্ত চেক হিসাবে কাজ করে এবং যদি সিস্টেমটি সেগুলি সঠিকভাবে প্রয়োগ করে।

প্রয়োজনীয়তা এবং ডকুমেন্টেশন নিখুঁত নয় এবং প্রায়শই বাস্তবায়ন কোনও বিকাশকারী দ্বারা প্রয়োজনীয়তার ব্যাখ্যা করার ফলস্বরূপ।

যখন পরীক্ষা পৃথক পৃথক পৃথক ব্যক্তি দ্বারা সম্পন্ন করা হয়, পরীক্ষার পরিকল্পনা তৈরি করার সময় এবং পরীক্ষাগুলি কার্যকর করার সময় তারা প্রয়োজনীয়তার নিজস্ব ব্যাখ্যাও সরবরাহ করে।

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


2

একজন প্রোগ্রামার পরীক্ষার সময়, "পরিমাণ" লেবেলযুক্ত একটি পাঠ্য বাক্স দেখতে পাবে এবং "1" লিখবে। একটি অত্যন্ত অভিজ্ঞ প্রোগ্রামার তারপরে "2" মান সহ একটি ফলোআপ পরীক্ষা করবে।

একজন ব্যবহারকারী "পরিমাণ" লেবেলযুক্ত একটি পাঠ্য বাক্স দেখতে পাবেন এবং "~~ ইউনিকর্নস রোক্স !!! ~~" প্রবেশ করবেন। একজন অভিজ্ঞ ব্যবহারকারী "-12 1/2" ব্যবহার করে দেখুন।

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


2

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

আর একটি কারণ সময়। পর্যায়ক্রমে নির্মিত বড় প্রকল্পগুলির জন্য, উন্নয়ন দলটি প্রথম পর্যায় 1 তৈরি করবে Then এটি সব ধাপে চলতে থাকে, সুতরাং পরীক্ষা করা হচ্ছে স্টেজটি পূর্বেরটি নির্মিত হয়েছিল।


1

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

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

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


3
ওপি বিকাশকারীদের পরীক্ষা করা উচিত কিনা তা জিজ্ঞাসা করছে না; ওপি জিজ্ঞাসা করছে যে এটি বিকাশকারীই একমাত্র পরীক্ষা নিরীক্ষা করছেন এটি একটি ভাল ধারণা ।
মিথ্যা রায়ান

1

আপনি কোডটি পছন্দ করেন কি না তা এই কোডটির সাথে অপরিচিত কেউ দ্বারা পরীক্ষা করা হয়। আপনি যে কেউ আপনার গ্রাহক হতে চান তা প্রশ্ন The


1

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

কারণগুলি চূড়ান্ত পরীক্ষা করা বিকাশকারীদের পক্ষে ঠিক আছে

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

কারণগুলির বিকাশকারী পরীক্ষা করা উচিত নয়

  • আর কিছু

সাধারণভাবে, দেখে মনে হচ্ছে আপনি আসল সমাধানের উপর আক্রমণ করার সঠিক পথে রয়েছেন - এসকিউএ বিশেষজ্ঞকে পরীক্ষার কেস উত্পন্ন করতে ...

দ্রষ্টব্য: আমি সাধারণত বিকাশকারীদের পরীক্ষার অনুমতি দেওয়ার পক্ষে, তবে আমি নিশ্চিত যে প্রথম বুলেট পয়েন্ট রয়েছে ...


1

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

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

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

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


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

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

  • প্রত্যেকেরই পরীক্ষার দায়িত্ব ভাগ করে নেওয়া উচিত । একটি কিউএ দল গুরুত্বপূর্ণ, তবে "টেস্টিং" এমন কিছু হিসাবে তৈরি করা যা কেবল কিউএ টিমই এটি একটি 'পৃথক' ক্রিয়াকলাপ হিসাবে পরিণত করে যা এটি পণ্য বিকাশ এবং কর্মপ্রবাহের সাথে একীভূত হয় না যা কোনও ভাল জিনিস নয়।

  • যখন কোনও উত্পাদন কখনও বিরতি দেয় তখন দুটি কাজ করে:

    1. প্রথম মন্তব্য হিসাবে "হুম, আমাদের কি এটির জন্য পরীক্ষা আছে " বলুন ।
    2. যেকোন ফিক্স তৈরির আগে সমস্যার পূর্বে , পুনরুত্পাদন করার আগে পরীক্ষার অন্তর্ভুক্ত করে

0

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


0

একটি সমস্যা হ'ল বিকাশকারীদের নিজস্ব কোড ভাঙার জন্য কিছুটা উত্সাহ রয়েছে - খুব কম লোকই তাদের নিজস্ব কাজের ত্রুটিগুলি অনুসন্ধান করতে ইচ্ছুক বা ভুল করতে রাজি হন। একটি পৃথক দল থাকা নিশ্চিত করে যাতে জিনিসগুলি নষ্ট হয়ে যায় helps


-1

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

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