Проводишь ли тестирование самостоятельно перед передачей задачи тестировщику?

Самостоятельное тестирование перед передачей задачи

Ответ: Да, обязательно

Передавать задачу тестировщику без собственного тестирования — это непрофессионально. Это элементарный уровень качества кода, который должен обеспечить разработчик перед тем, как сказать «готово».

Почему это важно

1. Экономия времени

Если я отправлю явно сломанный код тестировщику, то:

• Потратится время тестировщика на поиск очевидных ошибок
• Потом нужно вернуть код в разработку
• Потом тестировщик должен пересоздать и перепроверить то же самое

Лучше потратить 10 минут на самопроверку, чем растягивать process на часы.

2. Профессиональная репутация

Тестировщики запоминают разработчиков, которые:

• Проверяют свой код перед передачей → быстро проходит тестирование → спокойно
• Не проверяют и отправляют багованное → много замечаний → репутация падает

Хороший разработчик — это тот, кто берёт на себя часть ответственности за качество.

3. Быстрый feedback

Если я сам проверю код, я сразу найду проблему и смогу исправить её в текущем контексте. Код ещё горячий в памяти. Если передам багованным, потом вернусь к коду через день, забуду контекст.

Как я проверяю

Фиксированный чек-лист

Передав задачу, я всегда проверяю:

Функциональность:

• Основной сценарий работает
• Граничные случаи обработаны (пусто, null, 0)
• Ошибки обработаны (неверные данные, отсутствие доступа)
• Если есть расчёты — проверил формулу на бумаге

Интеграции (если есть):

• Внешние API вызывают корректно
• Обработаны таймауты и ошибки сети
• Логирование есть для отладки

Данные и регистры:

• Проверил что записи в регистры записываются правильно
• Если нужно переписать старые данные — проверил что правильно переписываются
• Посмотрел в БД что данные выглядят корректно

Производительность:

• Если запрос работает на 1000 записей, проверил что на 100к тоже нормально
• Нет N+1 проблем в циклах
• Индексы там где нужны

Стиль кода:

• Переменные названы понятно
• Нет дублирования кода (KISS и DRY)
• Комментарии есть для нетривиального кода
• Обработка ошибок правильная (нет двойного логирования)

Сценарии тестирования

Например, для документооборота я проверяю:

// Основной сценарий
1. Создал документ → Заполнил поля → Проверил видны ли данные
2. Отредактировал → Провел документ → Проверил регистры
3. Откатил проведение → Проверил что регистры очищены

// Граничные случаи
4. Создал без обязательных полей → должна быть ошибка
5. Попытался провести без инициатора → должна быть ошибка
6. Удалил документ → проверил что регистры очищены

// Особые случаи
7. Редактировал уже проведённый → проверил что перепроводится корректно
8. Одновременно два сеанса открыли документ → проверил блокировку

Инструменты

Логи и отладка:

// Временное логирование для самопроверки
ЗаписатьВЖурналРегистрации(
    "МояОперация",
    УровеньЖурналаРегистрации.Информация,
    , ,
    СтрШаблон("Создан документ: %1", Результат)
);

Отладчик:

• Ставлю точку останова на критичных местах
• Проверяю значения переменных
• Смотрю что вычисляется корректно

SQL запросы:

• Для сложных операций проверяю в СУБД что данные выглядят правильно

Когда оставляю на тестировщика

Есть вещи которые невозможно полностью проверить разработчику:

• Масштабируемость на реальном объёме данных (могу проверить на 10к, но в проде 1м)
• Интеграции с внешними системами, которые не всегда доступны в дев-окружении
• Регрессия в других частях системы, которые я не трогал
• User acceptance — удовлетворяет ли это требованиям бизнеса

Для этого и нужны тестировщики — чтобы проверить то, что разработчик не может.

Резюме

Мой процесс:

1. Написал код
2. Самостоятельно протестировал (30-45 мин на среднюю задачу)
3. Code review у коллеги если требуется
4. Передал тестировщику с уверенностью что основное работает

Это обеспечивает качество и скорость delivery, и показывает что разработчик берёт на себя ответственность за то что он делает.