ऑटोमेशन रिपोर्टिंग और डिबगिंग

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

कोई automated suite उतना ही काम का है जितनी जल्दी लाल result पर कार्रवाई हो सके। अगर failure सिर्फ़ expected true, received false छोड़ता है, तो किसी को test दोबारा चलाकर CI की conditions का अंदाज़ा लगाना पड़ता है; फिर team build हरा होने तक re-run करती है, और असली regressions शोर में निकल जाते हैं।

अच्छा evidence failure को छोटी जाँच में बदल देता है: screenshot और trace आम तौर पर दिखा देते हैं कि test ठीक करना है, environment owner को बुलाना है या defect report करना है। यह bug report को भी काम लायक बनाता है: “checkout test fail हुआ” की जगह fail हुई request, response और trace साथ में।

Reports: एक run, कई पाठक

एक run के कई पाठक होते हैं। जिसने run शुरू किया वह console पढ़ता है। जो failure की जाँच करता है उसे HTML report चाहिए, जिसमें हर test खुलकर अपने steps, error, retries और attachments दिखाए। CI server को machine-readable file चाहिए, आम तौर पर JUnit XML, ताकि वह हर test का result और उसकी history दिखा सके। Playwright में ज़रूरी formats reporter के नीचे list करें।

अच्छी report बिना किसी से पूछे बता देती है कि क्या fail हुआ, कहाँ, किस environment में और किस evidence के साथ। Tests का नाम उस behaviour पर रखें जिसे वे check करते हैं, business-level actions को test.step() में लपेटें ताकि report test case की तरह पढ़ी जाए, और वह data attach करें जो screen पर नहीं दिखता।

• Run context: build या commit, browser, base URL और शुरू होने का समय, ताकि failure को deployments और server logs से मिलाया जा सके।
• Flaky tests (पहले fail, फिर retry पर pass) को passed से अलग गिनें; वरना report उन्हें छिपा देती है।

// playwright.config.ts (excerpt): one run, three readers
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['list'],                                        // the terminal
    ['html', { open: 'never' }],                     // people: playwright-report/
    ['junit', { outputFile: 'results/junit.xml' }],  // the CI server
  ],
});

// checkout.spec.ts: steps and attachments make the report read like a test case
import { test, expect } from '@playwright/test';

test('VAT is added to the order total', async ({ page }, testInfo) => {
  const cart = await test.step('Create a cart with one 150.00 SAR book', () =>
    createCart(page, { sku: 'BOOK-01', qty: 1 }));     // createCart: a project helper
  await testInfo.attach('cart', {
    body: JSON.stringify(cart), contentType: 'application/json',
  });
  await test.step('Open checkout and check the total', async () => {
    await page.goto('/checkout/' + cart.id);
    await expect(page.getByTestId('order-total')).toHaveText('172.50 SAR');
  });
});

आज़माएँ: XML फ़ॉर्मेटर

Screenshots, video और traces: हर एक क्या दिखाता है

Evidence सिर्फ़ fail हुए tests के लिए रखें: हर तरह का evidence अलग सवाल का जवाब देता है और run time व storage खर्च करता है।

• Screenshot: failure के पल का page, जो बताता है “user ने क्या देखा?”: error banner, spinner, button के ऊपर कोई dialog। Playwright: screenshot: 'only-on-failure'; Cypress cypress run में test fail होने पर अपने-आप screenshot लेता है; Selenium में runner के failure hook में takeScreenshot() (JavaScript) या getScreenshotAs (Java) call करें।
• Video: पूरा test, जो क्रम और हलचल दिखाता है, जैसे पल भर को दिखा dialog, पर DOM, network या console data के बिना। Files भारी होती हैं: Playwright में video: 'retain-on-failure' इस्तेमाल करें; Cypress तभी record करता है जब उसका video option चालू हो (default रूप से बंद)।
• Trace: ऐसी recording जिसमें आप step by step चल सकते हैं। Playwright trace में हर action के पहले और बाद के DOM snapshots, call log, console, network requests और responses, और source line होती है। इसे npx playwright show-trace से, HTML report से, या trace.playwright.dev पर खोलें, जो file को आपके browser में ही load करता है, कहीं upload नहीं करता।
• Logs: runner output, browser console और उसी समय-खिड़की के server logs, जिन्हें timestamp या request id से मिलाया जाता है।
• Evidence भी data है: trace में request headers, cookies और test का टाइप किया हर value हो सकता है, इसलिए synthetic data इस्तेमाल करें और artifacts की expiry तय करें।

