मेन्यू

सॉफ्टवेयर परीक्षण प्रलेखन गाइड (यह क्यों महत्वपूर्ण है)

software testing documentation guide

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

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

यहां तक ​​कि मैंने प्रलेखन के बारे में अधिक जोर नहीं दिया, लेकिन मैं इसे अपनी आदत कह सकता हूं कि सभी डेटा को काले और सफेद में रखें और दूसरों को भी इसके बारे में अपडेट करें।

सॉफ्टवेयर टेस्टिंग डॉक्यूमेंटेशन गाइड (यह क्यों

आप क्या सीखेंगे:

मेरा अनुभव

बस अपना अनुभव आपसे साझा करना चाहता हूं:

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

मैक पर 7zip फाइलें कैसे खोलें

मुद्दा एक वेबसाइट की संगतता के बारे में कुछ था। जब यह मेरे पास आया, तो मुझे इस बात का सबूत था कि मुझे ऐसा कोई आवश्यकता दस्तावेज़ नहीं मिला है, जिसमें कहा गया हो कि मुझे वेबसाइट की अनुकूलता की भी जाँच करनी है। भगवान का शुक्र है कि मैं सुरक्षित था।

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

'स्याही सबसे अच्छी मेमोरी से बेहतर है' - चीनी कहावत

टेस्ट प्रलेखन: क्या है?

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

लेकिन, अगर हम गौर करें तो तथ्य यह है कि, जिन परियोजनाओं में सभी दस्तावेज होते हैं उनमें उच्च स्तर की परिपक्वता होती है।

ज्यादातर कंपनियाँ दस्तावेज़ीकरण को उतना महत्व नहीं देती हैं जितना वे सॉफ्टवेयर विकास प्रक्रिया को देती हैं। यदि हम वेब पर खोज करते हैं तो हम विभिन्न प्रकार के दस्तावेज़ बनाने के विभिन्न टेम्पलेट पा सकते हैं। लेकिन उनमें से कितने वास्तव में संगठनों या व्यक्तियों द्वारा उपयोग किए जाते हैं?

तथ्य यह है कि सावधान प्रलेखन संगठन के समय, प्रयासों और धन को बचा सकता है।

किसी भी प्रकार के प्रमाणीकरण के लिए जाते समय, प्रलेखन पर तनाव क्यों दिया जाता है, यह सिर्फ इसलिए है क्योंकि यह ग्राहक और व्यक्तिगत और संगठन के लिए प्रक्रियाओं के महत्व को दर्शाता है। जब तक आप एक दस्तावेज का उत्पादन करने में सक्षम नहीं होते हैं जो उपयोगकर्ता के लिए आरामदायक है कि आपका उत्पाद कितना अच्छा है, कोई भी इसे स्वीकार करने वाला नहीं है।

यह मेरा अनुभव है, हमारे पास एक उत्पाद है, जिसमें थोड़ी भ्रामक कार्यक्षमता है।

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

'प्रलेखन की कमी स्वीकृति के लिए एक समस्या बनती जा रही है' - वेटे वेनेमा

यहां तक ​​कि उपयोगकर्ता नियमावली पर भी यही बात लागू होती है। Microsoft का एक उदाहरण लें, वे हर उत्पाद को उचित दस्तावेजों के साथ लॉन्च करते हैं, यहां तक ​​कि कार्यालय 2007 के लिए भी हमारे पास ऐसे दस्तावेज हैं, जो किसी भी उपयोगकर्ता के लिए बहुत ही व्याख्यात्मक और समझने में आसान हैं। यही कारण है कि उनके सभी उत्पाद सफल हैं।

छोटी कंपनियों में, हमने हमेशा 'प्रोजेक्ट को प्रस्ताव या किकऑफ़ चरण में खारिज कर दिया' यह सिर्फ इसलिए सुना क्योंकि प्रस्ताव प्रलेखन में संक्षिप्त और अभिव्यंजक भाषा का अभाव है, और संगठन की क्षमता दिखाने के लिए।

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

मुझे व्यक्तिगत रूप से लगता है कि गुणवत्ता ही एकमात्र विभाग है जो इसे संभव बना सकता है। हम एकमात्र विभाग हैं, जो इस पर बहस कर सकते हैं और हमारे संगठनों के लिए एक सफल भविष्य प्रदान कर सकते हैं।

गुणवत्ता के परिप्रेक्ष्य में कुछ बिंदुओं पर सभी चर्चा को व्यवस्थित करें:

- गुणवत्ता के उद्देश्य और तरीकों को स्पष्ट करें
- कार्यों और प्रदर्शन की निरंतरता के बारे में स्पष्टता सुनिश्चित करें
- ग्राहक के काम में आंतरिक समन्वय सुनिश्चित करें
- निवारक कार्यों पर प्रतिक्रिया दें
- अपने योजना चक्र के लिए प्रतिक्रिया दें
- अपने गुणवत्ता प्रबंधन प्रणाली के प्रदर्शन का वस्तुनिष्ठ प्रमाण बनाएं

टेस्ट डॉक्यूमेंटेशन लक्ष्य प्राप्त करने में आपकी मदद करने के लिए 10 टिप्स

जैसा कि मैंने अपने पहले के पोस्ट में उल्लेख किया है, सामान्य तौर पर, सॉफ़्टवेयर परीक्षण प्रलेखन के बारे में समझ 'यह केवल उस व्यक्ति द्वारा किया जा सकता है जिसके पास खाली समय है'। हमें इस मानसिकता को बदलने की जरूरत है, और उसके बाद ही हम अपनी परियोजनाओं पर प्रलेखन शक्ति का लाभ उठा सकते हैं।

ऐसा नहीं है कि हम यह नहीं जानते कि दस्तावेज़ को सही कैसे किया जाए। हम इसे महत्वपूर्ण नहीं समझते हैं।

बग रिपोर्ट के लिए टेस्ट रणनीति, टेस्ट प्लान, टेस्ट मामलों और टेस्ट डेटा से शुरू होने वाले सभी प्रकार के प्रलेखन के लिए सभी के पास मानक टेम्पलेट होने चाहिए।

ये सिर्फ कुछ मानकों (CMMI, ISO, आदि) का पालन करने के लिए हैं, लेकिन जब वास्तविक कार्यान्वयन की बात आती है, तो इनमें से कितने दस्तावेज वास्तव में हमारे लिए उपयोग किए जाते हैं? हमें बस एक दस्तावेज में मानकों और एक अन्य प्रक्रिया के साथ हमारी गुणवत्ता प्रक्रिया को सिंक्रनाइज़ करने की आवश्यकता है।

सभी प्रकार के प्रलेखन का पालन करने के लिए सबसे सरल बात किक-ऑफ चरण से परियोजना में एक व्यक्ति को शामिल करना है जो परियोजना की गतिशीलता, डोमेन, उद्देश्य और प्रौद्योगिकी को समझता है। और इसके लिए एक क्यूए व्यक्ति से बेहतर कौन है (निश्चित रूप से ऐसा करने के लिए तकनीकी लेखक मौजूद हैं - लेकिन छोटी कंपनियों के सामान्य परिदृश्य को देखते हुए जहां तकनीकी लेखक मौजूद नहीं हैं)।

अजगर के लिए सबसे अच्छी विचारधारा क्या है

परीक्षण और प्रलेखन के इस लक्ष्य को प्राप्त करने के लिए मुझे लगता है कि हमें कुछ बिंदुओं पर ध्यान देने की आवश्यकता है।

यहां आपको परीक्षण प्रलेखन लक्ष्य को प्राप्त करने में मदद करने के लिए शीर्ष 10 युक्तियां दी गई हैं:

# 1) QA को परियोजना के पहले चरण में शामिल होना चाहिए ताकि QA और प्रलेखन काम में हाथ बँटाए।

#दो) क्यूए द्वारा परिभाषित प्रक्रिया को तकनीकी लोगों द्वारा पालन किया जाना चाहिए, यह बहुत प्रारंभिक चरण में अधिकांश दोषों को दूर करने में मदद करता है।

# 3) केवल निर्माण और रखरखाव सॉफ्टवेयर टेस्टिंग टेम्प्लेट पर्याप्त नहीं है, लोगों को उनका उपयोग करने के लिए मजबूर करें।

# 4) केवल आवश्यकता के अनुसार ही दस्तावेज़ बनाएं, अपडेट करें और छोड़ें।

# 5) परिवर्तन की आवश्यकता परियोजना का एक महत्वपूर्ण चरण है जो उन्हें सूची में जोड़ना नहीं भूलता है।

# 6) सब कुछ के लिए संस्करण नियंत्रण का उपयोग करें। इससे आपको अपने दस्तावेज़ों को आसानी से प्रबंधित और ट्रैक करने में मदद मिलेगी।

# 7) सभी दोषों का दस्तावेजीकरण करके दोष निवारण प्रक्रिया को आसान बनाएं। दोष का स्पष्ट विवरण, किसी भी दोष का दस्तावेजीकरण करते समय लेखक के बारे में कदम, प्रभावित क्षेत्र और विवरण को पुन: प्रस्तुत करना सुनिश्चित करें।

# 8) अपने काम को समझने के लिए आपको जो कुछ भी आवश्यक है उसे दस्तावेज करने की कोशिश करें और जब भी आवश्यक हो, आपको अपने हितधारकों को उत्पादन करने की आवश्यकता होगी।

# 9) प्रलेखन के लिए मानक टेम्पलेट का उपयोग करें। किसी भी एक्सेल शीट टेम्प्लेट या डॉक फाइल टेम्प्लेट की तरह और अपने सभी दस्तावेज़ों की ज़रूरतों के लिए उस पर टिके रहें।

# 10) परियोजना के सभी संबंधित दस्तावेजों को एक ही स्थान पर साझा करें, जब भी आवश्यकता हो अद्यतन करने के लिए संदर्भ के लिए टीम के प्रत्येक सदस्य के लिए सुलभ।

मैं यह नहीं कह रहा हूं कि कदम उठाने से आपको अचानक परिणाम मिलेंगे। मुझे पता है कि यह परिवर्तन एक या दो दिन में नहीं होगा, लेकिन कम से कम हम शुरू कर सकते हैं ताकि ये परिवर्तन धीरे-धीरे होने लगें।

आखिरकार 'डॉक्यूमेंटेशन को डॉक्यूमेंटेशन की जरूरत है'। क्या यह नहीं है?

सॉफ्टवेयर विकास और परीक्षण जीवनचक्र में इस्तेमाल होने वाले सैकड़ों दस्तावेज हैं।

महत्वपूर्ण सॉफ्टवेयर परीक्षण दस्तावेज

यहाँ मैं कुछ महत्वपूर्ण सॉफ्टवेयर परीक्षण दस्तावेजों को सूचीबद्ध कर रहा हूँ जिनका हमें नियमित रूप से उपयोग / रखरखाव करने की आवश्यकता है:

1) टेस्ट प्लान
2) टेस्ट डिजाइन और टेस्ट केस विशिष्टता
3) टेस्ट रणनीति
4) टेस्ट सारांश रिपोर्ट
5) साप्ताहिक स्थिति रिपोर्ट
6) उपयोगकर्ता दस्तावेज / नियमावली
7) उपयोगकर्ता स्वीकृति रिपोर्ट
8) जोखिम आकलन
9) टेस्ट लॉग
10) दोष रिपोर्ट
ग्यारह) परीक्षण डेटा
12) परीक्षण विश्लेषण

इसके अलावा, सॉफ्टवेयर परीक्षकों को नियमित रूप से निम्नलिखित दस्तावेजों को संदर्भित करने की आवश्यकता होती है:
1) सॉफ्टवेयर की आवश्यकता विनिर्देशों
2) कार्यात्मक दस्तावेज

निष्कर्ष

सॉफ़्टवेयर परीक्षण दस्तावेज़ हमेशा प्रोजेक्ट विकास / परीक्षण चरण में एक महत्वपूर्ण भूमिका निभाते हैं। इसलिए जब भी संभव हो चीजों को हमेशा दस्तावेज में रखें। मौखिक संचार पर निर्भर न हों। हमेशा सुरक्षित पक्ष पर रहें।

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

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

लेखक के बारे में: यह लेख एसटीएच टीम के सदस्य द्वारा लिखा गया है तेजस्विनी। वह एक संगठन में क्यूए प्रबंधक के रूप में काम कर रही है।

आप अपने दैनिक परीक्षण गतिविधियों में कौन से अन्य दस्तावेज बनाए रखते हैं?

अनुशंसित पाठ

^