यदि आप योग्य कर्मचारियों, समय और धन की अनंत संख्या रखते हैं, तो आप निश्चित रूप से परीक्षण रणनीति के बिना कर सकते हैं। एक शब्द में, वर्षों में एक रिलीज में कटौती करने की क्षमता। इस तरह की काल्पनिक आदर्श परिस्थितियों में, किसी भी रणनीति की आवश्यकता नहीं है, क्योंकि आप अपने उत्पाद को सभी मौजूदा तरीकों से परीक्षण कर सकते हैं जब तक आप चाहें, किसी भी क्रम में तकनीकों को लागू करना, कई मंडलियों के लिए, और जल्दी या बाद में किसी तरह से आप तैयार गुणवत्ता के उत्पादन के लिए आएंगे।

हकीकत में, परियोजना हमेशा समय सीमा तक जलती है, टीम की कार्य क्षमता / कौशल रबर नहीं होते हैं, और उत्पाद आवश्यकताएं लगातार विकसित हो रही हैं - और यहां आप एक अच्छी योजना के बिना नहीं कर सकते। इसलिए, एक परीक्षण रणनीति बचाव के लिए आती है।

इस लेख में, हम उन सवालों की पेशकश करेंगे, जिनमें परीक्षण रणनीति बनाने के लिए चर्चा करने की आवश्यकता है, और उदाहरणों के साथ यह दिखाना है कि किसी विशेष मामले में परीक्षण उपकरण के बारे में निर्णय कैसे किए जाते हैं।

0. चलो इसे किनारे पर पता करें

हमें परीक्षण रणनीति की आवश्यकता क्यों है?

• सीमित संसाधनों की शर्तों में प्रक्रिया को व्यवस्थित करने के लिए। इसलिए, शुरू करने के लिए, यह महसूस करना अच्छा होगा कि हमारे पास क्या संसाधन हैं।
• सभी परियोजना प्रतिभागियों के लिए परीक्षण की भूमिका को समझने के लिए, यह क्या दे सकता है, इससे हमें क्या लाभ होगा। ताकि गुणवत्ता नियंत्रण के क्षेत्र में जो कुछ हो रहा है उसकी सभी को समान अपेक्षाएं और समझ हो। और उन संभावित समस्याओं की पहचान करने के लिए भी जो चर्चा प्रक्रिया में अनिवार्य रूप से स्पष्ट हो जाएंगे।

रणनीति कौन बनाता है?

सबसे पहले, ज़ाहिर है, क्यूए और जरूरी एक परियोजना प्रबंधक।

तो, परीक्षक परियोजना प्रबंधक या परीक्षक प्रबंधक को हाथ से लें, कॉफी डालें, कागज, मार्कर, लैपटॉप लें, और ... चलें!

1. हम परियोजना पर किस प्रकार के परीक्षण का उपयोग करेंगे और क्यों

बहुत शुरुआत में, हम सभी मौजूदा प्रकार के परीक्षण को याद करने और प्रत्येक पर निर्णय लेने की पेशकश करते हैं: क्या हम इसका उपयोग करेंगे और क्यों। आइए कुछ उदाहरण देखें कि आप एक विशिष्ट प्रकार के परीक्षण की आवश्यकता पर कैसे निर्णय ले सकते हैं।

परीक्षण संस्करण स्थापना

किसी भी मामले में, भले ही आवेदन पूरी तरह से नया हो और पहली बार स्थापित (तैनात) किया जा रहा हो, आपको यह जांचने की आवश्यकता है कि इसे कैसे लिया गया: क्या यह शुरू होता है, क्या इसके साथ काम करना शुरू करना संभव है। चाहे वह मोबाइल एप्लिकेशन हो, डेस्कटॉप या वेब।

वेब अनुप्रयोगों के लिए, यह चर्चा करना उपयोगी है कि हम कैसे सत्यापित करते हैं कि अपडेट के बाद डेटा खो नहीं गया है। एक सक्रिय सत्र से हम किस तरह के व्यवहार की उम्मीद करते हैं।

