सॉफ़्टवेयर क्वालिटी क्या है?
ISTQB glossary quality को उस degree के रूप में परिभाषित करता है जिस तक कोई work product अपने stakeholders की stated और implied needs पूरी करता है। Software quality किसी software product के लिए यही degree है, और product quality model ISO/IEC 25010 भी इसी विचार पर बना है। Quality degree की बात है, हाँ या ना की नहीं। Stated needs requirements और user stories में लिखी होती हैं; implied needs बिना लिखे अपेक्षित होती हैं: password स्क्रीन पर न दिखे, Arabic नाम ठीक वैसा ही save हो जैसा टाइप किया गया, payment दो बार न कटे।
एक clinic booking app मरीज़ को doctor और समय ठीक वैसे चुनने दे सकता है जैसे उसकी user story कहती है। पर अगर खाली समय दिखने में एक मिनट लगे, या कोई मरीज़ address bar में एक number बदलकर दूसरे मरीज़ की booking खोल ले, तो कोई इसे quality product नहीं कहेगा।
यह क्यों ज़रूरी है
अगर quality का मतलब सिर्फ़ "features काम करते हैं" होता, तो testing सिर्फ़ features जाँचती। लेकिन software और तरीक़ों से भी लोगों को निराश करता है: peak time पर धीमा हो जाता है, personal data उजागर करता है, screen reader के साथ इस्तेमाल नहीं हो पाता, network टूटने पर काम खो देता है, या इतनी मुश्किल से बदलता है कि हर fix कुछ और तोड़ देता है। Design बदलने की गुंजाइश रहते ये कमियाँ पकड़ लेना समय और पैसा बचाता है।
Tester के लिए quality model एक checklist भी है और साझा शब्दावली भी: यह दिखाता है कि requirement में क्या छूट गया, और समझाने में मदद करता है कि कोई defect किसी ख़ास stakeholder के लिए क्यों मायने रखता है।
ISO/IEC 25010:2023 की नौ characteristics
ISO/IEC 25010 product quality को characteristics में बाँटता है, और हर characteristic को sub-characteristics में। Functional testing functional suitability जाँचती है; बाक़ी आठ non-functional testing के हिस्से हैं, जिसे एक बाद का पाठ कवर करता है।
पुरानी सामग्री, 2011 edition समेत, interaction capability की जगह usability और flexibility की जगह portability कहती है, और उसमें safety नहीं है। ISTQB Foundation syllabus (v4.0.1) usability और portability रखता है, उनके साथ नए नाम लिखता है और safety को भी गिनाता है। नए documents में 2023 के नाम इस्तेमाल करें:
- Functional suitability: functions पूरे, सही और users के कामों के लिए उपयुक्त हों।
- Performance efficiency: time behaviour, resource utilisation और capacity।
- Compatibility: दूसरे software के साथ co-existence और जुड़े systems के साथ interoperability।
- Interaction capability: users उसे सीखकर चला सकें और अपनी गलतियों से बचे रहें; accessibility की जगह अब inclusivity और user assistance हैं।
- Reliability: faultlessness, availability, fault tolerance और recoverability।
- Security: सिर्फ़ authorised access, confidentiality, integrity, authenticity, accountability, non-repudiation और attack के प्रति resistance के ज़रिए।
- Maintainability: modularity, reusability, analysability, modifiability और testability।
- Flexibility: product को adapt, scale, install और replace किया जा सके।
- Safety: जीवन, स्वास्थ्य, संपत्ति या पर्यावरण को ख़तरे में डालने से बचना, जैसे fail safe व्यवहार और hazard warning के ज़रिए।
Product quality और quality in use
Product quality software के अपने गुणों का वर्णन करती है, और इसका बड़ा हिस्सा release से पहले reviews, static analysis और tests से जाँचा जा सकता है। Quality in use उस असर का वर्णन करती है जो तब होता है जब लोग असली context में अपने लक्ष्यों के लिए product इस्तेमाल करते हैं।
ISO/IEC 25010 के 2011 edition में दोनों models थे; अब quality in use का अपना standard है, ISO/IEC 25019:2023। वह इसे उस हद के रूप में परिभाषित करता है जिस तक कोई product, किसी तय context of use में इस्तेमाल होने पर, तय लाभकारी लक्ष्य पाने के लिए stakeholders की needs पूरी करता है या उनसे आगे जाता है, और इसकी तीन characteristics हैं: beneficialness, freedom from risk और acceptability।
अच्छी product quality अच्छी quality in use को संभव बनाती है, पक्का नहीं। Booking app हर test में pass होकर भी उन मरीज़ों को निराश कर सकता है जो कमज़ोर signal वाले पुराने phone से booking करते हैं। यही अंतर असली users के साथ acceptance testing और release के बाद monitoring की एक वजह है।
Quality users और context पर निर्भर है
Stakeholders एक ही product को अलग तरह से तौलते हैं: मरीज़ कुछ taps में booking चाहता है, clinic manager double booking नहीं चाहता, health regulator को चिंता है कि medical data कौन पढ़ सकता है। कौन-सी characteristics सबसे ज़्यादा मायने रखती हैं, यह इस पर निर्भर है कि product कौन, किस काम के लिए और कहाँ इस्तेमाल करता है, इसलिए एक ही defect एक product में मामूली और दूसरे में गंभीर हो सकता है।
Characteristics आपस में टकराती भी हैं: हर sign-in पर one-time code माँगना security बढ़ाता है पर interaction capability घटाता है। संतुलन चुनना product का फ़ैसला है; tester evidence के साथ इस trade-off को सामने लाता है।
- तीन analysts के लिए महीने की internal report: पहले correctness; धीमी screen चल जाएगी।
- राष्ट्रीय sale के पहले दिन public payment page: performance efficiency, security और reliability।
- दवा की खुराक calculate करने वाला software: safety बाक़ी सब से ऊपर हो सकती है।
- ऐसा banking app जिसके कई users बुज़ुर्ग हैं या screen reader इस्तेमाल करते हैं: interaction capability मूल requirement है।
Worked example: clinic booking app के लिए सवाल
User story: "मरीज़ के रूप में, मैं किसी doctor के साथ खाली समय पर appointment book करना चाहता हूँ, ताकि मुझे clinic को फ़ोन न करना पड़े।" Clinics में कई बुज़ुर्ग मरीज़ आते हैं, medical data store होता है, और bookings सुबह 08:00 बजे खुलती हैं।
हर characteristic के लिए एक सवाल इस functional story को फ़ैसलों और आगे की checks में बदल देता है। Team functional suitability, interaction capability, reliability और security को high, बाक़ी चार को medium, और safety को low मानती है क्योंकि app कोई medical सलाह नहीं देता; फिर भी safety के सवाल का जवाब product owner देते हैं।
- Functional suitability: चुने गए doctor के साथ 09:00 book करने पर क्या ठीक वही slot reserve होता है?
- Performance efficiency: 08:00 बजे, जब बहुत से मरीज़ एक साथ कोशिश करें, खाली slots कितनी जल्दी दिखने चाहिए?
- Compatibility: क्या हर booking clinics के scheduling system तक सही पहुँचती है?
- Interaction capability: क्या नया मरीज़ बिना मदद के, screen reader या बड़े text के साथ booking कर सकता है?
- Reliability: confirmation के दौरान connection टूटे तो क्या ठीक एक booking बनती है या कोई नहीं?
- Security: क्या मरीज़ सिर्फ़ अपनी appointments देख सकता है, address bar में booking number बदलने के बाद भी?
- Maintainability: क्या cancellation की समय-सीमा बिना side effects के बदली जा सकती है?
- Flexibility: क्या app supported phone operating systems पर चलता है, और क्या नए clinics जोड़े जा सकते हैं?
- Safety: अगर visit की वजह "सीने में दर्द" लिखी हो, तो क्या app को मरीज़ को emergency care की ओर भेजना चाहिए?
| Characteristic | हर product से पूछा जाने वाला सवाल | Clinic booking app के लिए weight |
|---|---|---|
| Functional suitability | क्या यह users की ज़रूरत का काम पूरा और सही करता है? | Highstory ख़ुद यही है |
| Performance efficiency | क्या यह expected load पर, ठीक-ठाक resources में, काफ़ी तेज़ है? | Medium |
| Compatibility | क्या यह दूसरे software के साथ चलता है और जुड़े systems से data exchange करता है? | Medium |
| Interaction capability2011 में नाम: usability | क्या target users, disability वाले लोगों समेत, इसे सीखकर इस्तेमाल कर सकते हैं? | Highकई बुज़ुर्ग मरीज़ |
| Reliability | क्या यह चलता रहता है, और कुछ fail होने पर recover करता है? | Highएक booking या कोई नहीं |
| Security | क्या data और functions तक सिर्फ़ authorised लोग और systems पहुँचते हैं? | Highmedical data |
| Maintainability | क्या team इसे दूसरे हिस्से तोड़े बिना बदल और टेस्ट कर सकती है? | Medium |
| Flexibility2011 में नाम: portability | क्या इसे adapt, scale, नए environment में install या replace किया जा सकता है? | Medium |
| Safety2023 में नई | क्या इसकी कोई failure जीवन, स्वास्थ्य, संपत्ति या पर्यावरण को ख़तरे में डाल सकती है? | Lowकोई medical सलाह नहीं, फिर भी सवाल का जवाब दिया जाता है |
ये weights इस team का इस app के लिए आकलन हैं। कोई दूसरा product या context इन्हीं नौ सवालों को अलग तरह से तौलता है।
आम गलतियाँ
- Quality को "features काम करते हैं" मान लेना: functional suitability नौ में से एक characteristic है।
- सिर्फ़ लिखी हुई बातें टेस्ट करना और implied needs को अनदेखा करना।
- Users और context चाहे जो हों, हर product के लिए एक ही quality bar रखना।
- एक test plan में 2011 और 2023 के नाम मिला देना, जिससे usability और interaction capability दो अलग areas लगें।
- Characteristic, stakeholder और evidence बताए बिना किसी build को "अच्छा" या "बुरा" कहना।
- यह मान लेना कि अपने tests में pass होने वाला product असली users के लिए उनके context में भी अच्छा चलेगा।
QA का नज़रिया
Quality characteristics सबसे पहले stories के refinement और requirements review में सामने आती हैं। हर story के लिए पूछें कि कौन-सी characteristics मायने रखती हैं और क्या story उनके बारे में कुछ कहती है: "कितना response time स्वीकार्य है?", "यह data कौन देख सकता है?", "Payment provider down हो तो क्या होगा?" जवाबों को acceptance criteria या non-functional requirements के रूप में दर्ज करें ताकि उन्हें टेस्ट किया जा सके।
Bug reports में characteristic का नाम लें: "Reliability: confirmation के दौरान connection टूटने पर slot blocked रहता है और कोई booking नहीं दिखती।" Test reports में लिखें कि कौन-सी characteristics टेस्ट नहीं हुईं, ताकि team वह risk जानबूझकर स्वीकार करे।
अभ्यास
School fees portal के लिए quality सवाल लिखें
एक school web portal शुरू करता है जहाँ parents fees भरते हैं और अपने बच्चों के grades देखते हैं, phones और laptops पर, Arabic या English में। ज़्यादातर fees deadline से पहले के आख़िरी हफ़्ते में भरी जाती है।
हर characteristic के लिए एक quality सवाल लिखें, इस context के लिए तीन सबसे अहम characteristics कारण सहित चुनें, और एक implied need बताएँ कि वह किसकी need है (सिर्फ़ parents के बारे में न सोचें)। फिर अपनी list की तुलना उन angles से करें जो Test Scenario Generator सुझाता है।
मॉडल उत्तर दिखाएँ
उदाहरण सवाल। Functional suitability: क्या हर बच्चे की बकाया राशि सही है, और हर payment की receipt बनती है? Performance efficiency: क्या deadline वाले हफ़्ते में payment तेज़ रहता है? Compatibility: क्या payments school के finance system तक पहुँचते हैं? Interaction capability: क्या parent phone पर, Arabic में, बिना मदद के payment कर सकता है? Reliability: अगर bank page का time out हो, तो क्या पैसा एक बार कटता है या बिल्कुल नहीं? Security: क्या parents सिर्फ़ अपने बच्चों के grades देखते हैं? Maintainability: क्या अगले साल की fee table बिना side effects के बदली जा सकती है? Flexibility: क्या कोई दूसरा school जुड़ सकता है? Safety: जीवन या स्वास्थ्य को कोई ख़तरा नहीं; इसे छोड़ने की बजाय दर्ज करें।
सबसे अहम: security (बच्चों के grades और payment data), functional suitability (गलत राशि से पैसा और भरोसा दोनों जाते हैं) और reliability (deadline वाले हफ़्ते में खोया या दोहरा payment)। Deadline वाले हफ़्ते के peak की वजह से performance efficiency भी एक सही चुनाव है; अच्छा जवाब हर चुनाव को इस context की किसी बात से जोड़ता है।
Implied need: finance team को चाहिए कि online payments हर दिन bank statement से मिलें, जबकि requirement सिर्फ़ parents की बात करती है।
अक्सर पूछे जाने वाले सवाल
क्या software quality का मतलब defects न होना है?
नहीं। Defects quality घटाते हैं, लेकिन बिना किसी known defect वाला product भी धीमा, इस्तेमाल में मुश्किल या गलत need के लिए बना हो सकता है। Quality को stakeholders की needs से आँका जाता है, सिर्फ़ defects गिनकर नहीं।
Usability कहूँ या interaction capability?
नए documents में 2023 का नाम interaction capability इस्तेमाल करें, और पुरानी सामग्री में usability पहचानें, जिसमें ISTQB Foundation syllabus भी शामिल है जो पुराना नाम रखता है और नया नाम साथ में लिखता है। Portability और flexibility पर भी यही लागू होता है।
क्या tester हर project में नौ की नौ characteristics टेस्ट करता है?
नहीं। Team risk और context के आधार पर चुनती है। Model एक checklist है ताकि किसी characteristic को छोड़ना एक दर्ज किया गया फ़ैसला हो, भूल नहीं। कुछ, जैसे maintainability, मुख्य रूप से software चलाकर नहीं बल्कि reviews और static analysis से आँकी जाती हैं।
किसी product के लिए quality का मतलब कौन तय करता है?
Stakeholders, आम तौर पर product owner के ज़रिए, जो priorities तय करते हैं। Testers अकेले quality परिभाषित नहीं करते; वे उसके बारे में जानकारी देते हैं ताकि दूसरे सोच-समझकर फ़ैसले ले सकें।
संदर्भ
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
Mutqan tools से अभ्यास करें
किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
Mutqan AI से छूटी हुई requirements खोजें — error handling, permissions, edge conditions, non-functional ज़रूरतें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।