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

सॉफ़्टवेयर कैसे बनता है

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

Software development वह सारा काम है जो किसी idea को ऐसे software में बदलता है जिसे लोग इस्तेमाल कर सकें, और उसके बाद उसे चलता हुआ रखता है। Code लिखना इसका सिर्फ़ एक हिस्सा है: कोई तय करता है कि क्या बनाना है, कोई डिज़ाइन करता है कि वह कैसे व्यवहार करेगा, developers code लिखते हैं, testers उसे जाँचते हैं, और कोई उसे release करके चालू रखता है।

मान लीजिए एक grocery app चाहता है कि customers एक tap में पिछला order दोहरा सकें। किसी भी code से पहले product owner तय करता है कि यह बनाने लायक है, business analyst rules लिखता है (जो items stock में नहीं रहे, उनका क्या?) और designer screen का sketch बनाता है। जैसा पिछले पाठ में देखा, software इंसान बनाते हैं, इसलिए हर step ऐसी जगह है जहाँ गलती घुस सकती है या पकड़ी जा सकती है।

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

जो tester सिर्फ़ तैयार screen देखता है, वह एक लंबी chain का सिर्फ़ आख़िरी सिरा देखता है। कई defects code से पहले या code के बाहर शुरू होते हैं: एक अस्पष्ट requirement, बिना error state वाला design, या कोई setting जो environments के बीच अलग है। किस step ने कौन-सा work product बनाया, यह जानकर आप failure को उसके स्रोत तक trace कर सकते हैं और तब सवाल पूछ सकते हैं जब बदलाव अभी सस्ता है।

इससे यह भी पता चलता है कि किससे पूछना है और क्या record करना है: किसी test result का मतलब तभी है जब उसमें वह build और environment लिखा हो जिस पर वह मिला।

लोग: software टीम के roles

Role ज़िम्मेदारियों का एक सेट है, job title नहीं: एक व्यक्ति कई roles निभा सकता है, और एक role पूरी टीम भी हो सकता है।

  • Product owner: तय करता है कि product आगे क्या करे और किस क्रम में; Scrum में यह product की value बढ़ाने और product backlog, यानी product को बेहतर बनाने के लिए ज़रूरी कामों की क्रमबद्ध सूची, को manage करने के लिए जवाबदेह होता है।
  • Business analyst: बारीकियाँ (business rules, data, exceptions) निकालता है और उन्हें requirements के रूप में लिखता है; कुछ टीमें यह काम product owner पर छोड़ देती हैं।
  • Designer: तय करता है कि लोग feature कैसे इस्तेमाल करेंगे: flows, layouts, शब्द, और empty, loading व error जैसी states।
  • Developer: requirements और designs को code में बदलता है, unit tests लिखता है और साथियों के code का review करता है, अक्सर front end या back end जैसी किसी एक layer में।
  • Tester या QA engineer: requirements और designs का review करता है, tests चलाता है, defects report करता है और release के फ़ैसले के लिए टीम को quality की जानकारी देता है।
  • DevOps या operations engineer: build और deploy करने वाली pipeline, environments और production monitoring की देखभाल करता है। सख़्ती से देखें तो DevOps पूरी टीम के काम करने का तरीका है, पर यह एक आम job title भी है।

Work products: हर step आगे क्या सौंपता है

हर step कुछ ऐसा बनाता है जिसे अगला step इस्तेमाल करता है। ISTQB इन्हें work products कहता है; कई टीमें artifacts कहती हैं। Tester के लिए ये दो तरह से अहम हैं: आप इन्हीं के आधार पर टेस्ट करते हैं, और कोई code चलने से पहले इनका review करके इन्हें ख़ुद भी टेस्ट कर सकते हैं। ये बदलते भी हैं: कोई edit हो तो पुराना और नया version compare करें ताकि पता चले कि कौन-से tests प्रभावित हैं।

  • Requirements: acceptance criteria के साथ user stories, business rules, और response time जैसे targets। नीचे की story एक आम उदाहरण है।
  • Designs: designer से wireframes और prototypes; developers से architecture और API contracts।
  • Code: Git जैसे version control system में रखी source files; कई टीमों में हर बदलाव merge से पहले pull request में review होता है।
  • Build: code के एक बिल्कुल तय version से, आम तौर पर अपने-आप, बना runnable package, जिसका अपना identifier होता है; एक टीम दिन में कई builds बना सकती है।
  • Release: ऐसा build जिसे टीम ने users को देने का फ़ैसला किया, version number और release notes के साथ।
STORY-142  Checkout पर promo code लगाना
एक shopper के रूप में
मैं checkout पर promo code लगाना चाहता हूँ
ताकि मैं discount वाली कीमत चुकाऊँ।