डेस्कटॉप और मोबाइल एप्लिकेशन के लिए, आपको उपयोगकर्ता को नया वितरण और अपडेट प्रक्रिया देने का एक तरीका सोचने की आवश्यकता है, जो उपयोगकर्ता द्वारा लॉन्च किया गया है।

सभी परियोजनाओं के लिए, सिस्टम को गर्म करने के लिए ऐसी चीजों पर चर्चा करना उपयोगी है: निर्देशिकाओं को स्थापित करना, उपयोगकर्ताओं और अन्य डेटा को सेट करना जो उपयोगकर्ता को सिस्टम के साथ आरंभ करने की आवश्यकता होती है।

प्रदर्शन परीक्षण

ऐसे कारक निर्णय को प्रभावित करेंगे: सिस्टम में कितने उपयोगकर्ता काम करेंगे, कितना डेटा संसाधित किया जाएगा।

Dano	निर्णय
हम जानते हैं कि 10 लोग उत्पाद का उपयोग करेंगे। और हम जानते हैं कि वे कई हजार रिकॉर्डों की तालिका सौंपेंगे।	यह बड़ी मात्रा में डेटा के साथ वॉल्यूम परीक्षण की योजना बनाने के लिए समझ में आता है।
हम जानते हैं कि उत्पाद का उपयोग करने की प्रक्रिया में, उपयोगकर्ता ग्राहक के सर्वर पर कई मीडिया फाइलें अपलोड करेंगे।	आपको यह पता लगाना होगा कि यह सर्वर किस तरह के लोड के लिए बनाया गया है, और इस डेटा को ध्यान में रखें।
एप्लिकेशन का उपयोग कई लोगों द्वारा एक सप्ताह में किया जाता है, डेटा की मात्रा न्यूनतम होती है।	प्रदर्शन परीक्षण की आवश्यकता नहीं है।

प्रतिगमन परीक्षण

पूरे सिस्टम की पूरी जांच में हमेशा बहुत समय लगता है। इसलिए, एक निर्णय लेने के लिए, उपयुक्तता का मूल्यांकन करना आवश्यक है: एक पूर्ण प्रतिगमन के लिए कितना समय आवश्यक है, और यदि हम इसका संचालन नहीं करते हैं तो जोखिम क्या हो सकता है।

Dano	निर्णय
हम किसी उत्पाद या प्रोग्राम मॉड्यूल के पहले संस्करण को रोल आउट करते हैं।	प्रतिगमन परीक्षण की आवश्यकता नहीं है।
परियोजना बहुत बड़ी है, और नई सुविधाओं के जारी होने से पहले एक पूर्ण प्रतिगमन विकास की अवधि के तुलनीय है। आपूर्ति की आवश्यक दर इसकी अनुमति नहीं देती है।	हम तय करते हैं कि हम प्रतिगमन परीक्षण नहीं करते हैं, लेकिन अन्य प्रकार के परीक्षण और निगरानी पर अधिक ध्यान देते हैं।
माइक्रोसर्विसेज के बीच बातचीत अनुबंध परीक्षणों द्वारा कवर की जाती है।	एक पूर्ण प्रतिगमन अव्यवहारिक है। मैन्युअल परीक्षण के ढांचे में, हम डेवलपर की सिफारिश पर कार्यक्षमता का एक प्रतिगमन आयोजित करते हैं।

एकीकरण परीक्षण

एकीकरण परीक्षण की आवश्यकता को निर्धारित करने के लिए, सभी बाहरी प्रणालियों को सूचीबद्ध करना उपयोगी है, जिसके साथ उत्पाद बातचीत करता है और इंगित करता है कि हमें कौन सा डेटा प्राप्त होता है और संचारित होता है।

Dano	निर्णय
पोर्टल से बिक्री का डेटा विश्लेषणात्मक प्रणाली में स्थानांतरित किया जाता है।	यह न केवल यह सत्यापित करना महत्वपूर्ण है कि बिक्री चली गई है, सही प्रारूप में चली गई है, बल्कि यह भी कि वे सही प्रारूप में आए - रास्ते में कुछ भी नहीं खो गया था।

स्थानीयकरण परीक्षण

परियोजना के बारे में प्रश्नों का उत्तर देना महत्वपूर्ण है:

