Какие не чинил ошибки

Типы ошибок, с которыми я работал в качестве QA Engineer

На протяжении своей практики в тестировании, я столкнулся с множеством видов ошибок (дефектов или багов). Они варьируются от очевидных до сложных, требующих глубокого анализа. Вот основные категории и примеры.

1. Функциональные ошибки

Это нарушения основной бизнес-логики продукта.

• Пример: В финансовом приложении некорректный расчет комиссии при переводе средств.
• Сценарий: Ввод суммы 1000 руб., выбор комиссии 5%, ожидаемый результат — перевод 950 руб. и комиссия 50 руб. Если система показывает комиссию 60 руб., это функциональный дефект.

// Пример теста для проверки расчета
function testCommissionCalculation(amount, commissionRate) {
    const expectedCommission = amount * commissionRate;
    const actualCommission = calculateCommission(amount, commissionRate);
    assert.equal(actualCommission, expectedCommission, "Commission calculation is incorrect");
}

2. Ошибки интерфейса (UI/UX)

Дефекты связаны с внешним представлением и взаимодействием пользователя.

• Примеры: Несоответствие макету, неправильные цвета, текст перекрывает изображение, неработающие элементы управления.
• Сложный случай: Специфическая кроссбраузерная проблема: элемент dropdown работает в Chrome, но в Safari не открывается при клике.

/* Иногда проблема в CSS, например, неправильный z-index */
.dropdown-menu {
    position: absolute;
    z-index: 100; /* Может быть перекрыто элементом с z-index: 101 */
}

3. Ошибки производительности и нагрузки

Система не справляется с требуемым объемом данных или пользователей.

• Пример: При одновременном подключении 1000 пользователей к сервису чата время ответа превышает 5 секунд (при SLA 2 секунды).
• Инструменты: Использование JMeter или k6 для создания стресс-тестов.

# Пример запуска теста нагрузки с k6
k6 run --vus 1000 --duration 30s load_test.js

4. Ошибки безопасности

Уязвимости, позволяющие несанкционированный доступ или действия.

• Пример: SQL-инъекция в форме поиска: ввод ' OR '1'='1 мог возвращать все записи из базы данных.
• Другой пример: Отсутствие валидации входных данных, приводящее к XSS (Cross-Site Scripting).

-- Пример опасного запроса при инъекции
SELECT * FROM users WHERE username = '' OR '1'='1';

5. Ошибки интеграции и API

Проблемы взаимодействия между различными модулями или внешними системами.

• Пример: После обновления микросервиса "Платежи" API возвращает новый формат JSON, но клиентский сервис "История операций" ожидает старый формат, что вызывает ошибки отображения.
• Тестирование: Использование Postman или автоматизация с RestAssured.

// Пример теста API с RestAssured
given()
    .header("Content-Type", "application/json")
    .body(requestBody)
.when()
    .post("/api/v1/payments")
.then()
    .statusCode(200)
    .body("status", equalTo("success"));

6. Ошибки данных и состояния

Некорректное управление данными или состоянием системы.

• Пример: В многопоточной системе бронирования билетов два пользователя одновременно могли забронировать один и тот же последний билет (проблема race condition).
• Другой пример: Неправильная обработка null или пустых значений приводит к падению сервиса.

# Пример потенциальной проблемы с состоянием
def book_ticket(ticket_id):
    if tickets[ticket_id] == "available":
        # Задержка между проверкой и изменением состояния может создать race condition
        tickets[ticket_id] = "booked"

7. Ошибки конфигурации и среды

Дефекты, возникающие из-за различий в настройках среды.

• Пример: Приложение корректно работает на Windows с JDK 11, но на Linux с JDK 17 возникает исключение ClassNotFoundException из-за различий в модулях.
• Решение: Тщательное тестирование на всех поддерживаемых средах deployment.

8. Логические и косвенные ошибки

Дефекты, не проявляющиеся явно, но нарушающие логику.

• Пример: В системе отчетов данные фильтруются по дате "до 31 декабря", но включают записи с 1 января следующего года из-за ошибки в условии <= вместо <.

-- Ошибочное условие
SELECT * FROM sales WHERE sale_date <= '2023-12-31';
-- Правильное условие
SELECT * FROM sales WHERE sale_date < '2024-01-01';

Моя роль в обнаружении и анализе

Как QA Engineer, я не только обнаруживаю ошибки через ручное и автоматизированное тестирование, но и анализирую их:

• Определяю приоритет и severity (критичность).
• Формулирую четкие шаги воспроизведения и ожидаемый/актуальный результат.
• Предлагаю возможные корни проблемы (root cause analysis) для разработчиков.
• Использую методологии (например, FMEA для критичных систем) для профилактики.

Постоянное изучение новых типов ошибок в современных технологиях (например, в AI/ML моделях или IoT системах) позволяет мне оставаться эффективным специалистом и обеспечивать высокое качество выпускаемых продуктов.