Наша замена Selenium и другой инструментарий. Сложная разработка без брифов, часть 3

Уже много лет как мы в «Зионек» отказались от брифования клиентов. Мы создаём сложные высоконагруженные системы, внедряем и кастомизируем CRM, и разрабатываем корпоративные порталы и Интернет-магазины — и всё это без брифов. В двух предыдущих статьях этой серии мы рассказали о нашем процессе выявления потребностей клиентов (при внедрении CRM и при веб-разработке), а эта, заключительная статья — о важных технических аспектах процесса нашей работы и инструментах, которые важны для нашего процесса.

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

Качественные инструменты для тестирования для нас чрезвычайно важны, и поэтому мы серьёзно вложились в разработку качественного решения для тестирования, на которое невозможно наложить санкции и заблокировать его использование. Это браузер Hat — open-source разработка Евгения Сомова, Ведущего тестировщика в Зионек, которая по сути заменяет Селениум (Selenium) — браузер со встроенной технологией автоматизации тестирования Web приложений. Наша компания поддерживает этот проект, и в результате, мы и сами имеем возможность использовать качественный инструмент, и мы также видим ценность в том, чтобы этот инструмент был с открытым кодом и его могло использовать и развивать максимально широкое сообщество программистов.

Особенность браузера Hat в том, что автотесты напрямую выполняются в браузере — без Selenium и WebDriver.

Встроенный фреймворк HatFramework содержит достаточное количество методов, необходимых для выполнения основных задач автоматизации тестирования. Для описания скриптов автотестов используется язык программирования C# и встроенный редактор кода. Также в качестве редактора можно воспользоваться Visual Studio. Удобный интерфейс браузера отображает все шаги выполнения теста с подробным описанием событий. Результаты проверки формируются в отчет и отправляются на указанную почту. Запуск автотестов возможен из командной строки операционной системы Windows — это пригодится при использовании автотестов в популярных средствах непрерывной интеграции, таких как Jenkins, TeamCity, GitLab CI/CD.

Браузер Hat на github: https://github.com/SomovStudio/Hat

Другой наш важнейший инструмент — система контроля версий. Мы используем везде git — на сегодняшний день, это самая современная система контроля версий, всё остальное практически устарело.

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

Мы же используем git на 100% — мы всё разрабатываем, показываем клиенту, и всё делаем через систему контроля версий. А потом, когда клиентам устанавливаем «боевую» версию, мы это также делаем через git. У нас есть некий стенд — это одновременно пространство для наших тестов и то, как мы показываем клиенту текущую работу. Соответственно, после разворачивания на системе клиента «боевой» версии, дальнейшее взаимодействие идёт таким же образом — что-то мы показываем на тесте, и соответственно, когда клиент это принимает, мы это перекидываем с помощью git на текущую «боевую» версию («прод» в терминологии разработчиков); и, так как мы используем git, то мы не можем потерять какие-то изменения, которые внесли, а в случае чего — можем быстро откатиться назад.

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

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

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

Например, когда мы разворачиваем корпоративные порталы, нам часто помогает при настройке почты наш собственный модуль «Внешний SMTP. Отправка почты из коробочного 1C-Битрикс24 без боли и кода».

Благодаря этому модулю, отправка писем в коробочной версии работает так же, как в Облачном Битрикс24: вы просто создаёте ящики (столько ящиков, сколько вам нужно) в разделе «Почта» в CRM и спокойно пользуетесь, без дополнительных настроек. Модуль работает в почтовом клиенте CRM, в контактах, лидах, сделках и т.д.

Модуль уже настроен на работу с почтой Mail.RU, Яндекс.Почта и Google Mail, но если вам нужно добавить свой SMTP сервер, то это легко сделать в настройках. Это чрезвычайно удобный компонент, полностью снимающий головную боль при настройке почты в коробочной версии 1С-Битрикс24. Всем горячо рекомендую, вот ссылка: https://marketplace.1c-bitrix.ru/solutions/zionec.smtp/

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

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

Сложная разработка — без брифов (часть 1). Как это возможно и зачем отказываться от брифования клиента при внедрении CRM

Как отказаться от брифов в веб-разработке и какая от этого польза. (Сложная разработка без брифов, часть 2)

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

Мы часто берёмся за большие и сложные проекты, но умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!