Тестировщики в лучшем случае взаимодействуют скорее с функциональным уровнем требований и/или пользовательским. Однако в связи с тем, что протестировать можно все, мы вполне способны превентивно влиять на качество будущей документации, обращая внимание и на бизнесовый уровень
К сожалению, неполные требования часто приводят к отсутствию ожидаемого результата, наличие только лишь самих требований при тестировании — к отсутствию фактического. Ну и если формально проблем нет, а пользователь в который раз недоволен, то разве система идеальна с точки зрения обеспечения качества?
Теория (принципы, уровни и т.д.), тест-анализ и тест-дизайн (эквивалентное разбиение, граничные значения, таблица решений, состояния и переходы, комбинаторные техники), исследовательское тестирование (туры Уиттакера, чит-листы, SBTM и TBTM)
Языки: Python, Swift, SQL
UI (web): Selene, Playwright, могу написать свой враппер поверх Selenium WebDriver. Строю стабильные CSS- и XPath-селекторы, использую Page Object Model и её вариации (Element/Steps/Fluent Page Object)
API: REST API (OpenAPI/Swagger), gRPC (Protobuf), SOAP (WSDL/XSD), Requests, Pydantic, Postman
Mobile: Нативные автотесты с XCTest для iOS, кросс-платформенные с Appium (Screen Object Model, запуск на симуляторах и реальных устройствах)
MCP, Skills, Rules, AI-assisted coding (Claude, Codex), локальные модели с Ollama
Git, GitHub/GitLab, Git Flow, Conventional Commits, Commitizen, Pytest, Docker, Selenoid, Allure Reports, allure-notifications, GitLab CI/GitHub Actions/Jenkins, GNU/Linux (Debian 13)