वी एंड वी का मतलब प्रतिशोध नहीं है

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

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

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

एफडीए

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

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

हमारे लिए एफडीए क्या है और यह विकास प्रक्रिया और रिहाई चक्र को कैसे प्रभावित करता है?

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

FDA व्यावहारिक रूप से विकास प्रक्रिया की चिंता नहीं करता है, हम सामान्य SCRUM पर काम करते हैं (या बल्कि, SCRUM नहीं - वे कहते हैं कि गैर-स्प्रिंट रिलीज़ साइकिल के साथ इस तरह के "संशोधित SCRUM" को कॉल करना फैशनेबल है)। हम स्प्रिंट के अंत में (और यहां तक ​​कि तीन स्प्रिंट के अंत में भी नहीं जाते हैं, और दस भी अगर टाइमलाइन में 15 स्प्रिंट शामिल हैं), यानी, डिलीवरी के दृष्टिकोण से अंतिम उपयोगकर्ता तक, हम कुछ झरना जैसे हैं।

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

रिलीज चक्र काम की मात्रा पर निर्भर करता है, रिलीज आम तौर पर पुनरावृत्तियों के माध्यम से नहीं जाते हैं। रिलीज़ के बाद, एप्लिकेशन लंबे समय तक अपरिवर्तित रह सकता है, यानी रिलीज़ के बीच का विराम - कुछ महीनों से एक साल या उससे अधिक तक।

वी एंड वी

यह किस प्रकार का जानवर है, वी एंड वी, और यह स्वीकृति प्रक्रिया में कैसे परिलक्षित होता है।

“सॉफ्टवेयर परियोजना प्रबंधन, सॉफ्टवेयर परीक्षण, और सॉफ्टवेयर इंजीनियरिंग, सत्यापन और सत्यापन (V & V) यह जांचने की प्रक्रिया है कि सॉफ्टवेयर सिस्टम विनिर्देशों को पूरा करता है और यह अपने इच्छित उद्देश्य को पूरा करता है। इसे एक सॉफ्टवेयर गुणवत्ता नियंत्रण के लिए भी संदर्भित किया जा सकता है। यह सामान्य रूप से सॉफ़्टवेयर टेस्टर की ज़िम्मेदारी है, जो सॉफ़्टवेयर डेवलपमेंट जीवनचक्र के भाग के रूप में है। सरल शब्दों में, सॉफ़्टवेयर सत्यापन यह है: "मान लें कि हमें एक्स का निर्माण करना चाहिए, क्या हमारा सॉफ़्टवेयर बिना किसी बग या अंतराल के अपने लक्ष्यों को प्राप्त करता है?" दूसरी ओर, सॉफ़्टवेयर सत्यापन है: "क्या एक्स हमें बनाया जाना चाहिए था? क्या X उच्च स्तरीय आवश्यकताओं को पूरा करता है? » विकिपीडिया

मुफ्त अनुवाद:

“परियोजना प्रबंधन, परीक्षण और सॉफ्टवेयर विकास, सत्यापन और सत्यापन (V & V) यह सत्यापित करने की प्रक्रिया है कि विकसित सॉफ्टवेयर विनिर्देशों को पूरा करता है और अपने इच्छित कार्य को पूरा करता है। इसे सामान्य रूप से गुणवत्ता नियंत्रण के लिए भी जिम्मेदार ठहराया जा सकता है। आमतौर पर, परीक्षण इंजीनियर सॉफ्टवेयर विकास जीवन चक्र के सत्यापन और सत्यापन के लिए जिम्मेदार होते हैं। सरल शब्दों में, सॉफ़्टवेयर सत्यापन के रूप में वर्णित किया जा सकता है: "मान लीजिए कि हमें सिस्टम एक्स को विकसित करना है। क्या हमने बिना किसी लक्ष्य और मान्यताओं के लक्ष्य प्राप्त किया है?" दूसरी ओर, सॉफ़्टवेयर सत्यापन "विकसित सिस्टम एक्स वास्तव में कुछ है?" हम क्या पाना चाहते थे? क्या सिस्टम X उच्च-स्तरीय आवश्यकताओं को पूरा करता है? "

दूसरे शब्दों में:
सत्यापन: क्या हम उत्पाद सही कर रहे हैं?
सत्यापन: क्या हम सही उत्पाद बना रहे हैं?

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

• SIT - सिस्टम इंटीग्रेशन टेस्टिंग
• यूएटी - उपयोगकर्ता स्वीकृति परीक्षण

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

