यूज़ेबिलिटी टेस्टिंग
Usability testing में representative users को product पर realistic tasks पूरे करते हुए देखा जाता है, ताकि टीम देख सके कि वे कहाँ सफल होते हैं, कहाँ हिचकते हैं, गलती करते हैं या हार मान लेते हैं। ISO 9241-11 usability को इस तरह परिभाषित करता है: वह सीमा जिस तक किसी system, product या service को specified users किसी specified context of use में specified goals को effectiveness, efficiency और satisfaction के साथ हासिल करने के लिए इस्तेमाल कर सकते हैं। Usability test इन तीन शब्दों को ऐसी चीज़ों में बदल देता है जिन्हें देखा और गिना जा सके: task पूरा हुआ या नहीं, कितना समय लगा, कितने गलत मोड़ लिए गए, और व्यक्ति ने अनुभव को कैसा rate किया।
उदाहरण: पाँच ऐसे customers, जिन्होंने अपने bank का app सिर्फ़ transfers के लिए इस्तेमाल किया है, हर एक से कहा जाता है कि सामने रखे कागज़ के bill से बिजली का bill चुकाएँ, जबकि एक moderator देखता है और एक note-taker हर हिचक नोट करता है। अगर पाँच में से दो को पता ही न चले कि payments कहाँ हैं, तो टीम ने वह सीखा जो कोई functional test नहीं दिखा सकता: feature काम करती है, पर उसके users उसे ढूँढ नहीं पाते।
यह क्यों ज़रूरी है
कोई product हर functional और accessibility test पास करके भी users खो सकता है, क्योंकि जो feature काम तो करती है पर लोग उसे ढूँढ, समझ या पूरा नहीं कर पाते, वह उनकी नज़र में failure है। ऐसी failures defect tracker में कम ही दिखती हैं; वे छोड़े गए carts, support calls और one-star reviews में दिखती हैं, और तब तक जिन design decisions ने उन्हें जन्म दिया, उन्हें पलटना महँगा हो चुका होता है।
Tester के लिए usability testing evidence की दूसरी किस्म जोड़ती है। Functional tests दिखाते हैं कि system अपने rules मानता है; usability tests दिखाते हैं कि असली लोग उससे अपने goals तक पहुँच पाते हैं या नहीं। यह आपकी अपनी नज़र भी तेज़ करती है: एक बार किसी को बिना label वाले icon पर अटकते देख लेने के बाद आप ऐसी समस्याएँ पहले और evidence के साथ report करते हैं ("5 में से 4 participants ने पहले Transfers खोला"), राय के साथ नहीं ("menu confusing है")।
Usability, user experience और evaluation के तीन तरीके
Usability specified users, specified goals और specified context की बात है: एक payment flow फ़ोन पर रोज़ के customer के लिए usable हो सकता है और छोटी screen पर पहली बार आए user के लिए unusable। ISO 9241-11 तीन components बताता है, और हर एक usability testing को उसका एक measure देता है। Effectiveness वह accuracy और completeness है जिससे users अपने goals हासिल करते हैं, जो task success और रास्ते में हुई errors से मापी जाती है। Efficiency हासिल किए गए results के अनुपात में इस्तेमाल हुए resources हैं, सबसे अक्सर समय, जो time on task से मापी जाती है। Satisfaction वह सीमा है जिस तक product के इस्तेमाल से user की शारीरिक, मानसिक और भावनात्मक responses उसकी ज़रूरतें और उम्मीदें पूरी करती हैं; यह ratings और questionnaires से मापी जाती है।
User experience (UX) usability से व्यापक है। ISO 9241 series इसे किसी व्यक्ति की उन perceptions और responses के रूप में बताती है जो product के इस्तेमाल, या इस्तेमाल की उम्मीद, से पैदा होती हैं: पहली screen से पहले की उम्मीदें, इस्तेमाल के दौरान की भावनाएँ, और बाद का भरोसा और याद। Usability अच्छे UX का ज़रूरी हिस्सा है, पूरा UX नहीं। ISO/IEC 25010:2023 इसी क्षेत्र को interaction capability के तहत रखता है, learnability, operability और user error protection जैसी sub-characteristics के साथ। ISTQB का usability testing syllabus usability evaluate करने के तीन तरीके अलग करता है, और अच्छी टीम एक से ज़्यादा तरीके इस्तेमाल करती है:
- Usability reviews: एक या ज़्यादा reviewers, बेहतर हो कि usability या domain experts, interface की जाँच करते हैं और परखते हैं कि वह कहाँ usability requirements, guidelines या principles को तोड़ता है, users को tasks करते देखने के बजाय। Heuristic evaluation, यानी heuristics की एक छोटी सूची के आधार पर review, इनमें सबसे जानी-मानी है।
- Representative users के साथ usability testing: participants realistic tasks करने की कोशिश करते हैं, जबकि टीम देखती और मापती है। यह पाठ ज़्यादातर इसी तरीके के बारे में है।
- User surveys: participants अपने अनुभव के बारे में questionnaire भरते हैं, test session के बाद या असली इस्तेमाल के बाद।
Usability (ISO 9241-11) User experience (UX)
------------------------ ------------------------------------
specified users, goals पूरा व्यक्ति: इस्तेमाल से पहले,
और context of use दौरान और बाद में
effectiveness -> success, उम्मीदें, भावनाएँ, भरोसा,
errors product की याद
efficiency -> time usability शामिल है, और उससे ज़्यादा
satisfaction -> ratings
यह पाठ: session में usability मापना।
अगला पाठ: flows, navigation, messages और forms की UX testing।Planning: goals, tasks और participants
उन सवालों से शुरू करें जिनके जवाब टीम को चाहिए, जैसे "क्या नया customer बिना मदद के bill चुका सकता है?" फिर tasks को participant के अपने शब्दों में realistic scenarios की तरह लिखें, उस data के साथ जो उन्हें चाहिए और success की परिभाषा के साथ। Screen पर लिखे labels कभी इस्तेमाल न करें: "Payments खोलें और biller जोड़ें" यह टेस्ट करता है कि लोग instructions follow कर सकते हैं या नहीं, न कि वे payments ढूँढ सकते हैं या नहीं।
ऐसे participants recruit करें जो असली user profile से मेल खाएँ: उम्र, ऐसे ही products का अनुभव, भाषा, device। Product को जानने वाले colleagues representative नहीं हैं। कई टीमें एक round में हर user group से लगभग पाँच participants लेती हैं, जो मिला उसे ठीक करती हैं, और फिर एक और round चलाती हैं, क्योंकि दूसरा round अक्सर समस्याओं का अलग सेट दिखाता है। Roles तय करें: एक moderator जो tasks देता है और neutral सवाल पूछता है, और एक note-taker जो होने वाली हर बात record करता है; developers जैसे दूसरे stakeholders observers के रूप में session देख सकते हैं। अस्पष्ट tasks और timing ठीक करने के लिए एक pilot session चलाएँ, और consent व privacy का ध्यान रखें: participants देखे या record किए जाने पर सहमति दें, और report में कोई identifying data न जाए।
Task 3 of 4 (scenario, participant के शब्दों में)
"इस महीने का बिजली का bill आ गया है। इसे इस app से चुकाएँ।
Account number आपके सामने रखे कागज़ के bill पर है।"
Success: bill current account से चुकाया गया, confirmation दिखा
Target: 5 में से कम से कम 4 participants बिना मदद के सफल,
2 मिनट के अंदर, अधिकतम 1 गलत रास्ता
मत कहें: "Payments", "biller", "Add" - ये screen के शब्द हैंSession चलाना: think-aloud और चार measures
एक छोटे briefing से शुरू करें: टेस्ट product का हो रहा है, participant का नहीं; कोई जवाब सही या गलत नहीं; कृपया सोचते हुए बोलें। Think-aloud protocol में participant काम करते-करते बताता है कि वह क्या ढूँढ रहा है, क्या उम्मीद करता है और क्या उसे confuse कर रहा है। Moderator देखता है, सिर्फ़ neutral सवालों से prompt करता है, जैसे "अभी आप क्या सोच रहे हैं?" या "आपको क्या होने की उम्मीद थी?", और कभी समझाता या मदद नहीं करता। अगर participant पूरी तरह अटक जाए, तो moderator वह पल नोट करता है और या तो अगले task पर चला जाता है या सबसे छोटा संभव hint देता है; hint के बाद पूरा हुआ task successful नहीं, assisted के रूप में record होता है।
Note-taker हर task के लिए चार measures record करता है, साथ में वे quotes और गलत मोड़ जो उन्हें समझाते हैं:
- Success: बिना मदद पूरा, मदद के साथ पूरा, या failed (हार मान ली, समय ख़त्म, या कोई और task पूरा करके समझा कि हो गया)।
- Time on task: task पढ़ने से success criterion पूरा होने तक; median (समयों को क्रम से लगाने पर बीच वाला मान) report करें, क्योंकि एक भटका हुआ participant average बिगाड़ देता है।
- Errors: गलत रास्ते, गलत controls, गलत input, और क्या व्यक्ति ने गलती notice करके recover किया; हर task के लिए गिनें।
- Satisfaction: हर task के बाद एक rating (जैसे 1 से 5) और session के बाद एक questionnaire, जैसे System Usability Scale: दस statements जो 0 से 100 का score देते हैं।
- 1Planजवाब देने वाले सवाल, scenarios के रूप में tasks, हर task का success criterion और targets, participant profileSession से पहले
- 2Recruit और pilotहर user group से लगभग पाँच representative participants; एक pilot run अस्पष्ट tasks और timing ठीक करता है
- 3Participant को brief करेंConsent; "हम product टेस्ट कर रहे हैं, आपको नहीं"; कोई जवाब सही या गलत नहीं; think aloud कैसे करेंParticipant के साथ
- 4Think-aloud के साथ tasksModerator देखता है और neutral prompt देता है, कभी मदद नहीं करता; note-taker success, time, errors और quotes record करता है
शाखा: अटक गया: अगला task, या hint और task assisted के रूप में recordसावधानी
- 5Post-task rating और questionnaireहर task के बाद rating (जैसे 1 से 5); आख़िरी task के बाद SUS जैसा questionnaire और छोटा interview
- 6AnalyseParticipants के पार: success rate, median time, हर task की errors, ratings; हर समस्या evidence और severity वाली finding बनती हैSession के बाद
- 7Report और fixFindings: कितने participants प्रभावित हुए, कौन-सी heuristic टूटी और सुझाया गया बदलाव; targets से तुलना
चरण 4–5 के दौरान चार measures यहाँ record होते हैं: success, time on task, errors, satisfaction
चरण 1 पर वापस Design बदलने के बाद अगला round
Moderated session का आम क्रम; unmoderated remote session में live moderator नहीं होता और recordings पर भरोसा किया जाता है।
Heuristic evaluation: बिना users की expert review
Heuristic evaluation एक review है जिसमें कुछ evaluators, हर एक दूसरों से स्वतंत्र रूप से, मुख्य flows से गुज़रते हैं और हर screen को मान्य usability principles की एक छोटी सूची पर जाँचते हैं, फिर अपने notes मिलाते हैं और हर समस्या की severity rate करते हैं। इसे participants नहीं चाहिए, इसलिए यह शुरुआती prototypes, wireframes और usability test से पहले के हफ़्ते के लिए सही है।
Heuristic evaluation समस्याओं का अनुमान लगाती है; usability test उन्हें देखता है। Evaluators कई issues जल्दी और सस्ते में ढूँढ लेते हैं, पर वे ऐसी चीज़ें भी flag करते हैं जो users कभी notice नहीं करते, ऐसी चीज़ें छोड़ देते हैं जो सिर्फ़ users सामने लाते हैं, और success rates या समय नहीं बता सकते। पहले इसे करें, जो साफ़ दिखे उसे ठीक करें, फिर users के साथ टेस्ट करें। Principles की सबसे जानी-मानी सूची Jakob Nielsen की दस usability heuristics है:
- Visibility of system status: interface बताता है कि क्या हो रहा है, जैसे saved या sending की स्थिति।
- Match between system and the real world: ऐसे शब्द और concepts जो user जानता है, internal नहीं।
- User control and freedom: undo, cancel या वापस जाने का आसान रास्ता।
- Consistency and standards: हर जगह वही शब्द और patterns, और platform की conventions।
- Error prevention: ऐसी constraints और confirmations जो गलती होने से पहले रोक दें।
- Recognition rather than recall: options और actions दिखते रहें, याद न रखने पड़ें।
- Flexibility and efficiency of use: अनुभवी users के लिए shortcuts, नए users पर बोझ डाले बिना।
- Aesthetic and minimalist design: ऐसा कुछ नहीं जो users की ज़रूरी जानकारी से होड़ करे।
- Help users recognize, diagnose and recover from errors: साफ़ भाषा में messages जो बताएँ कि क्या गलत हुआ और कैसे ठीक करें।
- Help and documentation: ज़रूरत पर उपलब्ध, user के task पर केंद्रित।
Worked example: banking app में bill चुकाना
एक bank अपने app में bill payments जोड़ता है। Target users मौजूदा customers हैं जो app सिर्फ़ transfers के लिए इस्तेमाल करते हैं। टीम उनमें से पाँच recruit करती है, और moderator ऊपर वाले card से task देता है, data के रूप में एक कागज़ का bill देकर। Targets: 5 में से कम से कम 4 बिना मदद के 2 मिनट में, अधिकतम एक गलत रास्ते के साथ सफल हों, और post-task rating 4 या उससे ऊपर।
पाँचों sessions के बाद note-taker participants के पार नतीजे जोड़ता है: हर task का success, median time, हर task की errors और ratings, planning में तय targets से तुलना करके। हर देखी गई समस्या अपने evidence के साथ एक finding बनती है: कहाँ हुई, कितने participants ने उसे झेला, और उन्होंने क्या कहा।
- नतीजे: 5 में से 2 ने task बिना मदद के पूरा किया, 2 को hint चाहिए था और 1 failed; median time 2:00 के target के मुकाबले 4:10 रहा, गलत रास्तों का median 1 के मुकाबले 3, और rating का median 4 के मुकाबले 2। हर target चूका, और note-taker के notes बताते हैं क्यों: चार participants ने पहले Transfers खोला, क्योंकि Payments More के नीचे छिपा था, और फिर दो ने bill का account number transfer की amount field में टाइप किया, क्योंकि उस screen पर account और amount, दोनों fields पर सिर्फ़ icons थे।
- जो participant failed के रूप में record हुआ, उसने Pay दो बार दबाया: तुरंत कोई confirmation नहीं दिखा और button active रहा, इसलिए bill दो बार चुका और उसने यह न जानते हुए हार मान ली कि bill चुका भी या नहीं।
- Findings अपने evidence और जिस heuristic का उल्लंघन हुआ उसके साथ tracker में जाती हैं: छिपे menu के लिए recognition rather than recall, icon-only fields के लिए match with the real world, गुम confirmation के लिए visibility of system status और error prevention। दोहरा payment एक functional defect भी है, जिसे अलग से Critical severity के साथ report किया जाता है। नीचे दी गई consolidated sheet वही है जिससे report बनती है।
Task: इस महीने का बिजली का bill चुकाना (5 participants)
Measure Target Result
Success unaided / assisted / failed 5 में से 4 unaided 2 / 2 / 1
Time on task (median) <= 2:00 4:10
गलत रास्ते per participant (median) <= 1 3
Post-task rating 1 से 5 (median) >= 4 2
Notes: 4 ने पहले Transfers खोला; 2 ने account number amount field में
टाइप किया; 1 ने Pay दो बार दबाया, कोई confirmation नहीं दिखाआम गलतियाँ
- ऐसे tasks लिखना जो controls के नाम लेते हैं ("Payments tap करें, फिर biller add करें"); यह instructions follow करना टेस्ट करता है, usability नहीं।
- Participant अटके तो मदद या hint देना, और फिर उसे success गिनना।
- Representative users की जगह product जानने वाले colleagues के साथ टेस्ट करना।
- Heuristic evaluation को इसका सबूत मानना कि users सफल होंगे, या पाँच sessions को statistics मानना।
- सिर्फ़ राय दर्ज करना ("उन्हें पसंद आया") और success, time या errors की कोई गिनती नहीं।
- Usability finding और functional defect को मिला देना: दोनों tracker में जाते हैं, पर usability problem को crash reproduce करने के steps से ज़्यादा observation चाहिए (user ने क्या try किया, कहाँ भटका)।
QA का नज़रिया
जहाँ टीम में designer या UX researcher है, usability testing आम तौर पर उसकी ज़िम्मेदारी होती है; जहाँ नहीं है, अक्सर tester ही इसे चलाता है। इसे तब प्रस्तावित करें जब flow नया या redesigned हो और risk logic में नहीं, समझ में हो: onboarding, payment, बहुत fields वाले forms। जल्दी टेस्ट करें, clickable prototype पर, जब finding की कीमत design change हो, rewrite नहीं, और release से पहले फिर से। Developers और product owner को sessions देखना चाहिए, क्योंकि किसी user को अटकते देखना priorities किसी भी report से तेज़ बदलता है।
हर session के लिए build, device, participant profile (कभी नाम नहीं), tasks और चार measures record करें, और recordings consent में तय शर्तों के अनुसार रखें। हर finding को bug report की तरह लिखें, observation को evidence बनाकर: title, task, participants ने क्या try किया, कितने प्रभावित हुए, कौन-सी heuristic टूटी, severity और सुझाया गया बदलाव। Session से पहले product owner से success targets माँगें, और पूछें कि users सच में कौन हैं: जो product सबके लिए बना हो, उसका टेस्ट आम तौर पर किसी ख़ास के साथ नहीं होता।
अभ्यास
Clinic appointment feature के लिए usability test plan करें
एक clinic app माता-पिता को बच्चे के लिए vaccination appointment book करने देता है। Description और एक screen नीचे है। Usability test plan करें: तीन tasks scenarios की तरह लिखें, हर एक के success criterion के साथ; चार measures के लिए targets चुनें; briefing में बोलने वाली तीन बातें लिखें; और note-taker की sheet design करें। फिर screen description की Nielsen की heuristics पर एक quick heuristic जाँच करें और जो समस्याएँ आप expect करते हैं उन्हें सूचीबद्ध करें।
Feature: vaccination appointment book करना
Users: माता-पिता, 25-45, कई इस app के first-time users, Arabic या English
Flow: child चुनें > vaccine चुनें > clinic चुनें
> date और time चुनें > confirm
Screen "date और time चुनें":
- calendar में सभी दिन एक ही रंग के; भरे दिन पर tap से कुछ नहीं होता
- time slots 09:00, 09:20, 09:40 ... के रूप में, बिना बताए कौन-से भरे हैं
- "Next" button slot चुनने तक disabled; कोई message नहीं बताता क्यों
- back arrow home screen पर ले जाता है, "clinic चुनें" पर नहीं- Participant के शब्दों में तीन tasks लिखें, हर एक के success criterion के साथ।
- हर task के लिए success, time, errors और satisfaction का target तय करें।
- Briefing और think-aloud prompt लिखें जो आप इस्तेमाल करेंगे।
- Observation sheet के columns सूचीबद्ध करें।
- Screen description को heuristics पर जाँचें और टूटी heuristics के नाम लें।
मॉडल उत्तर दिखाएँ
Tasks (scenario रूप में)। पहला: "आपकी बेटी सारा, उम्र 2 साल, की अगली vaccine due है। अगले हफ़्ते के लिए इसे अपने घर के सबसे नज़दीकी clinic में book करें।" Success: सही child, vaccine और clinic के लिए appointment मौजूद है। दूसरा: "कुछ काम आ गया: अभी book किया appointment उसके अगले हफ़्ते पर ले जाएँ।" Success: नई date पर एक appointment, पुरानी पर कोई नहीं (अगर पहला task fail हुआ हो, तो moderator पहले से booking बना देता है ताकि यह task फिर भी आज़माया जा सके)। तीसरा: "Confirmation ढूँढें ताकि reception पर दिखा सकें।" Success: date, time और clinic वाला confirmation screen पर है।
Targets: हर task में 5 में से कम से कम 4 participants बिना मदद के सफल; median time booking के लिए अधिकतम 3 मिनट और बाकी दो के लिए 1 मिनट; हर task में अधिकतम एक गलत रास्ता; post-task rating 5 में से कम से कम 4। Product owner इन संख्याओं की पुष्टि करे या बदले।
Briefing: "हम app टेस्ट कर रहे हैं, आपको नहीं; जो भी मुश्किल लगे वह हमारी समस्या है जिसे हमें ठीक करना है। कृपया बोलकर बताएँ कि आप क्या ढूँढ रहे हैं और क्या होने की उम्मीद है। मैं मदद नहीं कर पाऊँगा, पर आप कभी भी रुक सकते हैं।" चुप्पी पर prompt: "अभी आप क्या सोच रहे हैं?"
Observation sheet के columns: participant code, task, start और end time, result (unaided / assisted / failed), गलत रास्ते (गिनती और कहाँ), input errors, quotes, post-task rating, moderator notes।
Heuristic जाँच: भरे दिन खाली दिनों जैसे दिखते हैं और tap से कुछ नहीं होता (visibility of system status, error prevention); भरे slots marked नहीं (recognition rather than recall, error prevention); बिना कारण disabled Next (visibility of system status, help users recognize and recover from errors); flow से बाहर ले जाने वाला back arrow (user control and freedom, consistency and standards)। इस screen पर गलत रास्तों और खोई bookings की उम्मीद रखें; sessions दिखाएँगे कि कितने participants प्रभावित होते हैं।
अक्सर पूछे जाने वाले सवाल
Usability test में कितने participants चाहिए?
इतने कि patterns दिखें, statistics साबित करने के लिए नहीं। कई टीमें हर round में हर user group से लगभग पाँच participants लेती हैं, मिली समस्याएँ ठीक करती हैं और फिर टेस्ट करती हैं; जो समस्या पाँच में से दो लोगों को रोक दे, वह ठीक करने लायक है, सटीक प्रतिशत जो भी हो। Statistically valid संख्याओं के लिए बड़े, आम तौर पर unmoderated, studies चाहिए।
क्या usability testing और user acceptance testing एक ही हैं?
नहीं। UAT acceptance testing का एक रूप है: यह validate करता है कि delivered system अपने intended users के लिए, असली या simulated operational environment में, इस्तेमाल के योग्य है, और उसे accept करने के फ़ैसले में मदद करता है। इसे आम तौर पर domain जानने वाले business users चलाते हैं, अक्सर scripted scenarios से। Usability testing मापती है कि representative users बिना मदद के goals हासिल कर पाते हैं या नहीं और उनका अनुभव कैसा रहा; यह किसी भी acceptance से बहुत पहले prototype पर चल सकती है।
क्या usability testing automate हो सकती है?
मापने में मदद मिल सकती है: tools screens, clicks और समय record करते हैं, और product analytics दिखाती है कि users कहाँ छोड़ जाते हैं। पर यह तय करना कि व्यक्ति अपने goal तक पहुँचा या नहीं, क्यों हिचका और क्या उम्मीद कर रहा था, अब भी किसी इंसान के देखने या recording review करने की माँग करता है। Heuristic evaluation भी human review है, हालाँकि checklist इसे consistent रखती है।
संदर्भ
- ISO 9241-11:2018 — Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsusability की अवधारणा का ढाँचा: निर्दिष्ट उपयोगकर्ताओं, लक्ष्यों और context of use के लिए effectiveness, efficiency और satisfaction, जहाँ usability को उपयोग का परिणाम माना जाता है।
- Certified Tester Usability Testing (CT-UT)usability testing पर ISTQB का specialist पाठ्यक्रम: usability, user experience और accessibility, मूल्यांकन के तरीके और दृष्टिकोण, और संबंधित मानक।
- 10 Usability Heuristics for User Interface Design (Jakob Nielsen)इंटरफ़ेस डिज़ाइन के लिए Jakob Nielsen के दस व्यापक rules of thumb — जैसे system status की दृश्यता और error prevention — जो मूल रूप से heuristic evaluation के लिए बने थे।
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
Mutqan tools से अभ्यास करें
किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
Mutqan AI से किसी भी फ़ीचर के लिए अनुकूलित QA चेकलिस्ट (functional, UI, API, security, performance, accessibility, release) बनाएँ।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।