• किन भाषाओं का समर्थन किया जाना चाहिए
• क्या हम समाधान के संचालन के दौरान अतिरिक्त स्थानीयकरण के कनेक्शन के लिए प्रदान करते हैं,
• हमारे उपयोगकर्ता किन देशों में काम करेंगे,
• क्या बिक्री और किन मुद्राओं में होगी
• क्या आपको समय क्षेत्र के साथ काम करने की आवश्यकता है?

Dano	निर्णय
प्रणाली में 2 भाषाएँ हैं: रूसी और अंग्रेजी।	यह चर्चा करने के लिए समझ में आता है कि हम उपयोगकर्ता को दिखाने के लिए किस भाषा में इंटरफ़ेस को समझेंगे।
ग्राहक एप्लिकेशन को बहुभाषी बनाने के लिए कहता है।	यह अपने आप में इस सवाल का जवाब देने के लायक है कि हम ग्रंथों का सत्यापन कैसे करेंगे, जहां हम अरबी से ग्रंथों को प्राप्त करेंगे, स्क्रीन को उस पाठ के लिए कैसे अनुकूलित किया जाएगा जो दाएं से बाएं लिखे गए हैं।

क्रॉस-ब्राउज़र और क्रॉस-प्लेटफ़ॉर्म

हम सामान्य रूप से सभी उपकरणों पर मोबाइल एप्लिकेशन के सही संचालन को सत्यापित नहीं कर सकते हैं। वेब एप्लिकेशन के मामले में, तुरंत सवाल उठता है: क्या हम IE9 का समर्थन करेंगे? इस प्रकार के परीक्षण को रणनीति में दर्ज करने से पहले, हम विश्लेषण करते हैं (यदि समाधान पहले से काम कर रहा है) या मान लें (यदि यह पहले से काम नहीं करता है) तो वे इसके लिए क्या उपयोग करेंगे।

Dano	निर्णय
मोबाइल ऐप उपयोगकर्ता देश भर में कर्मचारी हैं।	हम अपने एप्लिकेशन के प्लेटफार्मों के उपयोग पर मौजूदा आंकड़ों को देखते हैं और निर्णय लेते हैं कि हम उनमें से किस पर परीक्षण करेंगे।
हमारे आवेदन में स्थिर मशीनों पर कॉर्पोरेट उपयोगकर्ता हैं।	सबसे अधिक संभावना है, हम केवल एक ब्राउज़र का उपयोग करने की सिफारिश कर सकते हैं। और इस तरह क्रॉस-ब्राउज़र संगतता के लिए परीक्षण और समर्थन के लिए समय कम करें।

इसी तरह, आपको अन्य सभी प्रकार के परीक्षण को पार्स करने की आवश्यकता है:

• कार्यात्मक (संचालित या नहीं),
• स्वीकृति (जो इसका संचालन करता है और कैसे),
• UX / UI (एक अच्छे इंटरफ़ेस के लिए उद्देश्य मानदंड क्या हैं)
• मॉड्यूलर और यूनिट (जो अनुबंध परीक्षण लिखते हैं, जो यूनिट परीक्षण लिखते हैं और चाहे हम उन्हें बिल्कुल भी लिखते हैं),
• सुरक्षा परीक्षण (जो डेटा सुरक्षा की गारंटी देता है, और हैकिंग के लिए सिस्टम कितना प्रतिरोधी है),
• विफलता और पुनर्प्राप्ति (सिस्टम आपात स्थिति में कैसे व्यवहार करेगा)

और अन्य।

2. परीक्षण में प्राथमिकताएँ

फोर्स मेज्योर सभी प्रोजेक्ट्स पर होता है, इसलिए रैंडम बटनों को हथियाने के बजाय इस मामले में एक सोची-समझी योजना के साथ एक चीट शीट का होना उपयोगी है।



सामान्य मोड में, सार्थक प्राथमिकताएं भी महत्वपूर्ण हैं। उदाहरण के लिए, ऑटोटेस्ट्स के विकास को प्राथमिकताओं को ध्यान में रखते हुए योजना बनाई जानी चाहिए: सबसे पहले, सबसे महत्वपूर्ण परिदृश्य स्वचालित (धुआं परीक्षण) हैं।

