допустим есть конфа или программа, вы вносите изменения и как тестируете ее?
если конфа имеет много модулей, то все же не перепроверишь? а если это небольшое изменение, то проверять всю конфу?
вы сами это делаете? руками? программами?

(0) руками

у нас в компании - проги -прогят, тестирование итоговое за мной.(консультант)

(1) а если большая конфа?
(2) ты каждый раз всю конфу перетестировываешь?

(0) что за странные впоросы ...зачем тестировать всю конфу? Прог должен занть на что влияют его доработки

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

(5) + а небольшая доработка - не влечет за собой тестирование всей конфы, все предусмотреть все равно нереально, а основные моменты предусмотреть и протестировать нужно

(4) у меня случайно изменилось описание таблиц в скуле, изза чего данные не обновлялись. эта случайность не была в зоне изменений которые я делал, поэтому обнаружилось это уже потом по факту. поэтому и тема такая: как уберечься от случайностей, сбоев, невнимательности..

самое лучшее тестирование - дать тестить юзерам, особенно если больше сотни)

(8) + а если маленькая ошибка будет стоить, к примеру, остановки остановки большого производственного предприятия?

(8) + хорошая шутка

(3) Конфа большая, но спасает то, что она разбита на максимально независимые подсистемы.

(7) у меня случайно изменилось описание таблиц в скуле  - это как?

(12) просто есть файлик в котором описана структура. по ней я выгружаю данные в скуль и получаю их из скуля.

имена таблиц в скуле - непостоянны, после реструктуризации например может сменится

(5) Программист не может быть хорошим тестировщиком. Психологически.
Цели разные.

(15) +1000.
Программист не может и не должен быть хорошим тестировщиком.
Он не сможет подойти к процессу объективно, т.к. знает как должен работать допиленный блок, а представить как по факту с ним будет обращаться конечный пользователь не может.
Поэтому часто возникает ситуация, когда у прога - все работает, а у пользователя - нет, т.к. прог все правильно делает при проверке, а пользователь может чесать ухо пяткой.

У меня разброд и шатание. Но руководству это нравится.
Жаль когда перестанет нравиться, уже будет сложно что-то исправить.
Обновления релизов - тестируют пользователи. Под акты.
Доработки тестируют заказчики.
аналитики не могут в силу отсутствия ресурсов. Им бы с поддежркой справиться.
По хорошему тестирование должно занимать не меньше времени чем программирование. И это при хорошей документации разработки.
Дорого это.
Даже 1С и мелкософт выпускают продукты с ошибками.
Да и одно из правил хорошего программирования гласит - "программа без ошибок никому не нужна" (своими словами).

(3) ну вообще у нас доработки конфы одной. сделали доработку -тестирую, обучаю. зачем каждый раз то всю конфу?!

о каких тестированиях Вы интересуетесь ?

wiki:%D2%E5%F1%F2%E8%F0%EE%E2%E0%ED%E8%E5_%EF%F0%EE%E3%F0%E0%EC%EC%ED%EE%E3%EE_%EE%E1%E5%F1%EF%E5%F7%E5%ED%E8%FF

(0) на инфостартовской конференции будет Артур выступать по тестированию, не знаю как оно в жизни возможно применение, но думаю интересно будет послушать.

+(20)
артур поднял знамя fez

(21) ну я еще маленьким был, когда fez поднимал знамя TDD