वी एंड वी प्रतिशोध के लिए नहीं

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

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

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

एफडीए

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

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

हम क्या करते हैं और यह विकास प्रक्रिया और रिलीज चक्र को कैसे प्रभावित करता है, इसके संदर्भ में FDA क्या है?

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

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

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

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

वी एंड वी

वी एंड वी क्या है, और यह स्वीकृति प्रक्रिया को कैसे प्रभावित करता है।

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

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

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

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

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

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

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

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

भूमिकाएँ

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

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

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

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

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

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

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

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

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

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

FRS और URS या BRS - कार्यात्मक और उपयोगकर्ता की आवश्यकताएं। आमतौर पर, दो अलग-अलग दस्तावेज़ होते हैं लेकिन कभी-कभी व्यावसायिक आवश्यकताएँ विशिष्टता होती है जिसमें दोनों चश्मा शामिल होते हैं।

दोष लॉग - औपचारिक एसआईटी के दौरान आवेदन और / या आवश्यकताओं में पहचाने जाने वाले कीड़े का एक लॉग।

माइनर इश्यू लॉग - टेस्ट स्क्रिप्ट (टाइपो, बाएं या अनावश्यक आवश्यकताओं, किसी भी गलती) में मामूली बदलाव का एक लॉग।

टेस्ट सारांश रिपोर्ट - परीक्षण चरण परिणामों के बारे में एक रिपोर्ट, जिसमें निम्नलिखित शामिल हैं:

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

परिनियोजन योजना - जो दस्तावेज़ उत्पादन के लिए तैनाती के लिए उपयोग किया जाता है, उसमें रोल-बैक का विवरण शामिल होता है।

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

प्रलेखन अनुमोदन

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

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

आइए एक टेस्ट सूट के उदाहरण को देखें।

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

टेस्ट सूट पैराग्राफ:

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

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

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

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

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

पर्सनल डेटा के साथ काम करना

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

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

लेकिन तथ्य यह है कि यह हमारी समस्याओं में से सबसे कम है इसका मतलब यह नहीं है कि यह परेशानी नहीं ला सकता है। यहाँ रेक की एक जोड़ी है (दो बार कदम रखने के लिए नहीं) जो हमें अपनी परियोजनाओं पर मिली:

मज़ेदार हो सकता है (उस पल में हमारे लिए नहीं): "द ग्लोब"

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



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

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

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

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

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

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

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

लाभ:

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

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

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

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

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



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

एक और कहानी: "भारी अच्छा है, भारी विश्वसनीय है।" ©

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



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

स्वचालन

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

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

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

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

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

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

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

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

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


सामान्य तौर पर, निर्णय लेने की प्रक्रिया इस प्रकार है:

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

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

निष्कर्ष

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