परीक्षण: 20 शुरुआती सिद्धांत

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


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

1. पता करें कि आप क्या परीक्षण कर रहे हैं। निर्धारित करें कि कार्यक्रम किस उद्योग से संबंधित है, किस माध्यम से और किन भाषाओं में इसके घटक लिखे गए हैं, कौन से डेटाबेस का उपयोग किया जाता है, कौन से प्रोटोकॉल शामिल हैं। यह निर्दिष्ट करना सुनिश्चित करें कि किन देशों में इसका उपयोग किया जाएगा। उदाहरण के लिए, यदि आप दूरसंचार सॉफ्टवेयर का परीक्षण कर रहे हैं और इसे दुनिया भर में बेच रहे हैं, तो उत्तर अमेरिकी एनएएनपी नंबरिंग योजनाओं के बारे में पूछना उपयोगी होगा।
2. पता लगाएं कि आपका ग्राहक या अंतिम उपयोगकर्ता कौन है। स्वयं एक अंतिम उपयोगकर्ता बनें। यह मत भूलो कि सॉफ्टवेयर का उपयोग उन लोगों द्वारा किया जा सकता है जो आईटी से बिल्कुल दूर हैं और उनकी कार्य शैली पूरी तरह से अलग है। जांचें कि उपयोगकर्ता खुद क्या बदल सकता है, कौन से एक्सेस अधिकार निर्धारित किए जा सकते हैं, और यह कि, सिद्धांत रूप में, कार्यक्रम में इन अधिकारों को तोड़ा जा सकता है।
3. उन उपकरणों का एक नक्शा बनाएं जिनके साथ सॉफ्टवेयर बातचीत कर सकता है, इन उपकरणों के संयोजन को छाँट सकता है। जाहिर है, आज सॉफ़्टवेयर विभिन्न ऑपरेटिंग सिस्टम के तहत चलने वाले विभिन्न उपकरणों पर काम कर सकता है, अलग-अलग स्क्रीन रिज़ॉल्यूशन, कंट्रोल सिस्टम, आदि के साथ ... उन उपकरणों का एक नक्शा बनाएं जिस पर आपका सॉफ़्टवेयर चलता है, मुख्य तकनीकी विशिष्टताओं को लिखें, लोहे के संभावित संयोजनों के बारे में सोचें। और सॉफ्टवेयर। इससे काम में काफी आसानी होगी।
4. कार्यक्रम को टुकड़ों में तोड़ दें। ट्राइफल्स नहीं हैं। प्रोग्राम को अच्छी तरह से परखें: एक्ज़िट बटन से लेटेस्ट फंक्शन तक। आपको सभी जुड़े हुए मॉड्यूल के सिद्धांतों और निर्भरताओं को जानना चाहिए, यह पर्यावरण का परीक्षण कर रहा है, जो आपको बड़ी संख्या में बग की पहचान करने की अनुमति देता है, जो पास होने पर निश्चित रूप से क्लाइंट-साइड बन जाएगा। उदाहरण के लिए, एक ऐसा मामला था कि कार्यक्रम के संस्करणों में से एक ने निकास बटन का जवाब नहीं दिया था, लेकिन केवल एक क्रॉस के साथ बंद कर दिया गया था। बग छूट गया था और क्लाइंट केस के साथ वापस आ गया था।
5. परीक्षण के प्रकारों के बारे में जानें। आपकी सहायता के लिए सहयोगी, पुस्तकें और विकिपीडिया हैं। कार्यात्मक, प्रतिगमन, पवित्रता, भार आदि हैं। परीक्षण। जल्दी या बाद में, आप सभी प्रकारों को स्पर्श करेंगे और प्रत्येक के फायदे की सराहना करेंगे, इसलिए, पिछली पीढ़ियों द्वारा संचित सिद्धांतों और रहस्यों का ज्ञान चोट नहीं पहुंचाएगा।
6. बग ट्रैकर को जानें। आवश्यक फ़ील्ड देखें, ट्रायल बग सेट करें, ज़िम्मेदार लोगों का अध्ययन करें - यह भविष्य में समय बचाएगा और ऐसे मामलों का निर्माण करेगा जो सौ स्पष्ट प्रश्नों के साथ आपके पास वापस नहीं आएंगे।
7. बग ट्रैकर पढ़ें। यह परीक्षण का सबसे अच्छा सैन्य विश्वकोश है, जहां अनुभव आपकी संकीर्ण समस्या पर सटीक रूप से जमा हुआ है। आप देखेंगे कि समस्याओं का सबसे अधिक सामना करना पड़ता है, उन्हें महत्वपूर्णता और श्रम तीव्रता से विभाजित करें। पेशे के साथ गहरे परिचित के लिए यह एक महान उपकरण है।
8. उन सभी कमजोरियों को दर्ज करें जो आप मुठभेड़ करते हैं, भले ही ये वास्तव में बग न हों। ऐसे स्थान अक्सर कार्यक्रम में त्रुटियां पैदा कर सकते हैं। आपके पास अनुभव की अपनी संदर्भ पुस्तक होगी, जिसे आप अगले संस्करण का परीक्षण शुरू करने पर खोलेंगे और पूरक करेंगे।
9. महत्वपूर्ण स्थितियों को पुन: उत्पन्न करना। बग पर खुशी मत मनाओ। सबसे पहले, इसे दो बार खेलें, संभावित कारणों का विश्लेषण करें, प्लेबैक स्थितियों का सावधानीपूर्वक वर्णन करें: उपकरण, समय, प्रक्रिया। इससे डेवलपर्स को अपनी ओर से त्रुटि को पुन: उत्पन्न करने और इसकी घटना के कारणों को समझने में मदद मिलेगी।
10. लॉग के लिए देखें , यदि कोई हो। सख्ती से किसी भी लॉग को इकट्ठा करना सुनिश्चित करें जो परीक्षण के तहत कार्यक्रम लिख सकता है। यह आवश्यक रूप से कंसोल में मल्टी-पेज लॉग नहीं हैं, यह वेब पर पेजों को लटका दिया जा सकता है, त्रुटि विंडो, एक त्रुटि कोड के साथ लाइनें। यदि जानकारी को कॉपी या डाउनलोड करना संभव नहीं है, तो स्क्रीनशॉट लें। मामले में प्राप्त सभी जानकारी को संलग्नक के रूप में बनाएं - डेवलपर्स को यह पता लगाने की ज़रूरत नहीं होगी कि किस तरह की खिड़की बाहर गिर गई। इसके अलावा, अगर बग नहीं खेलता है, तो स्क्रीनशॉट या एक लॉग के साथ एक ड्रॉप की उपस्थिति एक तर्कपूर्ण मामला बनाने का एक अवसर है।
11. मोटे तौर पर सोचें। याद रखें कि यदि संभव हो तो आपका सॉफ़्टवेयर एक अलग स्वच्छ कंप्यूटर या गैजेट और अध्ययन प्रतियोगियों पर एक शून्य में अपना जीवन नहीं जीता है। संभवतः, किसी और की कार्यक्षमता का अध्ययन करने के बाद गैर-स्पष्ट और आकर्षक कुछ आपको बाहर से अधिक दिखाई देगा। या हो सकता है कि आप केवल एक अच्छी सुविधा को लागू करने की पेशकश कर सकते हैं।
12. सहयोगियों के साथ परामर्श करें : परीक्षक, डेवलपर्स और प्रबंधक। वे लेखक, उपयोगकर्ता और पेशेवर अनुभव के स्रोत हैं। यदि आप कुछ विशिष्ट (उदाहरण के लिए, हार्डवेयर सेटिंग्स) नहीं जानते हैं, तो Google से अपने सहयोगियों से पूछना बेहतर है - उन्होंने ऐसा बार-बार किया है और निश्चित रूप से मदद करेंगे। मेरा विश्वास करो, यह बदतर हो सकता है अगर, उदाहरण के लिए, आपके गलत तरीके से कॉन्फ़िगर किए गए उपकरण को अचानक डीएचसीपी के माध्यम से सभी को नए आईपी द्वारा वितरित किया जाता है।
13. नए परीक्षण के अवसरों का पता लगाएं। किताबें, समुदाय (वही हैबर) पढ़ें, अपने विकास में न रुकें, सरल स्क्रिप्ट लिखने की कोशिश करें, परीक्षण स्वचालन के बारे में अधिक जानें।
14. बग को ठीक करने के बाद कार्यक्षमता की जांच करने के लिए आलसी मत बनो। आपको वैसे भी ऐसा करने के लिए कहा जाएगा, लेकिन अगर अचानक आपको पता चले कि ऐसा कोई मामला नहीं है, तो बहुत आलसी न हों - मुफ्त मिनट चुनें और जांच करें। मामला जानबूझकर या अनजाने में परीक्षण योजना में जोड़ने के लिए भूल सकता था, और बग को फिर से खेलना अप्रिय होगा।
15. यदि आप एक लोड बना सकते हैं - इसे बनाएं। लोड का मतलब न केवल, उदाहरण के लिए, सामूहिक कॉल या इंटरकनेक्ट, बल्कि बहुत सारे डेटा, कई उपयोगकर्ताओं, आदि के साथ स्थितियां भी ... अपने सहयोगियों से मदद के लिए पूछें। यदि आवश्यक हो, तो अधिक परीक्षण डेटा प्राप्त करें, मल्टीमीडिया जोड़ें। प्रबंधकों से संपर्क करें - यह बहुत संभावना है कि उनके पास अनावश्यक परीक्षण क्लाइंट डेटा है, जिस पर आप श्रमिकों के लिए यथासंभव परिस्थितियों में सॉफ़्टवेयर का परीक्षण कर सकते हैं।
16. ऑपरेटिंग सिस्टम और प्रोग्रामिंग भाषा सीखें। यहां तक ​​कि अगर आप कोड का एक गंभीर ब्लॉक नहीं लिख सकते हैं, तो आप कार्यक्रम की वास्तुकला को बेहतर ढंग से समझेंगे, अनुमान लगा सकते हैं कि समस्याएं कहां पैदा हो सकती हैं और वे किससे जुड़े हैं।
17. जांच और प्रलेखन की समीक्षा करें। दस्तावेज़ीकरण उस सॉफ़्टवेयर का हिस्सा है जिसका परीक्षण भी किया जा रहा है। यदि आप इस तरह के मामले में नहीं आए हैं, तो आनन्दित न हों, लेकिन, इसके विपरीत, इसे पढ़ना सुनिश्चित करें - वहां आपको सॉफ्टवेयर के साथ काम करने के नए अवसर दिखाई देंगे, और शायद आप विसंगतियों या ओवरट त्रुटियों से मिलेंगे।
18. अनुभव साझा करें। परीक्षण विभाग इतने व्यवस्थित होते हैं कि लोग अक्सर उनमें बदल जाते हैं। एक नए व्यक्ति की मदद करना सुनिश्चित करें: जब एक प्रश्न की व्याख्या करते हैं, तो आप न केवल अपने ज्ञान को मजबूत करेंगे, बल्कि एक समाधान भी देखेंगे जो करीब था लेकिन नहीं मिला।
19. योजना। बेशक, आपके पास एक आविष्कार किए गए समय के साथ एक परीक्षण योजना होगी। लेकिन मुख्य योजना वह है जो आपने स्वयं संकलित की है, अपने गुणवत्ता मानदंडों के साथ। विधिपूर्वक चिह्नित करें कि क्या किया गया है, काम की प्रगति की जांच करें, यदि आपके पास समय नहीं है तो मदद लें। समय का उचित संगठन अद्भुत काम करता है और आपको स्व-शिक्षा में संलग्न होने की अनुमति देता है या यहां तक ​​कि काम के दिमाग से समय के साथ विचलित होता है, लेकिन बाहरी चीजें।
20. दूसरों पर विश्वास न करें। अजीब तरह से पर्याप्त है, लेकिन यह है। यदि आप देखते हैं कि आपके सहयोगी द्वारा परीक्षण किए जाने से पहले संस्करण के लिए एक विशिष्ट या समान मामला है, तो अपने निष्कर्षों और परीक्षण योजना पर पूरी तरह से विश्वास न करें, उनके आधार पर कोशिश करें कि वे कुछ अपना काम करें। मुझे लगता है, 20 बिंदु तक, अविश्वास के कारण आपके लिए स्पष्ट हो जाएंगे।

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

परीक्षण ज्ञान, जिम्मेदारी और थोड़ा भाग्य है। इसलिए शुभकामनाएँ!