देवऑप्स, कैटरीना क्लोकी में परीक्षण के लिए पुस्तक प्रैक्टिकल गाइड का सारांश

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

परीक्षण संगठन के दृष्टिकोण कैसे बदल गए हैं:

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

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

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

DevOps और CI के युग में परीक्षण

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

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

कैटरीना की मुख्य थीसिस है कि आपको हमेशा काम करने की शुरुआत से लेकर आखिरी रिलीज होने तक काम करने की जरूरत है।

काम का आयतन बहुत बड़ा है। सवाल उठता है कि सभी परीक्षण कैसे व्यवस्थित करें और पागल न हों।

जहां परीक्षण शुरू करना है

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

DevOps सिर्फ लचीले परीक्षण से अधिक है। DevOps की विचारधारा का तात्पर्य पूरी तरह से डिबग की गई प्रक्रिया से है, जो न केवल उत्पादन में एक नए संस्करण को शीघ्रता से लागू करती है और पिछले हिस्से में वापस लाती है, बल्कि देव और ऑपरेशन कमांड के बीच समान रूप से डिबगिंग संचार भी करती है।

अगर आपके परीक्षण में चंचलता है तो जाँच के लिए 10 मापदंड:

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

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

DevOps पर सहयोग अभ्यास

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

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

उत्पादन परीक्षण

निम्नलिखित उपकरण उत्पादन में परीक्षण को सुविधाजनक बनाने में मदद करेंगे:

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

पुनश्च

इस सारांश में बहुत सारी दिलचस्प चीजें शामिल नहीं थीं। पुस्तक अच्छी तरह से लिखी गई है, हम इसे उन परीक्षकों को सुझाते हैं, जो DevOps परियोजनाओं पर परीक्षण के बारे में सोच रहे हैं।

अंत में, उपयोगी लिंक के एक जोड़े:

• पुस्तक यहाँ खरीदी जा सकती है ।
• कटरीना के प्रदर्शन वीडियो को एजाइल टेस्टिंग डेज़ 2017 से लिंक करें।
• कटरीना क्लोकी के ब्लॉग का लिंक।