मैनुअल बनाम ऑटोमेटेड टेस्टिंग

सारांश। छह जाँचें ऑटोमेट होती हैं: K1 (UI), K2, K3 और K4 (API), K8 (ब्राउज़र ग्रिड पर UI) और K9 (लोड स्क्रिप्ट)। पहली पाँच तीनों सवाल पास करती हैं; K9 सिर्फ़ एक तारीख़ से पहले और जोखिम वाले बदलावों के बाद चलता है, पर लोड टेस्ट हाथ से हो ही नहीं सकता, इसलिए तय किया हुआ अपेक्षित परिणाम मिलते ही उसे ऑटोमेट किया जाता है। चार इंसान के पास रहती हैं: K5 और K10 निर्णय हैं, K6 एक्सप्लोरेटरी है और K7 एक बार चलती है। "अभी नहीं" ग्रुप बुकिंग को ऑटोमेट करने का जवाब है: वह डिज़ाइन फ़ाइनल होने तक रुकता है (K6 देखें)। स्तर टेस्ट पिरामिड तय करता है: जाँच सबसे निचले उस स्तर पर रहे जहाँ उसे व्यक्त किया जा सकता है, इसलिए K2, K3 और K4 API टेस्ट हैं और उन्हें UI टेस्ट की ज़रूरत नहीं, और ऑटोमेटेड जाँचों में सिर्फ़ K1 और K8 ब्राउज़र चलाते हैं। अगर आपका वर्गीकरण अलग है, तो उसे नीचे के कारणों से मिलाएँ; लिखे हुए कारण के साथ अलग चुनाव स्वीकार्य है, "क्योंकि हो सकता है" इसलिए ऑटोमेट की गई जाँच नहीं।

K1 — ऑटोमेट, UI स्तर, पाइपलाइन की एकमात्र एंड-टू-एंड यात्रा। यह GitLab CI में हर बदलाव पर और हर रिलीज़ से पहले चलती है (आवृत्ति), एक निश्चित परिणाम पर ख़त्म होती है (चुनी हुई दो सीटों के लिए QR कोड वाला टिकट), और भुगतान के स्टेप के अलावा इस रिलीज़ में बुकिंग की स्क्रीन नहीं बदलतीं (स्थिरता)। भुगतान का स्टेप एक बार, 15 अक्टूबर को बदलेगा: फ़्लो को अस्थिर कहने के बजाय उस रखरखाव की योजना बदलाव के दिन के लिए बनाएँ (नए प्रोवाइडर का टेस्ट कार्ड और उसकी स्क्रीन)। स्क्रिप्ट को यात्रा तक सीमित रखें; क़ीमतें, सीट की स्थिति और उपलब्धता उसके नीचे के स्तर पर जाँची जाती हैं।

K2 — ऑटोमेट, API स्तर, हर कमिट पर। सटीक अनुरोध, सटीक रिस्पॉन्स और तुलना के लिए OpenAPI स्पेसिफ़िकेशन ऑटोमेशन का आदर्श लक्ष्य है, और मोबाइल ऐप इसी कॉन्ट्रैक्ट पर निर्भर हैं, इसलिए कोई बदला हुआ या ग़ायब फ़ील्ड उन्हें उसी दिन तोड़ देगा जिस दिन वह शिप हो। जाँच सेकंडों में होती है और GitLab CI में यूनिट टेस्ट के बगल में उसकी जगह है।

K3 — ऑटोमेट, API स्तर, डेटा-ड्रिवन, हर कमिट पर; UI टेस्ट नहीं, क्योंकि क़ीमत API तय करता है और web app उसे सिर्फ़ दिखाता है। क़ीमत की गणना का डेवलपर यूनिट टेस्ट भी उतना ही सही स्तर है, क्योंकि वह सबसे निचला स्तर है जहाँ नियम व्यक्त किया जा सकता है। PR-7 दो साल से अपरिवर्तित है (स्थिरता), अपेक्षित क़ीमत सटीक है (निश्चितता), और यह हर रिलीज़ पर जाँची जाती है (आवृत्ति)। पंक्तियाँ आयु-वर्गों के बीच की बाउंड्री और दो तरह के दिन हैं, क़ीमतें SAR में: मंगलवार के अलावा किसी दिन, आयु 2 → मुफ़्त और कोई सीट नहीं, 3 → 25.00, 12 → 25.00, 13 → 45.00, 64 → 45.00, 65 → 30.00; मंगलवार को वही आयु → मुफ़्त, फिर बाक़ी पाँच के लिए 20.00। सिनेमा के time zone में दिन के किनारों पर पंक्तियाँ जोड़ें: सोमवार 23:59, मंगलवार 00:00, मंगलवार 23:59 और बुधवार 00:00। ये अपेक्षित परिणाम लिखने से पहले प्रोडक्ट ओनर से पूछें कि "मंगलवार" का मतलब क्या है — स्क्रीनिंग का दिन या बुकिंग का दिन — और जवाब दर्ज करें: जिस जाँच का निश्चित अपेक्षित परिणाम नहीं, वह ऑटोमेट करने के लिए तैयार नहीं है।

