जोखिम आधारित परीक्षण

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

लेख में, हम बताएंगे कि कैसे हमने सिम्बीरॉफ्ट पर जोखिम के साथ काम किया (उदाहरण के रूप में इंटरनेट अधिग्रहण प्रणाली और अन्य परियोजनाओं का उपयोग करके) और ग्राहक परियोजनाओं में हम जोखिम मूल्यांकन और प्रबंधन के कौन से तरीकों का उपयोग करते हैं।

परियोजना की शुरुआत में जोखिम

शुरू करने के लिए, हम बैंकिंग क्षेत्र के लिए विकास में अपने अभ्यास से एक उदाहरण देते हैं।

ग्राहक का प्रस्ताव: व्यक्तियों के लिए बैंक के वेब संस्करण पर ध्यान केंद्रित करना।

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

हमारे तर्क: मोबाइल और वेब संस्करणों द्वारा दर्शकों की समीक्षाओं और वितरण के आधार पर उपयोगकर्ता की प्राथमिकताओं के आंकड़े।

निष्कर्ष: व्यक्तियों के लिए, मोबाइल संस्करण अधिक सुविधाजनक है, क्योंकि फोन हमेशा हाथ में रहता है। ऑपरेशन तेज हैं, प्राधिकरण प्रणाली आपको सभी सुविधाजनक सेवाओं तक पहुंचने की अनुमति देती है। इस मामले में, सबसे लोकप्रिय कार्यों के सीमित सेट तक त्वरित पहुंच महत्वपूर्ण है।

कानूनी संस्थाओं के लिए, प्रदान किए गए कार्यों की पूर्णता, बड़ी मात्रा में जानकारी के साथ अपलोड करने, प्रिंट करने और काम करने की क्षमता महत्वपूर्ण हैं। इसके लिए, वेब संस्करण अधिक सुविधाजनक है।

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

परीक्षण की रणनीति को व्यावसायिक उद्देश्यों को पूरा करना चाहिए

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

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

निष्कर्ष: परियोजना, इसकी बारीकियों या विकास के चरण के आधार पर, परीक्षण की रणनीति बदल जाती है।

सर्वोत्तम गुणवत्ता के उत्पाद को सुनिश्चित करने के लिए परियोजना के लक्ष्यों के लिए रणनीति का चयन किया जाना चाहिए। वह सवालों के जवाब "क्या", "कहाँ" और "कब" का परीक्षण करेगी। किसी भी क्षण में, आप जानते हैं कि आप कहां हैं और भविष्य में आप कहां आएंगे - रणनीति के अनुसार।

एक व्यावसायिक लक्ष्य ग्राहक डेटा की सुरक्षा, साथ ही साथ उत्पादन स्तर पर सॉफ़्टवेयर को सुनिश्चित करना हो सकता है। सुरक्षा विकास प्रक्रिया के साथ शुरू होती है और परीक्षण चरण के माध्यम से जारी रहती है।

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

परीक्षण रणनीति के कारण, किसी विशेष परियोजना के लिए वास्तव में महत्वपूर्ण पहलुओं पर जोर दिया जा सकता है। यह तर्कसंगत है कि मोबाइल गेम या एक जटिल बैंकिंग सीआरएम-सिस्टम की रिहाई के लिए परीक्षण के विभिन्न तरीकों की आवश्यकता होती है।

बैंकिंग परीक्षण रणनीति

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

हम किन तकनीकों का उपयोग करते हैं:

• लचीली योजना और आंतरिक रिलीज की तैयारी;
• उपयोगकर्ता कहानी तैयार करना;
• रैलियों का आयोजन;
• पूर्वव्यापी आचरण करना।

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

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

हाल ही में, एक बैंकिंग परियोजना में, हमें संघीय कानून में बदलाव का सामना करना पड़ा - 18% से 20% तक वैट दर में वृद्धि। कानून के परिवर्तन के अनुकूल कई प्रारंभिक कार्य किए गए थे, क्योंकि परिवर्तन न केवल रूपों, इंटरफेसों के प्रतिस्थापन, बल्कि कई गणना सूत्रों के तर्क के परिवर्तन से संबंधित था। कई प्लेटफार्मों पर सही प्रदर्शन सुनिश्चित करना आवश्यक था। इसके अलावा, आस्थगित भुगतान फ़ंक्शन में, 18% और 20% की दरों के साथ संक्रमण की अवधि को ध्यान में रखना आवश्यक था।