कवरेज की आवश्यकता कब आवश्यक नहीं है?

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

अंततः, उत्पाद के अनुपालन के लिए आवश्यकताओं और आवश्यकताओं के अनुपालन के लिए उत्पाद के परीक्षण के लिए स्वीकृति परीक्षण का सार नीचे आता है।

भूमिका

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

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

स्वीकृति दस्तावेज

उत्पाद के रिलीज के हिस्से के रूप में, एक दस्तावेज़ीकरण पैकेज बड़ी संख्या में घोंसले के स्तर के साथ बनाया जाता है, जिसमें दस्तावेज़ीकरण शामिल है जो यह बताता है कि उत्पाद का परीक्षण कैसे किया गया था, क्यों इस तरह से परीक्षण किया गया था और अन्यथा नहीं, और क्या विशेष रूप से परीक्षण किया गया था और क्या छोड़ दिया गया था:

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

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

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

टेस्ट सूट - कार्यात्मक क्षेत्र, परीक्षण के प्रकार या किसी अन्य सुविधा द्वारा गठित परीक्षणों या चेकलिस्ट का एक सेट।

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

पीडीएस - उत्पाद डिजाइन विशिष्टता, एक तकनीकी सलाहकार या परियोजना वास्तुकार द्वारा विकसित एक दस्तावेज, अनिवार्य रूप से उच्च-स्तरीय और निम्न-स्तरीय अनुप्रयोग वास्तुकला (एचएलए और एलएलए) का संयोजन।

एफआरएस और यूआरएस या बीआरएस कार्यात्मक और उपयोगकर्ता की आवश्यकताएं हैं, आमतौर पर दो अलग-अलग दस्तावेजों के रूप में, लेकिन कभी-कभी व्यावसायिक आवश्यकताओं विनिर्देश में संयुक्त।

दोष लॉग - परीक्षण (आवेदन दोष और आवश्यकताओं) के दौरान पाया दोषों का एक लॉग।

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

टेस्ट सारांश रिपोर्ट - परीक्षण के परिणामों पर रिपोर्ट। TSR परीक्षण योजना का समापन दस्तावेज है और इसमें शामिल हैं:

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

परिनियोजन योजना - एक दस्तावेज जिसके लिए समर्थन और एकीकरण जिम्मेदार है, को एसआईटी पर्यावरण पर प्रतिष्ठानों के दौरान संकलित किया जाता है और बाद में उत्पादन पर संस्करण को तैनात करने के लिए उपयोग किया जाता है।

सत्यापन सारांश रिपोर्ट - सत्यापन योजना के लिए समापन दस्तावेज।

दस्तावेज़ स्वीकृति

प्रलेखन के अनुमोदन की कोई भी प्रक्रिया सशर्त रूप से 3 चरणों में विभाजित है:

• दस्तावेज तैयार करना।
• समीक्षा।
• स्वीकृति।

टेस्ट सूट के उदाहरण पर विचार करें।

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

परीक्षण किट के घटक:

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

बदले में, प्रत्येक परीक्षण में शामिल हैं:

• सेट के भीतर नाम और विशिष्ट पहचानकर्ता।
• विवरण।
• पूर्व शर्त।
• Postconditions।
• अनुरेखण (परीक्षण में कवर की गई आवश्यकताएं)।
• निष्पादन की विशेषताएं (उदाहरण के लिए, संवेदनशील डेटा को मास्क करने के लिए निर्देश)।
• कदम (आवश्यक कार्रवाई, अपेक्षित और वास्तविक परिणाम)।
• परीक्षा का परिणाम।
• चलाएँ।
• Revyuver।

एक परीक्षण का सामान्य जीवन चक्र एक प्रतिक्रिया झरना जैसा दिखता है और इस तरह दिखता है:

1. लेखन
   आवश्यकताओं का विश्लेषण। कार्यक्षमता की सबसे पर्याप्त कवरेज के लिए परीक्षण डिजाइन तकनीकों की परिभाषा और अनुप्रयोग। लेखन कदम।
2. कुंवारी लड़कियों पर परीक्षण मार्ग / मार्ग
   इस स्तर पर, यह मूल्यांकन किया जाता है कि एप्लिकेशन आवश्यकताओं को कितना पूरा करता है, और संभावित बगों के थोक, जिसमें बग्स शामिल हैं, को बाहर निकाल दिया जाता है।
