পরীক্ষার পরিকল্পনা কার লেখা উচিত?


10

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

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

  1. বোতাম ক্লিক করুন ।
  2. ফর্ম ক্ষেত্রে XYZ- এ কী এবং বোতামে ক্লিক করুন বি
  3. আপনার আচরণ সি দেখা উচিত ।

যা অনুরোধ প্রতিটি প্রয়োজন / বৈশিষ্ট্য জন্য আমাদের পুনরাবৃত্তি করতে হবে। এটি মূলত প্রয়োজনীয়তার নথিতে যা রয়েছে তা পুনরায় কাজ করছে।

আমরা আমাদের প্রকল্পগুলি পরিচালনার জন্য একটি চৌকস পদ্ধতির ব্যবহারের দিকে এগিয়ে যাচ্ছি এবং প্রতিটি পুনরাবৃত্তির শেষে এটিও অনুরোধ করা হয়েছে।

ইউনিট এবং ইন্টিগ্রেশন পরীক্ষা একপাশে, শেষ ব্যবহারকারীর গ্রহণযোগ্যতা পরীক্ষা পরিকল্পনা নিয়ে আসা কে হওয়া উচিত? এটি কি পুনরায় সরবরাহকারী বা বিকাশকারীদের হওয়া উচিত?

অগ্রিম ধন্যবাদ.

শুভেচ্ছা
সিকে


1
এই ডেভসগুলির কেবলমাত্র ইনপুটগুলিতে ক্ষেত্রগুলি এবং সম্ভবত কিছু প্রান্তের কেসগুলি পরীক্ষা করা উচিত (এবং ভুলে যাওয়া নয়) বোঝানো হচ্ছে। তবে ঠিক কীভাবে পরীক্ষা করা যায় সে সম্পর্কে তাদের ধাপে ধাপে ধাপে ধাপগুলি দেওয়া উচিত নয়।
ক্যাফগীক

উত্তর:


10

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

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


এক চাকরিতে বছরের পর বছর এটিই আমি বলছিলাম।
ডেভিড থর্নলি

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

1
ঠিক, @teterab। অভ্যন্তরীণ না জানা কিছু ধরণের পরীক্ষার কেসগুলি ডিজাইন করতে সহায়তা করে, ধূসর বাক্স পরীক্ষায় অভ্যন্তরীণ সহায়তা জেনে যেমন, উদাহরণস্বরূপ, আমি কোডের ঝুঁকিপূর্ণ অঞ্চলটি জানি, সেই কোডটিতে পৌঁছানোর জন্য আমাকে কেবল অ্যাপটি প্রমাণ করতে হবে।
dzieciou

7

কিউএ টিমের পরীক্ষা পরিকল্পনাটি লেখার এবং সম্পাদন করা উচিত।

আদর্শভাবে পরীক্ষার পরিকল্পনাটি কার্যকরী স্পেসিফিকেশনের সাথে সমান্তরালে লেখা উচিত - এটি কীভাবে কার্যকারিতা পরীক্ষা করতে হবে তা চিন্তা করে মনকে কেন্দ্রীভূত করে এবং স্পেসিফিকেশনকে উন্নত করে।


3
সম্ভবত বিকাশকারীদের সাহায্যে, তবে বেশিরভাগই QA দল।
জাচারি কে

আমাদের কিউএ টিম না থাকলে কী হবে? তাহলে এই কাজটি কি অনুরোধকারীদের উপর পড়তে হবে? উত্তরগুলি থেকে এখানে, এটি সবচেয়ে যুক্তিযুক্ত হবে।
ckng

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

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

4

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

তাহলে পরীক্ষা পরিকল্পনা তৈরির জন্য কে দায়বদ্ধ? দলটি

দলটি কে? পণ্য উপলব্ধি করতে প্রতিশ্রুতিবদ্ধ যে কোনও ব্যক্তির টিমের সদস্য হওয়া উচিত।

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


2

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

এটি সম্পূর্ণরূপে আপনি কীভাবে কাজ করছেন তার উপর নির্ভর করে তবে আমার মতে বিকাশকারীরা কীভাবে অ্যাপ্লিকেশনটি পরীক্ষা করতে হবে, এটি পরীক্ষা করার জন্য কোন ডেটা ব্যবহার করবেন ইত্যাদি সম্পর্কে কার্যকরী নথি লিখতে হবে না etc.


2

এখানে একটি ধারণা যা উভয় দলকেই সুখী করে তুলতে পারে এবং এগ্রিল পদ্ধতির দিকে এগিয়ে যাওয়ার জন্য এটি উপযুক্ত:

আপনার ব্যবহারকারীর গ্রহণযোগ্যতা চেকগুলি স্বয়ংক্রিয় করুন এবং সেগুলি স্ক্রীনকাস্ট করুন।

http://pragprog.com/magazines/2009-12/automating-screencasts

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

এটি প্রয়োজনীয়তা বাস্তবায়নের জন্য একটি উপায়ও সরবরাহ করে - আপনি কি গোজকো অ্যাডজিকের এক্সিকিউটেবল স্পেসিফিকেশনগুলি জুড়ে এসেছেন? এখানে একবার দেখুন: http://gojko.net/2010/08/04/let- परिवर्तन- the-tune/ আপনি যদি আপনার গ্রাহকদের ডেমো ডেমো করার জন্য একটি নির্বাহযোগ্য ফর্ম হিসাবে প্রয়োজনীয়তাগুলি পাওয়ার উপায় হিসাবে এটি ভাবছেন , তবে হঠাৎ এটি অনেক কম অর্থহীন বলে মনে হয়।

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

1) এখানে আমাদের নতুন নিবন্ধকরণ ফর্ম - এটি কীভাবে কাজ করে তা দেখতে এই স্ক্রিনকাস্টটি দেখুন!

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

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


দুর্দান্ত উত্তর, ক্লায়েন্টের প্রতিক্রিয়া পাওয়ার সময় নিস্তেজ একঘেয়েমি থেকে বের হয়ে আসার দুর্দান্ত উপায়। এবং দুর্দান্ত লিঙ্ক।
এথেল ইভান্স

1

উদাহরণস্বরূপ আপনার ঘর সংস্কার করুন। আপনি কি আপনার ঠিকাদারের দ্বারা সম্পন্ন একটি চেকলিস্ট গ্রহণ করবেন তিনি আপনাকে আপনার জন্য যা করেছেন তা পরীক্ষা করতে বলে? অথবা আপনি কি আপনার নিজের চেকলিস্ট নিয়ে এসে পরীক্ষা করবেন যে ঠিকাদার আপনি যা নির্দিষ্ট করেছেন তা করেছে?

উত্তরটি পরিষ্কার: অনুরোধকারীকে চেকস অনুসারে অনুরোধ করা হয়েছে কি না তা পরীক্ষা করে দেখা উচিত। তার / তার নিজের চেকলিস্টটি নিয়ে এসে অ্যাপটি পরীক্ষা করা উচিত। এই তালিকার বিরুদ্ধে।

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


1

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


আরও তথ্যের জন্য en.wikedia.org/wiki/…
এথেল ইভান্স

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