Dano	निर्णय
हवाई जहाज में चढ़ते समय यात्रियों को सेवाएं बेचने के लिए हमारे कार्यक्रम का उपयोग हवाई अड्डों पर किया जाता है। और अगर इस समय किसी तरह की त्रुटि होती है, तो हमारे पास हॉट फ़िक्स के लिए समय नहीं होगा। इसलिए, कोई गलती नहीं होनी चाहिए!	हम पहली बार में हवाई अड्डे पर उपयोग के परिदृश्य की जांच करते हैं।

3. काम के लिए माहौल

यह सोचना आवश्यक है कि टीम के साथ समन्वय करना चाहिए और काम के लिए कौन से वातावरण की आवश्यकता है, और उनका उपयोग कौन करेगा। एक नियम के रूप में, 2-3 परिवेश और बिक्री पर्याप्त है।

Dano	निर्णय
CD / CI प्रोजेक्ट पर, कार्यक्षमता के प्रारंभिक परीक्षण के लिए धूम्रपान परीक्षण लिखा गया था।	हमें एक शाखा में कोड की प्राथमिक असेंबली के लिए एक वातावरण की आवश्यकता है, धुएं के परीक्षण की दौड़, जहां बाहरी सिस्टम स्टब्स द्वारा बंद हो जाते हैं। ग्राहक सेवाओं (क्यूए) के साथ मैनुअल और एकीकरण परीक्षण के लिए भी आपको एक वातावरण की आवश्यकता होती है।
बीटा परीक्षण सत्र नियमित रूप से आयोजित किए जाते हैं।	हमें एक ऐसा वातावरण चाहिए जो "बाहर" दिखाई दे, क्यूए-पर्यावरण की तुलना में अधिक स्थिर हो।

4. प्रोजेक्ट पर टेस्टर का काम

यह उन सभी गतिविधियों पर पहले से चर्चा करने के लिए समझ में आता है जो हम परियोजना पर परीक्षक से उम्मीद करते हैं, क्योंकि वे सभी परियोजनाओं पर समान रूप से आवश्यक नहीं हैं। यह टीम के लिए किसी के लिए आश्चर्य की बात हो सकती है कि परीक्षक कुछ कर रहा है या कुछ नहीं कर रहा है।

यह आइटम प्रबंधकों को यह समझने में मदद करेगा कि परीक्षक से किस डिग्री की आवश्यकता है, और किस समय लोड की उम्मीद है। मौजूदा परियोजनाओं के लिए, यह इंगित करना भी महत्वपूर्ण है कि हम (क्यूए) सक्षम हैं ताकि प्रबंधक समझ सके कि उसके पास क्या मतलब है।

उदाहरण के लिए, यह हो सकता है:

• पूर्णता और स्थिरता के लिए स्प्रिंट उद्देश्यों का मूल्यांकन,
• परीक्षण के लिए श्रम लागत का आकलन,
• परीक्षण (या परीक्षण मामलों) के लिए जाँचकर्ताओं की तैयारी,
• ऑटोटेस्ट स्क्रिप्ट की समीक्षा
• कार्यात्मक ऑटोटेस्ट्स लिखना,
• प्रत्यक्ष मैनुअल परीक्षण,
• पर्यावरण में परिवर्तन की तैनाती,
• परीक्षण रणनीतियों को अद्यतन करना, आदि।

5. परियोजना पर परीक्षण प्रलेखन

किनारे पर सहमत होना आवश्यक है, और संभवतः आगे और नियमित रूप से परीक्षण प्रलेखन के प्रारूप की समीक्षा करें:

• क्या परीक्षण प्रलेखन हम परियोजना पर आचरण करेंगे,
• क्या हम परीक्षण के मामले लिखेंगे
• जाँच करें
• और इस प्रलेखन को कितनी बार अद्यतन करना है।