// playwright.config.ts (excerpt): keep evidence for failures only
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'on-first-retry',   // needs retries; with none, use 'retain-on-failure'
  },
});

// Then, in a terminal, open a trace downloaded from a CI run:
//   npx playwright show-trace trace.zip

Fail हुए test की debugging: पहले error से कारण तक

ISTQB testing और debugging को अलग करता है: testing failures दिखाती है, debugging उनके कारण ढूँढती, analyse करती और हटाती है। Fail हुए automated test में tester failure analysis करता है: defect product में है, test code में या environment में? Tester test code को debug करता है; developer उसी evidence से शुरू करके product को debug करता है।

पहला error पढ़ें, आख़िरी नहीं; बाद वाले errors आम तौर पर उसी के नतीजे होते हैं। उसका type बताता है कि कौन-सा artifact खोलना है। Setup error का मतलब है test अपने check तक पहुँचा ही नहीं: hook का error और server log पढ़ें। Timeout हुए action का मतलब है कोई element मिला नहीं या इस्तेमाल नहीं हो सका: उस action से पहले का DOM snapshot और उसका call log खोलें। Fail हुए assertion का मतलब है page ने कुछ और दिखाया: screenshot की तुलना expected value से करें, फिर Network tab में देखें कि data गलत आया या देर से।

• Local पर reproduce करें: npx playwright test --debug Playwright Inspector में test को step by step चलाता है, --ui UI mode खोलता है जिसमें हर run को समय में आगे-पीछे देख सकते हैं, और await page.pause() headed run में चुनी हुई line पर test रोक देता है। ‘फ़ेलियर रिप्रोड्यूस करना’ lesson की तरह एक बार में एक ही चीज़ बदलें।
• Timeout तब तक न बढ़ाएँ जब तक पता न हो कि समय क्यों ख़त्म हुआ: धीमा response ख़ुद defect हो सकता है।

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: टाइमस्टैम्प कन्वर्टर

Worked example: nightly run में गलत order total

Staging पर nightly UI run, build 512, एक failure report करता है; उसका retry भी fail हुआ, इसलिए यह failed है, flaky नहीं। नीचे report और trace के छोटे किए गए हिस्से हैं।

पहला error assertion है: element मिला, पर उसकी value गलत थी। Screenshot में cart का VAT 0.00 दिखता है, यानी test ने वही पढ़ा जो page ने दिखाया। Trace में GET /api/cart/8812 के response में पहले से "vatRate": 0 है: browser ने वही दिखाया जो server ने भेजा। आख़िरी green run, build 509, ने कोई trace नहीं रखा, पर उसकी report में अब भी वह cart JSON है जिसे test हर run में attach करता है, और उसमें "vatRate": 0.15 है; दोनों का JSON diff दिखाता है कि सिर्फ़ vatRate और total बदले।

तो कारण builds 509 और 512 के बीच back end का कोई बदलाव है या staging पर बदली हुई tax setting; developer या environment owner से एक सवाल तय कर देता है कि कौन-सा। Test सही है और जैसा है वैसा रहेगा। Report “Build 512 से Cart API सऊदी cart के लिए vatRate 0 लौटाता है” के साथ दोनों responses, trace और build range जाते हैं।

✘ checkout.spec.ts:42 › checkout › VAT is added to the order total
  failed (retry #1 failed too) · chromium · staging · build 512

  Error: expect(locator).toHaveText(expected)
  Locator:  getByTestId('order-total')
  Expected: "172.50 SAR"
  Received: "150.00 SAR"
    at checkout.spec.ts:51

  Attachments: cart · screenshot · video · trace

Build 512 › trace › Network › GET /api/cart/8812 → 200
  { "subtotal": 150.00, "vatRate": 0,    "total": 150.00 }

Build 509 (last green run, no trace kept) › HTML report › attachment "cart"
  { "subtotal": 150.00, "vatRate": 0.15, "total": 172.50 }

आज़माएँ: JSON डिफ़

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
• Trace viewer — PlaywrightMicrosoft (Playwright)टेस्ट रन को क़दम-दर-क़दम रिकॉर्ड और रीप्ले करना — DOM स्नैपशॉट, नेटवर्क, कंसोल — ख़ासकर CI की विफलताओं का निदान करने के लिए।
• Cypress DocumentationCypress.ioCypress से ब्राउज़र में एंड-टू-एंड और कंपोनेंट टेस्टिंग का आधिकारिक दस्तावेज़।