Финал любого заказа на доработку 1С выглядит обманчиво просто: программист пишет «готово», вы открываете программу, видите новую кнопку или отчёт, киваете «вроде работает» и переводите оплату. А через две недели, на закрытии месяца, выясняется, что новый отчёт неправильно считает по складам, которых нет в основном офисе, и что эта ошибка тихо жила всё это время. Теперь и деньги уплачены, и работа сдана, и доказать что-то сложно. Знакомая ловушка беглой приёмки.
Приёмка — это не формальность в конце, а полноценный этап, от которого зависит, получите вы рабочее решение или мину замедленного действия. «Вроде работает» — не приёмка, это самообман. Настоящая приёмка проверяет не только то, что доработка делает обещанное, но и то, что она не сломала соседнее, выдерживает нестандартные случаи и не лишила базу способности обновляться. Разберём, что именно проверять, как тестировать без знания кода, как зафиксировать гарантию и что делать, если ошибка всё же вылезла после сдачи.
Эта статья — практическая в разделе про доработку 1С. Смежные темы: как составить ТЗ с критериями приёмки, как сохранить обновляемость, какую модель оплаты выбрать.
Что вы узнаете из статьи
- Почему «вроде работает» — это не приёмка
- Что именно проверять, включая нестандартные случаи
- Как тестировать доработку без знания программирования
- Как зафиксировать гарантию на код и что она покрывает
- Что делать, если ошибка вылезла после сдачи
Что проверять при приёмке
Основа приёмки — те самые проверяемые сценарии, которые вы заложили в задание. Если в техзадании были примеры «при таких данных должен получиться такой результат», приёмка сводится к их прогону: подставили исходные данные, сверили результат с ожидаемым. Совпало — принято, не совпало — на доработку, без споров о вкусах. Если же примеров в критериях приёмки техзадания не было, приёмка превращается в гадание, поэтому их и стоит закладывать заранее.
Но прогнать «счастливый путь» мало. Главные сюрпризы прячутся в нестандартных случаях: пустые поля, нулевые и крайние значения, нетипичные документы, операции по нескольким складам или валютам. Хороший приём — специально подсунуть доработке то, на чём она может споткнуться. Если отчёт корректно считает по обычному документу, но рассыпается на возврате или на документе без контрагента — лучше узнать об этом сейчас, на приёмке, а не на закрытии периода перед сдачей отчётности.
Третье, что обязательно проверить, — что доработка не сломала соседний функционал и не лишила базу обновляемости. Бывает, что новая функция работает, но рядом что-то перестало. И отдельно убедитесь, что обновляемость сохранена: сделана ли доработка через расширение или влезли в типовой код. Это не косметический вопрос — от него зависит стоимость всех будущих обновлений, и узнавать ответ лучше до оплаты, а не через год.
Как тестировать без знания кода
Главная хорошая новость для заказчика: чтобы принять доработку, не нужно уметь читать код. Вы тестируете не как программист, а как пользователь — повторяете реальные сценарии своей работы и смотрите, получается ли ожидаемое. Ваше преимущество перед исполнителем в том, что вы знаете свой бизнес и сразу заметите, если цифра «какая-то не такая», даже не понимая, как она вычисляется.
Золотое правило тестирования — делать это на копии базы, а не на боевой. Копия позволяет спокойно экспериментировать, подставлять любые данные и ничего не бояться: что бы вы ни сделали, рабочая база в безопасности. Только убедившись, что на копии всё считается верно, изменения переносят в боевую — и желательно с предварительным бэкапом. Приёмка прямо на живой базе без копии — частая причина испорченных данных и нервных вечеров.
Откуда брать сценарии для проверки? Из примеров, которые вы заложили в техзадание, плюс из собственного знания, где у вас обычно «тонкие места». Прогоните типичную операцию, потом пару нетипичных, потом то, что в вашей практике чаще всего идёт не по плану. Этого набора достаточно, чтобы поймать большинство проблем до того, как они станут дорогими. Не торопитесь с финальным «принято»: лучше потратить лишний час на проверку, чем потом разбираться с ошибкой в боевом режиме.
Гарантия на код и что делать с ошибками
Даже самая тщательная приёмка не ловит всё — какие-то ошибки проявляются только со временем, на редких данных или в следующем отчётном периоде. Именно для этого существует гарантия на код. Это оговорённый период после сдачи, в течение которого исполнитель бесплатно исправляет ошибки, не связанные с вашими новыми изменениями. Стандартная практика — от двух недель до пары месяцев, в зависимости от сложности доработки.
Гарантию обязательно фиксировать письменно, причём заранее, ещё до старта работ. В договорённости должно быть два пункта: срок гарантии и что именно она покрывает. Тогда баг, вылезший вскоре после сдачи, чинится спокойно и без доплат, а не превращается в неловкий торг «это вы должны бесплатно — нет, это новая задача». Удобно увязывать гарантию с моделью оплаты: о том, как фикс и почасовка по-разному стыкуются с гарантийными обязательствами, есть отдельный разбор про модель оплаты и гарантию.
Важно заранее провести границу. Если ошибка в гарантийном периоде и не вызвана вашими новыми правками — это зона ответственности исполнителя, и он устраняет её бесплатно. Если же баг появился из-за изменений с вашей стороны или гарантия истекла — это уже новая оплачиваемая работа, и это честно. Большинство конфликтов на финале возникает не из-за самих ошибок, а из-за того, что границу гарантии не проговорили заранее. Чёткая письменная договорённость до начала работ снимает почти все эти споры — и защищает обе стороны одинаково.
Как платформа помогает с приёмкой и гарантией
На Где.Эксперт программиста 1С выбирают по реальным отзывам и истории заказов, и среди прочего видно, кто сдаёт работу с понятной гарантией и не спорит о багах, всплывших вскоре после сдачи. Оплата по факту выполнения сама по себе работает как механизм приёмки: деньги уходят за результат, а не вперёд.
Это снимает главный страх финала: заплатить, а потом обнаружить тихую ошибку и остаться с ней один на один. Можно заранее обсудить со специалистом критерии приёмки и срок гарантии, принять работу на копии базы и только потом переносить в боевую. Оплата идёт по факту, без депозитов, а отзывы прошлых клиентов показывают, кто реально стоит за свой код после сдачи, а кто исчезает сразу после оплаты.
Часто задаваемые вопросы
Что обязательно проверить при приёмке?
Прогоните примеры с числами из техзадания, проверьте нестандартные случаи (пустые данные, крайние значения, нетипичные документы), убедитесь, что не сломан соседний функционал и сохранена обновляемость. Приёмка — это сверка с ожидаемым, а не беглый взгляд.
Как тестировать без знания кода?
Как пользователь: повторите реальные сценарии работы и сверьте результат с ожиданием. Делайте это на копии базы, а не на боевой. Сценарии берите из примеров в техзадании.
Что такое гарантия на код?
Период после сдачи, когда исполнитель бесплатно правит ошибки, не связанные с вашими новыми изменениями. Зафиксируйте письменно срок (от двух недель до пары месяцев) и что покрывается.
Что делать, если ошибка вылезла после приёмки?
В гарантийном периоде и не из-за ваших правок — исполнитель чинит бесплатно. Из-за новых ваших изменений или после гарантии — это отдельная оплачиваемая работа. Границу проговорите заранее.
Можно ли принимать на рабочей базе?
Не стоит. Сначала проверяйте на копии, и только убедившись — переносите в боевую с предварительным бэкапом. Приёмка на живой базе без копии часто кончается испорченными данными.
Заключение
Приёмка — это не формальное «вроде работает» в конце, а полноценный этап, который отделяет рабочее решение от тихой мины в вашей базе. Проверяйте не только обещанное на обычных данных, но и поведение на нестандартных случаях, целостность соседнего функционала и сохранённую обновляемость. Тестировать можно как пользователь, без знания кода, — главное делать это на копии базы и сверять результат с заранее заложенными примерами.
И не забывайте про гарантию: письменно зафиксированный срок и покрытие превращают неизбежные поздние ошибки из повода для конфликта в рутинную бесплатную правку. Проговорите критерии приёмки и гарантию до старта, принимайте работу вдумчиво и платите по факту — тогда финал проекта по доработке 1С будет спокойным, а не нервным.
Найдите специалиста по 1С с гарантией на код на Где.Эксперт — выбирайте по отзывам, договоритесь о приёмке на консультации и платите по факту выполнения, без депозитов.