बग ट्रैकर में कार्यों को कैसे बंद करें

मैंने यह लेख 2013 में काम के संगम में लिखा था। और इस लेखन (2019) के समय, यह अभी भी प्रासंगिक था।

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

और इसलिए आप कार्य खोलते हैं, अंतिम टिप्पणी के माध्यम से पत्ता देखें कि क्या प्रलेखन, क्या काम करता है, और वहां ... यह खाली है। या मामूली "सब कुछ जाँच लिया गया है, सब कुछ ठीक है।" दस्तावेज कहां है? मैं कार्य के विषय में नहीं हूं, मैं और पढ़ना चाहता हूं!

या अगर ग्राहक लिखता है कि उसके लिए कुछ काम नहीं कर रहा है, और आप जांचना चाहते हैं कि क्या स्थिति आत्म-परीक्षण द्वारा कवर की गई है। आप कार्य पर जाते हैं, और ऑटोटेस्ट का कोई लिंक नहीं है। उन्होंने बिल्कुल नहीं लिखा? या सिर्फ लिंक नहीं दिया? मुझे पता लगाना होगा ...


और इसलिए कार्य बंद चेकलिस्ट दिखाई दिया:

1. कार्य (हैलो कैप) की जाँच करें। विशिष्ट कार्यों के लिए तैयार किए गए चेकलिस्ट का उपयोग करें + ऑटोटेस्ट्स में विशिष्ट त्रुटियों से बचें।
2. इस पर प्रलेखन लिखें (न्यूनतम उपयोगकर्ता, अधिकतम उपयोगकर्ता और "सहयोगियों के लिए")।
3. JIRA में, एक टिप्पणी छोड़ें "मैंने विधानसभा कोर ***, ग्राहक *** पर चेक किया, इस पर, यह और वह, यहां देखा।"
4. यदि कुछ मैन्युअल रूप से जांचा गया था, तो कार्य के लिए परीक्षण डेटा संलग्न करें।

यह "हमारे बारे में" है, लेकिन वास्तव में सार्वभौमिक है। ठीक है, जब तक कि परीक्षक आपकी कंपनी में दस्तावेज नहीं लिखता है, तब हम दूसरे पैराग्राफ को "जांच लें कि सभी आवश्यक दस्तावेज लिखे गए हैं या अपडेट किए गए हैं।"

हम प्रत्येक आइटम का अलग-अलग विश्लेषण करेंगे।

प्रलेखन

यदि कार्य के लिए कोई दस्तावेज नहीं है (यह बग या सुधार नहीं है तो कोई बात नहीं), इसे फिर से खोजा गया है।

यदि दस्तावेज है, लेकिन अंतिम टिप्पणी में JIRA में इसका कोई लिंक नहीं है, तो कार्य को फिर से खोजा गया है। (कठोर समय, कठोर उपाय)

उपयोगकर्ता की आवश्यकताओं को लिखने / सही करने की न्यूनतम आवश्यकता।

यदि प्रोजेक्ट के कॉन्फ़िगरेशन में परिवर्तन थे, तो आपको यह जांचने की आवश्यकता है कि इस तरह के बदलाव के लिए तकनीकी दस्तावेज है। अगर ऐसा नहीं है, तो लिखें।

यदि माइग्रेशन कार्य जोड़े गए थे, तो रिलीज़ को अपडेट करने के लिए तुरंत एक सामान्य निर्देश लिखें।

टिप्पणी

यदि आपको बाद में कार्य पर वापस लौटना है, तो यह पता लगाना कभी-कभी उपयोगी होता है कि परीक्षक ने किस संस्करण का परीक्षण किया और उसने क्या जाँच की (संक्षेप में)।

हम व्यापारियों से संस्करण लिखते हैं, प्रलेखन और एक संक्षिप्त विवरण के लिए एक लिंक देते हैं: मैंने इसे मैन्युअल रूप से / SOAP / बफ़र इंटरफ़ेस के माध्यम से जांचा।

डेटा का परीक्षण करें

यदि कार्य मैन्युअल रूप से जांचा गया था, तो इसे परीक्षण डेटा संलग्न करना सुनिश्चित करें (यदि वे 3Tb वजन नहीं करते हैं)