Dano	निर्णय
सिस्टम की कार्यक्षमता का लगभग एक तिहाई के लिए लगभग 300 परीक्षण मामले पहले ही लिखे जा चुके हैं। उन्हें न केवल समय-समय पर समीक्षा की जानी चाहिए, बल्कि समय-समय पर अद्यतन भी किया जाना चाहिए।	सीमित संसाधनों की स्थितियों में, हमने परीक्षण मामलों के साथ काम नहीं करने का फैसला किया, लेकिन प्रत्येक विशिष्ट कार्य के लिए सूचियों की जांच करने के लिए खुद को प्रतिबंधित कर दिया। और परिणामस्वरूप, हम परीक्षण की गुणवत्ता को खोए बिना प्रलेखन का समर्थन करने में समय बचाते हैं।

6. परीक्षण के मामले कैसे उत्पन्न होते हैं

परिचालन की स्थिति और परिदृश्य विशिष्ट समाधान पर निर्भर करते हैं, इसलिए चर्चा करना सुनिश्चित करें:

• क्या परीक्षण डिजाइन तकनीक यह उपयोग करने के लिए समझ में आता है। इस पैराग्राफ के भाग के रूप में, उन वस्तुओं की सूची बनाना उपयोगी है, जिनके साथ अनुप्रयोग और उनके समतुल्य वर्ग काम करते हैं।
• एक विशिष्ट परियोजना के लिए परीक्षण लिपियों के साथ आने के लिए उत्तराधिकार और भोज जीवन का अनुभव क्या है। मोबाइल एप्लिकेशन के लिए, मानक उत्तराधिकारियों का उपयोग करना सुविधाजनक है, उदाहरण के लिए, "I SLICED UP FUN"।

Dano	निर्णय
बीमा परियोजना पर, उपयोगकर्ता (एजेंट) को मशीन का निरीक्षण करना होगा, जिसके दौरान फोटो खींचना और उन्हें सर्वर पर अपलोड करना आवश्यक है। सामान्य ज्ञान यह बताता है कि गैरेज में मुश्किल से वाईफाई है। और कभी-कभी, कोई मोबाइल कनेक्शन नहीं है।	इसलिए, आपको केवल 3 जी के साथ काम करते समय ही आवेदन की जांच करने की आवश्यकता है, लेकिन संचार के अभाव में भी।
एयरलाइन के मोबाइल एप्लिकेशन में कोई भी उपयोगकर्ता कार्रवाई परिदृश्य का हिस्सा है। उदाहरण के लिए, आप पहले आरक्षण बनाए बिना टिकट जारी नहीं कर सकते।	इसलिए, "उपयोग केस" तकनीक का उपयोग करना तर्कसंगत है।

7. ट्रैकर के साथ काम करने की प्रक्रिया

विभिन्न ट्रैकर्स में, कार्यों की संभावनाएं और प्रकार भिन्न होते हैं। ट्रैकर की क्षमताओं के आधार पर, हम आपको इस बात पर सहमत होने की सलाह देते हैं कि बगों और कार्यों को व्यवस्थित करने के लिए किस प्रकार के कार्यों को कौन और किस सिद्धांत द्वारा निर्धारित करता है।

टीम के साथ मुख्य बातें बोलें:

• हम हमारे द्वारा पाई गई त्रुटियों और ग्राहकों द्वारा पाई गई त्रुटियों के बीच अंतर करेंगे (और क्या हमें उनके बीच अंतर करने की आवश्यकता है),
• सुधार कैसे करें
• क्या उन सुधारों को अलग करना आवश्यक है जो हमने स्वयं का आविष्कार किया था जो ग्राहक ने अनुरोध किया था। कैसे?
• यदि यह फिर से नहीं होता है, तो किस स्थिति में गलती की जानी चाहिए?
• किस स्थिति को अंतिम माना जाता है।

Dano	निर्णय
परीक्षक एक बग बनाता है। डेवलपर इसे पुन: पेश नहीं कर सकता है, इसे अस्वीकृत स्थिति में बदल देता है।	परीक्षक कार्य की पुनरावृत्ति करता है और बंद (अंतिम) की स्थिति निर्धारित करता है, यदि त्रुटि वास्तव में दूर हो जाती है, या विवरण को परिष्कृत करता है और नया पर लौटता है।
ग्राहक संशोधन के लिए कार्य निर्धारित करता है। डेवलपर समझता है कि उसके पास लागू करने के लिए पर्याप्त डेटा नहीं है।	डेवलपर कार्य को फीडबैक स्थिति में रखता है।

