QA 16: Test avtomatlashtirishga kirish — nimani avtomatlashtirish kerak, ROI va 2026 asboblar xaritasi

🧪 QA Engineer — Zero to Hero

QA 16: Test avtomatlashtirishga kirish — nimani avtomatlashtirish kerak, ROI va 2026 asboblar xaritasi

Holat: 2026-yil oktabr. Bu dars Avtomatlashtirish modulini ochadi: avtotest nima va nima emas, qaysi testni avtomatlashtirish o'zini oqlaydi, ROI qanday hisoblanadi, 2026-yilda qaysi asboblar ishlatiladi va avtomatlashtirish framework'i qanday quriladi. Versiyalar 2026-yil 9-oktabrda npm va GitHub'dan tekshirilgan (masalan, @playwright/test 1.64.0).

Bu darsdan keyin siz: "buni avtomatlashtiramizmi?" degan savolga hissiyot bilan emas, hisob-kitob bilan javob bera olasiz.

• avtotest va qo'lda (manual) testning kuchli tomonlarini ajrata olasiz;
• test case'ni avtomatlashtirish kerakmi yoki yo'qligini mezonlar asosida hal qilasiz;
• ROI va qoplanish nuqtasini (break-even) hisoblaysiz;
• 2026-yilgi asboblar xaritasida yo'naltirilasiz va nega bu kursda Playwright + TypeScript tanlanganini tushuntira olasiz;
• yaxshi avtotestning tamoyillarini bilasiz va yomon testni ko'rganda taniysiz.

Mundarija

1. Test avtomatlashtirish nima
2. Qo'lda va avtomatik test: kim nimada kuchli
3. Nimani avtomatlashtirish kerak, nimani yo'q
4. ROI: avtomatlashtirish qachon o'zini oqlaydi
5. Piramida avtomatlashtirish nigohidan
6. 2026-yil asboblar xaritasi
7. Nega bu kursda Playwright + TypeScript
8. Avtomatlashtirish framework'i arxitekturasi
9. Yaxshi avtotestning 10 tamoyili
10. Amaliy mashqlar
11. O'zingizni tekshiring
12. Xulosa
13. Manbalar

