Software Review के प्रकार

Review को औपचारिकता के आधार पर क्यों बाँटा जाता है

हर review प्रकार एक जैसे व्यापक लक्ष्यों के पीछे है — defects ढूँढना, क्वालिटी का आकलन, साझा समझ बनाना — पर उन्हें अलग वज़न देता है। Informal सिरे पर गति और कम लागत सबसे अहम है; formal सिरे पर गहराई, दोहराने योग्यता और प्रक्रिया सुधारने के लिए डेटा। Review जितना औपचारिक होगा, उतना ही वह सामान्य प्रक्रिया का पालन करेगा, भूमिकाएँ उतनी साफ़ अलग होंगी, और वह उतना ज़्यादा दर्ज और मापेगा।

दो अन्य संदर्भ थोड़ी अलग शब्दावली इस्तेमाल करते हैं। सॉफ़्टवेयर review और audit का IEEE मानक IEEE 1028-2008 (जिसे IEEE inactive-reserved के रूप में सूचीबद्ध करता है) पाँच प्रकार परिभाषित करता है: management review, technical review, inspection, walkthrough और audit। इसका management review प्रगति पर नज़र रखता है और plans व schedules का आकलन करता है; audit standards, नियमों, plans या procedures के अनुपालन की स्वतंत्र जाँच है। दोनों में से कोई भी मुख्य रूप से वर्क प्रोडक्ट की तकनीकी सामग्री में defects ढूँढने के लिए नहीं है। ISO/IEC 20246 वर्क प्रोडक्ट review का सामान्य फ़्रेमवर्क — प्रक्रिया, भूमिकाएँ और तकनीकें — बताता है, जिसका ISTQB review प्रक्रिया काफ़ी करीब से पालन करती है।

Informal review

Informal review किसी तय प्रक्रिया का पालन नहीं करता और औपचारिक दर्ज आउटपुट की ज़रूरत नहीं रखता। इसका मुख्य उद्देश्य anomalies ढूँढना है। किसी सहकर्मी का pull request पढ़ना, refinement से पहले किसी टेस्टर का user story पर नज़र डालना, "ज़रा यह query देख लोगे?" वाला मैसेज: ये सब informal review हैं। Pair programming और pair testing लगातार चलने वाले informal review की तरह काम करते हैं।

Informal review सस्ते और तेज़ हैं, इसीलिए सबसे आम हैं। उनकी कमज़ोरी यह है कि गहराई की कोई जाँच नहीं होती: बिना तैयारी या checklist के informal review सिर्फ़ मंज़ूरी की मुहर बन सकता है। दो आदतें मदद करती हैं: reviewer को बताएँ कि किस पर ध्यान देना है, और formatting automated checks पर छोड़ें ताकि reviewer का ध्यान logic पर जाए।

Walkthrough

Walkthrough का नेतृत्व author करता है, जो प्रतिभागियों को वर्क प्रोडक्ट से गुज़ारता है — अक्सर किसी scenario या dry run के ज़रिए। CTFL v4.0 उद्देश्यों की एक व्यापक सूची देता है: क्वालिटी का आकलन और भरोसा बनाना, reviewers को सिखाना, सहमति बनाना, नए विचार पैदा करना, authors को सुधार के लिए प्रेरित और सक्षम करना, और anomalies ढूँढना। सत्र से पहले individual preparation हो सकती है, पर ज़रूरी नहीं।

Walkthrough उन वर्क प्रोडक्ट के लिए ठीक है जिन्हें इस्तेमाल करने के लिए दूसरों का समझना ज़रूरी है: वह test plan जो उसे चलाने वाली टीम के सामने रखा जाए, नया architecture जो उस पर बनाने वाले डेवलपरों को समझाया जाए, कोई जटिल business rule जो टेस्टरों को समझाया जाए। जोखिम यह है कि author कहानी पर नियंत्रण रखता है और कमज़ोर जगहों से आगे निकल सकता है, इसलिए कम से कम एक ऐसे प्रतिभागी को बुलाएँ जिसका काम "अगर ऐसा हो तो…?" पूछना हो।

Technical review

Technical review तकनीकी रूप से योग्य reviewers करते हैं और moderator इसका नेतृत्व करता है। इसके मुख्य उद्देश्य किसी तकनीकी समस्या पर सहमति बनाना और फ़ैसले लेना हैं; यह anomalies भी ढूँढता है, क्वालिटी आँकता है, भरोसा बनाता है, नए विचार लाता है और authors को सुधारने में मदद करता है। Reviewers से individual preparation की अपेक्षा होती है, और नतीजा — findings और फ़ैसले — दर्ज किया जाता है।