3. परियोजना प्रबंधक की समीक्षा (SIT टीम लीड)
   शैलीगत और तार्किक समीक्षा।
4. एसआईटी पर्यावरण पर टेस्ट पास / पास
   इस स्तर पर, पर्यावरण की स्थापना, पर्यावरण और कॉन्फ़िगरेशन से जुड़ी त्रुटियां पकड़ी जाती हैं (डिफ़ॉल्ट रूप से यह माना जाता है कि एसआईटी का वातावरण ठीक है या लगभग पूरी तरह से पीआरडी को दोहराता है)। इस चरण के सफलतापूर्वक पूरा होने का अर्थ है कि जो संस्करण घिरा हुआ है वह स्थिर है और रिलीज को एक उम्मीदवार माना जा सकता है।
5. ग्राहक की समीक्षा (वैश्विक QC)
   ग्लोबल क्यूसी पुष्टि करता है कि आवश्यकताओं को पूरा किया गया है और यह लिखा है कि एसओपी परीक्षण कंपनी के साथ हैं।
6. स्वीकृति (ग्लोबल क्यूसी, तकनीकी पीओ, बिजनेस पीओ)।
7. एसआईटी पर्यावरण पर औपचारिक परीक्षण निष्पादन (जारी उम्मीदवार संस्करण)
   पास (पी। 6) के लिए परीक्षणों की मंजूरी और एसआईटी पर्यावरण (पी। 4) पर परीक्षण पास के सफल समापन के बाद, परिणाम की औपचारिक फिक्सिंग के साथ परीक्षण औपचारिक रूप से एसआईटी पर्यावरण पर किया जाता है। यदि परीक्षण पास पर पाए जाने वाले कीड़े को औपचारिक नहीं बनाया जाता है और बस इसी तरह जीरा में प्रवेश किया जाता है जो विकास प्रक्रिया के दौरान होता है, तो औपचारिक पास पर पाए जाने वाले प्रत्येक बग के लिए एक अलग दोष रूप बनाया जाता है, जो उत्पाद प्रलेखन के आउटपुट पैकेज में शामिल है।
8. परियोजना के लिए जिम्मेदार मार्ग (एसआईटी टीम लीड) के परिणामों की समीक्षा।
   इसी तरह से बिंदु 3 में, भरने की शैली की जांच की जाती है और परिणामों का विश्लेषण किया जाता है।
9. ग्राहक की समीक्षा (वैश्विक QC)
   ग्लोबल क्यूसी परिणाम, संभावित त्रुटियों, पुष्टियों की उपस्थिति (उदाहरण के लिए, स्क्रीनशॉट) को भरने की शुद्धता और पूर्णता की जांच करता है। एक महत्वपूर्ण बिंदु, क्योंकि यह ग्लोबल क्यूसी है जो बाहरी ऑडिट (एफडीए या ग्राहकों द्वारा) को दस्तावेजों का पैकेज प्रदान करने के लिए जिम्मेदार है।

व्यक्तिगत डेटा के साथ काम करें

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

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

लेकिन तथ्य यह है कि यह हमारी समस्याओं में से सबसे कम है इसका मतलब यह नहीं है कि यह परेशानी नहीं ला सकता है। यहाँ कुछ रेक हैं जो हम अपनी परियोजनाओं के लिए इस्तेमाल करते थे:

ए प्रेटेंस ऑफ फन: ए ग्लोब

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



Moral: डेमो से दो घंटे पहले डेटा को न छुएं।

कहानी नंबर दो: "गुमनामी के बारे में"

पृष्ठभूमि: डेटा को बड़ी संख्या में स्रोतों से भंडार में एकत्र किया जाता है, डेटा विभिन्न डोमेन से संबंधित होते हैं, लेकिन पहचानकर्ताओं द्वारा परस्पर जुड़े होते हैं।

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

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

व्यवहार में इलेक्ट्रॉनिक बनाम पेपर वर्कफ़्लो

एचपी एएलएम के साथ काम करने वाले को सर्कस में हंसी नहीं आती है।

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

पेशेवरों:

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

विपक्ष (विशेष रूप से HP ALM के लिए):

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

कागजी कार्रवाई और मैनुअल हस्ताक्षर से संबंधित केस स्टडी: "रिलीज से पहले दुःस्वप्न"

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



नैतिक: साधनों का चुनाव लक्ष्यों के अनुरूप होना चाहिए।

कहानी नंबर दो: "गुरुत्वाकर्षण अच्छा है, गंभीरता विश्वसनीय है"