(हमने इस लेख में बग्स और यूजरस्टोर का वर्णन करने के तरीकों के बारे में अधिक लिखा है)।

8. परीक्षण शुरू करने और समाप्त करने के लिए मानदंड

यदि परीक्षक किसी भी समय किसी भी कार्य को लेता है, तो यह आदेश नहीं है, लेकिन अराजकता है। क्योंकि कार्य तैयार नहीं हो सकता है। या तैयार है, लेकिन मुक्त नहीं है। या तैयार, तैनात, लेकिन अन्य कार्यों पर निर्भर करता है जो अभी तक तैयार नहीं हैं। नतीजतन, परीक्षक समय और तंत्रिकाओं को खोजता है और त्रुटियों को ठीक करता है, लेकिन वास्तव में आपको बस इंतजार करना होगा। इसलिए, हम इस बात से सहमत हैं कि कार्य के ऊपर QA जिम्मेदारी क्षेत्र किस बिंदु पर शुरू और समाप्त होता है।

परियोजना के विकास के शुरुआती चरणों में, कार्य / संस्करण की तत्परता आंख द्वारा निर्धारित की जाती है।
आत्म-जागरूकता के विकास के साथ, हम समझते हैं कि हमें स्पष्ट मानदंडों की आवश्यकता है कि कार्य / संस्करण तैयार है। ताकि यह निर्णय सभी के लिए पारदर्शी हो, न कि "परीक्षक को यह महसूस होता है कि सब कुछ सामान्य है।" उदाहरण के लिए, एक ट्यून्ड सीडी के संदर्भ में, हम मानते हैं कि कार्य परीक्षण के लिए तैयार है जैसे ही यह क्यूए वातावरण में तैनात किया जाता है और इसे हल की स्थिति प्राप्त होती है।

Dano	निर्णय
परियोजना पर एक प्रक्रिया स्थापित की गई है कि परीक्षण के लिए एक चेकलिस्ट प्रत्येक संशोधन के लिए संकलित है।	यदि हम चेकलिस्ट पर सभी बिंदुओं को पारित कर चुके हैं तो हम सत्यापित कार्य पर विचार करते हैं।
परियोजना स्प्रिंट पर काम कर रही है।	स्प्रिंट को तैयार माना जाता है यदि सभी सुधार बंद स्थिति में हैं और प्राथमिकता के साथ कोई त्रुटि नहीं है सामान्य और उच्चतर।
परियोजना ने प्राथमिकता के आधार पर कार्यक्षमता की एक सूची तैयार की।	हम मानते हैं कि संस्करण रिलीज़ के लिए तैयार है यदि सूची के पहले बिंदुओं से कार्यक्षमता सफलतापूर्वक काम करती है।
परियोजना ने परीक्षण के मामले लिखे हैं और रिलीज से पहले प्रतिगमन परीक्षण किया है।	एक संस्करण रिलीज़ के लिए तैयार माना जाता है, यदि प्रतिगमन परीक्षण के परिणामों के आधार पर, प्राथमिकता के साथ कोई त्रुटि सामान्य या उच्च नहीं पाई गई (या असफल परिदृश्यों का प्रतिशत 5 से अधिक नहीं था)।

9. काम के लिए उपकरण

तब अनुभाग उपयोगी होता है ताकि कार्यों को प्रभारी (प्रशासक और प्रबंधक को) पहले से ही परीक्षण नियोजन स्तर पर रखा जा सके और काम की शुरुआत तक सभी आवश्यक उपकरण प्राप्त कर सकें।

यह इस तरह के मुद्दों पर चर्चा करने लायक है:

• परीक्षण दस्तावेज़ीकरण करने के लिए हमें किन उपकरणों की आवश्यकता होती है,
• क्या उपकरण परीक्षण डेटा तैयार कर सकते हैं,
• स्वचालन के लिए कौन से उपकरण आवश्यक हैं।