K4 — ऑटोमेट, API स्तर, दो केस में: जिस सीट का भुगतान एक ग्राहक कर रहा है, वह दूसरे ग्राहक को अस्वीकार हो (एक के बाद एक दो अनुरोध), और एक ही सीट के लिए एक ही पल में भेजी गई दो बुकिंग का अंत ठीक एक सफलता और एक अस्वीकृति पर हो (जैसे 201 Created और 409 Conflict)। परिणाम निश्चित है, भले ही टाइमिंग न हो, और यह जाँच हर रिलीज़ पर मायने रखती है क्योंकि दो बार बुक हुई सीट रिफ़ंड और भरोसे की क़ीमत लेती है। हाथ से, दो ब्राउज़र वाले दो टेस्टर अपने क्लिक एक ही मिलीसेकंड में नहीं डाल सकते, इसलिए दूसरा केस कॉन्करेंसी को कभी जाँचे बिना पास हो जाता; कॉन्करेंट अनुरोध पैदा करना परिभाषा से ही ऑटोमेशन है। इसे हर रात या बुकिंग सर्विस के हर कमिट पर चलाएँ।

K8 — ऑटोमेट, UI स्तर, हर रात और हर रिलीज़ से पहले, हर कमिट पर नहीं। यह K1 की यात्रा ही है जो चारों ब्राउज़र पर, डेस्कटॉप और फ़ोन पर, असली या एमुलेटेड डिवाइस वाले ब्राउज़र ग्रिड के ज़रिए फिर चलती है: एक स्क्रिप्ट, आठ कॉन्फ़िगरेशन। हाथ से इसका मतलब होगा हर दो हफ़्ते वही यात्रा आठ बार दोहराना — दोहराव वाला, निश्चित काम, ठीक वही जिसे नियम ऑटोमेशन को भेजता है — और K1 पहले से ऑटोमेटेड है, इसलिए अतिरिक्त लागत कॉन्फ़िगरेशन की है, नए कोड की नहीं। यह बाक़ी सूट से धीमी है, इसीलिए हर कमिट को नहीं रोकती।

K9 — ऑटोमेट, एक लोड स्क्रिप्ट के रूप में जो ब्राउज़र के बिना सीट मैप और चेकआउट के HTTP अनुरोध भेजती है; लोड टेस्ट परिभाषा से ही ऑटोमेशन है, क्योंकि 10:00 बजे 2,000 ग्राहक हाथ से पैदा नहीं किए जा सकते। यह 24 अक्टूबर से पहले चलता है और फिर सीट होल्डिंग या चेकआउट के कोड में किसी भी बदलाव के बाद, प्रोडक्शन के आकार के staging environment पर — प्रोडक्शन पर नहीं, और ऐसे सिस्टम पर, जो टीम का नहीं है (जैसे पेमेंट प्रोवाइडर), लिखित अनुमति के बिना कभी नहीं। चलाने से पहले इसे निश्चित अपेक्षित परिणाम दें, जैसे सीट मैप और चेकआउट के लिए टीम जो response time और error rate स्वीकार करती है; वरना यह संख्याएँ देगा पर फ़ैसला नहीं।

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

K6 — टाइम-बॉक्स्ड, चार्टर-आधारित एक्सप्लोरेटरी सेशन, जैसे: "6 से 20 सीटों की ग्रुप बुकिंग को, सीट बदलने और भुगतान समेत, एक्सप्लोर करें ताकि भ्रामक या टूटा हुआ व्यवहार मिले", नोट्स के साथ 60–90 मिनट के सेशन में। अभी कोई निश्चित अपेक्षित परिणाम नहीं है — अपेक्षित व्यवहार अभी खोजा जा रहा है — और स्क्रीन अस्थिर हैं, तो यह नए फ़ीचर पर वह पहला पास है जिसे गाइड इंसान को देती है। डिज़ाइन फ़ाइनल होने पर रखने लायक केस लिखें और उनमें से स्थिर केस ऑटोमेशन को सौंपें, आम तौर पर K1 के बगल में एक ग्रुप-बुकिंग यात्रा।

K7 — एक बार की जाँच, हाथ से या एक बार इस्तेमाल होने वाली query से, सूट में नहीं। यह एक बार, 15 अक्टूबर को चलती है, इसलिए आवृत्ति में विफल है, और स्क्रिप्ट की लागत जाँच से ज़्यादा होगी। फिर भी इसे सावधानी से करें: बदलाव से पहले 1,214 ऑर्डर की id दर्ज करें, बाद में सूची की तुलना करें — सिर्फ़ गिनती की नहीं — और नतीजा रिलीज़ नोट्स के साथ रखें।

K10 — स्क्रिप्टेड मैनुअल समीक्षा, जिसका निश्चित हिस्सा अलग कर लिया गया है। मैसेज समझ में आता है और ग्राहक को बताता है कि क्या करना है — इसकी तुलना किसी अपेक्षित मान से नहीं हो सकती; टेस्टर हर मैसेज को उसके संदर्भ में, अंग्रेज़ी और अरबी में, हर रिलीज़ पर या जब भी कोई टेक्स्ट बदले, पढ़ता है। निश्चित हिस्सा ऑटोमेशन में जाता है: API तय किया हुआ error code लौटाता है (K2 के बगल में एक API जाँच), और हर एरर स्थिति में कोई मैसेज दिखता है (K1 के बगल में UI यात्रा का एक स्टेप)।

Q1। ऑटोमेशन स्क्रिप्टेड मैनुअल रिग्रेशन — ज्ञात जाँचों को हाथ से दोहराने — की जगह लेता है, और लेना चाहिए: K1, K2, K3 और K8 ठीक यही हैं, और K9 व K4 का कॉन्करेंसी वाला केस तो हाथ से हो ही नहीं सकते। यह एक्सप्लोरेटरी टेस्टिंग (K6), उपयोगिता और लोकलाइज़ेशन के निर्णय (K5, K10) या आवश्यकताओं की समीक्षा की जगह नहीं ले सकता, क्योंकि स्क्रिप्ट सिर्फ़ वही जाँचती है जिसका लिखते समय किसी ने अनुमान लगाया था। जो टीम सब कुछ ऑटोमेट करती है, उसके पास मज़बूत रिग्रेशन सूट और बढ़ते हुए ऐसे प्रोडक्शन दोष रह जाते हैं जिनके लिए किसी ने स्क्रिप्ट नहीं लिखी। असली वादा अलग है: जब सूट हर बदलाव पर उसकी रक्षा करता है जो पहले से काम करता है, तब टेस्टरों का समय उससे आगे चला जाता है — आवश्यकताएँ, नए फ़ीचर, एक्सप्लोरेटरी सेशन।

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

Q3। सीट मैप की फ़्लेकी जाँच इसी हफ़्ते ठीक करें या हटाएँ: हफ़्ते में एक बार बिना किसी ख़राबी के लाल होने वाला सूट टीम को लाल की अनदेखी सिखाता है, और कोई उसे दोबारा नहीं चलाता — यह दिखाता है कि ऐसा हो भी चुका है। 38 जाँचों को देखें और बिज़नेस नियम की हर जाँच — क़ीमतें, सीट की स्थिति, उपलब्धता — ब्राउज़र से निकालकर API स्तर पर ले जाएँ, जहाँ वह सेकंडों में चलती है; API स्तर पर टेस्ट किया गया नियम UI टेस्ट नहीं माँगता। UI सूट में सिर्फ़ वे यात्राएँ रखें जो UI में विफल हो सकती हैं, K1 से शुरू करके और बाद में ग्रुप बुकिंग, ताकि सूट रात में एक बार की बजाय GitLab CI में हर बदलाव पर मिनटों में चले; सिर्फ़ क्रॉस-ब्राउज़र रन (K8) रात में चलता रहता है। हर तिमाही सूट में डुप्लिकेट और मृत जाँचों की समीक्षा करें, और ऑटोमेशन इंजीनियर को इस सूची का बाक़ी हिस्सा, इसी क्रम में, पहले महीने के काम के रूप में दें।