obsidian/wiki/testing/web-app-testing-guide.md
2026-04-29 12:43:08 +01:00

6 KiB
Raw Permalink Blame History

title aliases tags sources created updated
Web Application Testing — Comprehensive Guide
web-testing
webapp-testing
тестирование-веб-приложений
testing
qa
selenium
playwright
cypress
security
performance
tdd
bdd
raw/Подробное руководство по тестированию веб-приложений.md
2026-04-29 2026-04-29

Overview

Testing is not a "final check" — it's an integral part of development. Web apps differ from desktop apps: multi-layer architecture, network dependency, cross-browser/device matrix, and public internet exposure all demand systematic testing.


Types of Testing

Functional Testing

Area What to Check
User flows Registration, login, search, checkout, account management
Forms & input Validation, data types, bad input handling
Business logic Calculations, rules, exception handling
Integrations Payment APIs, partner APIs, analytics, delivery services

Performance Testing

Type Goal Business Value
Load Normal user count Daily usability
Stress Exceeding normal load Black Friday readiness
Volume Large data sets Scalability at growth
Stability Long-running without degradation 24/7 reliability

Security Testing

Key attack vectors to test per OWASP Top 10:

  • SQL Injection — malicious SQL via input fields → test all inputs with special chars/SQL commands
  • XSS (Cross-Site Scripting) — injected JS executing in browser → check all user-input reflection
  • CSRF — forced user actions → verify CSRF tokens and request origin validation
  • Man-in-the-Middle — traffic interception → verify HTTPS and certificate correctness
  • Auth/Authz weaknesses — session management, access control, privilege escalation

Also check: data encryption, PII handling, regulatory compliance (GDPR etc.)

UI Testing

  • Cross-browser — same behavior in Chrome, Firefox, Safari, Edge
  • Responsive — correct layout across screen sizes (mobile-first matters)
  • Usability — intuitive navigation, clear controls
  • Accessibility (a11y) — semantic HTML, screen reader support, keyboard navigation, color contrast, font scaling

Methodologies

Waterfall vs Agile

Approach When Testing Happens Best For
Waterfall End of dev cycle Stable, well-defined requirements
Agile/Iterative Every sprint Evolving requirements, fast feedback

TDD — Test-Driven Development

Cycle: Red → Green → Refactor

  1. Write a failing test
  2. Write minimal code to pass it
  3. Refactor without breaking tests

Benefits: better architecture, high coverage, confidence when changing code.

BDD — Behavior-Driven Development

Uses natural language: Given / When / Then

  • Bridges communication gap between devs, QA, and business
  • Tests become living documentation

Risk-Based Testing

When resources are limited, prioritize by probability × business impact:

  • High-risk areas → thorough coverage
  • Medium-risk → standard methods
  • Low-risk → sampling

Tools

UI Automation

Tool Strengths Weaknesses
Selenium Multi-language, multi-browser, mature ecosystem Complex setup, steep learning curve
Cypress Simple DX, great debugging Chrome-based only (mostly)
Playwright True cross-browser (Chrome/Firefox/Safari), modern API Newer, smaller ecosystem

API Testing

  • Postman — manual/exploratory API testing
  • REST Assured — Java-based API automation

Load Testing

  • JMeter — open source, widely used
  • k6 — modern, JS-based, CI-friendly
  • Artillery / Gatling — alternatives for smaller projects

Security Testing

  • OWASP ZAP — free, good for baseline scanning
  • Burp Suite — professional-grade, expert features

Test Management

  • TestRail, Xray, Azure DevOps — plan, track, report, link to requirements

Cloud Cross-Browser

  • BrowserStack, Sauce Labs — access hundreds of browser/device combos without owning hardware

Dynamic Content Testing

  • AJAX — use explicit waits, test loading states, test network error handling
  • WebSockets — test connection establishment, message types, graceful disconnect

Microservices Test Environment

  • Use Docker + Docker Compose for isolated per-service environments
  • Service mocking for unavailable dependencies
  • Contract testing to verify inter-service interfaces

Bug Report Template

A good bug report must include:

  1. Clear problem description
  2. Step-by-step reproduction
  3. Screenshot or video
  4. Environment (browser, OS, app version)
  5. Expected vs actual behavior
  6. User impact
  7. Labels/categories

Key Takeaways

  • Testing is part of development, not after it — early detection is 10× cheaper than late fixes
  • Web apps need functional + performance + security + UI testing as a minimum
  • OWASP Top 10 is the checklist for security testing
  • TDD → better architecture; BDD → better team communication
  • Tool choice depends on team expertise and project needs — Playwright is the modern default for UI automation
  • Cross-browser and mobile testing can be outsourced to BrowserStack/Sauce Labs cheaply
  • For microservices: Docker Compose + service mocking + contract testing
  • Risk-based testing helps when you can't test everything


Sources