टेस्ट एविडेंस

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · शुरुआती

Test evidence इस बात का record है कि आपने क्या टेस्ट किया, किस build और environment पर, कब, और असल में क्या हुआ: screenshots, screen recordings, logs और context का एक छोटा note। यह "leave request fail हो गई" को ऐसी चीज़ में बदल देता है जिसे developer जाँच सके: 10:15 बजे screen पर दिखा error, वह request जिसने status 504 लौटाया, और वह request id जिससे server log की मिलती-जुलती lines मिलती हैं।

Evidence वह है जो आप test run में दर्ज results के साथ attach करते हैं, सबसे पहले failed results के साथ।

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

जो failure होते समय capture नहीं होता, उसे दोबारा दिखाना अक्सर मुश्किल होता है: data बदल चुका होता है, environment फिर से deploy हो चुका होता है, या problem intermittent थी। Evidence के बिना report "cannot reproduce" कहकर बंद हो सकती है, और बिना proof के दर्ज pass पर audit या acceptance sign-off में सवाल उठ सकता है।

Evidence का अपना जोखिम भी है। Screenshot में किसी customer का phone number दिख सकता है, और network export में ऐसी session cookie हो सकती है जिससे file रखने वाला कोई भी व्यक्ति उस user के रूप में काम कर सके। सिर्फ़ ज़रूरी चीज़ capture करना उन लोगों की रक्षा करता है जिनका data system में है।

Evidence क्या है, और कितना चाहिए

Evidence test execution के दौरान बना कोई भी record है जो test result को सहारा देता है। ISTQB Foundation syllabus test logs, screenshots, database dumps और recordings को ऐसी सामग्री बताता है जो defect report में शामिल हो सकती है ताकि failure reproduce किया जा सके।

Evidence को context चाहिए। अकेला screenshot सिर्फ़ यह साबित करता है कि कोई screen कभी ऐसी दिखी थी; test case, run, build, environment, account role, test data और time zone के साथ समय जुड़ने पर वह साबित करता है कि उस test में क्या हुआ।

Failed test: इतना कि developer बिना आपसे पूछे failure देख सके — expected result के बगल में actual result, साथ में वे logs जो दिखाते हैं कि अंदर क्या हुआ।
Passed test: आम तौर पर दर्ज result काफ़ी है। Regulated काम, contractual acceptance और कुछ UAT sign-offs में pass का proof चाहिए; किन tests के लिए और किस रूप में, यह test plan बताता है।
Evidence execution के दौरान capture करें और result के साथ रखें: बाद में किसी दूसरे build पर दोबारा बनाया गया evidence एक नए test का होता है।

Screenshots और screen recordings

Screenshot इस बात का सबसे तेज़ evidence है कि user ने क्या देखा। पूरी window capture करें, जिसमें address और logged-in account दिखे, error के चारों ओर tight crop नहीं; अगर failure किसी बदलाव में है, तो एक screenshot पहले और एक बाद में लें। Problem को एक copy पर चिह्नित करें और original रखें।

Recording वह दिखाती है जो screenshot नहीं दिखा सकता: क्रम और timing। इसे कई steps वाले flows, flicker, slow responses और intermittent failures के लिए इस्तेमाल करें; recording छोटी रखें और वह second नोट करें जिस पर failure दिखता है।

Error messages को text के रूप में भी copy करें ताकि उन्हें search किया जा सके; screenshot से OCR के ज़रिए text निकालना fallback है।

आज़माएँ: इमेज को टेक्स्ट में बदलें

Logs: browser console, network और server

Logs दिखाते हैं कि screen के नीचे क्या हुआ। Web application में तीन logs ज़्यादातर failures cover करते हैं, और पहले दो browser के developer tools (DevTools) में होते हैं, जो F12 या Ctrl+Shift+I (Mac पर Cmd+Option+I) से खुलते हैं।

Web testing module में DevTools, और HTTP module में requests, headers और status codes गहराई से पढ़ाए जाते हैं। अभी इतना जानना काफ़ी है कि page जब भी server से बात करता है, browser एक request भेजता है और एक response पाता है, जिसमें तीन अंकों का status code होता है (2xx success, 4xx request में problem, 5xx server की तरफ़ failure) और headers होते हैं: नाम वाली extra जानकारी की lines, जैसे वह cookie जो user को logged in रखती है।