अब हम इस बारे में अधिक विस्तार से बात करेंगे कि हम अपनी रणनीति कैसे बनाते हैं और हम अक्सर जोखिम-आधारित परीक्षण क्यों चुनते हैं।

जोखिम-आधारित परीक्षण के पेशेवरों

कई परीक्षण रणनीतियाँ हैं जिन्हें विशिष्ट उद्देश्यों के लिए चुना गया है:

• आवश्यकताओं के आधार पर;
• व्यवस्थित;
• प्रतिक्रियात्मक रणनीतियों;
• सलाहकार रणनीति।

जटिल व्यावसायिक तर्क के साथ परियोजनाओं के साथ काम करने के मामले में, सिस्टम के डिजाइन में कठोर आवश्यकताओं का निर्धारण करना आवश्यक है, जिस पर परीक्षण आधारित है। एक उपयुक्त उपकरण आवश्यकताओं-आधारित परीक्षण है।

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

जोखिम दो प्रकार के होते हैं:

1. उत्पाद जोखिम

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

2. परियोजना जोखिम

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

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

किसी परियोजना पर जोखिम आधारित दृष्टिकोण का कार्यान्वयन चार चरणों में होता है:

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

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

इंटरनेट अधिग्रहण प्रणाली के परीक्षण के उदाहरण द्वारा जोखिम आधारित दृष्टिकोण पर विचार करें।

जोखिम के साथ काम करें (इंटरनेट अधिग्रहण प्रणाली के उदाहरण पर)

हम निम्नलिखित आवश्यकताओं को पूरा करते हैं:
D1.Provide 1000 प्रति सेकंड सिस्टम के साथ कनेक्शन।
डी 2। लेन-देन सुरक्षा।
डी 3। लेन-देन की पहुंच केवल लेनदेन करने वाले व्यक्ति को ही उपलब्ध होनी चाहिए।
D4। एसईटी (सुरक्षित इलेक्ट्रॉनिक लेनदेन) मानक प्रदान करना और समर्थन करना।

उत्पाद जोखिम के रूप में, हम भेद कर सकते हैं:
RP1। एक साथ कनेक्शन के साथ सिस्टम क्रैश।
RP2। लेनदेन के दौरान SQL इंजेक्शन का उपयोग करना।
RP3। URL में पैरामीटर बदलते समय किसी और के लेन-देन तक पहुंच।
RP4। लेन-देन के समय बैंक से कनेक्शन खो जाने पर डेटा का नुकसान।
RP5। SET (सुरक्षित इलेक्ट्रॉनिक लेनदेन) प्रणाली प्रदान करते समय अमान्य प्रमाणपत्र का उपयोग।

संगठनात्मक जोखिम के रूप में:
RO1। बाहरी प्रणालियों की दुर्गमता के कारण विकसित प्रणाली का पतन।
RO2। एक परीक्षण वातावरण में पाया जा सकता है कि मुश्किल से पुन: पेश मामलों की उपस्थिति।

इस प्रकार, प्रत्येक जोखिम तार्किक रूप से उन आवश्यकताओं का पालन करता है जो सिस्टम में हैं, लेकिन उनके लिए सीमित नहीं है। जोखिम आवश्यकताओं को पूरा करते हैं और अतिरिक्त मामलों की पहचान करते हैं जो सिस्टम के साथ काम करते समय उत्पन्न हो सकते हैं।

जोखिम को कम किया जा सकता है या परियोजना के उद्देश्यों और प्रणाली की आवश्यकताओं के आधार पर मुआवजा दिया जा सकता है। यह स्वीकार किया जाता है कि जोखिम को कम से कम एक बार परीक्षण मामले द्वारा कवर किया जाता है:

1. प्रत्येक उत्पाद जोखिम के लिए, परीक्षण मामलों का एक सेट RP1-RP4 इस शर्त के साथ तैयार किया जाता है कि प्रत्येक आवश्यकता और प्रत्येक जोखिम को कम से कम एक परीक्षण मामले द्वारा कवर किया जाना चाहिए। परीक्षण के उद्देश्यों के आधार पर, परीक्षण मामलों के सेट का विस्तार एक निश्चित स्तर तक किया जाता है।

2. प्रत्येक संगठनात्मक जोखिम के लिए, गतिविधियों की एक सूची तैयार की जाती है जो विकसित होने वाले उत्पाद पर जोखिम के प्रभाव को कम कर सकती है।

जोखिम मूल्यांकन और प्रबंधन तकनीक

