QA 29: Amaliyot — Capstone loyiha va 30 ta topshiriq (Zero to Hero Challenge)

🧪 QA Engineer — Zero to Hero

QA 29: Amaliyot — Capstone loyiha va 30 ta topshiriq (Zero to Hero Challenge)

Holat: 2026-yil oktabr. Kursning yakuniy amaliy darsi: real amaliyot ilovasi (Toolshop) ustida 3 haftalik capstone loyiha va butun kursni qamraydigan 30 ta topshiriq. Kod yechimlari Playwright 1.64 (Chromium), Zod 4.6 va @axe-core/playwright 4.13 bilan, SQL yechimlari SQLite 3.51 da, Postman kolleksiyasi Newman 6.2 bilan ishga tushirib tekshirilgan; API misollari restful-booker va Toolshop'ning 2026-yil oktabrdagi haqiqiy javoblariga asoslangan.

Bu darsdan keyin siz: ishga topshirishda ko'rsatadigan to'liq QA portfolio'ga va 1–28-darslardagi har bir ko'nikmani amalda sinab ko'rgan tajribaga ega bo'lasiz.

• real ilova uchun strategiyadan CI'gacha bo'lgan butun QA siklini o'zingiz bajarasiz;
• 30 ta topshiriq orqali test dizayn, hujjatlar, API, SQL, mobil, avtomatlashtirish va "hero" ko'nikmalarini mustahkamlaysiz;
• har bir yechimni tekshirilgan namuna bilan solishtirib, o'z xatolaringizni topasiz.

Mundarija

1. Bu dars qanday ishlaydi
2. Capstone loyiha: Toolshop'ni to'liq QA qilish
3. Topshiriqlar xaritasi
4. Test dizayn: 1–8
5. Hujjatlar va bug'lar: 9–13
6. Web, API va SQL: 14–19
7. Mobil va Proxyman: 20–22
8. Avtomatlashtirish: 23–27
9. Hero darajasi: 28–30
10. Zero → Hero: bosib o'tgan yo'lingiz
11. Xulosa
12. Manbalar

1. Bu dars qanday ishlaydi {#qanday}

Dars ikki qismdan iborat:

1. Capstone loyiha — 2–3 haftalik katta ish, natijasi GitHub'dagi portfolio (QA 28'da nega muhimligini ko'rdik);
2. 30 ta topshiriq — har biri 15 daqiqadan 2 soatgacha; capstone'dan oldin "isinish" yoki keyin takrorlash uchun.

Qoidalar:

• Avval o'zingiz yeching, keyin yechimni oching. Yechim — to'g'ri variantlardan biri, yagona to'g'ri javob emas.
• Kod yechimlari biz tekshirgan muhitda ishlaydi: Node.js 24, @playwright/test 1.64.0 (Chromium), zod 4.6.5, @axe-core/playwright 4.13.0, newman 6.2.3, SQLite 3.51. Boshqa versiyada kichik farqlar bo'lishi mumkin.
• Amaliyot saytlari — umumiy ommaviy resurs. Ularga yuklama (load) testi, xavfsizlik skanerlari yoki yuzlab akkaunt yaratish bilan zarar yetkazmang.
• DemoBozor — kursdagi xayoliy mahsulot; uning qoidalari (QA 5 va boshqa darslarda) topshiriqlarda ham amal qiladi.

2. Capstone loyiha: Toolshop'ni to'liq QA qilish {#capstone}

Capstone: Toolshop'ni 3 haftada to'liq QA qilish — haftalar va natijalar

2.1. Nega aynan Toolshop

Practice Software Testing — "Toolshop" — testlashni o'rganish uchun maxsus yaratilgan ochiq loyiha: Angular'da yozilgan do'kon interfeysi, Laravel'dagi REST API va Swagger hujjati. Eng qimmatli tomoni — ataylab bug'lar qo'shilgan versiyasi bor: haqiqiy bug hunting mashqi uchun ideal.

Demo akkauntlar (loyiha README'sidan; customer va admin login'lari API orqali 2026-yil oktabrda tekshirildi):

Nimalarni testlash mumkin: katalog (kategoriyalar, brendlar, eco-friendly filtri, saralash, qidiruv), mahsulot sahifasi, savatcha, checkout, kirish/ro'yxatdan o'tish/parolni tiklash, shaxsiy kabinet, aloqa formasi, ijara (rentals) bo'limi; v5'da 7 tilga o'tish (DE, EL, EN, ES, FR, NL, TR).

Texnik faktlar (2026-yil oktabrda tekshirilgan):

• UI elementlarida data-test atributlari bor (email, password, login-submit, search-query, sort, product-name, product-price ...) → Playwright'da testIdAttribute: 'data-test';
• v5 oddiy yo'llardan foydalanadi (/auth/login, /category/hand-tools), bug'li versiya esa hash yo'llardan (/#/auth/login);
• POST /users/login → { "access_token": "..." }; GET /products?page=1 → sahifalangan javob (current_page, data, per_page, total, last_page).

💡 Maslahat: Soddaroq yo'l kerak bo'lsa — capstone'ni saucedemo + restful-booker juftligida bajaring. QA 18–QA 21dagi kod deyarli o'zgarishsiz ishlaydi. Lekin Toolshop real mahsulotga yaqinroq va bug'li versiyasi bug report'lar uchun haqiqiy material beradi.

2.2. Deliverable'lar va ball taqsimoti

2.3. Repo tuzilmasi

toolshop-qa-portfolio/
├── README.md
├── .env.example               # BASE_URL, API_BASE_URL, TOOLSHOP_EMAIL, TOOLSHOP_PASSWORD
├── docs/
│   ├── test-strategy.md
│   ├── risk-matrix.md
│   ├── checklist.md
│   ├── test-cases.csv
│   ├── exploratory-sessions.md
│   └── bugs/                  # BUG-001.md ... BUG-010.md + skrinshotlar
├── postman/                   # yoki bruno/
├── pages/                     # LoginPage.ts, CatalogPage.ts, ProductPage.ts, CartPage.ts
├── fixtures/test.ts
├── schemas/product.ts         # Zod sxemalari
├── tests/
│   ├── ui/
│   ├── api/
│   ├── a11y/
│   └── visual/
├── playwright.config.ts
├── package.json
└── .github/workflows/playwright.yml

2.4. Boshlang'ich kod (tekshirilgan)

playwright.config.ts:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  fullyParallel: true,
  retries: process.env.CI ? 1 : 0,
  reporter: [["list"], ["html", { open: "never" }]],
  use: {
    baseURL: process.env.BASE_URL ?? "https://practicesoftwaretesting.com",
    testIdAttribute: "data-test",
    trace: "on-first-retry",
  },
  projects: [{ name: "chromium", use: { ...devices["Desktop Chrome"] } }],
});

