Season Trailer & Orientation (Hinglish)
Apni local practice shop ko explore karenge, actions aur assertions ka farq samjhenge, paanch browser-testing missions ka roadmap dekhenge, aur do clear test expectations likhenge.
Shop Online Hai. Cart Atka Hua Hai.
Shop Online Hai. Cart Atka Hua Hai.
Humari shop load ho rahi hai. Product cards dikh rahe hain. Server successful response de raha hai. Lekin jab hum Add to Cart dabate hain, tab bhi cart 0 hi dikha raha hai.
Sochiye agar peak sale ke dauran aisa ho jaye. Yeh samjhane ke liye ek illustrative scenario hai, koi reported incident nahi. Server health check pass hone ke bawajood customers apni purchase complete nahi kar pa rahe.
Ek server check is sawal ka jawab deta hai: “Kya yeh service respond kar sakti hai?” Lekin yeh zaroori nahi batata ki: “Kya koi customer product add karke checkout complete kar sakta hai?” Yeh dono bilkul alag sawal hain.
Isi gap se shuru hota hai MetaWise India ka season: Playwright: Humara Pehla Browser Testing Mission.
Paanch practical episodes mein hum apni local practice shop ke liye ek chhota browser-test suite banayenge. Hum jaan-boojhkar daala gaya (deliberate) bug pakdenge, tests ko improve karenge, failures investigate karenge, aur code change hone par automated checks chalane ka workflow banayenge.
Humara mission: expected customer journey ko repeatable checks aur visible evidence (dikhne wale thos saboot) mein badalna. Is orientation ke liye kisi installation ki zaroorat nahi hai.
Click Se Check Tak
Click Se Check Tak
Ek restaurant inspection ka example lete hain. Kitchen mein bijli hona yeh saabit nahi karta ki order sahi table tak pahunchega. Humein order se lekar delivery tak ki poori customer journey ko dekhna hota hai.
Browser testing ka concept bhi bilkul aisa hi hai: hum web page par ek specific journey run karte hain aur uske outcome ko check karte hain.
Playwright Chromium, Firefox aur WebKit browser engines ko control kar sakta hai. Is season mein hum Playwright Test use karenge, jisme test runner, assertions aur debugging tools bhi milte hain. Pehla setup focused rakhne ke liye hum Chromium se shuru karenge.
Ek script browser ko instructions deta hai. Browser humari shop kholta hai aur uske saath interact karta hai. Assertion verify karti hai ki screen par dikhne wala result humari expectation se match karta hai ya nahi.
| Step / Hissa | Humari shop mein | Yeh humein kya batata hai |
|---|---|---|
| Starting state | Cart mein koi item nahi hai | Humein pata hai ki test kahan se shuru hota hai |
| Action | Add to Cart par ek baar click kiya | Humne user interaction trigger kiya |
| Assertion | Verify kiya ki cart count 1 ho gaya | Expected result ka concrete evidence mil gaya |
Click ek action hai. Cart count ka update hona evidence (saboot) hai. Iske baad aane wala shared diagram isi path ko darshata hai: test → browser → assertion.
Ek automated browser har ek human experience ko reproduce nahi kar sakta. Passing tests sirf unhi specific journeys, test data aur browser configurations ko validate karte hain jinhe humne check kiya hai. Yeh is baat ka praman nahi dete ki application ka har feature sahi kaam kar raha hai, aur na hi yeh unit tests, API tests, accessibility checks ya manual exploratory testing ka replacement hain.
action-to-evidence
Hum Kya Kar Paayenge?
Hum Kya Kar Paayenge?
Hum ek local practice shop aur simulated checkout ke saath kaam karenge. Yahan real payment ya customer data ki koi zaroorat nahi hai. Deliberate (jaan-boojhkar daale gaye) bugs humein bina kisi risk ke mistakes investigate karne ki ek safe practice space dete hain.
| Humara starting point | Dikhane-layak useful progress |
|---|---|
| Students aur beginners | Action aur assertion ka farq explain karna, browser test run karna, aur portfolio walkthrough mein failure explain karna |
| UI tests add karne wale developers | Clear aur resilient locators chunna, checkout boundary cases check karna, aur tests ko independent rakhna |
| Teams ke saath kaam karne wale engineers | Failure evidence inspect karna aur code changes par automated checks lagana |
Season ke end tak humara deliverable ek chhota test suite hoga jisme readable expectations, ek debugging workflow, aur ek GitHub Actions workflow shaamil honge. Yeh ek solid foundation hai jise hum explain bhi kar sakte hain aur aage extend bhi. Is approach ko production system par apply karne ke liye uski apni test data strategy, security controls, coverage decisions aur ongoing maintenance ki zaroorat hoti hai.
AI-generated Tests Ke Saath Kaam
AI tezi se test script suggest kar sakta hai. Lekin woh koi fragile selector chun sakta hai ya galat result check kar sakta hai. Evidence ki aakhiri zimmedari humari hi rehti hai.
Engineer ringmaster hai: hum kaam ko direction dete hain aur uske behavior ko inspect karte hain. Jab bhi generated code convincing lage, humein yeh sawal poochna hai: Yeh kis requirement ko check karta hai, aur kya yeh us bug ko pakad paayega jiska humein dhyan rakhna hai?
Kisi paid AI assistant ya API key ki koi zaroorat nahi hai. Hum har exercise khud tests likhkar aur run karke poori kar sakte hain.
Paanch Missions, Ek Badhta Test Suite
Paanch Missions, Ek Badhta Test Suite
Hum ek broken interaction se shuru karenge aur browser tests investigate aur maintain karne ki habits banayenge. Iske baad aane wala shared roadmap diagram isi sequence ko summarize karta hai.
| Episode | Mission | Progress Ka Evidence (Saboot) |
|---|---|---|
| 01 · The Crime Scene & First Blood | Local shop start karna, lab dependencies install karna, aur Add to Cart check karna | Assertion deliberate cart bug ko expose karti hai; hum failure ko inspect karke fix verify karte hain |
| 02 · Ghost Clicks & Resilient Locators | Role ya label se controls dhoondhna aur automatic waiting samajhna | Hum fragile locator ko replace karte hain aur explain karte hain ki test kis cheez ka wait karta hai |
| 03 · Breaking Checkout: The Edge Case Gauntlet | Quantities, invalid input, checkout rules aur independent starting states check karna | Tests boundary behavior express karte hain aur kisi doosre test ke state changes par depend nahi karte |
| 04 · The Autopsy: Trace Viewer & Flaky Tests | UI Mode aur recorded traces se failures investigate karna | Hum available page snapshots, action details aur network evidence se failure explain karte hain |
| 05 · The Automated Shield: GitHub Actions CI | Selected pushes aur pull requests par suite chalana aur reports retain karna | Workflow code change ke saath test results available karata hai |
Locator batata hai ki test page element kaise dhoondhega. Flaky test aisa test hota hai jo bina kisi code change ke kabhi pass aur kabhi fail hota rehta hai. Continuous integration (CI) code changes integrate hote waqt automated checks chalata hai. Hum in terms ko unki missions mein detail se unpack karenge.
Episode 1 Se Pehle
Humein basic JavaScript familiarity honi chahiye: variables, functions aur chhota code example samajhna. Pehle se software testing ka koi experience hona zaroori nahi hai. Asynchronous test syntax jaise-jaise samne aayega, hum use step-by-step samjhenge.
- Supported operating system wala computer; sirf mobile phone se yeh lab run nahi ho sakti.
- Recommended runtime Node.js 24 LTS, npm, VS Code jaisa text editor, aur ek terminal.
- Shuru mein packages aur browser downloads ke liye internet connection; uske baad shop aur tests locally run honge.
- Episode 5 ke hosted workflow ke liye Git aur ek free GitHub account. Is orientation ke liye account ki zaroorat nahi hai.
Current Playwright documentation Node.js 22.x, 24.x ya 26.x; Windows 11+, Windows Server 2019+ ya WSL; macOS 14+; aur supported Debian/Ubuntu releases list karti hai. Installation se pehle hum official system requirements ko apne machine aur lab version se verify karenge.
Free Tools Aur Episode Access
Core lab ke tools 100% free hain aur inke liye koi paid API key, cloud subscription ya real payment setup nahi chahiye. Local test runs poore season mein available rahenge.
Hosted CI ke liye humara free practice route public practice repository aur standard GitHub-hosted runners use karega. Private repositories ki allowances plan par depend karti hain; hum GitHub Actions usage guidance follow karenge aur reports ko included storage limits ke andar rakhenge. GitHub Actions ek hosted service hai; yeh local open-source tools se alag hai.
Seasons, episodes aur curated downloads ka access applicable MetaWise India membership tier ke hisaab se hota hai. Free practice tools aur episode access alag-alag cheezein hain.
season-mission-roadmap
Humara Pehla Test Ek Sentence Se Shuru Hota Hai
Humara Pehla Test Ek Sentence Se Shuru Hota Hai
Terminal kholne se pehle, aaiye ek clear expectation likhte hain.
Starting state: Cart poori tarah khaali hai aur product available hai. Action: Hum Add to Cart par ek baar click karte hain. Expected evidence: Cart count 1 ho jata hai.
Yeh sentence ek chhoti test specification hai: ek starting state, ek action aur ek observable result. Pichle image diagram mein bhi humne test script, browser aur assertion ke beech theek yahi relation dekha tha.
A 60-Second Challenge
Isi pattern se apni practice shop ke liye do aur expectations likhte hain:
Given ek known starting state, when koi action hota hai, hum expect karte hain ek observable result.
Hum quantity change ya incomplete checkout form chun sakte hain. Pehle intended rule ko clearly state karte hain: jaise fixed unit price par quantity 2 ka subtotal us price ka double hona chahiye, alag fees add hone se pehle. Hum bina kisi requirement ke red border ya disabled button assume nahi karenge jab tak shop ka design specifically aisa na kahe.
Humara self-check: Kya koi doosra engineer bina kisi andaze ke bata sakta hai ki har expectation pass hui ya fail? “Checkout kaam karta hai” bohot vague statement hai. Ek named, concrete result humein aisi cheez deta hai jise hum inspect kar sakein.
Kisi submission ya code run karne ki zaroorat nahi hai. Do clear expectations wali note hi is orientation ka intended outcome hai.
Episode 1 mein hum apni local shop start karenge aur is empty-cart expectation ko ek real browser test mein convert karenge. Wahan aane wala pehla failure humein saath milkar investigate karne ka evidence dega.
Keep Learning, Keep Growing.