Как проверяешь свою работу на наличие ошибок

Проверка собственной работы на ошибки — это многоуровневый процесс, который сочетает ручные и автоматизированные методы. Я подхожу к нему системно: сначала проверяю логику и соответствие требованиям, затем тестирую граничные случаи и, наконец, фиксирую все найденные проблемы в трекере. Такой подход позволяет минимизировать риск пропустить ошибку и повышает качество результата.

Основные методы проверки

1. Парное тестирование — обсуждение логики с коллегой или заказчиком. Это помогает выявить неочевидные кейсы и взглянуть на задачу со стороны. Например, при написании SQL-запроса я могу спросить: "Что если статус заказа будет NULL?" — и проверить, как запрос это обработает.

2. Сверка с требованиями — прохожу по каждому пункту технического задания и сравниваю с реализацией. Отклонения фиксирую отдельно, чтобы понять, является ли это ошибкой или осознанным изменением.

3. Проверка граничных значений — тестирую крайние случаи: пустые данные, максимальные и минимальные значения, отсутствие данных. Например, для отчёта по продажам проверяю, как система ведёт себя при нулевом количестве заказов.

4. Автоматизированные проверки — использую скрипты для валидации данных или инструменты профилирования (например, SQL Profiler). Это позволяет быстро находить аномалии в больших объёмах данных.

5. Юзер-стори тестинг — прохожу весь путь пользователя от начала до конца, проверяя логику работы системы. Это помогает увидеть, как функция вписывается в общий сценарий и не ломает ли она другие процессы.

Как фиксировать ошибки

Все найденные ошибки я записываю в баг-трекер (например, Jira или Redmine) с обязательным описанием шагов воспроизведения. Это важно, потому что:

• Разработчик может быстро понять, в чём проблема.
• Ошибка не теряется и не забывается.
• Можно отследить, какие ошибки повторяются, и улучшить процесс.

Пример описания ошибки:

• Заголовок: Неверный расчёт суммы в отчёте при пустом списке товаров.
• Шаги: 1. Открыть отчёт. 2. Выбрать период без продаж. 3. Нажать "Сформировать".
• Ожидаемый результат: Сумма равна 0.
• Фактический результат: Отображается "NaN".

Подводные камни

• Слепое доверие автоматизации — скрипты проверяют только то, что в них заложено, поэтому они не заменяют ручную проверку логики.
• Игнорирование граничных случаев — часто ошибки возникают именно на крайних значениях, поэтому их проверка обязательна.
• Отсутствие сверки с требованиями — можно "улучшить" функционал, но это не соответствует ТЗ, что приводит к переделке.

Коротко

• Используй несколько методов: парное тестирование, сверку с ТЗ, граничные значения, автоматизацию и юзер-стори тестинг.
• Всегда фиксируй ошибки в трекере с шагами воспроизведения.
• Не полагайся только на автоматизацию — ручная проверка логики обязательна.
• Проверяй крайние случаи и соответствие требованиям, чтобы избежать скрытых проблем.