जोखिमों के आकलन और प्रबंधन के लिए कई तरीके हैं: हल्के तरीके (PRAM, PRISMA) और अधिक औपचारिक (FMEA, FTA)।

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

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

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

हल्के जोखिम विश्लेषण के तरीके औपचारिक लोगों के समान हैं। वे तकनीकी या वाणिज्यिक जोखिमों पर ध्यान केंद्रित करते हैं, जोखिम की घटना की संभावना और इस संभावना को प्रभावित करने वाले कारकों का वजन करते हैं।

हालांकि, इन विधियों द्वारा उपयोग किए जाने वाले केवल दो कारक जोखिम और इसके प्रभाव की संभावना हैं। इसके अलावा, ये दृष्टिकोण निर्णय लेने के लिए सरलीकृत गुणात्मक निर्णय और पैमानों का उपयोग करते हैं।

हमारी टीमें लचीले हल्के तरीकों का उपयोग करती हैं और PRAM और PRISMA दृष्टिकोण को अपने लक्ष्यों के अनुकूल बनाती हैं।

हम जोखिम-आधारित परीक्षण के साथ कैसे काम करते हैं

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

उत्पादों के साथ एक जोखिम तालिका बनाई जाती है। वे एक जोखिम होने की संभावना का आकलन करते हैं और पांच-बिंदु पैमाने पर सिस्टम पर इसके संभावित प्रभाव का आकलन करते हैं। तालिका 1 में - सबसे मजबूत प्रभाव, 5 - सबसे कमजोर। संभावना 1 के लिए भी - उच्च संभावना, 5 - कम संभावना।

हम उत्पाद जोखिम के साथ कैसे काम करना जारी रखते हैं

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

हम निम्नलिखित जांचों का चयन करते हैं:

TC1। सिस्टम से 1000 से अधिक कनेक्शन के साथ लोड की जांच करें
TC2। 1000 सिस्टम कनेक्शन के साथ लोड टेस्ट
TC3। लेनदेन के दौरान SQL इंजेक्शन दर्ज करें
TC4। अन्य डेटा को प्रतिस्थापित करके, सफल लेनदेन पृष्ठ पर SQL इंजेक्शन दर्ज करें
TC5। लेनदेन करते समय इनपुट के लिए उपलब्ध फ़ील्ड में XSS (क्रॉस-साइट स्क्रिप्टिंग) स्क्रिप्ट दर्ज करना
TC6। लेन-देन के दौरान डिस्कनेक्ट किए गए इंटरनेट कनेक्शन का अनुकरण
TC7। सत्यापन चरण में लेन-देन सत्र से बाहर निकलना
TS8। लेन-देन के दौरान समय सीमा समाप्त प्रमाण पत्रों का सत्यापन



इस प्रकार, प्राथमिकता की जांच टीसी 2, टीसी 4, टीसी 5 हैं।

TC6 और TC8 का उच्च प्रभाव पड़ता है, लेकिन इसकी संभावना कम होती है, इसलिए उनके लिए जाँच की प्राथमिकता कम है, लेकिन जाँच भी आवश्यक है।

TC7 आवश्यकताओं में से किसी पर भी लागू नहीं होता है, लेकिन एक नकारात्मक परिदृश्य के लिए परीक्षण का विस्तार करता है, जो सिस्टम के स्थिर संचालन के साथ संभव है।

हम प्रोजेक्ट जोखिम के साथ कैसे काम करना जारी रखते हैं

हम प्रोजेक्ट जोखिमों के लिए भी कार्रवाई निर्धारित करते हैं, जिसके द्वारा हम अतिरिक्त उपाय और निर्णय लेते हैं।

जोखिम पर “RO2। हार्ड-टू-प्रजनन मामलों की उपस्थिति जो परीक्षण वातावरण में पता नहीं लगाई जा सकती ”, आप निम्नलिखित ले सकते हैं:

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

आपातकालीन योजना

उत्पाद या प्रोजेक्ट जोखिम कार्यों में से एक के मामले में एक कार्य योजना होना महत्वपूर्ण है। कभी-कभी यह परियोजना की एक बैकअप प्रणाली स्थापित करने से बचा सकता है। हमेशा जोखिम को न्यूनतम स्तर तक कम करना संभव नहीं है, लेकिन कम से कम इसके परिणामों को कम करना संभव होना चाहिए। हमारी पोस्ट "क्रिसमस स्टोरी" इस विषय पर थी: एक जोखिम कैसे काम कर सकता है, इसकी संभावना शून्य हो जाती है।

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

निष्कर्ष

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