पेपर वर्कफ़्लो पेपर है (जो संदेह करेगा)। सबसे बड़े आवेदन से एक दूर के स्वागत के लिए, यह पांच किलोग्राम के क्षेत्र में बदल सकता है।



निष्कर्ष जो खुद को उपरोक्त कहानियों (और कई अनकही से) से पता चलता है: इलेक्ट्रॉनिक दस्तावेज़ प्रबंधन की सूचीबद्ध और सूचीबद्ध कमियों के बावजूद - यदि आप चुन सकते हैं, तो निश्चित रूप से इलेक्ट्रॉनिक का चयन कर सकते हैं, भले ही एचपी एएलएम (अब एचपी नहीं)।

स्वचालन

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

हम कम से कम आंशिक स्वचालन के लिए कैसे और क्यों आए?

पहला काम खुद को यह समझाना था कि कुछ मामलों में हम वास्तव में समय हासिल करेंगे। हां, यह समझ में आता है: हर कोई स्वचालन में विश्वास नहीं करता है और अक्सर इसका उपयोग खुद को सही नहीं ठहराता है - क्योंकि इसका उपयोग गलत तरीके से किया जाता है, वहां नहीं, और उसके लिए नहीं, लेकिन यह एक अलग रिपोर्ट के लिए एक विषय है, जिनमें से "स्वचालन के लिए थोड़ा कम होना चाहिए" !!! ", लेकिन अभी भी मात्रा में।

दूसरा ग्राहक को यह समझाना है कि वह समय प्राप्त करेगा और यह औपचारिक दृष्टि से पर्याप्त विश्वसनीय और स्वीकार्य होगा। उद्योग को एक कारण से नियंत्रित किया जाता है।

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

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

हमारे मामले में सवालों की सूची:

1. क्या इस विशेष मामले में परीक्षण को स्वचालित करना संभव है?
2. क्या घटक * परीक्षण स्थिर होने के लिए स्वचालित होने के लिए है?
3. हमें कितनी बार एक घटक के लिए लिखे गए परीक्षण चलाने चाहिए?
4. क्या यह कार्यक्षमता व्यवसाय के लिए महत्वपूर्ण है? *
5. परीक्षण को स्वचालित करना कितना मुश्किल है?

* स्थिर = घटक कुछ समय के लिए नहीं बदला है और आगामी रिलीज के लिए घटक परिवर्तन की योजना नहीं है।
** यह व्यापार विश्लेषक द्वारा आवश्यकताओं के लिए जोड़े गए क्षेत्र के मूल्य के आधार पर चिपका है।


सामान्य शब्दों में, निर्णय लेने की प्रक्रिया इस प्रकार है:

1. इनपुट FRS की आवश्यकताओं को प्राप्त करता है।
   एक डिज़ाइन मैट्रिक्स संकलित किया गया है, जहां प्रत्येक पंक्ति FRS से एक आवश्यकता है। कॉलम के रूप में:
   
   • आवश्यकता विवरण
   • प्रश्न 1-5
   • टीम का फैसला
   • अनुमानित लेखन समय
   • अनुमोदन
   • टिप्पणियाँ
2. टीम सवालों के जवाब नीचे रखती है और प्राप्त आंकड़ों के आधार पर यह निर्धारित करती है कि क्या यह एक विशिष्ट आवश्यकता / पूरे या हिस्से में आवश्यकताओं के समूह के स्वचालित परीक्षण के लायक है।
3. ग्राहक प्रस्तावित समाधान की समीक्षा करता है और अंतिम संस्करण को मंजूरी देता है।
4. डिजाइन मैट्रिक्स द्वारा अनुमोदन के बाद, ऑटोटेस्ट लिखा जाता है। ऑटोटेस्ट्स के लिए वर्णलेख का वर्णन गेरकिन पर किया गया है और मैनुअल टेस्ट (ग्लोबल क्यूसी, टेक्निकल ओनर, बिजनेस ओनर) के लिए इसी तरह की समीक्षा से गुजरना पड़ता है। ग्राहक की ओर से तकनीकी विशेषज्ञ सहित, अनुरोधों के पूल पर चरण परिभाषाएँ, पृष्ठ ऑब्जेक्ट और इतने पर समीक्षा की जाती है। ग्लोबल क्यूसी के पक्ष में ऑटोटेस्ट परिणाम और उत्पन्न रिपोर्ट अनुमानित हैं।

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

निष्कर्ष

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