आम विषय डिज़ाइन के विकल्प और specifications हैं: दो data models में से चुनना, implementation से पहले API contract मंज़ूर करना, यह तय करना कि कोई service किसी dependency के बंद होने को कैसे संभालेगी। Moderator की क़ीमत यह है कि चर्चा किसी फ़ैसले पर ख़त्म हो, सबसे ऊँची आवाज़ वाली राय पर नहीं।

Inspection

Inspection सबसे औपचारिक review प्रकार है। यह पूरी सामान्य review प्रक्रिया का पालन करता है, और इसका मुख्य उद्देश्य जितनी हो सकें उतनी anomalies ढूँढना है; यह क्वालिटी भी आँकता है, भरोसा बनाता है और authors को सुधार के लिए प्रेरित करता है। Metrics इकट्ठा करके सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकल सुधारने में इस्तेमाल होते हैं, जिसमें inspection प्रक्रिया ख़ुद शामिल है। Inspection में author, review leader या scribe की भूमिका नहीं निभा सकता।

Inspection की जड़ें 1970 के दशक में IBM में Michael Fagan के काम में हैं। व्यवहार में इसमें entry criteria (डॉक्यूमेंट inspect करने लायक पूरा है), पिछले defects से बनी checklists, हर reviewer की individual preparation, moderator द्वारा चलाई गई मीटिंग जो fixes पर बहस के बजाय findings दर्ज करती है, औपचारिक rework, और rework पूरा होने की जाँच होती है। Inspection महँगा है, इसलिए इसे उन वर्क प्रोडक्ट के लिए रखें जहाँ छूटा defect महँगा पड़ता है: payment या tax calculation rules, security-critical कोड, नियामक requirements, safety से जुड़ा logic, data migration scripts।

चारों प्रकारों की तुलना

यह तालिका CTFL v4.0 में बताई विशेषताओं का सार है, और जहाँ सिलेबस विकल्प खुला छोड़ता है वहाँ आम प्रैक्टिस भरी गई है। इसे मार्गदर्शक मानें: कोई टीम inspection जैसी checklists के साथ technical review कर सकती है, या छोटे लिखित log के साथ informal review।

Inspection metrics में आम तौर पर वर्क प्रोडक्ट का आकार, हर reviewer का preparation time, मीटिंग का समय, type और severity के अनुसार findings, finding density (प्रति पेज या प्रति हज़ार लाइन), rework effort और बाद में review से छूटे defects शामिल होते हैं। इन संख्याओं का उद्देश्य प्रक्रिया सुधारना है — author या reviewers को आँकना कभी नहीं।

• Informal review — उद्देश्य: anomalies जल्दी ढूँढना। औपचारिकता: सबसे कम। नेतृत्व: कोई नहीं, या author। भूमिकाएँ: author और एक या अधिक reviewers। तैयारी: वैकल्पिक। डॉक्यूमेंटेशन: ज़रूरी नहीं। Metrics: शायद ही कभी।
• Walkthrough — उद्देश्य: समझ बनाना, सिखाना और नए विचार। औपचारिकता: कम से मध्यम। नेतृत्व: author। भूमिकाएँ: author और प्रतिभागी। तैयारी: वैकल्पिक। डॉक्यूमेंटेशन: वैकल्पिक नोट्स। Metrics: शायद ही कभी।
• Technical review — उद्देश्य: सहमति और तकनीकी फ़ैसले। औपचारिकता: मध्यम से ऊँची। नेतृत्व: moderator। भूमिकाएँ: moderator, योग्य reviewers और scribe। तैयारी: अपेक्षित। डॉक्यूमेंटेशन: findings और फ़ैसले। Metrics: वैकल्पिक।
• Inspection — उद्देश्य: जितनी हो सकें उतनी anomalies ढूँढना। औपचारिकता: सबसे ज़्यादा। नेतृत्व: review leader, जो कभी author नहीं होता। भूमिकाएँ: सभी, साफ़ तौर पर अलग-अलग। तैयारी: ज़रूरी, checklists के साथ। डॉक्यूमेंटेशन: entry/exit criteria, log, report और rework की जाँच। Metrics: इकट्ठा करके प्रक्रिया सुधारने में इस्तेमाल।

                Informal review   Walkthrough          Technical review       Inspection
Main purpose    find anomalies    understanding,       consensus and          find as many
                quickly           education, ideas     technical decisions    anomalies as possible
Formality       lowest            low to medium        medium to high         highest
Led by          nobody / author   the author           a moderator            a review leader;
                                                                              never the author
Roles           author +          author +             moderator, qualified   all roles, clearly
                1..n reviewers    participants         reviewers, scribe      separated
Preparation     optional          optional             expected               required, with checklists
Documentation   none required     optional notes       findings + decisions   entry/exit criteria, log,
                                                                              report, rework check
Metrics         rarely            rarely               optional               collected and used to
                                                                              improve the process

सामान्य review प्रक्रिया

CTFL v4.0 ISO/IEC 20246 में परिभाषित सामान्य review प्रक्रिया की पाँच गतिविधियाँ बताता है। Review जितना औपचारिक होता है, हर गतिविधि के उतने ज़्यादा काम ज़रूरी होते हैं: inspection पूरी प्रक्रिया का पालन करता है, जबकि informal review किसी परिभाषित प्रक्रिया का पालन नहीं करता।

• Planning — scope तय करें: review का उद्देश्य, वर्क प्रोडक्ट, किन क्वालिटी विशेषताओं का आकलन होगा, किन हिस्सों पर ध्यान देना है, exit criteria, standards जैसी सहायक जानकारी, और effort व समय-सीमा।
• Review initiation — पक्का करें कि हर व्यक्ति और हर चीज़ तैयार है: प्रतिभागियों के पास वर्क प्रोडक्ट की पहुँच है, वे अपनी भूमिकाएँ और ज़िम्मेदारियाँ समझते हैं, और उनके पास checklists व संबंधित डॉक्यूमेंट जैसी ज़रूरी चीज़ें हैं।
• Individual review — हर reviewer अकेले वर्क प्रोडक्ट की जाँच करता है, checklist-based या scenario-based reviewing जैसी एक या अधिक review तकनीकें लागू करता है, और anomalies, सुझाव व सवाल दर्ज करता है।
• Communication and analysis — anomalies पर चर्चा और विश्लेषण होता है, आम तौर पर review मीटिंग में या review टूल में। हर एक के लिए समूह उसका status, owner और ज़रूरी action तय करता है, और वर्क प्रोडक्ट का क्वालिटी स्तर व कोई follow-up तय करता है, जिसमें दूसरा review भी हो सकता है।
• Fixing and reporting — जिन findings पर सुधार चाहिए उनके defect reports बनते हैं ताकि उन्हें ट्रैक किया जा सके; exit criteria पूरे होने पर वर्क प्रोडक्ट स्वीकार किया जा सकता है, और review के नतीजे रिपोर्ट किए जाते हैं।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Acceptance Criteria रिव्यूअर आज़माएँ: टेक्स्ट डिफ़

Review की भूमिकाएँ

CTFL v4.0 छह मुख्य भूमिकाएँ बताता है। Informal review में एक-दो लोग सब निभाते हैं; inspection में ये अलग-अलग लोगों को दी जाती हैं। ISO/IEC 20246 और विस्तृत भूमिकाएँ भी बताता है।

• Manager — तय करता है कि किसका review होगा और लोग व समय जैसे संसाधन देता है।
• Author — वर्क प्रोडक्ट बनाता है और review के बाद उसे ठीक करता है।
• Moderator (facilitator) — review मीटिंग का प्रभावी संचालन पक्का करता है: मध्यस्थता, समय प्रबंधन, और ऐसा सुरक्षित माहौल जिसमें हर कोई खुलकर बोल सके।
• Scribe (recorder) — reviewers से anomalies इकट्ठा करता है और फ़ैसले व मीटिंग में मिली नई anomalies जैसी review जानकारी दर्ज करता है।
• Reviewer — review करता है। Reviewer टीम का सदस्य, विषय विशेषज्ञ या कोई भी stakeholder हो सकता है; अलग दृष्टिकोण (यूज़र, टेस्टर, operations, security) वाले reviewers चुनने से अलग defects मिलते हैं।
• Review leader — review की पूरी ज़िम्मेदारी लेता है: तय करता है कि कौन शामिल होगा और आयोजित करता है कि review कब और कहाँ होगा।

Review को सफल क्या बनाता है

• स्पष्ट उद्देश्य और मापने योग्य exit criteria। प्रतिभागियों का मूल्यांकन कभी उद्देश्य नहीं होना चाहिए।
• वर्क प्रोडक्ट और उसके जोखिम के हिसाब से सही review प्रकार — payment rules के लिए inspection, टेक्स्ट बदलाव के लिए informal review।
• छोटे हिस्से। लंबे डॉक्यूमेंट और बड़े diffs पर reviewers का ध्यान टूटता है; काम को बाँटें ताकि हर सत्र केंद्रित रहे।
• Authors और stakeholders को feedback, ताकि प्रोडक्ट और प्रक्रिया दोनों सुधरें।
• तैयारी के लिए पर्याप्त समय, जो schedule में शामिल हो, दूसरे कामों के बीच ठूँसा न जाए।
• Management का दिखता हुआ समर्थन, और review को संगठन की सीखने व सुधारने की संस्कृति का हिस्सा मानना।
• प्रतिभागियों को उनकी भूमिकाओं और review तकनीकों का प्रशिक्षण।
• Facilitated मीटिंग जो findings और फ़ैसले दर्ज करें, कमरे में बैठकर प्रोडक्ट दोबारा डिज़ाइन न करें।
• टिप्पणियाँ काम पर हों, व्यक्ति पर नहीं — जैसे "यह branch expired token को कभी हैंडल नहीं करती", न कि "तुम expired token भूल गए"। Google की code review गाइड भी यही बात कहती है।

व्यावहारिक उदाहरण और review log

उदाहरण के लिए, कोई टीम review प्रकार ऐसे चुन सकती है: दो लाइन के bug-fix pull request का एक साथी द्वारा informal review, CI static checks gate के रूप में; नए release का regression test plan, test lead के नेतृत्व में walkthrough में उन टेस्टरों के सामने जो उसे चलाएँगे; product catalogue API के लिए दो caching रणनीतियों के बीच चुनाव, एक architect, दो senior डेवलपर और एक operations इंजीनियर के साथ moderated technical review में, फ़ैसला दर्ज; और payment फ़ीचर के refund rules, पिछले refund defects से बनी checklist के साथ inspection में।

Review log के लिए किसी ख़ास टूल की ज़रूरत नहीं। नीचे का काल्पनिक उदाहरण वे फ़ील्ड दिखाता है जो findings को traceable और metrics को संभव बनाते हैं।

Log को ऐसे पढ़ें: ऊपर review किया गया डॉक्यूमेंट और उसका version, review का प्रकार (यहाँ inspection), हर भूमिका किसके पास है (author न leader है, न scribe), और entry व exit criteria। फिर हर finding की एक पंक्ति: ID, डॉक्यूमेंट में जगह, finding का प्रकार (अस्पष्टता, छूटी बात, असंगति, testability), severity, finding ख़ुद, owner और status। यहाँ दो major findings हैं — refund की कोई समय-सीमा नहीं, और discount code से चुकाए गए order के आंशिक refund का कोई नियम नहीं — और दो minor: दो sections (4.2 और 6.2) में refund की अलग-अलग सीमा, और ग्राहक को सूचना किस माध्यम से और कितने समय में मिलेगी यह अस्पष्ट। अंत में metrics (पेज, तैयारी और मीटिंग का समय, findings की गिनती) और फ़ैसला: rework ज़रूरी है, और स्वीकार करने से पहले moderator fixes की जाँच करता है।

Review:     REQ-PAY-014 Refund rules v0.3            Type: Inspection
Leader:     Neha R.   Moderator: Omar K.   Scribe: Priya S.   Author: Arjun M.
Entry:      document complete, linked to epic PAY-7, checklist CL-REFUND v2 attached
Exit:       no open major findings; every minor finding has an owner

ID    Where   Type          Sev    Finding                                          Owner  Status
F-01  2.1     Ambiguity     Major  "Refunds are processed promptly" has no time     Arjun  Open
                                   limit. State it in business days.
F-02  3.4     Omission      Major  No rule for a partial refund on an order         Arjun  Open
                                   paid with a discount code.
F-03  4.2     Consistency   Minor  Refund limit is 50,000 INR here, 30,000 INR      Arjun  Fixed
                                   in 6.2.
F-04  AC-7    Testability   Minor  "The customer is informed": by which channel,    Arjun  Open
                                   and within what time?

Metrics:   9 pages · preparation 4 h 10 min total · meeting 45 min · 4 findings (2 major)
Decision:  rework required; moderator verifies the fixes before acceptance

आज़माएँ: AI टेस्ट केस ऑप्टिमाइज़र आज़माएँ: AI डुप्लिकेट टेस्ट केस डिटेक्टर आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017वर्क प्रोडक्ट की समीक्षा का सामान्य फ़्रेमवर्क — review प्रक्रिया, भूमिकाएँ और review तकनीकें।
• IEEE 1028-2008 — IEEE Standard for Software Reviews and AuditsIEEE Standards Association · 2008management review, technical review, inspection, walkthrough और audit की क्लासिक परिभाषाएँ (IEEE इसे inactive-reserved के रूप में सूचीबद्ध करता है)।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Code Review Developer GuideGoogle (eng-practices)Google की प्रकाशित code review प्रथाएँ: reviewer क्या देखते हैं, बदलाव मंज़ूर करने का मानक और review टिप्पणियाँ कैसे लिखें।