Dano	निर्णय
कार्यान्वित कार्यक्षमता का वर्णन करने के लिए, हमने दिमाग के नक्शे का उपयोग करने का निर्णय लिया।	टीम के लोग अलग-अलग प्लेटफ़ॉर्म पर काम करते हैं, इसलिए आपको एक माइंड-मैप फ़ाइल फॉर्मेट चुनने की ज़रूरत है, जिसे आप विंडोज, लिनक्स और मैक में काम कर सकते हैं।
हम सहमत थे कि हमें परियोजना पर स्वचालन की आवश्यकता है।	इसलिए, हमें ऐसे उपकरण चाहिए जो हमें परीक्षण डेटा तैयार करने की अनुमति दें (उदाहरण के लिए, डेटाबेस पर स्क्रिप्ट को रोल करने के लिए), हमें पाइपलाइन (उदाहरण के लिए, न्यूमैन) के भीतर लॉन्च करने की अनुमति देते हैं, और हमें स्टब्स (उदाहरण के लिए, वायरमॉक) बनाने की अनुमति देते हैं।

10. परियोजना गुणवत्ता मूल्यांकन और निगरानी उपकरण

इस खंड में, हम इस बात पर सहमत होने का प्रस्ताव देते हैं कि KPI आवेदन के स्वास्थ्य का आकलन करने के लिए क्या हैं (परीक्षण कवरेज की स्पष्ट गणना के अलावा)। यह सूचक मापनीय और प्राप्य होना चाहिए। विशेष रूप से, निम्नलिखित प्रश्नों को समझें और उत्तर दें:

• हम ठेस में त्रुटियों को कैसे ट्रैक करेंगे
• हम उपयोगकर्ताओं से प्रतिक्रिया कैसे एकत्र करेंगे,
• हम अपनी सुविधाओं के उपयोग पर आंकड़े कैसे एकत्र करेंगे।

Dano	निर्णय
सिस्टम की एक नई सुविधा के जारी होने के बाद, उपयोग निगरानी को कॉन्फ़िगर किया गया है (उदाहरण के लिए, सेवा बिक्री की संख्या)।	जांच के लिए गिरावट एक ट्रिगर है। शायद यह फीचर उम्मीद के मुताबिक काम नहीं करता है, या हमने स्क्रिप्ट का हिस्सा लागू नहीं किया है।
हमने बुनियादी संचालन करने की गति की निगरानी के लिए कार्यक्रम को कॉन्फ़िगर किया है।	काम की गुणवत्ता के लिए मानदंड यह होगा कि उपयोगकर्ताओं की आमद के साथ, निष्पादन की गति कम नहीं होती है।

निष्कर्ष

एक एकल और सार्वभौमिक परीक्षण रणनीति जो सभी के लिए उपयुक्त है, मौजूद नहीं है। यह व्यक्तिगत रूप से प्रत्येक परियोजना के लिए डिज़ाइन किया गया है।

• यह समझना महत्वपूर्ण है कि रणनीति अपने आप में एक अंत नहीं होनी चाहिए - यह केवल एक उपकरण है जो हमें अपने लक्ष्यों को प्राप्त करने की अनुमति देता है।
• यह बिल्कुल सामान्य है कि सभी सवालों का जवाब तुरंत देना संभव नहीं है। यह उत्पाद के ग्राहक या उपयोगकर्ताओं के साथ फिर से बात करने का अवसर है।
• परियोजना बढ़ रही है, और अगर कल उत्पादकता के साथ परेशान करना बहुत जल्दी था, तो कल शायद यह समय होगा। इसलिए, रणनीति तैयार करने के बाद, नियमित रूप से अपडेट करना और उसकी भरपाई करना और टीम में बदलाव लाना महत्वपूर्ण है।
• एक रणनीति लिखने के बाद, यह आमतौर पर स्पष्ट हो जाता है कि परीक्षण में विफलताएं कहां हैं और क्या करने की आवश्यकता है। यह लक्ष्य निर्धारित करने, गतिशीलता देखने और ... कुछ समय बाद रणनीति को अपडेट करने का एक अवसर है।