Birinchi UI testi — tests/ui/login.spec.ts:

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

test('customer tizimga kiradi va "My account" sahifasini ko\'radi @smoke', async ({ page }) => {
  await page.goto("/auth/login");
  await page
    .getByTestId("email")
    .fill(process.env.TOOLSHOP_EMAIL ?? "customer@practicesoftwaretesting.com");
  await page.getByTestId("password").fill(process.env.TOOLSHOP_PASSWORD ?? "welcome01");
  await page.getByTestId("login-submit").click();

  await expect(page).toHaveURL(/\/account$/);
  await expect(page.getByTestId("page-title")).toHaveText("My account");
});

Birinchi API testlari — tests/api/products.spec.ts:

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

test.use({
  baseURL: process.env.API_BASE_URL ?? "https://api.practicesoftwaretesting.com",
});

const ProductPage = z.object({
  current_page: z.number(),
  per_page: z.number(),
  total: z.number(),
  last_page: z.number(),
  data: z.array(
    z.object({
      id: z.string(),
      name: z.string(),
      price: z.number(),
      in_stock: z.boolean(),
    }),
  ),
});

test("API: login token qaytaradi", async ({ request }) => {
  const res = await request.post("/users/login", {
    data: {
      email: process.env.TOOLSHOP_EMAIL ?? "customer@practicesoftwaretesting.com",
      password: process.env.TOOLSHOP_PASSWORD ?? "welcome01",
    },
  });
  expect(res.status()).toBe(200);
  const body = await res.json();
  expect(typeof body.access_token).toBe("string");
});

test("API: mahsulotlar sahifalanadi va sxemaga mos", async ({ request }) => {
  const res = await request.get("/products?page=1");
  expect(res.ok()).toBeTruthy();
  const page1 = ProductPage.parse(await res.json());
  expect(page1.data.length).toBeLessThanOrEqual(page1.per_page);
  expect(page1.last_page).toBe(Math.ceil(page1.total / page1.per_page));
});

Bu uchta test 2026-yil oktabrda Chromium'da o'tdi. Login ma'lumotlari koddan emas, muhit o'zgaruvchilaridan olinadi (TOOLSHOP_EMAIL, TOOLSHOP_PASSWORD, BASE_URL, API_BASE_URL); fallback qiymatlar faqat ommaviy demo akkaunt uchun. .env faylini o'qish uchun QA 19dagi kabi dotenv ulang va o'zgaruvchilarni prefiks bilan nomlang (USERNAME kabi tizim nomlaridan qoching). Shu yerdan boshlab QA 19'dagi kabi POM va fixture'larga o'ting.

💡 Maslahat: Network mocking uchun tayyor g'oya: QA 19da mahsulotlar API'si 500 qaytarganda Toolshop interfeysi foydalanuvchiga hech qanday xato xabarini ko'rsatmasligi aniqlangan. Shu holat uchun page.route testi va bug report — capstone'ga kuchli qo'shimcha.

API qismi uchun tayyor g'oyalar (2026-yil 9-oktabrda curl bilan tekshirilgan):

2.5. 3 haftalik reja

2.6. Baholash rubrikasi

⚠️ Diqqat: Toolshop — ko'pchilik o'quvchilar foydalanadigan ommaviy sayt. Ro'yxatdan o'tishni testlasangiz, o'rtacha miqdorda va unikal emaillar bilan qiling; yuklama testi va xavfsizlik skanerlarini ishga tushirmang. Bug'li versiyada topilgan bug'larni portfolio'ingizda hujjatlashtiring.