AC1  Valid code payment से पहले order total कम करता है।
AC2  Expired code पर "इस code की अवधि ख़त्म हो चुकी है" message दिखता है।
AC3  एक order पर सिर्फ़ एक code लगाया जा सकता है।

आज़माएँ: टेक्स्ट डिफ़

Idea से operation तक

Roles और work products को साथ रखें तो वह रास्ता मिलता है जिससे हर बदलाव गुज़रता है। अगला module इसे software development lifecycle (SDLC) कहता है और उन models की तुलना करता है जिनसे टीमें इसे व्यवस्थित करती हैं; यहाँ इसका सरल रूप है।

Idea से operation तक: हर step पर सबसे सक्रिय role और वह work product जो वह आगे सौंपता है, और requirements से ही testers की भागीदारी। वैचारिक मॉडल
  1. 1IdeaProduct ownerFeedback, business goal या regulation से बना backlog item
  2. 2RequirementsProduct owner, business analystUser stories, acceptance criteria, business rules
  3. 3DesignDesigner, developersScreens और flows, API contracts, data changes
  4. 4BuildDevelopersReviewed code; pipeline एक build बनाती है
  5. 5TestTestersTest results, defect reports, confirmation tests
  6. 6ReleaseProduct owner तय करता है; DevOps engineer deploy करता हैVersion number और release notes
  7. 7OperateDevOps engineer, support, पूरी टीमMonitoring, user reports, अगला idea

चरण 2–7 के दौरान Testers पूरे रास्ते शामिल रहते हैं: requirements और designs का review, builds की testing, releases की जाँच और production feedback पढ़ना।

चरण 1 पर वापस Operation में टीम जो सीखती है, वही अगला idea बनता है

सरल रूप: हर बदलाव के लिए steps आपस में overlap करते हैं और दोहराए जाते हैं, और एक व्यक्ति कई roles निभा सकता है।

दो बातों का ध्यान रखें। Steps आपस में overlap करते हैं और दोहराए जाते हैं: defect काम को build पर वापस भेजता है, अस्पष्ट requirement उसे requirements पर। और testers सिर्फ़ test step तक सीमित नहीं: ISTQB Foundation syllabus सलाह देता है कि हर development activity के सामने एक test activity हो, और testers work products का review उनके draft उपलब्ध होते ही करें।

  • Idea: feedback, business goal या कोई regulation; product owner तय करता है कि यह करने लायक है या नहीं।
  • Requirements: stories, rules और acceptance criteria, जिनका testers review करते हैं।
  • Design: designer से screens और flows, developers से technical design।
  • Build: code लिखा और review किया जाता है; pipeline एक build बनाती है।
  • Test: test environment में build पर tests चलते हैं; fixes दोबारा टेस्ट होते हैं (confirmation testing)।
  • Release: टीम तय करती है कि build तैयार है, और वह release notes के साथ production में deploy होता है।
  • Operate: टीम live system की monitoring और support करती है; जो सीखती है वही अगला idea बनता है।

Worked example: एक promo code, idea से operation तक

एक online store को बार-बार ऐसे customers के support messages मिलते हैं जिन्हें नहीं मिलता कि discount code कहाँ डालें। Product owner promo code field को backlog में सबसे ऊपर ले आता है, और business analyst STORY-142 लिखता है। बाकी steps में इसका पीछा करें:

  • Requirements: tester पूछता है कि कोई item हटाने पर discount का क्या होगा, और क्या codes case-sensitive हैं। कोई code लिखे जाने से पहले ही जवाब AC4 और AC5 बन जाते हैं।
  • Design: tester loading state माँगता है, क्योंकि code जाँचने के लिए server को call जाती है।
  • Build और test: pull request 318 merge होने के बाद pipeline build 1047 बनाकर उसे test environment पर deploy करती है। Tester दो defects report करता है, हर एक में build 1047 और fail हुआ criterion लिखकर, और build 1049 में fixes confirm करता है (confirmation testing)।
  • Release: build 1049 version 4.6.0 के रूप में production में जाता है, और tester deployment के ठीक बाद एक छोटी जाँच करता है।
  • Operate: एक user बताता है कि एक valid code आख़िर में extra space की वजह से reject हुआ। Fix एक नए regression test के साथ अगली release में जाता है, और loop पूरा होता है।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: User Story → टेस्ट सिनेरियो

आम गलतियाँ

  • यह सोचना कि testing तब शुरू होती है जब code पूरा हो जाए। Requirements और designs का review, और उनके defects की खोज, किसी भी code से पहले हो सकती है।
  • Steps को एक-तरफ़ा line मानना; जब भी कोई defect या अस्पष्ट requirement सामने आती है, काम पीछे लौटता है।
  • किसी तय build की जगह "app" को टेस्ट करना: जिस defect report में build और environment न लिखा हो, उसे reproduce करना अक्सर नामुमकिन होता है।
  • Requirement की जगह screen पर दिख रही चीज़ के आधार पर टेस्ट करना, जिससे आप defect और intended behaviour में फ़र्क नहीं कर पाते।
  • मान लेना कि quality सिर्फ़ tester का काम है। ISTQB एक whole-team approach बताता है जिसमें हर कोई quality के लिए ज़िम्मेदार है।

QA का नज़रिया

असली टीम में हर काम के लिए जानें कि वह किस step पर है, कौन-सा work product source of truth है और उसका owner कौन है; इसी से पता चलता है कि किससे पूछना है। Business rules के लिए product owner या analyst, screen states के लिए designer, "fix किस build में है?" के लिए developer। Backlog refinement sessions में शामिल हों, जहाँ सवाल सबसे सस्ते पड़ते हैं।

हर जगह identifiers record करें: हर test result और defect report में requirement, build या version, और environment लिखें। Release के बाद production signals और user reports पढ़ें; वे दिखाते हैं कि आपके tests से क्या छूट गया।

अभ्यास

एक feature को idea से operation तक map करें

आपका काम

एक clinic booking app मरीज़ों को appointment से 24 घंटे पहले text message reminder भेजना चाहता है। सातों steps में से हर एक के लिए मुख्य role, work product, और एक चीज़ लिखें जो tester उस step पर कर या पूछ सकता है। फिर लिखें कि defect report में क्या होना चाहिए ताकि developer को ठीक-ठीक पता चले कि कौन-सा version fail हुआ।

मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Idea — product owner; एक backlog item। पूछें कि सफलता कैसे मापी जाएगी, जैसे छूटे appointments में कमी।

Requirements — product owner या business analyst; acceptance criteria के साथ story। पूछें: अगर booking 24 घंटे से कम पहले हो तो? कौन-सा time zone माना जाएगा? अगर मरीज़ reminder के बाद appointment cancel कर दे तो?

Design — designer और developers; हर भाषा में message के शब्द और scheduled job का technical design। पूछें कि sending failures कैसे log होते हैं।

Build — developers; code और build। 23, 24 और 25 घंटे बाद वाले appointments तैयार करें, और पूछें कि पूरा दिन इंतज़ार किए बिना job कैसे trigger करें।

Test — tester; test results और defect reports। तैयार किए गए cases चलाएँ, reminder के बाद cancel हुई booking समेत, test phone numbers के साथ, असली मरीज़ों के नंबरों से कभी नहीं।

Release — product owner तय करता है, DevOps engineer deploy करता है; version और release notes। जाँचें कि production में reminders schedule हो रहे हैं।

Operate — DevOps engineer और support; fail हुए messages की monitoring। शिकायतों को नए test cases में बदलें।

Defect report: build या version, environment, जिस requirement या criterion को वह तोड़ता है, और test की तारीख़, समय और time zone, क्योंकि reminders समय पर निर्भर हैं।

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

क्या इस process में काम करने के लिए coding आनी चाहिए?

शुरुआत में नहीं। Tester को steps समझने, work products पढ़ने और हर role से बात करने की ज़रूरत है। Code पढ़ना बाद में काम आता है, जैसे unit tests का review करते समय या checks automate करते समय, और इस roadmap के automation modules इसे सिखाते हैं।

क्या यही software development lifecycle (SDLC) है?

यह उसका सरल preview है। ISTQB SDLC को software development के हर stage पर होने वाली activities और उनके आपसी संबंध, तार्किक और समय दोनों के क्रम में, के रूप में बताता है। Waterfall, V-model और Agile जैसे models इन्हीं activities को अलग-अलग तरह से व्यवस्थित करते हैं; अगला module इनकी तुलना करता है।

Build और release में क्या अंतर है?

Build code के एक version से बना runnable package है; एक टीम दिन में कई builds बना सकती है, और ज़्यादातर सिर्फ़ टेस्ट होते हैं। Release वह build है जिसे टीम ने users को देने का फ़ैसला किया, version number और release notes के साथ। हर release एक build है, पर ज़्यादातर builds कभी release नहीं होते।

Test environment क्या है, और सीधे production में टेस्ट क्यों नहीं करते?

Test environment system की एक अलग copy है जिस पर builds टेस्टिंग के लिए install किए जाते हैं, असली customers के data की जगह test data के साथ। वहाँ टेस्ट करने का मतलब है कि failure से किसी असली user को नुकसान नहीं होता और data reset किया जा सकता है। Release के बाद कुछ checks production में भी होते हैं, पर सावधानी से और टीम की सहमति से।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
  • About pull requestsGitHubpull request क्या है: एक branch के बदलावों को दूसरी में merge करने का प्रस्ताव, जहाँ merge से पहले चर्चा, review और checks होते हैं।
टूल्स

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

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

और गहराई से

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

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