कार्यात्मक परीक्षण के माध्यम से अनुसंधान

प्रस्तावना

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

योजना क्यों?

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

तकनीकी कार्यों की योजना

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

तो:

1. उस कोड की जांच, जिसे काल्पनिक रूप से संशोधित करने की आवश्यकता है।
   यह दृष्टिकोण लागू किया जा सकता है यदि आप कार्यान्वयन में बहुत अच्छी तरह से उन्मुख हैं, और लगभग पूर्ण निश्चितता के साथ आप बता सकते हैं कि सिस्टम के कौन से हिस्से परिवर्तन के अधीन होंगे
2. सिस्टम लॉग की जांच।
   यदि आप सिस्टम और इसके व्यवहार के कार्यान्वयन के बारे में अपने ज्ञान के बारे में सुनिश्चित नहीं हैं, तो आप लॉग में बदल सकते हैं। सबसे पहले, आप उपयोगकर्ता को इनपुट डेटा दर्ज करने के लिए कह सकते हैं और देख सकते हैं कि लॉग में छोड़ी गई प्रणाली क्या है। उसके बाद, आप आत्मविश्वास से कह सकते हैं कि कार्यान्वयन का कौन सा भाग एक विशेष व्यवसाय एल्गोरिथ्म प्रदर्शन करता है और नए तर्क को लागू करने की श्रम लागतों का मूल्यांकन करता है
3. परीक्षण लिखिए
   कोई उपयोगकर्ता नहीं है जिसे सिस्टम के व्यवहार को पुन: उत्पन्न करने के लिए एक्सेस किया जा सकता है। और अगर वहाँ है, तो हर बार संपर्क करना धन्यवाद का काम है, और हम सब कुछ मैन्युअल रूप से दोहराना नहीं चाहते हैं। एल्गोरिथ्म को लागू करने से पहले एक स्वचालित परीक्षण क्यों नहीं लिखा जाता है?
   
   हाँ, यह ATDD (एक्सेसेन्स टेस्ट ड्रिवेन डेवलपमेंट) और प्रश्न में कार्यात्मक परीक्षण है।
   परियोजना के शुरू होने के तुरंत बाद इस प्रकार के परीक्षण का ध्यान रखना चाहिए। ऐसे परीक्षणों को लिखने और निष्पादित करने की रूपरेखा परियोजना के साथ विकसित होनी चाहिए। यह आसानी से एक्स्टेंसिबल और स्केलेबल होना चाहिए। इसके अलावा, इस तरह के परीक्षणों को निरंतर एकीकरण पर समर्थित किया जाना चाहिए।
   यदि आपके पास एक परीक्षण है जो सिस्टम के वर्तमान व्यवहार को पुन: पेश करता है और आपको पता है कि परिणाम क्या होना चाहिए, तो आधा काम पहले ही हो चुका है। यह बहुत डेल्टा का मूल्यांकन करने के लिए रहता है जिसे लागू करने की आवश्यकता है ताकि: ए) मौजूदा परीक्षण गिर न जाएं, और बी) एक नया परीक्षण भी नए अपेक्षित आउटपुट के साथ गुजरता है।
   
   बहुत ही राजनीतिक सवाल उठता है। क्या किसी कार्य को निर्धारित करने से पहले इस तरह के परीक्षण लिखना वास्तव में आवश्यक है? इसका उत्तर यह तथ्य हो सकता है कि आपका कार्यात्मक परीक्षण ढांचा कितनी जल्दी आपको इस प्रकार के परीक्षण लिखने की अनुमति देता है। यदि यह कुछ घंटों का प्रश्न है, तो इसका उत्तर हां है, यह लिखना बेहतर है, यदि नहीं, तो आपको तकनीकी विभाग के बारे में सोचना चाहिए और निकट भविष्य में स्थिति को ठीक करना चाहिए।
   
   यदि आप एक पुनरावृत्त विकास तकनीक का उपयोग करते हैं, तो सुनिश्चित करें कि अगली पुनरावृत्ति से पहले उपयोगकर्ता कहानी आवश्यकताओं के दृष्टिकोण से पर्याप्त स्पष्ट है। आवश्यकताओं को आसानी से स्वीकृति टेस्ट, उदाहरण के लिए विनिर्देशन (SBE) में परिवर्तित किया जा सकता है। SBE, वैसे, परीक्षण उपकरण जैसे कि फिटने, BDD कार्यान्वयन जैसे कि Spock, Easyb, आदि के साथ अच्छी तरह से एकीकृत करता है।
   
   

   नैतिकता

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