3. Topshiriqlar xaritasi {#mashqlar}

4. Test dizayn: 1–8 {#test-dizayn}

Topshiriq 01: SMS kod uchun Equivalence Partitioning (🟢) {#t01}

DemoBozor qoidasi: SMS kod — 6 raqam, 120 soniya amal qiladi, 3 marta noto'g'ri kiritilsa raqam 15 daqiqaga bloklanadi. Kod kiritish maydoni uchun ekvivalent bo'laklarni (valid va invalid) aniqlang va har biriga vakil qiymat hamda kutilgan natija yozing.

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

E'tibor bering:

• V2 — klassik tuzoq: kod son sifatida saqlansa, 012345 → 12345 bo'lib qoladi va to'g'ri kod rad etiladi;
• I6 va I7 — vaqt va holatga bog'liq bo'laklar; ularning chegaralarini (119/120/121 soniya; 2- va 3-xato) keyingi texnikalar — BVA va state transition bilan to'liq tekshiramiz.

</details>

Topshiriq 02: Savatcha soni uchun 2 va 3 qiymatli BVA (🟢) {#t02}

DemoBozor: savatchada bitta mahsulot soni 1–99 (butun son). Ekvivalent bo'laklarni yozing, keyin 2 qiymatli va 3 qiymatli BVA bo'yicha test qiymatlarini va kutilgan natijalarni chiqaring.

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

Bo'laklar: ≤ 0 (invalid) · 1–99 (valid) · ≥ 100 (invalid). Har bir chegarada ikkita chegaraviy qiymat bor — chap bo'lakning oxiri va o'ng bo'lakning boshi: 0 | 1 va 99 | 100.

• 2 qiymatli BVA (chegaraviy qiymat + qo'shni bo'lakdagi eng yaqin qiymat): 0, 1, 99, 100;
• 3 qiymatli BVA (har bir chegaraviy qiymat + ikkala qo'shnisi): 0 → {−1, 0, 1}, 1 → {0, 1, 2}, 99 → {98, 99, 100}, 100 → {99, 100, 101}. Birlashtirilganda: −1, 0, 1, 2, 98, 99, 100, 101.

⚠️ Diqqat: Ko'p manbalarda 3 qiymatli BVA faqat valid bo'lakning chegaralari atrofida olinadi ({0, 1, 2, 98, 99, 100}). Bu ISTQB ta'rifining keng tarqalgan noto'g'ri talqini: invalid bo'laklarning chegaraviy qiymatlari (0 va 100) ham chegaraviy qiymat hisoblanadi. Batafsil: QA 5.

Qo'shimcha: −1 va 100 ni API orqali ham yuboring (POST /api/v1/cart/items — xayoliy endpoint) — UI cheklovi server cheklovi emas.

</details>

Topshiriq 03: Bepul yetkazib berish chegarasi (🟢) {#t03}

Qoida: mahsulotlar summasi ≥ 300 000 so'm bo'lsa yetkazib berish bepul, aks holda 20 000 so'm. Premium a'zolar uchun har doim bepul. Chegaraviy test qiymatlarini yozing. Qaysi qiymat QA 2dagi > vs >= defektini ushlaydi? Qanday savollarni PO'ga berasiz?

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

Bo'laklar: < 300 000 (yetkazish pullik) va ≥ 300 000 (bepul); chegara 299 999 | 300 000.

• > vs >= defektini aynan 300 000 ushlaydi: noto'g'ri kodda 300 000 so'mlik buyurtmaga 20 000 qo'shiladi. Bu — QA 8dagi deliveryFee() bug'i (DB-210).
• Amaliy nuans: agar narxlar faqat mingga karrali bo'lsa, real qo'shnilar 299 000 va 301 000 bo'ladi. BVA'da qo'shni qiymat — ma'lumotning eng kichik qadami.

PO'ga savollar:

1. Chegirma qo'llanib, summa 300 000 dan pastga tushsa — yetkazish pullikmi? (Qoida "mahsulotlar summasi" deydi — chegirmadan oldingi summa, lekin tasdiqlatish kerak.)
2. Savatchadan mahsulot o'chirilib, summa chegaradan tushsa, narx darhol qayta hisoblanadimi?
3. Viloyatlar uchun ham shu qoidami?

</details>

Topshiriq 04: Chegirmalar decision table (🟡) {#t04}

DemoBozor qoidalari: yangi mijoz (birinchi buyurtma) — 10%; yaroqli BAHOR15 promo-kodi — 15% (minimal summa 200 000 so'm); chegirmalar qo'shilmaydi — kattasi qo'llanadi; Premium a'zo — har doim bepul yetkazib berish. Mahsulotlar summasi 250 000 so'm deb oling (promo minimalidan yuqori, bepul yetkazish chegarasidan past). To'liq decision table tuzing (chegirma, yetkazish, jami), keyin uni qisqartiring.

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

To'liq jadval (2³ = 8 qoida):

Qisqartirilgan jadval: promo-kod yaroqli bo'lsa, "yangi mijoz" sharti natijaga ta'sir qilmaydi (15% > 10%), shuning uchun R1+R5 va R2+R6 birlashadi:

8 o'rniga 6 ta test. Lekin ehtiyot bo'ling: qisqartirish haqiqiy foizlarga bog'liq. TEJA5 (5%) promo-kodi bilan yangi mijozning 10% i yutadi va R1/R5 natijalari farq qiladi — konfiguratsiyani tekshirib, kerak bo'lsa to'liq jadvalga qayting. Muddati o'tgan QISH10 yoki KUZ10 esa "promo-kod yaroqli = Yo'q" ustunlariga tushadi.

</details>

Topshiriq 05: Buyurtma holatlari — state transition (🟡) {#t05}

DemoBozor buyurtma holatlari: CREATED → PENDING_PAYMENT → PAID → PACKING → SHIPPED → DELIVERED; CANCELLED — CREATED, PENDING_PAYMENT, PAID (pul qaytariladi) va PACKING dan; RETURNED — DELIVERED dan 10 kun ichida; naqd to'lovda CREATED → PACKING.

1. Barcha ruxsat etilgan o'tishlarni sanang.
2. Barcha o'tishlarni qamraydigan minimal test yo'llarini (path) tuzing.
3. Kamida 5 ta ruxsat etilmagan o'tishni yozing.

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

1. Ruxsat etilgan o'tishlar — 11 ta (hodisa nomlari QA 6dagi state table bilan bir xil):

8 holat × 8 hodisa = 64 katak; shundan faqat 11 tasi ruxsat etilgan o'tish, qolgan 53 tasi — "ruxsat etilmagan" kataklar, ularning eng xavflilarini alohida testlaymiz.

2. Barcha 11 o'tishni qamraydigan 5 ta yo'l:

3. Ruxsat etilmagan o'tishlar (kutilgan natija: rad etiladi, holat o'zgarmaydi, tushunarli xabar):

• SHIPPED → CANCELLED
• DELIVERED → CANCELLED
• CANCELLED → PAID
• PENDING_PAYMENT → SHIPPED (bosqichdan sakrash)
• RETURNED → DELIVERED
• DELIVERED → RETURNED 11-kuni (guard sharti: chegarani BVA bilan — 10-kun ruxsat, 11-kun rad)

Ruxsat etilmagan o'tishlarni odatda API orqali testlash qulay — UI'da bunday tugma ko'rinmasligi mumkin, lekin server buni baribir tekshirishi shart.

</details>

Topshiriq 06: Pairwise — 54 kombinatsiyadan 9 ta test (🟡) {#t06}

Checkout'ni quyidagi parametrlar bilan testlash kerak:

• Brauzer: Chrome, Safari, Firefox
• Til: uz, ru, en
• To'lov: Uzcard, Humo, Naqd
• Qurilma: Desktop, Mobil

To'liq kombinatsiyalar soni nechta? Har bir juftlik kamida bir marta uchraydigan to'plam tuzing.

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

To'liq: 3 × 3 × 3 × 2 = 54 kombinatsiya. Pairwise to'plam — 9 ta test (uchta 3-qiymatli parametr juftligi uchun kamida 3 × 3 = 9 qator kerak):

Bu to'plam L9 ortogonal massiviga asoslangan; barcha juftliklar qamralgani skript bilan tekshirildi (yetishmayotgan juftlik — 0). Amalda bunday jadvalni qo'lda emas, Microsoft PICT kabi vosita bilan yarating va cheklovlarni (masalan, "Safari faqat Apple qurilmalarida") model faylida yozing — QA 6.

</details>

Topshiriq 07: Muddatli to'lov — EP + BVA kombinatsiyasi (🔴) {#t07}

Qoida: muddatli (foizsiz) to'lov — yosh 18–65 (shu jumladan), buyurtma summasi 500 000 – 30 000 000 so'm, muddat 3, 6 yoki 12 oy. Minimal, lekin kuchli test to'plamini tuzing. Nega bitta testda bir nechta noto'g'ri qiymatni birlashtirmaslik kerak?

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

Bu yerda 2 qiymatli BVA ishlatildi (17/18, 65/66, 499 999/500 000, 30 000 000/30 000 001). 3 qiymatli BVA har chegaraga yana qo'shni qiymatlarni qo'shadi — masalan, yosh uchun 16, 19, 64 va 67 (QA 5).

"Bir vaqtda bitta noto'g'ri qiymat" qoidasi: agar testda yosh ham, summa ham noto'g'ri bo'lsa va tizim rad etsa — qaysi tekshiruv ishlaganini bilmaysiz; bittasi buzilgan bo'lsa ham test "o'tadi" (defect masking).

Qo'shimcha nozik joylar:

• Yosh tug'ilgan sanadan hisoblanadi: bugun 18 yoshga to'lgan va ertaga 66 ga to'ladigan (bugun hali 65) mijozlar — ikkalasi ham ruxsat;
• "Bugun" qaysi vaqt zonasida? Asia/Tashkent (UTC+5) — server UTC'da ishlasa, tunda chegara siljishi mumkin;
• Summa chegarasi chegirmadan oldingi yoki keyingi summaga qo'llanadimi — talabni aniqlashtiring.

</details>

Topshiriq 08: Exploratory charter va sessiya hisoboti (🟡) {#t08}

DemoBozor checkout'idagi promo-kod maydoni uchun 60 daqiqalik exploratory sessiya rejalang: charter yozing va kamida 10 ta g'oya ro'yxatini tuzing. Sessiya hisoboti qanday ko'rinishda bo'lishi kerak?

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

Charter: Promo-kod maydonini checkout'da (Web, Chrome) turli formatdagi va holatdagi kodlar, ikki brauzer tab'i va sekin tarmoq bilan tekshirib, chegirma hisobidagi va qayta ishlatishdagi xatolarni topish.

G'oyalar:

1. Kichik harflar: bahor15 (qoida: faqat katta harf — avtomatik o'zgartiriladimi yoki rad etiladimi?);
2. Boshida/oxirida probel: " BAHOR15 ";
3. Uzunlik chegaralari: 5, 6, 12, 13 belgi;
4. Kirill harflari lotinga o'xshash: ВАНОR15 (В, А, Н, О — kirill) — ko'zga bir xil, lekin boshqa kod; eng "makkor" holatlardan biri;
5. Muddati o'tgan kodlar (QISH10, KUZ10) va kelajakda boshlanadigan kod;
6. BAHOR15ning minimal summasi chegarasida (200 000) va undan 1 so'm kam (199 999);
7. Promo-kod + yangi mijoz chegirmasi birga: TEJA5 (5%) bilan yangi mijozning 10% i qo'llanishi kerak;
8. Kod qo'llangandan keyin mahsulot o'chirilib, summa minimaldan tushsa — chegirma olib tashlanadimi?;
9. Ikki tab'da bir vaqtda bitta kodni ishlatish (race condition);
10. Sekin tarmoqda "Qo'llash" tugmasini ikki marta bosish;
11. Kod qo'llanib, sahifa yangilansa yoki "orqaga" qaytilsa;
12. Bir marta ishlatilgan kodni boshqa buyurtmada qayta ishlatish.

Sessiya hisoboti tuzilmasi (session-based test management uslubida):

</details>

5. Hujjatlar va bug'lar: 9–13 {#hujjatlar}

Topshiriq 09: OTP login uchun 5 ta test case (🟢) {#t09}

DemoBozor mobil ilovasida telefon raqami va SMS kod bilan kirish uchun 5 ta test case yozing (ID, sarlavha, oldingi shartlar, qadamlar, test ma'lumotlari, kutilgan natija, ustuvorlik).

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

Test ma'lumotlari va muhit (staging, test raqamlari) test case'ning o'zida yoki test suite darajasida ko'rsatiladi. TC-005'dagi "yangi kod eskisini bekor qiladi" — talabda yo'q bo'lsa, PO'dan tasdiqlatiladigan taxmin.

</details>

Topshiriq 10: Yomon test case'ni tuzatish (🟢) {#t10}

Quyidagi test case'ning kamchiliklarini toping va uni qayta yozing:

TC1: Login'ni tekshirish
Qadamlar: Ilovaga kiring va hamma narsani tekshiring.
Kutilgan natija: Hammasi ishlaydi.

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

Kamchiliklar: sarlavha nimani tekshirishini aytmaydi; bitta case'da "hamma narsa" (atomar emas); oldingi shartlar va test ma'lumotlari yo'q; qadamlar takrorlanmaydi; kutilgan natija o'lchab bo'lmaydigan ("ishlaydi"); talabga bog'lanmagan; ustuvorlik yo'q.

Qayta yozilgani (bir nechta case'ga bo'linadi; bittasi namuna):

</details>

Topshiriq 11: Toolshop'dagi real bug uchun bug report (🟡) {#t11}

https://with-bugs.practicesoftwaretesting.com ni oching. Saralash ro'yxatidan "Price (High - Low)" ni tanlang va natijani kuzating. Bu xatti-harakat uchun to'liq bug report yozing.

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

Biz 2026-yil oktabrda kuzatgan natija: saralashdan keyin narxlar o'sish tartibida chiqdi ($4.92, $9.17, $11.14, $11.48, ...). Normal v5 build'da xuddi shu variant narxlarni kamayish tartibida ko'rsatadi ($89.55, $86.71, $80.19, ...).

ID: BUG-003
Sarlavha: [Katalog] "Price (High - Low)" saralash mahsulotlarni narx o'sishi bo'yicha ko'rsatadi

Muhit: https://with-bugs.practicesoftwaretesting.com (Toolshop v5.0 with bugs)
       Chrome for Testing 156 (Playwright 1.64), macOS; mehmon foydalanuvchi
Oldingi shartlar: yo'q

Qayta hosil qilish qadamlari:
1. Bosh sahifani oching.
2. "Sort" ro'yxatidan "Price (High - Low)" ni tanlang.
3. Birinchi qatordagi mahsulot narxlarini kuzating.

Kutilgan natija: mahsulotlar narx kamayishi bo'yicha (eng qimmati birinchi).
Haqiqiy natija:  mahsulotlar narx o'sishi bo'yicha ($4.92, $9.17, $11.14, $11.48, ...).

Takrorlanishi: 3/3
Severity: Major (funksiya teskari ishlaydi; workaround: "Low - High" ni tanlash)
Priority: P2
Komponent: Catalog / Sorting
Ilovalar: skrinshot (sort-high-low.png)

Qo'shimcha ma'lumot: DevTools'da "Price (High - Low)" option'ining qiymati "price,asc".
Label va qiymat almashib qolgan bo'lishi mumkin. Boshqa variantlar ("Name (A - Z)" — qiymati
"name,desc") alohida tekshirilib, alohida report qilinadi.

Nega bunday yozildi: sarlavha qayerda + nima formulasida (QA 8); bitta report — bitta bug; haqiqiy natijada aniq qiymatlar; ildiz sababi haqida taxmin "Qo'shimcha" bo'limida, faktlardan ajratilgan. Bu build'da boshqa bug'lar ham bor — ularni capstone uchun o'zingiz topasiz.

</details>

Topshiriq 12: 8 ta bug — severity va priority (🟡) {#t12}

Har bir DemoBozor bug'iga severity (Blocker/Critical/Major/Minor/Trivial) va priority (P0–P3) bering, qisqa asoslang:

1. Android 14'da "To'lash" tugmasi bosilganda ilova yopilib qoladi (barcha foydalanuvchilar).
2. Bosh sahifadagi logotip ostida "DemoBozr" deb yozilgan.
3. Admin panelidagi oylik PDF hisobot eksporti crash bo'ladi (oyiga 2 marta ishlatiladi, CSV eksport ishlaydi).
4. Aynan 300 000 so'mlik buyurtmaga yetkazish haqi olinadi.
5. Sharh matni 1000 belgidan uzun bo'lsa server 500 qaytaradi (UI 1000 dan ortiq yozdirmaydi, faqat API orqali mumkin).
6. Dark mode'da "Savatcha" tugmasi kontrasti juda past.
7. Bitta promo-kodni ikki tab'da bir vaqtda ikki marta ishlatish mumkin.
8. Rus tilida savatcha sahifasi sarlavhasi "Cart" bo'lib qolgan.

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

±1 daraja farq normal — muhimi asoslash. Esda tuting: severity — texnik ta'sir, priority — biznes shoshilinchligi; ularni triage'da PO bilan birga yakunlaysiz.

</details>

Topshiriq 13: Mini RTM va qamrov (🟡) {#t13}

Talablar va test case'lar:

• REQ-01: SMS kod 6 raqam, 120 soniya amal qiladi → TC-AUTH-001, TC-AUTH-003
• REQ-02: 300 000 so'mdan yetkazish bepul → TC-DLV-001, TC-DLV-002
• REQ-03: Promo-kod har foydalanuvchiga bir marta → TC-PRM-004
• REQ-04: Savatchada soni 1–99 → TC-CRT-001 ... TC-CRT-006
• REQ-05: Sharhni faqat DELIVERED buyurtma egasi yozadi → (yo'q)

Oxirgi run: TC-DLV-002 — Failed (BUG-012), TC-PRM-004 — Blocked (staging'da promo-kodlar yo'q), qolganlari — Passed. RTM tuzing, talablar qamrovini hisoblang va xulosa yozing.

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

• Talablar qamrovi (kamida 1 testi bor): 4 / 5 = 80%;
• To'liq tasdiqlangan talablar: 2 / 5 (REQ-01, REQ-04).

Xulosa va harakatlar: REQ-05 uchun test case'lar yozish (DELIVERED egasi — ruxsat; boshqa holatdagi buyurtma egasi va begona foydalanuvchi — rad, API orqali ham); REQ-03 uchun staging'ga test promo-kodlari qo'shilishi kerak (bloklovchi muammoni DevOps/PO'ga ko'tarish); BUG-012 tuzatilgach TC-DLV-002 ni qayta testlash va regressiya.

</details>

6. Web, API va SQL: 14–19 {#web-api-sql}

Topshiriq 14: DevTools — bug kimniki? (🟢) {#t14}

Har bir holat uchun bug front-end'dami yoki back-end'dami aniqlang va bug report'ga nimani biriktirishni ayting:

1. Katalog bo'sh ko'rinadi. Network: GET /api/v1/products → 200, javobda 24 ta mahsulot. Console'da TypeError: Cannot read properties of undefined (reading 'map').
2. "Buyurtma berish" bosilganda xato oynasi. Network: POST /api/v1/orders → 500, javobda stack trace va SQL so'rovi ko'rinadi.
3. Narx API'da 250000, UI'da "25 000 so'm".
4. "Saqlash" tugmasi bosilganda hech narsa bo'lmaydi; Network'da so'rov yo'q; Console toza.

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

4-holatda jim ishlamaslik — UX bug'i ham: foydalanuvchi hech qanday xabar ko'rmaydi.

</details>

Topshiriq 15: curl bilan booking yaratish va o'qish (🟢) {#t15}

restful-booker'da curl bilan yangi booking yarating, uni ID bo'yicha o'qing va status kodlarini ko'rsating.

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

# 1) Booking yaratish
curl -s -w "\nHTTP %{http_code}\n" -X POST https://restful-booker.herokuapp.com/booking \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"firstname":"Aziz","lastname":"Karimov","totalprice":250,"depositpaid":true,"bookingdates":{"checkin":"2026-11-01","checkout":"2026-11-05"},"additionalneeds":"Breakfast"}'

# 2) Javobdagi bookingid ni qo'yib o'qish (masalan, 2142)
curl -s -w "\nHTTP %{http_code}\n" https://restful-booker.herokuapp.com/booking/2142 \
  -H "Accept: application/json"

2026-yil oktabrdagi haqiqiy javob (ID har safar boshqacha):

{
  "bookingid": 2142,
  "booking": {
    "firstname": "Aziz",
    "lastname": "Karimov",
    "totalprice": 250,
    "depositpaid": true,
    "bookingdates": { "checkin": "2026-11-01", "checkout": "2026-11-05" },
    "additionalneeds": "Breakfast"
  }
}

E'tibor bering: yaratish **200 OK** qaytaradi. REST konvensiyasida yangi resurs uchun odatda 201 Created kutiladi — bu farqni ham kuzatuv sifatida qayd qiling. GET esa 200 va booking obyektini qaytaradi.

</details>

Topshiriq 16: API negative va authZ testlari (🟡) {#t16}

restful-booker uchun kamida 6 ta negative/avtorizatsiya testini rejalashtiring, har biri uchun REST nuqtai nazaridan kutilgan natijani yozing. Keyin ularni curl bilan bajarib, haqiqiy natijani solishtiring. DemoBozor'da IDOR (BOLA) testini qanday qilgan bo'lardingiz?

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

2026-yil 9-oktabrda bajarilgan natijalar:

Negative so'rov namunasi (3-qator):

curl -s -w "\nHTTP %{http_code}\n" -X POST https://restful-booker.herokuapp.com/booking \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -d '{"firstname":"Aziz"}'

IDOR / BOLA — restful-booker'da bitta admin bor, shuning uchun "begona resurs" testini qilib bo'lmaydi. DemoBozor'da (xayoliy API) ikkita xaridor akkaunti kerak:

1. A foydalanuvchi o'z buyurtmasini oladi: GET /api/v1/orders/1001 (A token) → 200;
2. A foydalanuvchi B'ning buyurtmasini so'raydi: GET /api/v1/orders/1002 (A token) → **403 yoki 404** kutiladi; 200 va B'ning ma'lumoti — kritik xavfsizlik bug'i;
3. Xuddi shuni POST /api/v1/orders/1002/cancel uchun ham — o'qish himoyalangan, lekin o'zgartirish himoyalanmagan holatlar uchraydi.

Batafsil: QA 11, QA 24. Faqat o'z test muhitingizda!

</details>

Topshiriq 17: Postman — token chaining (🟡) {#t17}

Postman kolleksiyasi yarating: (1) POST /auth → token'ni o'zgaruvchiga saqlash; (2) POST /booking → bookingIdni saqlash; (3) token bilan DELETE; (4) o'chirilgan booking GET → 404. Har so'rovga Post-response testlari yozing va kolleksiyani Newman bilan ishga tushiring.

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

Kolleksiya o'zgaruvchilari: baseUrl = https://restful-booker.herokuapp.com, token, bookingId.

1. Auth — Post-response (Tests) skripti:

pm.test("Status 200", () => pm.response.to.have.status(200));
const body = pm.response.json();
pm.test("Token bor va bo'sh emas", () => {
  pm.expect(body.token).to.be.a("string").and.not.empty;
});
pm.collectionVariables.set("token", body.token);

2. Booking yaratish (POST {{baseUrl}}/booking, Accept: application/json):

pm.test("Status 200", () => pm.response.to.have.status(200));
const body = pm.response.json();
pm.test("bookingid son", () => pm.expect(body.bookingid).to.be.a("number"));
pm.test("Ism saqlangan", () =>
  pm.expect(body.booking.firstname).to.eql("Aziz"),
);
pm.test("Javob 2 soniyadan tez", () =>
  pm.expect(pm.response.responseTime).to.be.below(2000),
);
pm.collectionVariables.set("bookingId", body.bookingid);

3. O'chirish (DELETE {{baseUrl}}/booking/{{bookingId}}, header Cookie: token={{token}}):

pm.test("Status 201 (restful-booker quirk)", () =>
  pm.response.to.have.status(201),
);

4. Tekshirish (GET {{baseUrl}}/booking/{{bookingId}}):

pm.test("Status 404", () => pm.response.to.have.status(404));

Ishga tushirish (kolleksiyani eksport qilib):

npx newman run booker.postman_collection.json

Biz Newman 6.2.3 bilan ishga tushirdik: 4 ta so'rov, 8 ta assertion, 0 ta xato. Eslatma: Postman'ning Free tarifi 2026-yil martidan bitta foydalanuvchiga cheklangan — jamoaviy ish uchun Bruno yoki Hoppscotch'da xuddi shu mantiqni qurish mumkin (QA 10).

</details>

Topshiriq 18: SQL — buyurtmalar yaxlitligi (🟡) {#t18}

Quyidagi DemoBozor ma'lumotlarini SQLite'ga yuklang (sqlite3 capstone.db < capstone_seed.sql) va to'rtta so'rov yozing:

• (a) subtotal buyurtma qatorlari yig'indisiga (quantity × unit_price) teng bo'lmagan buyurtmalar;
• (b) total ≠ subtotal − discount + delivery_fee bo'lgan buyurtmalar;
• (c) yetkazish qoidasi buzilgan buyurtmalar (≥ 300 000 bo'lsa ham haq olingan yoki < 300 000 bo'lsa ham premium bo'lmagan mijozdan olinmagan);
• (d) mavjud bo'lmagan buyurtmaga bog'langan "yetim" order_items.

-- capstone_seed.sql
CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  phone TEXT UNIQUE NOT NULL,
  full_name TEXT NOT NULL,
  role TEXT CHECK (role IN ('buyer','seller','admin')) DEFAULT 'buyer',
  is_premium INTEGER DEFAULT 0,
  created_at TEXT
);
CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  category TEXT,
  price INTEGER NOT NULL,
  stock INTEGER NOT NULL,
  seller_id INTEGER REFERENCES users(id)
);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  status TEXT CHECK (status IN ('CREATED','PENDING_PAYMENT','PAID','PACKING','SHIPPED','DELIVERED','CANCELLED','RETURNED')),
  payment_method TEXT CHECK (payment_method IN ('UZCARD','HUMO','VISA','MASTERCARD','CASH')),
  promo_code TEXT,
  subtotal INTEGER,
  discount INTEGER,
  delivery_fee INTEGER,
  total INTEGER,
  created_at TEXT
);
CREATE TABLE order_items (
  id INTEGER PRIMARY KEY,
  order_id INTEGER REFERENCES orders(id),
  product_id INTEGER REFERENCES products(id),
  quantity INTEGER CHECK (quantity BETWEEN 1 AND 99),
  unit_price INTEGER
);
CREATE TABLE payments (
  id INTEGER PRIMARY KEY,
  order_id INTEGER REFERENCES orders(id),
  amount INTEGER,
  status TEXT CHECK (status IN ('SUCCESS','FAILED','REFUNDED')),
  provider TEXT,
  created_at TEXT
);

INSERT INTO users VALUES
  (1, '+998900000001', 'Aziz Karimov',     'buyer',  0, '2026-08-01 10:00:00'),
  (2, '+998900000002', 'Malika Rasulova',  'buyer',  1, '2026-08-03 12:30:00'),
  (3, '+998900000003', 'Jasur Toshmatov',  'seller', 0, '2026-07-15 09:00:00'),
  (4, '+998900000004', 'Dilnoza Yusupova', 'buyer',  0, '2026-08-20 18:45:00'),
  (5, '+998900000005', 'Admin',            'admin',  0, '2026-07-01 08:00:00');

INSERT INTO products VALUES
  (1, 'Elektr choynak',   'Maishiy texnika', 250000,  40, 3),
  (2, 'Paxta ko''ylak',   'Kiyim',           120000, 100, 3),
  (3, 'Simsiz quloqchin', 'Elektronika',     450000,  25, 3),
  (4, 'Gilam (2x3 m)',    'Uy',             1800000,   5, 3),
  (5, 'Telefon g''ilofi', 'Aksessuar',        45000, 200, 3);

INSERT INTO orders VALUES
  (101, 1, 'DELIVERED', 'UZCARD',     NULL,       295000,  29500, 20000,  285500, '2026-09-01 11:00:00'),
  (102, 2, 'DELIVERED', 'VISA',       NULL,       450000,      0,     0,  450000, '2026-09-02 15:20:00'),
  (103, 4, 'PAID',      'HUMO',       NULL,       240000,      0, 20000,  260000, '2026-09-05 09:10:00'),
  (104, 1, 'SHIPPED',   'UZCARD',     'BAHOR15', 1890000, 283500,     0, 1606500, '2026-09-07 19:00:00'),
  (105, 2, 'DELIVERED', 'MASTERCARD', NULL,       340000,      0,     0,  340000, '2026-09-08 13:40:00'),
  (106, 4, 'CANCELLED', 'VISA',       NULL,       250000,      0, 20000,  270000, '2026-09-10 10:05:00'),
  (107, 1, 'CREATED',   'CASH',       NULL,       450000,      0,     0,  405000, '2026-09-12 21:15:00'),
  (108, 4, 'DELIVERED', 'UZCARD',     NULL,       700000,      0, 20000,  720000, '2026-09-14 08:30:00'),
  (109, 1, 'DELIVERED', 'HUMO',       NULL,        90000,      0, 20000,  110000, '2026-09-15 17:50:00');

INSERT INTO order_items VALUES
  (1, 101, 1, 1, 250000),
  (2, 101, 5, 1,  45000),
  (3, 102, 3, 1, 450000),
  (4, 103, 2, 2, 120000),
  (5, 104, 4, 1, 1800000),
  (6, 104, 5, 2,  45000),