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

Здравствуйте, Аноним, Вы писали:

А>есть большая кодовая база с очень плохой архитектурой (ее нет, одна лапша).
А>с горем пополам оно все почти отладилось. но есть такие баги, которые просто не получается воспроизвести. воспроизводятся только у клиентов.
А>списаться с клиентами не получается. что в таком случае обычно делают?

Немного непонятно, как это — баги у них воспроизводятся, а списаться с ними нельзя? Если связь односторонняя, выпустите версию с обильным (можно даже избыточным) логгированием, и попросите прислать логи.

А>какие практические советы есть по внедрению тестирования в такой проект?
Если тестирования вообще нет?
1. Нанять тестировщика уровнем не ниже Senior
2. Предоставить ему возможность решить проблемы

Ну или
1. Начать покрывать код тестами, в зависимости от риска, критические участки кода — модульными, критические сценарии — функциональными.
2. Продолжать по мере убывания рисков
3. Делать все это на конфигурациях, близких к клиентским, чтобы избежать эффекта "а у меня работает".

Здравствуйте, Аноним, Вы писали:

А>привет всем.
А>есть большая кодовая база с очень плохой архитектурой (ее нет, одна лапша).
А>с горем пополам оно все почти отладилось. но есть такие баги, которые просто не получается воспроизвести. воспроизводятся только у клиентов.
А>списаться с клиентами не получается. что в таком случае обычно делают?
А>какие практические советы есть по внедрению тестирования в такой проект?

Сделайте ведение лога, причем максимально подробного (если только это не будет
сильно в ущерб производительности). И к этому нужно прикрутить какую-нибудь
систему отправки логов пользователями. Применял такую тактику в одном
проекте — там, правда, кода было всего порядка двадцати тысяч строк, но
за несколько недель было обнаружено пять или шесть ну очень тонких ошибок,
которые при иных обстоятельствах дремали бы еще неизвестно сколько.

Здравствуйте, Аноним, Вы писали:

А>привет всем.
А>есть большая кодовая база с очень плохой архитектурой (ее нет, одна лапша).
А>с горем пополам оно все почти отладилось. но есть такие баги, которые просто не получается воспроизвести. воспроизводятся только у клиентов.
А>списаться с клиентами не получается. что в таком случае обычно делают?
А>какие практические советы есть по внедрению тестирования в такой проект?

В свое время мне очень помогла книга Working Effectively with Legacy code, там содержится много практических советов о том, как последовательно улучшить качество legacy-кода, как покрыть его тестами и т. д.:

On 29.06.2011 23:20, Аноним 973 wrote:

> с горем пополам оно все почти отладилось. но есть такие баги, которые просто не
> получается воспроизвести. воспроизводятся только у клиентов.
> списаться с клиентами не получается. что в таком случае обычно делают?

Плюют на баги.

Если баг невозможно воспроизвести -- это не баг, а глюк.
У бага должно быть repro.

Это не шутка, это серьёзно. Если проблема не воспроизводится, то
с ней ничего сделать нельзя. Она либо будет жить своей жизнью,
пока её не воспроизведут и исправят, либо будет исправлена сама
в ходе рефакторинга и исправления других багов.

Сходите на тренинг "Как искать и находить баги", много полезных вещей расскажут, которые потом можно применить на практике. Игры, упражнения, соревнования, и конечно – реальное тестирование, всё это будет в программе тренинга.

После него вы вернётесь на своё рабочее место “намагниченным” и “заряженным” на поиск багов. И они это почувствуют, не сомневайтесь

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Аноним, Вы писали:

А>>привет всем.
А>>есть большая кодовая база с очень плохой архитектурой (ее нет, одна лапша).
А>>с горем пополам оно все почти отладилось. но есть такие баги, которые просто не получается воспроизвести. воспроизводятся только у клиентов.
А>>списаться с клиентами не получается. что в таком случае обычно делают?
А>>какие практические советы есть по внедрению тестирования в такой проект?

O>Сделайте ведение лога, причем максимально подробного

триггеры вешали?

Здравствуйте, Аноним, Вы писали:

А>привет всем.
А>есть большая кодовая база с очень плохой архитектурой (ее нет, одна лапша).
А>с горем пополам оно все почти отладилось. но есть такие баги, которые просто не получается воспроизвести. воспроизводятся только у клиентов.
А>списаться с клиентами не получается. что в таком случае обычно делают?
А>какие практические советы есть по внедрению тестирования в такой проект?

Запускать отдельный процесс, который умеет класть приложение в Dump. На клиенте баг выявлять либо по assert-у, либо спец. действием пользователя, которому сказали по телефону. Дальше дамп памяти процесса отправляется разработчику по e-mail, открывается отладчиком и смотрится, что именно там навернулось.

Microsoft такой сбор дампов в глобальных масштабах делает, так что дорога проторенная.