मॉड्यूल 1 · Software और QA की बुनियाद

सॉफ़्टवेयर क्या है?

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Software निर्देशों और जानकारी का वह समूह है जो किसी computer, फ़ोन या दूसरे device से कोई काम करवाता है। जब आप किसी app से खाना ऑर्डर करते हैं, तो software menu दिखाता है, total निकालता है, payment लेता है और order को restaurant तक पहुँचाता है। Tester के लिए software सिर्फ़ code नहीं है: वह एक program है, वह data है जिस पर program काम करता है, और वह configuration है जो उसे नियंत्रित करता है, और यह सब दूसरे software और hardware की layers पर चलता है।

यह क्यों ज़रूरी है

जिस चीज़ का आप वर्णन नहीं कर सकते, उसे अच्छी तरह टेस्ट भी नहीं कर सकते। Checkout screen पर गलत total screen से, server के किसी business rule से, database की किसी price से, या test और live system में अलग किसी setting से आ सकता है। हिस्सों को जानकर आप बता पाते हैं कि problem कहाँ दिखी और सही व्यक्ति से पूछ पाते हैं।

Problem की कीमत इस पर भी निर्भर करती है कि वह कहाँ है: कटा हुआ label users को परेशान करता है, जबकि configuration में ज़रूरत से ज़्यादा रखा गया tax rate deploy होने के पल से हर customer से ज़्यादा पैसे लेता है।

Program, data और configuration

हर चलता हुआ system तीन तरह की सामग्री को जोड़ता है, जो अलग-अलग रफ़्तार से बदलती हैं। एक ही program दूसरे data या configuration के साथ अलग व्यवहार कर सकता है: जो checkout test environment में काम करता है, वह production में fail हो सकता है, क्योंकि production दूसरी payment service इस्तेमाल करता है, या क्योंकि असली data में किसी भी test data से लंबा product name है। इसलिए हर test result के साथ version, data और environment दर्ज करें।

  • Program (code): निर्देश जो developers लिखते हैं और चलने लायक रूप में build करते हैं, जैसे वह code जो order में VAT जोड़ता है। यह सिर्फ़ नए release के साथ बदलता है।
  • Data: वह जानकारी जिस पर program काम करता है और जिसे रखता है, जैसे customers, products, prices और orders। Users इसे दिन भर बदलते हैं, बिना किसी नए release के।
  • Configuration: settings जो code बदले बिना व्यवहार बदलती हैं, जैसे tax rate, payment service का address या session timeout। यह आम तौर पर हर environment में अलग होता है, जैसे test और production में।
PROGRAM         total = subtotal + round(subtotal * vat_rate, 2)

CONFIGURATION   vat_rate: 0.15
                payment_service: https://payments.test.example.com
                session_timeout_minutes: 30

DATA            {"sku": "1042", "name": "Arabic coffee 250 g", "price": 38.00}

आज़माएँ: YAML फ़ॉर्मेटर आज़माएँ: JSON ट्री व्यूअर

Software के प्रकार जिन्हें आप टेस्ट करेंगे

प्रकार से पता चलता है कि software कहाँ चलता है, users तक कैसे पहुँचता है और कौन-से risks अहम हैं। कई products कई प्रकार जोड़ते हैं: कोई bank website, mobile apps, partners के लिए API और card terminals में software चला सकता है।

  • Web applications browser में चलती हैं और अपने pages server से load करती हैं। User कुछ install नहीं करता, लेकिन हर page अलग-अलग browsers, screen sizes और भाषाओं में चलना चाहिए।
  • Mobile apps Android या iOS devices पर install होती हैं और इन्हें बहुत-से device models, permissions, calls जैसी रुकावटों और कमज़ोर networks से निपटना पड़ता है।
  • Desktop applications Windows, macOS या Linux पर install होती हैं, जैसे दुकान के counter पर point-of-sale program। Installation, updates और local printers भी testing का हिस्सा बन जाते हैं।
  • APIs और services की कोई screen नहीं होती: दूसरे programs इन्हें network पर call करते हैं, जैसे कोई shop payment service को call करती है। इन्हें requests भेजकर और responses जाँचकर टेस्ट किया जाता है।
  • Embedded software card terminals और smart meters जैसे devices के अंदर चलता है, अक्सर सीमित memory के साथ और हमेशा असली hardware पर। Field में devices को update करना धीमा या मुश्किल हो सकता है, इसलिए उन तक पहुँचा defect ठीक करना महँगा पड़ता है।

आज़माएँ: User-Agent पार्सर

एक आम web application की layers

ज़्यादातर business software अपना काम layers में बाँटता है, और हर layer का एक काम होता है। Teams इन्हें अलग-अलग नाम देती हैं (presentation, application और data tiers; या client और server), लेकिन एक आम web application में ये चार layers होती हैं। Mobile app आम तौर पर वही back end, database और infrastructure इस्तेमाल करता है; app ख़ुद एक और front end है।

  • Front end (presentation): browser में web pages या app की screens। यह जानकारी दिखाता है, input लेता है और "यह field ज़रूरी है" जैसी शुरुआती जाँच करता है। यहाँ tester layout, शब्द, input handling और messages जाँचता है।
  • Back end (application logic): servers पर programs जो business rules लागू करते हैं, जैसे prices, VAT, stock और permissions। Front end इसे किसी API को HTTP requests भेजकर call करता है। यहाँ tester rules और calculations screen से या API से जाँचता है।
  • Database (data): customers, products और orders जैसे records user के जाने के बाद भी रखता है। यहाँ tester जाँचता है कि सही records सेव, बदले या delete हुए, और कुछ और नहीं।
  • Infrastructure: servers या cloud services, operating systems, networks, domain names, certificates और हर environment का configuration। यहाँ tester दर्ज करता है कि कौन-सा environment और version टेस्ट हुआ।
आम web app चार layers में: user सिर्फ़ front end देखता है, जबकि back-end logic, database और उनके नीचे का infrastructure नज़र से दूर अपना काम करते हैं।

Requests front end से back end और database तक नीचे जाती हैं; responses ऊपर लौटते हैं

“Front end” परत पर: User को दिखती है“Infrastructure” परत पर: User की नज़र से दूर

  1. 1Front endPresentationBrowser में web pages या app की screens: जानकारी दिखाता है, input लेता है, शुरुआती जाँच करता है

    Tester layout, शब्द, input handling और messages जाँचता है

  2. 2Back endApplication logicServers पर programs जो business rules लागू करते हैं: prices, VAT, stock, permissions; API को HTTP requests से call होते हैं

    Tester rules और calculations screen या API से जाँचता है

  3. 3DatabaseDataCustomers, products और orders जैसे records user के जाने के बाद भी रखता है

    Tester जाँचता है कि सही records सेव, बदले या delete हुए, और कुछ और नहीं

  4. 4InfrastructureServers या cloud services, operating systems, networks, domain names, certificates और हर environment का configuration

    Tester दर्ज करता है कि कौन-सा environment और version टेस्ट हुआ

Layers के नाम team के हिसाब से बदलते हैं: कोई presentation, application और data tiers कहता है, तो कोई client और server।

Worked example: एक order हर layer से होकर

एक customer 38.00 SAR वाले कॉफ़ी के दो pack ख़रीदता है और "Place order" दबाता है। Front end और back end HTTP requests और responses का आदान-प्रदान करते हैं, जिनका अर्थ RFC 9110 में परिभाषित है।

Customer सिर्फ़ steps 1 और 6 देखता है। उनके बीच का सब कुछ नज़र से दूर होता है, इसलिए screen पर दिखा confirmation यह साबित नहीं करता कि order सही तरह सेव हुआ।

1  Front end   checks that the address is filled in, then sends the order
2  Request     POST https://shop.example.com/api/orders
               {"items": [{"sku": "1042", "qty": 2}]}
3  Back end    checks stock; 2 x 38.00 = 76.00; VAT 15% = 11.40; total = 87.40
4  Database    saves order 55031 with its line; reduces the stock of 1042 by 2
5  Response    201 Created   {"orderId": 55031, "total": "87.40"}
6  Front end   shows the confirmation: order 55031, total 87.40 SAR

   Underneath  infrastructure: servers, network, certificate of shop.example.com

आज़माएँ: URL पार्सर आज़माएँ: HTTP स्टेटस कोड लुकअप आज़माएँ: JSON फ़ॉर्मेटर

Software इंसान बनाते हैं, और इंसान गलतियाँ करते हैं

उस order का हर हिस्सा किसी ने लिखा या set up किया। लोग requirements गलत समझ लेते हैं, कोई case भूल जाते हैं, 0.15 की जगह 0.51 लिख देते हैं, या दो ऐसे हिस्से बनाते हैं जो अकेले ठीक चलते हैं पर आपस में मेल नहीं खाते। Defects जटिल चीज़ें बनाने का सामान्य नतीजा हैं, लापरवाह team की निशानी नहीं।

ISTQB की भाषा में: कोई व्यक्ति error (गलती) करता है, जिससे code में या किसी दूसरे work product में, जैसे requirement या configuration file में, defect (जिसे fault या bug भी कहते हैं) बन सकता है; defect वाले हिस्से का execution failure पैदा कर सकता है। आगे का एक पाठ इन terms को विस्तार से समझाता है। Coffee order में हर layer अपना defect छिपा सकती है, जबकि customer सिर्फ़ screen देखता है:

  • Front end: double tap से order दो बार चला जाता है।
  • Back end: VAT गलत रकम पर निकाला जाता है।
  • Database: order अपनी line के बिना सेव होता है।
  • Infrastructure और configuration: test environment असली payment service की ओर इशारा करता है।

आम गलतियाँ

  • Software को सिर्फ़ code मानना और data व configuration को नज़रअंदाज़ करना, जबकि ये code बदले बिना system तोड़ सकते हैं।
  • System को screen से आँकना: "Order confirmed" यह साबित नहीं करता कि order सही तरह सेव हुआ।
  • इस्तेमाल किए गए environment, version, device और test data के बिना problem report करना।
  • हर प्रकार के software को एक ही तरह टेस्ट करना, जबकि mobile app, API और embedded device के risks अलग हैं।
  • Defect को किसी की लापरवाही का सबूत मानना, न कि जटिल systems बनाने का सामान्य नतीजा।

QA का नज़रिया

नए project में system का चित्र जल्दी बनाएँ: front ends (web, Android, iOS), वे कौन-सी back-end services और APIs call करते हैं, databases और बाहरी services, और environments। किसी developer से चित्र ठीक करवाएँ; यही आपका पहला नक्शा बनता है कि tests कहाँ चाहिए और हर हिस्से का owner कौन है।

हर bug report में वह layer लिखें जहाँ आपने problem देखी, और वह context जो program, data और configuration की पहचान कराए: environment, build या app version, browser या device, test account और data, और समय। तब developer सीधे सही logs तक पहुँच सकता है।

अभ्यास

Clinic booking system के हिस्सों को वर्गीकृत करें

आपका काम

एक clinic मरीज़ों को अपनी website पर appointments बुक करने देता है और SMS reminders भेजता है। List A के हर item को program, data या configuration में वर्गीकृत करें, और नोट करें कि कौन-से items test और production में अलग होंगे। फिर list B की हर problem के लिए वह layer बताएँ जिसे आप सबसे पहले जाँचेंगे, और team से पूछने के लिए एक सवाल लिखें।

सामग्री
A. System के हिस्से
   1. वह code जो एक ही मरीज़ को तीसरी आगामी appointment बुक करने से रोकता है
   2. Doctors की सूची, उनकी specialties और काम के घंटे
   3. cancellation_hours: 24
   4. मरीज़ों की बुक की हुई हर appointment
   5. sms_service: https://sms.test.example.com
   6. वह code जो appointment से एक दिन पहले reminder SMS भेजता है

B. Report हुई problems
   1. Phone पर "Book" button on-screen keyboard के पीछे छिप जाता है।
   2. एक मरीज़ तीसरी आगामी appointment बुक करने में सफल रहा।
   3. Reminders test environment में आते हैं, पर production में कभी नहीं।
   4. Site ने "Booked" दिखाया, पर अगले दिन appointment गायब है।
चरण
  1. List A के हर item के लिए पूछें: क्या यह निर्देश है (program), वह जानकारी जिस पर program काम करता है (data), या ऐसी setting जो नए code के बिना व्यवहार बदलती है (configuration)?
  2. उन items को चिह्नित करें जिनकी सामग्री test और production environments में अलग है।
  3. List B की हर problem के लिए लिखें कि symptom कहाँ दिखता है, फिर कौन-सी layer उसे पैदा कर सकती है।
  4. हर problem के लिए उस layer के owner से पूछने का एक सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

List A: 1 program, 2 data, 3 configuration, 4 data, 5 configuration, 6 program। Item 5 test और production में निश्चित रूप से अलग है, item 3 शायद, और items 2 व 4 का data भी, क्योंकि production में असली doctors और appointments होते हैं।

List B: 1 front end, यानी keyboard खुला होने पर layout; पूछें कि page को किन screen sizes को support करना है। 2 back end, यानी list A के item 1 वाला rule; पूछें कि limit server पर जाँची जाती है या सिर्फ़ screen पर।

3 configuration और infrastructure: दोनों environments में program वही है, इसलिए जो अलग है उसे जाँचें, जैसे sms_service; पूछें कि production configuration में क्या है। 4 database और back end: जाँचें कि record सेव हुआ या नहीं और क्या बाद में बदला या हटाया गया; booking के समय का record और server logs माँगें। अगर record कभी सेव ही नहीं हुआ, तो यह भी जाँचें कि कहीं back end के error लौटाने के बावजूद front end ने "Booked" तो नहीं दिखा दिया।

अक्सर पूछे जाने वाले सवाल

क्या configuration सच में software का हिस्सा है?

हाँ। Configuration program के साथ आता है या हर environment में अलग से set किया जाता है; program चलते समय उसे पढ़ता है, और वह program का व्यवहार बदलता है, इसलिए उसमें भी defects हो सकते हैं। एक गलत setting सही program को तोड़ सकती है, इसीलिए configuration के बदलाव को भी code के बदलाव की तरह testing चाहिए।

क्या इन layers को समझने के लिए programming आनी ज़रूरी है?

नहीं। आपको यह जानना है कि हर layer क्या करती है और उसे कैसे observe करें: front end के लिए screen, back end के लिए requests और responses, database के लिए stored records, और infrastructure के लिए environment की details। आगे के modules इनमें से हर एक को tools के साथ सिखाते हैं।

API और back end में क्या फ़र्क है?

Back end server पर चलने वाला वह program है जो rules लागू करता है। API वह interface है जो यह program दूसरे programs को देता है: वह कौन-सी requests स्वीकार करता है और कौन-से responses लौटाता है। Front end, back end को उसकी API के ज़रिए इस्तेमाल करता है, और कोई mobile app या partner system भी वही API इस्तेमाल कर सकता है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • Overview of HTTP — MDNMDN Web Docs (Mozilla)HTTP कैसे काम करता है: एक stateless client–server प्रोटोकॉल, जिसमें client request भेजता है और server response संदेश से जवाब देता है।
टूल्स

Mutqan tools से अभ्यास करें

URL पार्सर

किसी URL को protocol, host, port, path, क्वेरी पैरामीटर, fragment और क्रेडेंशियल में तोड़ें।

वेब

HTTP स्टेटस कोड लुकअप

किसी भी HTTP स्टेटस कोड का अर्थ, RFC संदर्भ और उसे कब इस्तेमाल करना है — सब एक जगह देखें।

वेब

JSON फ़ॉर्मेटर

अपने ब्राउज़र में ही JSON को तुरंत फ़ॉर्मेट, सुंदर और वैलिडेट करें, मनचाहे इंडेंटेशन के साथ।

JSON और डेटा

JSON ट्री व्यूअर

JSON को कोलैप्सिबल ट्री के रूप में देखें — पाथ, टाइप और वैल्यू की संख्या के साथ।

JSON और डेटा

YAML फ़ॉर्मेटर

YAML को एकसमान इंडेंटेशन और quoting के साथ फ़ॉर्मेट और वैलिडेट करें।

फ़ॉर्मेटिंग

User-Agent पार्सर

User-Agent स्ट्रिंग से ब्राउज़र, वर्शन, इंजन, OS, डिवाइस टाइप और बॉट की पहचान करें।

वेब

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

कोई पूर्व-आवश्यकता नहीं: यह शुरुआती बिंदु है।