1. Test avtomatlashtirish nima {#nima}

Test avtomatlashtirish — test'ni (yoki test ishining bir qismini) dastur yordamida bajarish. Dastur ilovani ochadi, foydalanuvchi qiladigan harakatlarni takrorlaydi, natijani kutilgan natija bilan solishtiradi va hisobot beradi.

Oddiy qilib aytganda: avtotest — sizning test case'ingizning kod ko'rinishidagi nusxasi. U charchamaydi, xato bosmaydi, kechasi ham ishlaydi. Lekin u faqat siz o'rgatgan narsani tekshiradi.

Keling, bitta qo'lda yoziladigan test case'ni avtotestga aylantirib ko'ramiz. Mashq uchun haqiqiy demo do'kon — saucedemo.com dan foydalanamiz:

To'liq ko'rinishi:

import { test, expect } from "@playwright/test";

test("standard_user muvaffaqiyatli kiradi", async ({ page }) => {
  await page.goto("/");
  await page.getByTestId("username").fill("standard_user");
  await page.getByTestId("password").fill("secret_sauce");
  await page.getByTestId("login-button").click();

  await expect(page).toHaveURL(/\/inventory\.html$/);
  await expect(page.getByTestId("title")).toHaveText("Products");
});

Hozircha sintaksisni tushunish shart emas — buni QA 17 (TypeScript) va QA 18 (Playwright) darslarida bosqichma-bosqich o'rganamiz. Muhimi — g'oya: qadam → kod, kutilgan natija → assertion.

Avtomatlashtirish nima EMAS

• Yangi bug'larni "o'zi" topadigan sehr emas. Avtotest asosan regressiyani ushlaydi: kecha ishlagan narsa bugun buzilmaganini tekshiradi. Yangi, kutilmagan muammolarni ko'pincha inson exploratory testing'da topadi.
• Manual QA'ni almashtirmaydi. "Bu ekran tushunarlimi?", "foydalanuvchi bu yerda adashmaydimi?" degan savollarga dastur javob bermaydi.
• "Bir marta yozdim — tamom" emas. Avtotest — kod. U ham eskiradi, buziladi, refactoring talab qiladi.
• 100% qamrov maqsad emas. Maqsad — eng muhim risk'larni eng arzon qatlamda tekshirish.
• Faqat UI emas. Unit, API, performance, accessibility, visual tekshiruvlar ham avtomatlashtiriladi.

🎯 Intervyuda: "Avtomatlashtirish manual testing'ni to'liq almashtira oladimi?" — Yo'q. Avtomatlashtirish takrorlanadigan va aniq natijali tekshiruvlarni tezlashtiradi; exploratory, usability va yangi funksiyani birinchi marta "his qilib" ko'rish inson ishi bo'lib qoladi. Yaxshi jamoada ular bir-birini to'ldiradi.

2. Qo'lda va avtomatik test: kim nimada kuchli {#manual-vs-auto}

Keng tarqalgan afsonalar

🧠 Esda tuting: Avtomatlashtirish — test qilishning o'zi emas, test qilishni tezlashtiruvchi vosita. Nimani tekshirishni test dizayn (QA 5–6) hal qiladi, avtomatlashtirish faqat uni tez va ko'p marta bajaradi.

3. Nimani avtomatlashtirish kerak, nimani yo'q {#nimani}

"Ha" degan signallar

1. Ko'p takrorlanadi — har relizdagi regression, har PR'dagi smoke.
2. Funksionallik barqaror — talab va UI har hafta o'zgarmaydi.
3. Biznes riski yuqori — login, savatcha, checkout, to'lov. Bu yerda bug qimmatga tushadi.
4. Ma'lumotga asoslangan — bir xil qadamlar, lekin o'nlab kirish qiymatlari (QA 5 dagi EP/BVA jadvallari).
5. Qo'lda zerikarli yoki xato qilish oson — 80 ta API endpoint, 3 brauzer × 4 ekran o'lchami.
6. Natija aniq — "summa 340 000 so'm bo'lishi kerak" kabi qat'iy kutilgan natija (oracle) bor.

"Yo'q" yoki "hozircha yo'q" degan signallar

1. Exploratory testing — u ta'rifiga ko'ra oldindan yozilmaydi.
2. UX va "chiroyli ko'rinadimi?" — qisman visual testlar yordam beradi (QA 25), lekin yakuniy hukm insonda.
3. Bir martalik tekshiruv — masalan, bir martalik ma'lumot migratsiyasini qo'lda tekshirish arzonroq.
4. Tez o'zgarayotgan UI — prototip bosqichidagi ekran uchun yozilgan test har hafta buziladi.
5. Boshqarib bo'lmaydigan tashqi tizim — "SMS haqiqatan telefonga keldimi?", "bank kartadan pul yechdimi?". Bularni test muhitida sandbox, mock yoki test hook bilan quyi qatlamda tekshiramiz.
6. Ataylab avtomatlashtirishga qarshi himoyalar — CAPTCHA kabi. Test muhitida ular dasturchilar bilan kelishilgan holda o'chiriladi, avtotest ularni "aylanib o'tmaydi".

Amaliy baholash usuli

Har bir test case'ga 4 ta mezon bo'yicha 1–3 ball qo'ying va yig'ing. Bu standart emas, amaliy usul — jamoa ichida qaror qabul qilishni tezlashtiradi:

9–12 ball → avtomatlashtiramiz; 6–8 → muhokama qilamiz; 4–5 → qo'lda qoldiramiz.

DemoBozor (kurs davomidagi xayoliy onlayn do'konimiz) misolida:

4. ROI: avtomatlashtirish qachon o'zini oqlaydi {#roi}

Menejer sizdan "avtomatlashtirishga 160 soat sarflasak, nima olamiz?" deb so'raydi. Javobni his bilan emas, hisob bilan bering.

M  = bitta qo'lda regression yugurishi narxi (soat)
A  = avtomatlashgan yugurishdagi qoldiq ish (qo'lda qolgan testlar + natijani tahlil + testlarni tuzatish)
I  = boshlang'ich investitsiya (framework + testlarni yozish, soat)

Bir yugurishdagi tejash:          S = M − A
Qoplanish nuqtasi (break-even):   n = I / S   (shuncha yugurishdan keyin investitsiya qaytadi)
Davr uchun ROI:                   ROI = (S × yugurishlar soni − I) / I × 100%

Ishlangan misol: DemoBozor regression'i

• Regression to'plami: 120 ta test case × 6 daqiqa = 12 soat (M = 12).
• Reliz har 2 haftada → yiliga 26 ta regression.
• Avtomatlashtirish: framework + 100 ta test'ni yozish — I = 160 soat. Qolgan 20 ta test (UX, tashqi tizimlar) qo'lda qoladi.
• Avtomatik yugurishdagi qoldiq ish: 20 ta qo'lda test ≈ 2 soat + natijani tahlil va testlarni tuzatish ≈ 2 soat → A = 4 soat.

Hisob:

S = 12 − 4 = 8 soat tejaladi (har yugurishda)
n = 160 / 8 = 20 yugurish → 20 × 2 hafta ≈ 40 hafta (~9 oy)
1-yil ROI = (8 × 26 − 160) / 160 × 100% = (208 − 160) / 160 = 30%

💡 Maslahat: Testlar qanchalik ko'p ishga tushsa, investitsiya shunchalik tez qaytadi. Agar regression faqat relizda emas, har PR'da ishlasa, qo'lda bunday tekshiruvni hech kim qila olmasdi — avtomatlashtirishning haqiqiy qiymati shu yerda ochiladi.

Hisobga kirmaydigan, lekin muhim narsalar

⚠️ Diqqat: Yuqoridagi raqamlar — o'quv misoli. O'z loyihangiz uchun haqiqiy vaqtlarni o'lchang: bitta regression necha soat oladi, testlarni tuzatishga haftasiga qancha vaqt ketadi. Aks holda ROI jadvali chiroyli, lekin yolg'on bo'ladi.

🎯 Intervyuda: "Avtomatlashtirish foydali ekanini qanday isbotlaysiz?" — Qo'lda regression narxi, yugurishlar chastotasi va qo'llab-quvvatlash xarajatini o'lchab, qoplanish nuqtasini hisoblayman; bundan tashqari tezroq feedback va ushlangan regression bug'lar sonini ko'rsataman.

5. Piramida avtomatlashtirish nigohidan {#piramida}

QA 4 da test piramidasi bilan tanishgansiz. Avtomatlashtirishda bu piramida byudjet rejasi kabi ishlaydi: tekshiruvni qayerda qilsangiz, shuncha narx to'laysiz.

Google Testing Blog'dagi mashhur maqolada shunday maslahat bor: boshlang'ich taxmin sifatida 70% unit, 20% integratsion, 10% end-to-end test; aniq nisbat jamoaga qarab farq qiladi, lekin piramida shakli saqlanishi kerak. Teskari piramida — "muzqaymoq" (ice cream cone) — anti-pattern sifatida ko'rsatilgan.

                 ▲  sekin, qimmat, beqarorroq
               /E2E\        ~10%  — foydalanuvchi oqimi (Playwright UI)
              /------\
             /  API   \     ~20%  — servislar va integratsiya (Playwright request, Postman)
            /----------\
           /    Unit    \   ~70%  — funksiya va klasslar (Vitest, Jest, XCTest)
          /--------------\
                 ▼  tez, arzon, barqaror

Bitta qoida — uch qatlam

DemoBozor'da "mahsulotlar summasi ≥ 300 000 so'm bo'lsa yetkazib berish bepul" qoidasi bor. Uni qanday taqsimlaymiz?

Ko'rdingizmi: chegaradagi barcha holatlar arzon qatlamda, UI'da esa faqat "ulanish ishlayaptimi" tekshiriladi. Agar 6 ta BVA holatini ham UI orqali tekshirsak, 6 ta sekin va beqaror test olamiz.

6. 2026-yil asboblar xaritasi {#asboblar}

Versiyalar 2026-yil 9-oktabrdagi npm latest (k6 — GitHub releases) bo'yicha. Versiyalar tez o'zgaradi — loyihaga qo'shishdan oldin npm view <paket> version bilan tekshiring.

💡 Maslahat: Asboblar ro'yxatini yodlash shart emas. Muhimi — kategoriyalarni bilish: "bu UI test asbobi", "bu yuk (load) testi asbobi". Vakansiyada notanish asbob ko'rsangiz, uning kategoriyasini aniqlab, tanish analogiga bog'lang.

7. Nega bu kursda Playwright + TypeScript {#nega-playwright}

Playwright haqida faktlar

• Microsoft tomonidan ishlab chiqiladi, ochiq kodli (Apache-2.0 litsenziya).
• Uchta brauzer dvigatelida ishlaydi: Chromium, Firefox, WebKit (Safari dvigateli).
• Tillar: TypeScript/JavaScript, Python, Java, .NET. Node.js versiyasi o'zining test runner'i bilan keladi; Python uchun rasmiy tavsiya — Pytest plagini.
• Auto-waiting: action'dan oldin element ko'rinishi, barqaror bo'lishi va bosilishga tayyorligini o'zi kutadi.
• Test izolyatsiyasi: har bir test uchun yangi BrowserContext (inkognitoga o'xshash profil) yaratadi — cookie va localStorage testlar orasida "oqib o'tmaydi".
• O'zida: test runner, parallel ishga tushirish, retry, fixture'lar, API testlash, trace viewer, UI mode, codegen.
• Tizim talablari (rasmiy hujjat): Node.js 22.x, 24.x yoki 26.x; macOS 14+; Windows 11+ yoki WSL; Debian 12/13, Ubuntu 22.04/24.04/26.04.

Uch mashhur asbobni solishtiramiz

Xulosa: uchalasi ham ishlaydigan, haqiqiy loyihalarda ishlatiladigan asboblar. Bu kurs uchun Playwright'ni tanladik, chunki u bitta asbobda UI, API, mobil emulyatsiya, trace va parallel ishga tushirishni beradi, hamda TypeScript'da birinchi darajali qo'llab-quvvatlanadi. Selenium'ni bilish ham foydali — ko'plab katta va eski loyihalar unda yozilgan.

Qaysi tilni tanlash kerak?

💡 Maslahat: "Eng yaxshi til" yo'q. Eng yaxshisi — jamoangiz yozadigan til: kod review'dan o'tadi, dasturchilar yordam bera oladi, CI'da bir xil asboblar ishlaydi. Boshlovchi uchun maslahat: bitta tilni chuqur o'rganing, qolganlari keyin tez o'zlashtiriladi.

🎯 Intervyuda: "Nega Selenium emas, Playwright?" — Playwright auto-wait, test izolyatsiyasi (har test uchun yangi browser context), o'zida runner, trace viewer va API testlashni beradi; Selenium esa W3C standartiga asoslangan, tillar tanlovi keng va eski loyihalarda keng tarqalgan. Tanlov loyiha va jamoaga bog'liq.

8. Avtomatlashtirish framework'i arxitekturasi {#arxitektura}

"Framework" — bu shunchaki testlar to'plami emas, balki testlarni yozish, ishga tushirish va qo'llab-quvvatlashni osonlashtiradigan tuzilma. Yaxshi tuzilmada har bir qatlamning bitta vazifasi bor.

Avtomatlashtirish framework'ining qatlamlari: test spec'lardan CI'gacha

Kurs davomida quradigan loyihamiz tuzilmasi (QA 18–QA 21):

qa-demo-tests/
├── package.json
├── playwright.config.ts      # baseURL, brauzerlar, testIdAttribute, trace
├── .env.example              # BASE_URL, API_BASE_URL, SAUCE_USERNAME, SAUCE_PASSWORD
├── pages/                    # Page Object'lar (QA 19): LoginPage.ts, InventoryPage.ts ...
├── fixtures/test.ts          # test.extend — page object'larni testga berish (QA 19)
├── api/BookingClient.ts      # API client (QA 20)
├── schemas/booking.ts        # Zod schema'lar (QA 20)
├── tests/
│   ├── auth.setup.ts         # bir marta login, storageState (QA 19)
│   ├── ui/login.spec.ts      # QA 18
│   ├── ui/cart.spec.ts       # QA 18–19
│   ├── ui/checkout.spec.ts   # QA 18–19
│   └── api/booking.spec.ts   # QA 20
└── .github/workflows/playwright.yml   # CI (QA 21)

🧠 Esda tuting: Bog'liqlik yuqoridan pastga ketadi: test → page object → locator. Agar sahifadagi tugma o'zgarsa, faqat bitta page object'ni tuzatasiz, 40 ta testni emas. Bu tamoyilni QA 19 da amalda ko'ramiz.

9. Yaxshi avtotestning 10 tamoyili {#tamoyillar}

1. Har bir test mustaqil. Test boshqa test'dan oldin yoki keyin ishlashiga bog'liq bo'lmasligi kerak. Playwright har test uchun yangi browser context beradi — bundan foydalaning.
2. Ma'lumot deterministik. Har yugurishda test o'z ma'lumotini yaratadi (unikal nom, faker + seed) va iloji bo'lsa o'zi tozalaydi. Bir umumiy hisobni parallel testlar o'zgartirmasin.
3. **sleep yo'q.** "3 soniya kutib turaman" — sekin va baribir beqaror. O'rniga auto-wait va web-first assertion (QA 18).
4. AAA tuzilmasi: Arrange (tayyorlash) → Act (harakat) → Assert (tekshirish).
5. Bitta test — bitta xatti-harakat. "Login, savatcha, profil va chiqish" bitta testda bo'lsa, yiqilganda nima buzilganini topish qiyin.
6. Nom xatti-harakatni tasvirlaydi. test1 emas, "2 ta mahsulot qo'shilsa badge 2 ni ko'rsatadi".
7. Testlarda DAMP > DRY. Testlar o'qilishi oson bo'lsin (Descriptive And Meaningful Phrases). Biroz takror normal; faqat "shovqin"ni (login, ma'lumot yaratish) fixture/page object'ga chiqaring. Google Testing Blog'ning "Tests Too DRY? Make Them DAMP!" maqolasi aynan shu haqida.
8. Barqaror locator'lar. Rol, label, test id. div:nth-child(3) > span kabi DOM tuzilmasiga bog'liq selektorlardan qoching. Kerak bo'lsa dasturchilardan data-testid qo'shishni so'rang — testlanuvchanlik (testability) jamoaning umumiy ishi.
9. Test kodi = production kodi. Git, code review, lint, tushunarli nomlar. Yomon yozilgan test ham texnik qarz.
10. Yiqilish o'zini tushuntirsin. Aniq assertion, kerak bo'lsa izohli xabar, trace va screenshot. "Expected true, received false" — yomon xabar.

Yomon test qanday ko'rinadi: haqiqiy tajriba

Quyidagi ikki test saucedemo'da yozilgan. Ularda bir nechta tamoyil buzilgan:

import { test, expect } from "@playwright/test";

let loggedIn = false; // ❌ testlar orasida umumiy holat

test("1-test: login", async ({ page }) => {
  await page.goto("https://www.saucedemo.com/");
  await page.locator("#user-name").fill("standard_user");
  await page.locator("#password").fill("secret_sauce");
  await page.locator("#login-button").click();
  await page.waitForTimeout(5000); // ❌ "uxlash"
  loggedIn = true;
});

test("2-test: savatcha", async ({ page }) => {
  if (!loggedIn) return; // ❌ shart bajarilmasa test "jimgina o'tadi"
  await page.goto("https://www.saucedemo.com/inventory.html");
  await page
    .locator('//*[@id="inventory_container"]/div/div[1]/div[2]/div[2]/button')
    .click(); // ❌ mo'rt XPath
  const badge = await page.locator(".shopping_cart_badge").textContent();
  expect(badge).toBe("1"); // ❌ qayta urinmaydigan tekshiruv
});

Biz bu testni Playwright 1.64 da ikki xil rejimda ishga tushirib ko'rdik:

Bir xil kod — ikki xil natija. Mana shu flaky (beqaror) testning tug'ilishi. Uni qanday tuzatishni mashq 4 da ko'rasiz.

⚠️ Diqqat: Eng xavfli test — yiqiladigan test emas, hech narsani tekshirmay o'tadigan test. U jamoaga yolg'on xotirjamlik beradi. Har yangi testni bir marta ataylab "sindirib" ko'ring: kutilgan natijani noto'g'ri qilib yozing — test qizarishi kerak.

Flaky testlarning sabablari (vaqtga bog'liqlik, umumiy ma'lumot, testlar tartibi, tashqi servislar) va ularni boshqarish — QA 21 da.

10. Amaliy mashqlar {#mashqlar}

Mashq 1: Avtomatlashtiramizmi?

DemoBozor uchun quyidagi tekshiruvlarni ko'rib chiqing. Har biri uchun qaror qabul qiling: avtomatlashtiramiz (qaysi qatlamda?) yoki qo'lda qoldiramiz. Sababini bir jumlada yozing.

1. Telefon raqami formati (+998 + 9 raqam) — 15 ta turli kirish qiymati.
2. Yangi "Bayram aksiyasi" banneri chiroyli ko'rinadimi.
3. Buyurtma statusi PAID → PACKING → SHIPPED o'tishlari.
4. iOS ilovada qo'ng'iroq kelganda checkout holati saqlanishi.
5. 3 marta noto'g'ri SMS kod → 15 daqiqa blok.
6. Admin panelda bir martalik ma'lumot ko'chirish natijasi.
7. Har relizdan oldin login → qidiruv → savatcha → buyurtma oqimi.
8. Mahsulot sahifasida rasm sifati.

<details> <summary>💡 Javobni ko'rish</summary>

</details>

Mashq 2: ROI hisobi

Ma'lumotlar: qo'lda regression — 90 ta test case × 5 daqiqa. Regression har hafta ishlaydi. Avtomatlashtirish uchun boshlang'ich investitsiya — 120 soat. Avtomatlashgandan keyin har yugurishda qoldiq ish: 1,5 soat qo'lda testlar + 1,5 soat tahlil va testlarni tuzatish.

Hisoblang: M, A, S, qoplanish nuqtasi (necha hafta?) va 1 yillik (52 hafta) ROI.

<details> <summary>💡 Javobni ko'rish</summary>

M = 90 × 5 daqiqa = 450 daqiqa = 7,5 soat
A = 1,5 + 1,5 = 3 soat
S = 7,5 − 3 = 4,5 soat (har yugurishda)
n = 120 / 4,5 = 26,7 → 27 ta yugurish ≈ 27 hafta (~6 oy)
1-yil: tejash = 4,5 × 52 = 234 soat
ROI = (234 − 120) / 120 × 100% = 95%

Xulosa: haftalik regression bilan investitsiya yarim yilda qaytadi, birinchi yilning o'zida ~95% ROI. Agar testlar har PR'da ishlasa, foyda yanada katta bo'ladi (garchi qoldiq tahlil vaqti ham o'zgarishi mumkin).

</details>

Mashq 3: Qaysi asbob?

Har bir vaziyat uchun asbobni tanlang va bir jumlada asoslang:

1. iOS jamoasi native ilovaning login ekranini Xcode ichida testlamoqchi.
2. QA jamoasi kod bazasiga kirmasdan iOS va Android ilovalarining asosiy oqimlarini YAML'da tez avtomatlashtirmoqchi.
3. API 500 so'rov/soniya yukni ko'tara oladimi — tekshirish kerak.
4. TypeScript biladigan QA REST API regression'ini CI'da ishga tushirmoqchi.
5. Dizayn tizimidagi tugmalar tasodifan o'zgarib qolmasligini nazorat qilish kerak.
6. Java/Spring'da ishlaydigan jamoa API testlarini o'z tilida yozmoqchi.
7. Sahifa WCAG talablariga mosligini avtomatik tekshirish kerak.

<details> <summary>💡 Javobni ko'rish</summary>

</details>

Mashq 4: Yomon testni tuzating

9-bo'limdagi ikki testni oling. (a) Undagi barcha muammolarni sanab chiqing. (b) Testni tamoyillarga mos qilib qayta yozing (baseURL = https://www.saucedemo.com va testIdAttribute: 'data-test' sozlangan deb hisoblang).

<details> <summary>💡 Javobni ko'rish</summary>

(a) Muammolar:

1. let loggedIn — testlar orasida umumiy o'zgaruvchan holat; parallel rejimda har worker'da alohida bo'ladi.
2. 2-test 1-test'ga bog'liq (tartibga bog'liqlik).
3. if (!loggedIn) return; — test hech narsani tekshirmay "o'tadi" (yolg'on yashil).
4. waitForTimeout(5000) — har safar 5 soniya yo'qotiladi va baribir kafolat yo'q.
5. Uzun XPath — DOM sal o'zgarsa buziladi.
6. textContent() + toBe() — qayta urinmaydigan tekshiruv, sahifa kechiksa yiqiladi.
7. To'liq URL testlar ichida — muhit almashtirish qiyin (baseURL ishlatilmagan).
8. Test nomlari xatti-harakatni emas, tartib raqamini aytadi.

(b) Tuzatilgan versiya (Playwright 1.64 da ishga tushirib tekshirilgan):

import { test, expect } from "@playwright/test";

test.describe("Savatcha", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/");
    await page.getByTestId("username").fill("standard_user");
    await page.getByTestId("password").fill("secret_sauce");
    await page.getByTestId("login-button").click();
    await expect(page.getByTestId("title")).toHaveText("Products");
  });

  test("Backpack qo'shilganda savatcha belgisi 1 bo'ladi", async ({ page }) => {
    // Arrange: beforeEach'da login qilindi
    // Act
    await page.getByTestId("add-to-cart-sauce-labs-backpack").click();
    // Assert
    await expect(page.getByTestId("shopping-cart-badge")).toHaveText("1");
  });
});

Har test o'zi login qiladi (keyinroq QA 19 da buni storageState bilan tezlashtiramiz), sleep yo'q, locator'lar barqaror, assertion auto-retry qiladi.

</details>

Mashq 5: Piramidaga joylang

DemoBozor promo-kod funksiyasi uchun quyidagi tekshiruvlarni Unit / API / E2E qatlamlariga taqsimlang:

1. Promo-kod formati: 6–12 belgi, faqat A–Z va 0–9.
2. Muddati o'tgan promo-kod rad etiladi.
3. Yangi mijoz (10%) va promo-kod (15%) bir vaqtda — kattasi (15%) qo'llanadi.
4. Checkout ekranida promo-kod maydoniga kod kiritib, "Qo'llash" bosilganda chegirma qatori ko'rinadi.
5. Bitta foydalanuvchi bir promo-kodni ikkinchi marta ishlata olmaydi.
6. Promo-kod minimal summadan kam buyurtmaga qo'llanmaydi.

<details> <summary>💡 Javobni ko'rish</summary>

Natija: 1 ta E2E, qolganlari arzon va tez qatlamlarda — piramida shakli saqlandi.

</details>

Mashq 6: Framework qatlamlari

Har bir fayl qaysi papkaga tegishli? pages/, fixtures/, api/, schemas/, tests/ui/, tests/api/, ildiz (root), .github/workflows/.

1. CheckoutPage.ts
2. booking.ts (Zod schema)
3. playwright.yml
4. checkout.spec.ts
5. BookingClient.ts
6. test.ts (test.extend bilan page object'larni beradi)
7. playwright.config.ts
8. booking.spec.ts (API CRUD testlari)

<details> <summary>💡 Javobni ko'rish</summary>

</details>

11. O'zingizni tekshiring {#checklist}

• [ ] Avtotest nima ekanini va nima emasligini 1 daqiqada tushuntira olaman
• [ ] Test'ni avtomatlashtirish uchun 6 ta "ha" va 6 ta "yo'q" signalini bilaman
• [ ] M, A, S, I bilan qoplanish nuqtasi va ROI'ni hisoblay olaman
• [ ] 70/20/10 piramida g'oyasini va "muzqaymoq" anti-pattern'ini tushuntira olaman
• [ ] Playwright, Cypress va Selenium farqlarini faktlar bilan ayta olaman
• [ ] Framework qatlamlarini va bog'liqlik yo'nalishini bilaman
• [ ] Yolg'on yashil testni taniy olaman

Xulosa {#xulosa}

• Avtomatlashtirish — test qilishni tezlashtiruvchi vosita; nimani tekshirishni test dizayn hal qiladi, inson ishi (exploratory, UX) qoladi.
• Avtomatlashtirish uchun eng yaxshi nomzodlar: ko'p takrorlanadigan, yuqori riskli, barqaror va aniq natijali tekshiruvlar.
• ROI'ni his bilan emas, hisob bilan asoslang: S = M − A, n = I / S. Testlar qanchalik ko'p ishlasa, investitsiya shunchalik tez qaytadi.
• Piramida — byudjet: ko'p tekshiruv unit/API'da, UI'da faqat asosiy oqimlar (boshlang'ich taxmin 70/20/10).
• 2026-yilda web UI uchun asosiy tanlovlar: Playwright 1.64, Cypress 16, Selenium 4.50; bu kurs Playwright + TypeScript bilan boradi.
• Framework qatlamlari: test → page object → fixture/helper → API/data → config → runner/CI. Bog'liqlik yuqoridan pastga.
• Eng xavfli test — hech narsani tekshirmay o'tadigan test. Har yangi testni bir marta ataylab "sindirib" ko'ring.
• Keyingi dars: QA 17: QA uchun TypeScript — o'zgaruvchilar, funksiyalar, async/await, class'lar va npm

Manbalar {#manbalar}

1. Playwright — Installation (tizim talablari)
2. Playwright — Best Practices
3. Playwright — Isolation va Browser Contexts
4. Playwright — Supported languages
5. Playwright — GitHub releases
6. Google Testing Blog — Just Say No to More End-to-End Tests (Mike Wacker, 2015)
7. Google Testing Blog — Tests Too DRY? Make Them DAMP! (2019)
8. Martin Fowler — Test Pyramid
9. Ham Vocke — The Practical Test Pyramid
10. Cypress — Trade-offs
11. Cypress — Cross Browser Testing
12. [Cypress — Experiments (experimentalWebKitSupport)](https://docs.cypress.io/app/references/experiments)
13. Selenium — Selenium Manager
14. Grafana k6 — GitHub releases
15. Sauce Labs demo do'koni — saucedemo.com