Console: JavaScript errors, resources load न होने के errors और warnings। Error को text के रूप में copy करें, उसकी file, line और समय के साथ; अगर timestamps छिपे हों तो console settings में उन्हें चालू करें।
Network panel: हर request, उसके method, URL, status, timing, headers और bodies के साथ। पहले step से पहले इसे खोलें और Preserve log (Firefox में: Persist Logs) चालू करें ताकि page बदलने पर यह साफ़ न हो। HAR file (HTTP Archive, एक JSON format) export करें या सिर्फ़ fail हुई request copy करें।
Server logs: अक्सर tester की पहुँच से बाहर। Developer को time zone के साथ सटीक समय दें, क्योंकि कई servers UTC में log करते हैं (Riyadh में 10:14, यानी UTC+3, 07:14 UTC है), और response में लौटी कोई भी request id, जैसे X-Request-Id जैसे header में (नाम बदलते रहते हैं)। वे जो lines ढूँढें उन्हें attach करें, पूरी file नहीं।

आज़माएँ: JSON ट्री व्यूअर आज़माएँ: Timezone कन्वर्टर

Evidence capture करते समय privacy और security

Evidence data को ऐसी जगहों पर copy करता है जहाँ ज़्यादा लोगों की पहुँच होती है: defect trackers, chat, email, suppliers के tickets। HAR file में session का हर header और body हो सकता है, उन cookies और tokens समेत जिनसे file रखने वाला कोई भी व्यक्ति, उनके valid रहने तक, उस user के रूप में काम कर सकता है। Evidence के अंदर का personal data भी personal data ही है, जिस पर Saudi Arabia के Personal Data Protection Law (PDPL) जैसे क़ानून और आपकी organisation की policies लागू होती हैं।

किसी log में password, token या personal data होना अपने आप में एक finding है (OWASP Logging Cheat Sheet कहता है कि passwords, session identifiers, access tokens और sensitive personal data को logs में सीधे record नहीं करना चाहिए): value paste किए बिना इसे report करें।

Test accounts और generated data इस्तेमाल करें, पूरे desktop की जगह browser window capture करें, और recording से पहले notifications बंद करें।
Mask के लिए solid, opaque box इस्तेमाल करें, हल्का blur नहीं। PDF में ऊपर बनाया गया box नीचे का text नहीं हटाता; असली redaction इस्तेमाल करें।
HAR में (नीचे cleaning से पहले की एक entry दिखाई गई है) Cookie, Set-Cookie और Authorization की values, उन्हें दोहराने वाली cookies arrays, और bodies में मौजूद passwords या personal data हटाएँ। Chrome 130 और उसके बाद के versions ये तीन headers default रूप से छोड़ देते हैं (उनका "sanitized" export), पर bodies बनी रहती हैं और दूसरे browsers सब कुछ रख सकते हैं, इसलिए हर file जाँचें। Logout करने से कई sessions ख़त्म हो जाते हैं, पर कुछ tokens expire होने तक valid रहते हैं।
Evidence team के access-controlled tools में रखें, public channels में कभी नहीं, और तय retention period ख़त्म होने पर delete करें।

{
  "startedDateTime": "2026-09-30T07:14:52.118Z",
  "request": {
    "method": "POST",
    "url": "https://staging.example.test/api/leave-requests",
    "headers": [
      { "name": "Authorization", "value": "Bearer eyJhbGciOi..." },
      { "name": "Cookie", "value": "sid=4f9c..." }
    ],
    "cookies": [{ "name": "sid", "value": "4f9c..." }],
    "postData": {
      "mimeType": "application/json",
      "text": "{\"type\":\"annual\",\"days\":3}"
    }
  },
  "response": {
    "status": 504,
    "headers": [{ "name": "X-Request-Id", "value": "8b1f0c2e" }]
  }
}

आज़माएँ: PDF रिडैक्ट करें आज़माएँ: फ़ेक यूज़र जनरेटर

Worked example: fail हुई leave request का evidence

एक tester HR portal के Sprint 42 regression run में staging पर TC-LV-009, "3 दिन की annual leave request submit करें", चलाता है; DevTools खुले हैं और Preserve log चालू है। Tester form भरता है, screenshot लेता है, browser window की recording शुरू करता है और Submit पर click करता है। Spinner 30 seconds घूमता है, फिर "Request failed. Try again." दिखता है। Tester screenshot लेता है और My requests खोलता है: request Pending के रूप में listed है, इसलिए message पर भरोसा करने वाला user duplicate request submit करेगा।

Tester HAR export करता है, session values हटाता है, console error copy करता है और request id नोट करता है। उस id से developer server log lines ढूँढता है: request save हो गई थी, फिर leave service approval service की call के जवाब का इंतज़ार करती रही, और 30 seconds बाद उसके आगे वाले gateway ने इंतज़ार छोड़कर 504 (Gateway Timeout) लौटाया। Run result और DEF-1874 से attach किया गया package:

Fail हुई leave request का evidence package: context, तीन screenshots, console error, session values हटाई गई HAR, request id से मिली server log lines, और 41 seconds की recording।

Run result और DEF-1874 से attach किया गया package

भाग 1:1DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  भाग 2:201-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  भाग 3:304-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  भाग 4:405-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  भाग 5:506-server.txt     log lines for 8b1f0c2e, provided by the developer
  भाग 6:607-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests

1Context: क्या, कहाँ, कबTest case, run, build, environment, browser, account role और time zone के साथ समय। इसके बिना कोई बाकी files को server log से मिला नहीं पाता।30 Sep 10:14:52 UTC+3
2Screenshots: पहले, error, बाद मेंपूरी window, problem एक copy पर box की गई। तीसरा screenshot दिखाता है कि error message के बावजूद request save हुई।personal data mask करें
3Browser consoleError text के रूप में, अपने समय के साथ, ताकि उसे search किया जा सके और network request से मिलाया जा सके।504 (Gateway Timeout)
4Network: HAR fileRequest, status और 30 seconds का इंतज़ार साबित करती है; request id इसे server log से जोड़ती है।POST /api/leave-requests -> 504cookies और tokens हटाएँ
5Server log excerptDeveloper ने request id से ढूँढा: request save हुई, फिर approval service के जवाब का इंतज़ार gateway की 30 seconds की सीमा से आगे चला गया। सिर्फ़ relevant lines attach होती हैं।X-Request-Id: 8b1f0c2e
6Screen recordingक्रम और timing दिखाती है: 30 seconds का spinner, जैसा user ने झेला, जो screenshot नहीं दिखा सकता।notifications बंद करें

File names और numbering एक team का तरीका है; ज़रूरी यह है कि हर file क्रम में हो, नाम वाली हो और result से attach हो।

Package से बाहर रखा गया: desktop, session values, और HAR में पहले की login request, जिसकी body में test account का password था।

पाठ संस्करण

DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  01-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  04-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  05-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  06-server.txt     log lines for 8b1f0c2e, provided by the developer
  07-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests

आम गलतियाँ

Screenshot को crop करके सिर्फ़ error message रखना, जिससे कोई नहीं बता सकता कि वह किस page, account या data से आया।
बिना context के evidence attach करना: न build, न environment, न time zone, न test data।
DevTools सिर्फ़ failure के बाद खोलना, या Preserve log के बिना, जिससे fail हुई request कभी record ही नहीं हुई।
ऐसी HAR, screenshot या recording share करना जिसमें अब भी tokens, cookies या personal data हो, किसी ऐसे channel या ticket में जिसे बाहरी लोग देख सकें।
हर passed step का evidence "बस एहतियातन" capture करना: इससे execution धीमा होता है, protect करने लायक data बढ़ता है, और उसे कोई नहीं पढ़ता।

QA का नज़रिया

Execution से पहले evidence का level तय करें, test plan में या team के working agreement में: pass और failure को क्या चाहिए, evidence कहाँ रखा जाएगा और कितने समय तक। Developers से पूछें कि कौन-से logs उनकी मदद करते हैं और request id कैसे मिलती है, और क्या staging में production data है।

Execution के दौरान data save करने वाले steps से पहले DevTools खोलें और Preserve log चालू करें। कुछ भी attach करने से पहले उसे बाहरी व्यक्ति की नज़र से देखें: क्या यह failure दिखाता है, और क्या कुछ ऐसा जो नहीं दिखना चाहिए?

अभ्यास

Data leak के लिए सुरक्षित evidence package बनाएँ

आपका काम

आप HR portal के staging environment पर TC-PAY-012 चलाते हैं। Download हुई payslip आपके test account की जगह किसी दूसरे employee का नाम, employee ID और salary दिखाती है। नाम असली लगते हैं: लगता है staging में production से copy किया गया data है।

Run result और defect report के लिए evidence package plan करें। उसे failure साबित करना है, leaked data को और फैलाए बिना।

सामग्री

TC-PAY-012  September की payslip PDF के रूप में download करें
Run:        Sprint 42 regression · staging · build 5.2.0-rc1 · Chrome 129
Account:    qa.employee07 (employee role)
Time:       30 Sep 11:02 UTC+3
Expected:   PDF में qa.employee07 का नाम, employee ID और salary दिखे
Actual:     PDF में किसी दूसरे employee का नाम, employee ID और salary दिखती है
Request:    GET /api/payslips/2026-09/pdf -> 200, Content-Type: application/pdf
Response:   X-Request-Id: 51d7a0c3

