Agile (SCRUM) के किस चरण में हमें स्वचालन परीक्षण शुरू करना चाहिए?

9

मेरी थोड़ी सी पृष्ठभूमि - मैं SCRUM (1-2 सप्ताह स्प्रिंट) का उपयोग कर एक चुस्त वातावरण के भीतर लगभग 2 वर्षों के लिए एक मैनुअल परीक्षक हूं। इसलिए मैं सेलेनियम वेबड्राइवर (जावा के साथ) का उपयोग करके अपने काम में स्वचालन परीक्षण शुरू करना चाहता हूं।

मेरा प्रश्न यह है कि मुझे कार्यक्षमता का परीक्षण कब करना चाहिए और मुझे स्वचालन परीक्षण के लिए कब परिवर्तित करना चाहिए?

मैं विभिन्न दृष्टिकोणों को पढ़ रहा हूं और प्राप्त कर रहा हूं, जैसे:

जब एक नया स्प्रिंट शुरू हो रहा है, तो उपयोगकर्ता की कहानियों को पिछले स्प्रिंट से स्वचालित स्क्रिप्ट में कनवर्ट करें, या;
एक ही स्प्रिंट के भीतर उपयोगकर्ता कहानियों में कनवर्ट करें।

किसी भी सलाह / s बहुत सराहना की जाएगी। पहले ही, आपका बहुत धन्यवाद।

— नीलकंठ
स्रोत

4

कृपया दो अलग-अलग स्टैक एक्सचेंज साइटों पर एक ही प्रश्न को पार न करें। कृपया उनमें से एक को हटा दें।

— आर साहू

2

Sqa.stackexchange.com/questions/27017/… पर पोस्ट किया गया क्रॉस ।

— आर साहू

13

परीक्षण स्वचालन (और अन्य सभी परीक्षण) किए गए की परिभाषा का हिस्सा होना चाहिए । यह एक संभावित shippable उत्पाद बनाने के लिए। यदि यह परीक्षण नहीं किया गया था तो क्या आप जहाज कर सकते हैं?

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

Agile में टेस्ट स्वचालन बहुत महत्वपूर्ण है क्योंकि:

संगठनात्मक चपलता तकनीकी चपलता से विवश है

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

https://less.works/less/technical-excellence/index.html

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

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

— नील्स वैन रिइजर्सडाल
स्रोत

मैं पहले "चाहिए" पर असहमत हूं। किए गए की परिभाषा कुछ ऐसी है, जिसे स्क्रैम टीम को खुद के लिए काम करने की आवश्यकता है। यदि टीम स्वचालित परीक्षण को महत्वपूर्ण मानती है, तो वे इसे अपनी परिभाषा के हिस्से के रूप में शामिल करेंगे। हालाँकि यह प्रक्रिया स्वयं यह नहीं कहती है कि उन्हें या उन्हें भी ऐसा करना चाहिए। यह ऐसा कुछ है जो पूरी तरह से टीम के ऊपर है, और कोई सही, गलत या पसंदीदा उत्तर नहीं है।

— एरोथ

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

— नील्स वैन रीजर्सडाल

2

महत्वपूर्ण बात यह है कि आप किसी कहानी को तब तक पूरा नहीं करते जब तक कि आपने उस कहानी के लिए स्वचालित परीक्षण न लिख लिए हों।

तो 1 लगता है, जैसा कि आप पिछले स्प्रिंट में पूरा किए गए कार्य के लिए परीक्षण लिख रहे हैं। क्या होगा अगर परीक्षण विफल?

— ईवान
स्रोत

इसलिए यदि सप्ताह में एक नए स्प्रिंट में से कोई भी उस स्प्रिंट की कोई उपयोगकर्ता कहानी नहीं है, तो यह प्रतिगमन परीक्षण हो सकता है, तो आपको सुझाव है कि ओपी को घर जाना चाहिए और कुछ भी नहीं करना चाहिए? मेरे लिए बहुत कुशल नहीं लगता ;-)

— डॉक्टर ब्राउन

परीक्षक को पहले सप्ताह का उपयोग करना चाहिए कि कल्पना करने के लिए "हम्म के रूप में एक उपयोगकर्ता के रूप में मैं अपने वेब पेज पर पृष्ठभूमि संगीत की उम्मीद करूंगा .." अपूर्ण कहानियों में बग ढूंढते हैं और आमतौर पर परेशानी करते हैं। देवों को यह कहने की अनुमति दी जाती है कि वे एकतरफा परीक्षण योजना नहीं लिख सकते हैं

— इवान

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

— ब्रायन ओकली

1

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

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

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

— ब्रायन ओकली
स्रोत

0

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

— मार्टिन मात
स्रोत

1

यह सेलेनियम जैसे यूआई परीक्षण उपकरण के साथ काम नहीं करता है। परीक्षण बनाने में सक्षम होने के लिए आपको एक कार्यशील और स्थिर UI की आवश्यकता होती है ।

— डॉक्टर ब्राउन

@DocBrown: मुझे नहीं लगता कि यह सच है। यदि आप मुझे एक नए वेब पेज के लिए एक विनिर्देश देते हैं, तो मैं पेज लिखे जाने से पहले स्वचालित परीक्षण लिखना शुरू कर सकता हूं (और शायद खत्म कर सकता हूं)। आपको बस डेवलपर के साथ सहयोग करने की आवश्यकता है ताकि आप दोनों इस बात पर सहमत हों कि पृष्ठ संरचना क्या है, तत्व आईडी क्या हैं, इत्यादि।

— ब्रायन ओकले

0

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

— मूर्ख
स्रोत

0

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

वास्तव में चुस्त वातावरण में, हर कोई सब कुछ करने में सक्षम है। परीक्षण के लिए समर्पित कोई 100% नहीं होगा, आप कुछ बुनियादी यूआई काम, या कुछ और के साथ मदद करने के लिए कौशल विकसित करेंगे। हालांकि, हम शायद ही कभी एक आदर्श दुनिया में रहते हैं।

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

— krillgar
स्रोत

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

— ब्रायन ओकले