हां, यह डेटा साझा भंडार से प्राप्त किया जा सकता है, लेकिन वहां उन्हें पहले से ही बदला जा सकता है या हटाया भी जा सकता है। (हमारे पास परीक्षण डेटा का एक सामान्य भंडार है, लेकिन सभी फाइलें डिस्क पर संग्रहीत हैं। हमने इसे संस्करण नियंत्रण प्रणाली में आज़माया, मुझे यह पसंद नहीं आया, कोई भी वहाँ बिल्कुल भी नहीं आता है, लेकिन वे इसे किसी भी तरह डिस्क पर डालते हैं।

कभी-कभी ऐसा लगता है कि यह सब कचरा है, उन्होंने एक प्रतिपक्ष या एकत्र चयन को देखने के द्वारा बनाया।

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

याद रखें - एक तैयार sql क्वेरी लेने में 1 मिनट लगेगा और डेटाबेस के खिलाफ जांच होगी। और फिर से बैठने के लिए और यह अनुरोध करने के लिए - यह एक घंटे लग सकता है, यदि अधिक नहीं। अपना समय बचाओ!

इसलिए:

1. DbStart - अटैचमेंट dbStart (एक्सेल, जिसमें परीक्षण के लिए डेटाबेस का एक टुकड़ा सहेजा गया है) से एक डेटाबेस बनाया गया है।
2. हमने भंडारण से परीक्षण डेटा डाउनलोड किया - हम डाउनलोड की गई फ़ाइल संलग्न करते हैं।
3. हमने उन्हें कहीं और से डाउनलोड किया - हम उन्हें भंडार में जोड़ते हैं और कार्य के साथ जोड़ते हैं।

यह भी देखें:

मावेन में एक टेम्प्लेट डेटाबेस कैसे जल्दी से बनाएं? - कैसे हम परीक्षण के लिए dbStart करते हैं।

परीक्षण, डॉक्स और डेटा पर टिप्पणी अंतिम होनी चाहिए। और इतना नहीं कि "मैंने ऐसे और इस तरह के परीक्षण लिखे, ऐसी और ऐसी समस्याएं पाईं" और फिर 20 टिप्पणियों के लिए डेवलपर के साथ पत्राचार किया, और आपका "अंतिम" बीच में कहीं खो गया। यदि आप खो जाते हैं - डुप्लिकेट (पुराने को हटाया जा सकता है)।

उदाहरण

जब हमने नए परीक्षकों की भर्ती की, तो यह लेख पर्याप्त नहीं था। क्योंकि मैंने जूनियर्स के कार्यों को फिर से खोजा और बताया कि अंतिम टिप्पणी को कैसे ठीक किया जाए ताकि यह समझ में आए। और, उन्होंने बदले में, "कैसे करें" के उदाहरणों के लिए कहा।

तो लेख में एक और ब्लॉक दिखाई दिया - "उदाहरण"। कामकाजी जीरा में वास्तविक कार्यों के लिंक प्रदान करना महत्वपूर्ण है + संगम में कुछ अतिरिक्त लेख। उदाहरण अलग-अलग होने चाहिए: दोनों बड़ी टिप्पणियों के लिए जब एक कार्य पर 200 ऑटोटेस्ट लिखा गया था, और छोटे कार्यों के लिए जो हर दिन लोगों का सामना करेंगे।

मैं लिंक नहीं दूंगा, लेकिन अर्थ, मुझे आशा है, स्पष्ट है। खंड कुछ इस तरह दिखता है:

बड़े कार्यों के उदाहरण जहां कई डॉक और परीक्षण हैं:

• टेस्ट -679 - जेएमएस में सुधार
• TEST-760 - विभिन्न JMS स्रोतों में प्रवाह लौटें

छोटे कार्यों के उदाहरण: टेस्ट -816 - सहमति मॉडल का विस्तार किया।

"डेमो में कार्यक्षमता जोड़ें" का परीक्षण करते समय, रीफैक्टरिंग पर विशेष ध्यान दें - कोर को प्रलेखन सबमिट करें, डेमो में सभी परीक्षण, और समावेश के माध्यम से बाकी, आदि। उदाहरण: TEST-4519 - डेमो में FL-IP का क्रॉस-सुलह जोड़ें।

उपयोगी टिप्पणियों के उदाहरण "मैंने यह कैसे किया"

* ब्रायक: ब्रेकपॉइंट (स्लैंग) - कोड ब्रेकपॉइंट। यह तब होता है जब आप स्रोत कोड को डिबग मोड में चलाते हैं, ऐसे बिंदु त्रुटि को स्थानीय बनाने के लिए मापदंडों को ट्रैक करने में मदद करते हैं।

पुनश्च - मेरे ब्लॉग में अन्य परीक्षण लेख देखें