चरण

तय करें कि दूसरे व्यक्ति का data copy किए बिना failure क्या साबित करता है।
अपने package की files list करें: हर file क्या दिखाती है और उसमें आप क्या mask करेंगे या हटाएँगे।
बताएँ कि download हुई PDF का आप क्या करेंगे और किसे बताएँगे।

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

मॉडल उत्तर

00-context.txt: test case, run, build, environment, browser, account role, time zone के साथ समय और request id 51d7a0c3।

01-payslip.png: payslip, portal के उस header के बगल में जो logged-in test account दिखाता है, और दूसरे व्यक्ति का नाम, employee ID और salary solid boxes के नीचे। Mismatch ही proof है; आप data दिखाए बिना इसे लिख सकते हैं, और developer request id से जाँच सकता है कि कौन-सा record भेजा गया।

02-request.txt: GET /api/payslips/2026-09/pdf, status 200 और request id, cookie या authorization values के बिना और response body के बिना, क्योंकि वह body leaked PDF है। Server log lines सिर्फ़ तब, जब उनमें personal data न हो।

न recording, न original PDF: file कहीं attach न करें। Security या data protection contact से पूछें कि क्या उन्हें इसकी ज़रूरत है, उसे सिर्फ़ उनके निर्देश के अनुसार रखें, फिर अपनी copy delete करें।

अगर tracker अनुमति दे तो defect की visibility सीमित करें, अपने test lead को बताएँ और संभावित personal data incident की process अपनाएँ। दो findings: एक employee दूसरे की payslip download कर सकता है, और staging में असली personal data है।

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

क्या हर passed test step का screenshot चाहिए?

आम तौर पर नहीं। ज़्यादातर teams के लिए test run में दर्ज result ही pass का evidence है। Regulated domains, contractual acceptance और कुछ UAT sign-offs में pass का proof चाहिए, और तब test plan बताता है कि किन tests के लिए और किस रूप में। Automated tests अपना evidence ख़ुद बनाते हैं: report, logs, और वे screenshots या traces जो कई tools test fail होने पर save करते हैं।

HAR file क्या है, और क्या इसे share करना सुरक्षित है?

HAR (HTTP Archive) file browser के Network panel से export की गई JSON file है। इसमें हर recorded request और response होता है: URLs, headers, cookies, timings और अक्सर bodies भी। Export की गई हालत में इसे share करना सुरक्षित नहीं, क्योंकि इसमें session cookies, access tokens, login request का password और personal data हो सकता है; Chrome 130 और उसके बाद के versions cookie और authorization headers default रूप से छोड़ देते हैं, पर bodies नहीं। पहले sensitive values हटाएँ, सिर्फ़ team के tracker से share करें, और जब काफ़ी हो तो सिर्फ़ fail हुई request भेजें।

Video record करूँ या screenshot लूँ?

जब problem एक state हो, तब screenshot लें: गलत value, टूटा layout, error message। जब problem क्रम या timing हो, तब record करें: flicker, slow response, कई steps वाला flow या कभी-कभी दिखने वाला failure। अक्सर सबसे अच्छा evidence एक छोटी recording और अहम पल का एक screenshot है, ताकि video चलाए बिना details पढ़ी जा सकें।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
What are browser developer tools? — MDNMDN Web Docs (Mozilla)ब्राउज़र में बने developer tools का परिचय — inspector, JavaScript console और debugger — टेस्ट करते समय पेज की जाँच के लिए।
OWASP Cheat Sheet Series: LoggingOWASP Foundationक्या लॉग करें और क्या कभी न करें (पासवर्ड, टोकन, निजी डेटा), और लॉग को छेड़छाड़-प्रकट कैसे रखें।
Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।

टेस्ट एविडेंस

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

Evidence क्या है, और कितना चाहिए

Screenshots और screen recordings

Logs: browser console, network और server

Evidence capture करते समय privacy और security

Worked example: fail हुई leave request का evidence

आम गलतियाँ

QA का नज़रिया

अभ्यास

Data leak के लिए सुरक्षित evidence package बनाएँ

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

संदर्भ

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

इमेज को टेक्स्ट में बदलें

JSON ट्री व्यूअर

Timezone कन्वर्टर

PDF रिडैक्ट करें

फ़ेक यूज़र जनरेटर

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Evidence क्या है, और कितना चाहिए

Screenshots और screen recordings

Logs: browser console, network और server

Evidence capture करते समय privacy और security

Worked example: fail हुई leave request का evidence

आम गलतियाँ

QA का नज़रिया

अभ्यास

Data leak के लिए सुरक्षित evidence package बनाएँ

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics