Как тестировать консультантов 1с

Обновлено: 07.07.2024

Проектирование в 1С очень часто пропускается. Если оно и происходит, то только в достаточно небольшом объеме, и то только у серьезных команд. Чаще всего, оно происходит в уме (где-то, как-то).

Очень многие, особенно небольшие группы разработки, новички – сразу приступают к следующему этапу – этапу кодирования.

Дальше идет следующий этап – это этап тестирования. То есть, тестирование – это мы проверяем требования заказчика (требования, которые мы должны выполнить).

Дальше идет поиск ошибок, отладка.

Как правило, я сам проходил эти этапы. Тестированием занимаются очень немногие. Еще меньше число тех, кто вообще представляет, что же такое «тестирование». Для большинства разработчиков цикл разработки представляет собой совокупность только двух этапов - процесса кодирования и отладки. Причем отладка занимает очень много времени.

Есть такой закон, который я, например, прочитал у Макконелла – Главный закон качества ПО:

Повышение качества программного обеспечения снижает затраты на разработку и сопровождение системы.

Что это означает? Это означает, что чем лучше у нас написана система, чем лучше она спроектирована, чем лучше обоснованы связи, тем легче мы сможем ее дорабатывать, исправлять и т.д.

Пример правильности этого закона: Отладка и исправление неверного кода занимает около 50 % времени. То есть – 50 % времени всей разработки мы тратим на поиск ошибок.

Это касается как крупных проектов, так и мелких. Методик, чтобы снизить свои затраты и не допустить ошибок, очень много – главный принцип, которого нужно придерживаться в разработке, используя разные методики, - это просто их использовать (использовать комбинации методик, использовать одну методику, а не просто писать свой код не думая над ним, не исправляя его).

Методики разработки

  • Защитное программирование
  • Обзоры кода
  • Проектирование
  • Тестирование
  • Экстремальное программирование

Я лично пользуюсь всеми перечисленными методиками.

  1. Защитное программирование – это методика, когда мы ведем разработку и само написание кода помогает нам не допускать ошибок. То есть, в этом случае мы что делаем? Мы проверяем данные.
    Элементарный пример – у нас есть какая-то функция, которая принимает входные параметры определенного типа, определенных значений. Мы можем в функции сделать предположение (так называемый инвариант или утверждение) и проверить эти предположения. То есть, мы не пишем, как 1С привыкла: параметр и в комментариях пишем, что тип такой-то, значения такие-то, варианты и так далее… Мы можем прямо написать утверждение – вот этот параметр должен быть такого типа. Если это утверждение не выполняется, программа просто выдает исключение и останавливает свою работу, потому что это является ошибкой разработки.
  2. Следующая методика – это «Обзоры кода». То есть, мы можем читать чужой код. То есть, один кто-то написал код, мы можем попросить соседнего разработчика, руководителя посмотреть и проанализировать ошибки, которые были допущены в этом коде. Это методика очень эффективна.
    Я люблю читать чужой код, люблю свой код пересматривать. Таким образом находится достаточное число ошибок.
  3. Следующая методика - проектирование. Чем лучше мы построим программу, чем лучше продумаем связи, чем лучше продумаем архитектуру, интерфейсы взаимосвязей, тем лучше наша система будет работать, тем удобнее нам ее будет исправлять.
  4. Методика, которая известна лучше всех предыдущих – это тестирование. Фактически, каждый разработчик выполняет эту функцию, применяет методику тестирования. Но очень многие проверяют в уме. То есть этот код должен получить такие-то результаты… Мы проверяем какой-то один вариант, проверяем два варианта, проверяем три варианта… А на самом деле в сложных системах вариантов очень много и их нужно проверять достаточно большое количество. И когда вариантов очень много для проверки, фактически получается, что они не проверяются все. У меня есть пример, есть система, идет цикл разработки, система отдается на проверку пользователю. У пользователя стоит тестирование – проверить 40 разных пунктов – релиз выпускается, например, раз в два месяца (или в месяц). Пользователь должен перед выпуском каждого релиза проверить 40 пунктов – это тяжело и он никогда практически не будет этого делать. Он будет помнить, что он это проверял в прошлый раз – и сегодня он этого делать не будет, потому что тогда на это придется потратить весь день. Как правило, отдельный тестировщик на проекте есть очень редко, обычно человек должен выполнить функцию тестировщика и выполнить свою основную функцию. В итоге функции тестировщика, как правило, пропускаются и тестирование не выполняется в полном объеме.
    Дальше я еще потом на тестировании остановлюсь…
  5. Следующая – очень эффективная методика – это методикаэкстремального программирования. Это методика свежая, буквально начала-середины 90-х годов. На западе очень сильно распространена, очень много информации по ней. У нас применяется не так много. Иногда эту методику называют «гибкие методики разработки», иногда – экстремальное программирование.

Экстремальное программирование

У него есть несколько принципов:

  • Единая команда
  • Совместное владение кодом системы
  • Обзоры кода и парное программирование
  • Разработка через тестирование (TDD)
  • Функциональное тестирование
  • Рефакторинг
  • Простота
  • Короткие циклы
  • Непрерывная интеграция
  • Улучшение дизайна, постоянное планирование

Расскажем о них поподробнее:

Вернемся к тестированию. Будем говорить только о тестировании.

Виды тестирования

  • Модульное тестирование (юнит-тестирование)
  • Функциональное тестирование
  • Тестирование методом черного ящика и методом белого ящика
  • Нагрузочное тестирование
  • Тестирование разработчиком и специальными тестерами
  • Самый проблемный вид тестирования – тестирование пользовательского интерфейса

Теперь об этих видах тестирования подробнее:

Сейчас немного коснусь существующих систем тестирования

Существующие системы тестирования

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

Одна из самых первых разработок, поэтому я о ней упомянул.
Она неудобная и непродуманная на самом деле.


Это опять же, зачаточный такой модуль, просто пример того, как это можно организовать в 1С.


достаточно интересная, но почему-то автор ее удалил

  • Функциональное тестирование на обычных формах
  • Можно подключать различные алгоритмы
  • Можно тестировать запросы и т.д.
  • Недостатки: Нет управляемых форм и нет дальнейшего развития
  1. Дальше я укажу те системы, которые я сам реально использовал, с которых мое знакомство с системами тестирования для 1С началось:
  • Я ее в 8.2 до сих пор успешно использую.
  • Недостатки: немного устарела, нет управляемых форм
  • Шаги в нужном направлении
  • Только Управляемое приложение

В этом тестировании используется два клиентских приложения. Одно приложение является тестером, другое приложение является клиентом.


То есть, толстый клиент или тонкий клиент менеджер тестирования взаимодействует (общается) с клиентом тестирования (толстым, тонким или Web-клиентом).
То есть – пишется тест на языке 1С. И заданные действия выполняются в клиенте тестирования.

Пример вызова приложения-теста


На данном скриншоте красная стрелка как раз показывает – есть вариант вызова записи действий пользователя, то есть в 8.3 можно использовать следующую схему работы:

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

Рекомендуемая система для тестирования в 1С

(я фактически ее product-owner и один из авторов) -

Защитное программирование

Защитное программирование – очень важный этап применения методики тестирования

На своем опыте - а я общался с разными программистами, специалистами - очень мало народу почему-то использует утверждения. А этот метод очень удобен в разработке.

Использование инвариантов/утверждений

Обработчик ошибок в программе должен проверять некорректные входные данные из внешних источников, предусмотренные программистом, а утверждения – только ошибки в самой программе. Никаких проверок дополнительных не должно быть, только ошибки в программе - это проверка только для разработчика.

Потому что иногда начинают использовать утверждения для передачи данных во внешнюю систему – это неправильно. Это уже не утверждение.

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

Теперь – самое интересное: Тестирование разработчиком и разработка через тестирование.

Тестирование разработчиком

Это та методика, которая должна использоваться любым разработчиком, если он хочет быть квалифицированным и получить максимальную скорость.

  • Затруднение у разработчиков (Цель тестирования отлична от других этапов разработки, Тестирование требует поиска ошибок в своем коде)
    Тестирование разработчиком вызывает затруднения, потому что цель тестирования отлична от цели разработки. То есть от разработки мы хотим получить правильный код, который правильно работает, получает верные результаты, содержит минимум ошибок и т.д. А в тестировании мы должны найти ошибки, наоборот. Иногда бывает это трудно. Разработчику бывает лень искать ошибки. Разработчик не понимает, что ошибки нужно искать и т.д.
  • Тестирование никогда не доказывает отсутствия ошибок.
    Но наличие тестов – это лучше, чем отсутствие тестов.

Что еще можно сказать об основных требованиях к тестированию:

Два главных требования тестирования:

  • Тестирование должно быть автоматизированным. А еще лучше – автоматическим 100%. Если тестирование не будет автоматизированным, его никто никогда выполнять не будет.
  • Тестирование должно быть быстрым.
    Если тесты будут выполняться медленно, их опять же никто не будет делать. Это все из опыта.

Разработка через тестирование (TDD)

Быстро расскажу о результатах, которых можно достичь, используя методику разработки через тестирование:

Результаты использования TDD

Здесь указаны основные принципы, как надо выполнять разработку через тестирование (TDD).

С самого начала стоит разграничить два понятия «Консультант 1С» и «Продажник 1С». Дело в том, что очень часто эти два понятия путают как клиенты нашей компании, так и соискатели на ту или иную вакансию.

Почему же многие путают этих два понятия – «Консультант 1С и Продажник 1С».

Дело в том, что все мы ходим в магазины с целью приобрести новые джинсы или деловой костюм, поэтому много раз имели возможность общения с обязательным атрибутом практически любого бутика или магазина – продавцом-консультантом. Когда мы видим в магазине человека с бейджиком «продавец-консультант», то не столько воспринимаем его как советчика в области выбора одежды, сколько видим в нем продавца, который принесет нужный размер и оформит покупку.

С 1С все не так. Консультант 1С – это именно консультант, от слова «консультация».

Консультанты 1С не занимаются обзвоном всех предприятий, фирм, компаний в области и за ее пределами.

Консультанты 1С не рекламируют нашу компанию.

Консультант 1С не занимается продажами от слова «совсем».

Чем занимается консультант 1С?

Для того чтобы понять, чем занимается консультант 1С, необходимо понимать специфику деятельности компании, в которой он работает.

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

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

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

Что должен уметь и знать хороший консультант 1С?

Во-первых, обязательно знать непосредственно программный продукт 1С. Разбираться в функциональных блоках программы, нюансах настройки и эксплуатации.

Во-вторых, обязательно разбираться в предметной области. Если сопровождается программа 1С Бухгалтерия, то без знаний основ бухгалтерского учета, налогового законодательства оказать качественную услугу консультирования не представится возможным. Если речь идет о программном продукте 1С Управление торговлей или 1С Розница — то, безусловно, нужно представлять себе, как устроены основные бизнес-процессы в опте и рознице.

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

В-четвертых, — это готовность к непрерывному получению новых знаний. Это относится не только к консультантам 1С, но и ко всем без исключения специалистам в обслуживании 1С программ. Разработчики 1С-программ никогда не дают скучать, ни пользователям, ни специалистам по сопровождению. Новые программные линейки, новые релизы, новые сервисы – всему этому регулярно приходится учиться, повышать свою компетенцию практически в режиме нон-стоп и часто в параллельно основной работе.

В-пятых, готовность решать нерешаемое. Для нашей компании нет нерешаемых вопросов, но иногда так бывает, что проблема, которой занимается консультант 1С, не имеет описанного решения, т.е. ранее не появлялась ни у одного клиента. Кроме того, найти ее решение ни в документации к программному продукту, ни во внутренних ресурсах разработчика, ни даже в «окей гугл» — не удается. А консультант 1С должен найти выход из такой ситуации. Здесь очень пригодится еще один навык — умение находить нестандартные подходы для поиска решений. Хороший консультант 1С — это профессиональный решатель головоломок.

Чем обычно занимается консультант 1С

  • Обучение пользователей. Приобретая программный продукт 1С, как правило, клиенты часто заказывают обучение по его использованию, и это прямая обязанность консультанта 1С — научить пользователя использовать программные продукты 1С.
  • Работа в режиме «техподдержки». В процессе эксплуатации возникают проблемы вида «подскажите, где находится отчет», «не получается рассчитать себестоимость», «что-то зависло», «почему в оборотно-сальдовой ведомости я вижу отрицательные цифры» и т.д. С этими вопросами поможет консультант 1С.
  • Участник команды по внедрению в проектах. Первоначальная настройка всей программы или отдельных функциональных блоков. Здесь и обучение пользователей, и техподдержка, как показывает практика, и то и другое одновременно.
  • Постановщик технического задания. В нашей работе зачастую имеют место быть ситуации, когда пользователь (клиент) не имеет навыков для формирования задания программисту 1С для реализации той или иной задачи, а программист 1С не понимает пользователя. Изъясняются они на разных языках! В таких случаях консультант 1С выступает как некий посредник, этакий сурдопереводчик, связующее звено между программистом 1С и пользователем, формулируя для первого подходящее и понятное задание, а для второго осуществляет взаимодействие на понятном для того языке.

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

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

Как становятся консультантами 1С

1. Необходимо иметь большое желание работать в области 1С, иметь интерес к IT технологиям, не бояться трудностей, с которыми неминуемо придется столкнуться.

2. Иметь «базовые компетенции» — уже имеющиеся навыки понимания в той или иной области учета в бухгалтерии, кадрах и т.д. Иногда достаточно знаний, полученных в ВУЗах.

3. Учиться, учиться и еще раз учиться. Как уже было сказано, специалисты 1С учатся всегда и непрерывно, а на первых порах — еще и 24 часа в сутки. Ради справедливости стоит заметить, что с реальными задачами на реальных кейсах — это всегда интересно и не скучно.

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

Разработка на платформе 1С: Предприятие — не самый сложный процесс. Самое сложное — принять концепцию написания кода на родном языке :)
Но не смотря на то, что в 8й версии платформы был совершён положительный качественный скачок в устройстве платформы и встроенного языка (например, появление концепции MVC для объектов метаданных конфигурации) многие народные кодеры продолжают выдавать мегабайты «мусора», который каким-то чудом работает в рамках того, что смог/успел проверить такой кодер.
У меня нет богатого «опыта» работы в различных франчайзи, у меня за все годы перед глазами только опыт единственного отдела, который выпускает коробочные продукты, продукты продаются, клиенты находят баги, терроризируют техподдержку, техподдержка бегает к разработчикам, разработчики радостно фиксят найденные баги, попутно внося разнообразные новые, короче говоря — работа есть всем и хватит её надолго.
Сколько времени уходит на фикс багов, а сколько на создание нового функционала — пропорция известна лишь приблизительно. Баги, найденные клиентами, воспринимаются как неизбежное зло, и для уменьшения времени на их исправление прибегают к усиленному ручному тестированию релизов и наймом/воспитанием грамотных разработчиков. Ручное тестирование отделом QA это достаточно трудоёмко и нет возможности точно определить золотую середину соотношения глубины тестирования к потраченному на тестирование времени. Про наличие огромного количества талантливых разработчиков вообще говорить не приходится.
Во «взрослых» языках программирования подобные проблемы стараются решать повсеместным тестированием. Начиная с уровня разработчика — unit-тестами, далее функциональными и регрессионными, и заканчивая интеграционными тестами. В особо интересных случаях тесты запускаются на каждый чих коммит в определённую ветку репозитория.
К сожалению фирма «1С» не балует разработчиков на своей платформе какими-либо достойными инструментами, хорошо, хоть репозиторий/хранилище сделали.
Несколько лет назад, приступая к новому проекту, лично мне надоели регулярные удары одними и теми же граблями по лбу. С руководством было оговорено время на разработку своей наколенной системы тестирования в том виде как я её видел и работа закипела.

Применение.

Лично мне на одном проекте данная система сэкономила не менее года времени проведённого в отладчике. Ещё один проект уже несколько лет использует систему для функциональных тестов огромного количества вариантов скидок/оплат и т.п. Ещё три проекта начинают её использовать. Вообще, конечно, внедрять такую систему «снизу» это как долбиться лбом в стену небоскрёба. Но если долбить каждый день, то результат рано или поздно появится. Главное — успешный пример и поддержка «сверху».

Описание.

  • модульные тесты;
  • функциональные тесты;
  • регрессионные тесты*;
  • интеграционные тесты;
Устройство.

Так как система создавалась ещё во времена платформы 8.1, то поддержки управляемых форм в ней нет, ибо мне уже не надо, а текущим проектам ещё не надо. Но основной функционал системы это тестирование кода и весь недостаток в том, что обработка тестирования написана не на управляемых формах.

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

Рабочая форма выглядит так:

1. Текущий проект
2. Имя пользователя системы тестирования
3. Тесты можно разбивать на группы, это удобно при настройке автоматического тестирования и позволяет структурировать сами тесты.
4. Выбран тест с кодом 400, указано имя теста, тестируемый метод находится в форме встроенной обработки «Транслятор», последней колонкой выведено имя тестируемого метода.
5. Сюда вставляется полная сигнатура тестируемого метода, которая автоматически парсится (нажатием на кнопку 8) на входящие параметры — 6 и результаты — 7.
6. Тут задаются входящие параметры примитивных и ссылочных типов, также можно указать путь к файлу, если установлен флажок Файл.
7. У выбранного теста всего одно возвращаемое значение функции, для него предопределено имя _ВозвратПерем.
8. Распарсить сигнатуру метода на входящие параметры и возвращаемые результаты.

Для понимания дальнейшего повествования необходимо отвлечься на поле 5, где есть ещё немного вкладок.
Перед выполнением:

Поле предназначено для выполнения произвольного кода перед вызовом тестируемого метода. Можно как угодно видоизменить входящие параметры, подготовить коллекции или объекты информационной базы.
Аналогичное поле После выполнения позволяет обработать полученные результаты вызова тестируемого метода до начала сравнения их с сохранёнными ранее эталонными значениями.
Выполняемый код:

Тут показан весь код, который будет выполнен при запуске теста.
Вкладка Описание — здесь можно подробно описать что это за тест.
Ну и наконец вкладка Версии:

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

9. Выполнить тест. Выполняется код, видимый на вкладке Выполняемый код. Поле 7 заполняется результатами работы выполняемого кода.
10. Кнопка сохранения полученных после нажатия кнопки 9 результатов в качестве эталона.
11. Запуск теста и сравнение результатов с ранее сохранённым эталоном.
12. Просмотр сохранённых эталонных значений.

Пример.
Итого.

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

Система не создавалась для продажи, система много где не доведена до ума, но даже то, что уже есть сильно помогает избегать как минимум глупых ошибок из серии — поправил в одном месте, отвалилось в трёх других.

Попытался систематизировать собственный опыт и некоторые знания в области HR, составив некоторый портрет "идеального программиста 1С". После того, как такой "портрет" получилось построить, выбрал все знания/умения/навыки, которыми такой "идеальный" кандидат должен обладать, выбрал 10 наиболее важных (по моему опыту) и сформулировал вопросы, которыми данные качества/знания/навыки можно проверить. Всё это мы неоднократно проделываем на собеседовании, вот только времени обычно на это минуты 2-3, потому как не привыкли же мы заранее продумывать вопросы, которые зададим.


Вопрос 1 Есть ли у Вас сертификаты 1С? Какие?

В России мы привыкли пренебрежительно относиться ко "всякого рода бумажкам". Это общий подход. Жизнь научила нас им не доверять. Привыкли мы к "купленным правам", "купленным дипломам" и т.п. Тем не менее, таким замечательным инструментом первичной оценки знаний нужно пользоваться. 1С достаточно трепетно относится к выдаче своих сертификатов (что касается "Специалист" и выше). "Покупать" сертификаты вряд ли кто будет - не такая это большая ценность, чтобы пытаться, да и не просто это, я думаю. Круг лиц весьма ограничен. А о чём говорит сертификат "1С Специалист":
- Есть хоть какая-то школа. При сдачи экзаменов 1С смотрят не просто как человек умеет ездить (программировать), а как человек умеет ездить по правилам (программировать по методикам)
- Как минимум - человек программировать в 1С умеет, может и не большой профи, но умеет, поэтому кучу всевозможных проверок одним вопросом мы отбрасываем
Лучше всего если у кандидата несколько сертификатов - по платформе и по прикладному решению с которым ему предстоит работать.
Но очень внимательно отнеситесь если у кандидата много сертификатов, либо среди них есть сертификаты вида "Руководитель проекта, ведущий консультант, Эксперт по техн. вопросам". Если эти люди ищут работу обычным программистом - на то должны быть другие причины, кроме того уровень желаемого дохода может оказаться несоразмерным вашему бюджету.

Вопрос 2. Вы знакомы с документом "Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8"?

Вопрос 4. Насколько хорошо вы знаете функциональность прикладного решения ". "? Перечислите основные процедуры проведения Документа в решении ". ".

"Доверяй но проверяй". Прикладное решение естественно должно использоваться (планироваться к использованию) в вашей организации и заявлено у программиста в резюме как знакомое. Собственно если человек достаточно хорошо знает "внутренности" того или иного прикладного решения, В модули проведения документа он вмешивался не один раз. Изменения, которые не влияют на проведение, часто можно считать "косметическими". А уж если приходилось добавлять новые документы в рамках функциональности прикладного решения, и добавлять их "правильно", то эти процедуры надолго отложатся в памяти. Проверить конечно это стало достаточно трудно, т.к. в решениях на 8.2 логика проведения поменялась, и следовательно процедуры поменялись тоже.
Для УТ 11 на момент написания статьи они такие:

ИнициализироватьДополнительныеСвойстваДляПроведения(Ссылка, ДополнительныеСвойства, РежимПроведения);
ИнициализироватьДанныеДокумента(Ссылка, ДополнительныеСвойства);
ПроведениеСервер.ПодготовитьНаборыЗаписейКРегистрацииДвижений(ЭтотОбъект);
. ОтразитьДвижение. (ДополнительныеСвойства, Движения, Отказ);
СформироватьСписокРегистровДляКонтроля();
ЗаписатьНаборыЗаписей(ЭтотОбъект);
ВыполнитьКонтрольРезультатовПроведения(ЭтотОбъект, Отказ);

Вообще программист 1С должен хорошо ориентироваться во всех типовых конфигурациях, потому что основная работа квалифицированного программиста не написать код, а грамотно спереть код оттуда где подобная задача уже решена.


Вопрос 5. Перечислите все статьи баланса, которые вы знаете.

Простой тест на превичное знание бух. и упр. учета. Собственно должно получиться что-то похожее на

Вопрос 6. Вам знакомо понятие "Валюта Баланса"?

Вопрос 9. Бухгалтер просит вас перенумеровать счета фактуры по организации ООО ". " за текущий месяц. Посмотрев ситуацию вы находите там всего 10 счетов фактур. Что бы вы сделали?

Самая типичная ситуация на примере которой выясняется личностное поведение программиста. Однозначно правильного ответа на данный вопрос нет. Зато есть однозначно неправильный - "перенумерую руками". Это именно то поведение, которое часто встречается даже у квалифицированных программистов, но резко снижает их полезность для организации. Выполнять какую-либо операторскую работу программист не должен - это не рентабельно для компании, т.е. разница в з/п обычно составляет 2-3 и более порядков.
Идеальным вариантом будет использование ключевой фразы: "при отсутствии текущих задач" или "небольшой текущей загрузке" напишу илилучше скачаю механизм перенумерации объектов, и научу бухгалтера им пользоваться. Либо "при высокой текущей загрузке" позвоню и вежливо предложу перенумеровать СФ самостоятельно, в случае необходимости объясню как это сделать.
Но собственно в данном случае всё зависит от того, какого человека вы ищите. Если проектника (задачи внедрения), то конечно иделальным поведением будет "вежливо попросить" бухгалтера не приставать с такими вопросами, если же на поддержку, то вариант с "вежливо попросить" просто отпадает.

Вопрос 10. Вам знакома библиотека ITIL? А технология PMI?

Если вы ищите только программиста, то на эти вопросы лучше если будет отрицательный ответ. ITIL - библиотека Best practice процессного менеджмента для управления процессами ИТ. PMI - технология управления проектами. Собственно 2 самых популярных инструмента ИТ руководителей на момент написания данной статьи. Если кандидат знаком с ITIL следовательно он наметил для себя карьеру ИТ директора в будущем. Если PMI - следовательно стремится стать менеджером проектов. Если же человек достаточно хорошо знаком или с одним или с другим то нужно заранее планировать либо карьерный рост кандидата, либо его уход из компании.

Расшифровка результатов

Естественно все результаты рассмотреть не получится - много возможных сочетаний. Могу только сказать что вопросы расположены в порядке убывания их значимости. В принципе положительно ответивший на первые 3-4 вопроса кандидат - уже очень хороший вариант для приёма на работу/в проектную команду. В таблице ниже попытался рассмотреть ещё несколько "типичных" случаев программистов, и по каким ответам их проще распознать. Ответы не обязательно полностью должны совпасть с тем что указано. На указанные вопросы должны быть положительные ответы - точно. Может быть ещё 1 или 2 положительных ответа. Особое внимание стоит обратить только на вопросы 7 и 8. Человек ответивший положительно только на них как правило не тот кто вам нужен.

Ответы

Комментарий

Денег платить придётся не мало. Кандидат конечно этого стоит, но столько ли у вас задач, чтобы использовать потенциал? Посадить такого программиста на суппорт будет явно не рентабельно

Вы готовы заняться обучением?

Типичный случай бухгалтера-программиста. Не очень плохой вариант. Нужно дополнительно пообщаться на предмет технического мышления. Если хоть немного присутствует для суппорт-а бухгалтерии и финансов такой программист очень неплохо подойдёт. Для реальной разработки сложного и нового функционала – скорее нет

Очень плохой случай. Вы имеет дело с типичным технарем. Как правило, эти люди очень самолюбивы, 1С считают «убогим продуктом, с которым им приходится работать». Управлять ими трудно, добиться чего-либо полезного ещё труднее. Все задачи решаются «творчески». Часто поступают «интересные» предложения вроде «перейти на Linux », написать систему самому на C ++ и т.п. Без «плюсов» в 1, 2 и 3 таких людей лучше не брать.

Собственно перед вами скорее человек который претендует на руководящую позицию чем разработчик.

Перед вами Администартор-программист. Очень часто в мелких компаниях одному человеку приходится сочетать эти качества. Человек привык к суппорту наверно даже идеален для такового, но для использования в более серьёзных проектах скорее всего потребуется дополнительное обучение.

Читайте также: