Testing
Accessibility bugs are cheap to fix when caught during development and expensive to fix in production. Automated accessibility testing with axe-core and Playwright catches a significant portion of WCAG violations without manual effort — and it fits neatly into any CI pipeline. This guide walks through everything from installation to
OWASP ZAP
OWASP ZAP (Zed Attack Proxy) is the most widely used open-source web application security scanner. It acts as a proxy between your browser and the target application, passively scanning traffic for vulnerabilities. It also has an active scanner that sends attack payloads to find SQL injection, XSS, CSRF, and
Testing
Automated accessibility testing gives you speed and consistency. Run it on every PR and you'll catch the class of violations that tools can reliably detect — missing labels, contrast failures, invalid ARIA — before they reach production. The key is understanding what each tool covers, how to integrate it into
Security Testing
Most security tools are designed to be run manually by security engineers during a dedicated audit phase. OWASP ZAP (Zed Attack Proxy) is different — it's designed to be automated. The ZAP team maintains official Docker images with CI-oriented scan modes, GitHub Actions integrations, and a configuration system
Testing
Most teams use axe-core with default settings: run it against a page, count violations, fail the build. That works until your design system produces dozens of false positives, or your app has accessibility requirements that no default rule covers. This guide covers the axe-core internals you need to
Testing
The OWASP Top 10 is the most referenced list in web application security. Published by the Open Web Application Security Project, it represents the ten most critical security risks based on data from thousands of real-world applications. This checklist gives you concrete tests for each category — not just definitions,
Security Testing
Security testing is not the exclusive domain of penetration testers. Developers who understand the OWASP Top 10 and can write test cases against each category catch vulnerabilities before they ever reach a staging environment — let alone production. This guide walks through each OWASP Top 10 item (2021 edition) with a
Testing
AWS SQS and SNS are foundational to event-driven architectures on AWS. Testing code that uses them requires a layered approach: fast unit tests with mocked clients, integration tests against LocalStack or a real AWS sandbox account, and end-to-end tests for Lambda triggers. Layer 1: Unit Testing with
Testing
AWS SQS and SNS are everywhere in serverless and microservice architectures. They're also surprisingly easy to test badly. This guide covers the three layers of SQS/SNS testing: unit tests with SDK mocks, integration tests with LocalStack, and end-to-end tests for complete async flows. The Three
QA
The "build vs buy" question for QA is one that every growing engineering team eventually faces. Hire a QA team internally, or outsource to an agency? The answer is rarely obvious because the tradeoffs are real on both sides — and the right choice depends on factors most comparison
AWS
AWS SAM (Serverless Application Model) gives you infrastructure-as-code for serverless applications, but testing SAM applications before deployment has historically been painful. The sam local toolchain has matured significantly — this guide covers how to use it effectively for unit tests, local integration tests, and pre-deploy validation. Why SAM
Testing
OpenTelemetry semantic conventions define standard names and attributes for common operations — HTTP requests, database calls, messaging systems, and more. When your instrumentation follows them, your observability data works correctly with standard dashboards, automatic anomaly detection, and cross-service correlation. When you deviate from semantic conventions — even slightly — things break in