Система контроля качества внедрений от компании 1С-Битрикс. Битрикс мониторинг качества
Как пройти монитор качества в Битриксе — наш чек-лист — Сибирикс
«Монитор качества — инструмент для проверки качества выполненного проекта перед сдачей его заказчику.
- Структурированная методика управления качеством внедрения;
- Система тестов для веб-разработчиков, набор рекомендаций для клиентов;
- Состоит из 26 обязательных тестов и 39 необязательных;
- Включает 12 автоматических проверок.»
На наш взгляд — технология сыровата и требует доработки напильником. Ее главная проблема: многие тесты не имеют смысла для большинства сайтов, либо их имеет смысл проверять только в продуктивных условиях, когда проект уже полностью готов.
Тем не менее, мы считаем, что идея внутреннего монитора качества — хороша, т.к. это потенциально уменьшит количество говнокода и сделает мир светлее. Вот наша небольшая внутренняя инструкция, как и на какой фазе проходить монитор качества:
Общий процесс прохождения теста
- Делаете все задачи по проекту, желательно все спринты перед выкладкой на хостинг.
- После тасков перед тестированием просматриваете все пункты МК, проверяете, что они выполнены, где считаете нужным — пишете комментарии.
- Отдаете на тест, тестер во время проверки проверяет все пункты МК (относящиеся к программированию, которые помечены ниже, ориентируется на комменты программиста) и проверяет все автотесты.
- После выкладки на сервер программистом проходятся пункты МК, относящиеся к выкладке на хостинг и производительности.
- Если в каком-то пункте (например, «Настроена цепочка навигации — QD0050») требуется проверить настройку/выполнение пункта, который не требуется по ТЗ либо вообще отсутствует на сайте — ставите статус «Пройден успешно», указывая в комментарии разработчика, что «данный функционал не требуется по ТЗ/дизайну/прототипу/отсутствует в данной редакции Битрикса».
Важно: Статус «Пройдено успешно» имеют право выставлять только тестер и менеджер проекта, для програмиста Монитор Качества выступает только в роли чеклиста и напоминалки.
Кому и в каком порядке проходить тест
Интеграция дизайна и разработка
- Интеграция дизайна — от программиста требуется написать комменты по всем пунктам, т.к. это затруднительно проверить тестером.
- Интеграция структур данных.
- Интеграция стандартных компонентов и модулей.
- Интеграция собственных компонентов и модулей — от программиста требуется написать комменты по всем пунктам, т.к. это затруднительно проверить тестером.
- Дополнительно — от программиста требуется написать комменты по всем пунктам, т.к. это затруднительно проверить тестером.
Безопасность
- Программисту — настроить всё в соответствии с требованиями безопасности. Пункты «Удалены тестовые данные», «Настроены политики безопасности по работе с БД» — только после выкладки на хостинг.
Производительность
- Проходить только после выкладки проекта на хостинг. Все пункты проходит программист, выкладывающий сайт на хостинг.
Размещение на хостинге
Сдача проекта
- Лицензионный ключ активирован — трясти менеджера.
- Ядро проекта не модифицировалось — этот тест является обязательным.
- Введена информация об интеграторе решения — в наших чистых сборках битрикса, установленных через .bitrixInstall автоматически на главную страницы админки добавляется виджет с информацией о нас. Проверить что он есть.
- Введена информация о техподдержке проекта — если виджет из предыдущего пункта есть — то тест пройден.
Пользуйтесь, вносите свои предложения. С удовольствием почитаем ваши мысли по поводу монитора качества в комментах внизу.
blog.sibirix.ru
Монитор качества — повышаем удовольствие от разработки
Коллеги, добрый день!Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 11 версии платформы Битрикс — «Мониторе качества».
Идеальный мир — Водопад
Да, да. Существует методика обеспечения высокого качества веб-проекта, при соблюдении которой он не будет глючить, а Клиенты не будут атаковать вас сообщениями об ошибках на форумах и твиттере.
Для этого нужно всего лишь:
- Найти программиста(ов), сертифицированного для разработки на языке PHP, с опытом работы от 5 лет и большим портфолио успешных проектов.
- Найти верстальщика(ов), в тонкостях разбирающегося в особенностях HTML/CSS во всех популярных браузерах последних версий, висящего с утра до обеда на профессиональных форумах (пишу, а в глазах появляются слезы :-) ). Но этого не достаточно, т.к. верстальщик должен уметь программировать для javascript (и знать диалекты этого языка для всех популярных браузеров), т.е. быть «по совместительству» опытным программистом.
- Найти системного администратора(ов), хорошо разбирающегося хоть в одной операционной системе и с опытом работы от 10 лет.
- Найти тестировщика, который сумеет организовать систему со 100% покрытием создаваемого кода веб-проекта модульными тестами и функциональными тестами. Этот тестировщик должен будет в тонкостях разбираться в предметной области веб-проекта, знать его лучше Клиента.
- И, конечно же, найти Клиента, который а) знает в тонкостях что он хочет лучше любого аналитика в данной предметной области, б) не меняет свои требования до запуска веб-проекта в эксплуатацию.
- Как только команда собрана, вы начинаете проектировать веб-сайт, отрисовываете, верстаете и включаете в ТЗ описание каждой веб-страницы как в админке, так и публичной части, с точностью до пикселя и разными вариантами страницы в зависимости от разрешения экрана Пользователя. В итоге получается иллюстрированное ТЗ страниц, эдак, на 500, написанное примерно за полгода.
- Затем нужно оценить каждую страницу в ТЗ, составит подробный план разработки на каждый день, назначить дату ввода веб-проекта в эксплуатацию.
- Конечно, перед запуском выделяется время на тщательное тестирование сделанного веб-сайта на соответствие ТЗ и дизайн-макетам, с точностью до пикселя и буквы в ТЗ. Придется тестировать долго, в несколько подходов, нельзя же открывать функционал с ошибками для Клиентов — скорее всего многофазовое тестирование займет месяца 2-3, если не больше.
И тогда в веб-проекте скорее всего не будет ошибок и система будет запущена в срок! Но сайт, скорее всего, морально устареет, уже не будет нужен Пользователям, а Клиент получит не то, что он хочет, а то, что он написал в ТЗ :-) Многие в настоящее время, к сожалению, забывают, что веб-проект является программной системой с жесткой «булевой» логикой прикладной математики и не обладает чувством прекрасного. Эта инженерная конструкция как любая другая конструкция (мост, дом, самолет) — должна, по-хорошему, проектироваться вплоть до винтика, тестироваться до винтика, а любое изменение потребует пересмотра всей проектной документации. И так, обстоятельно и научно, раньше и делали программные системы — Каскадный подход (Водопад).
Но интуиция подсказывает, что запускать веб-сайт таким способом очень дорого и видимо очень долго. Да и найти высококлассных специалистов в команду — задача не из простых. Хочется найти способ «схалтурить подешевле», не выполнить домашнее задание по математике: как-то же запускают веб-проекты быстро и с достаточным качеством без многотомных ТЗ? :-)
Разведка боем — Итерационный подход
Люди осознали, что сесть с Клиентом и не выходя из переговорки спроектировать веб-решение за 2-3 дня — невозможно. И даже запирание системных аналитиков в офисе на неделю — не решит задачу. Пришло понимание, что эффективнее каждый раз обсуждать и делать систему частями, разбирать результаты завершенного этапа и учитывать их при проектировании следующего. Идти вперед небольшими шагами, не заглядывая в будущее дальше, к примеру, 3 месяцев.
Для многих Клиентов так работать удобнее — видишь результат и корректируешь план. Для разработчиков и тестировщиков это, конечно, серьезно добавляет хлопот:
- Не получается поддерживать в актуальном состоянии всю проектную документацию, скриншоты, диаграммы, ТЗ — т.к. через небольшой период времени скорее всего нужно будет вносить изменения. Поэтому идут на «хитрость» — ведут менее формальное описание системы, например в wiki, без отслеживания зависимостей между компонентами, полагаясь на память коллег :-)
- Нужно так программировать/верстать, чтобы внесение ожидаемых изменений было простым, мало рискованным процессом. А это значит, что а) нужно знать и грамотно использовать паттерны проектирования (а найти знающих эту область разработчиков — не просто), б) нельзя поддаться искушению и создавать универсальную и расширяющуюся во все места систему, т.к. это серьезно увеличит сроки разработки
- Нужно уметь тестировать эту, периодически меняющуюся систему. Знать где и что поменялось, где это проявится. Т.е. повышается нагрузка на тестировщиков — нужно описывать изменения, вносить изменения в модульные и интеграционные тесты и т.п.
Видим, что, в итерационном подходе с одной стороны стало удобней Клиенту и, возможно, работающему с ним менеджеру проекта, а с другой стороны — повысилась нагрузка на разработчиков и специалистов по качеству, а также возросли требования к их квалификации.
Можно организовать подобный процесс как более формально (RUP и т.п.), так и менее формально. Все зависит от конкретного веб-проекта. Соответственно, можно использовать специализированный софт, а можно все построить «на коленках» (эксельки, вики, стенки в листиках и т.п.).
Высший пилотаж… на гране хаоса — Гибкий процесс (Agile)
В настоящее время — интенсивно набирающий популярность процесс разработки веб-сайтов. Постулируется следующее:
- Требования постоянно меняются, т.к. рынок меняется, поэтому писать, а еще страшнее — менять и поддерживать в актуальном состоянии детальное ТЗ — трата времени. Иначе потребуется отдел системной аналитики, отдел дизайна и департамент проектирования архитектуры
- Т.к. требования меняются, изменения в проект будут вносится постоянно, поэтому нужно сделать всё, чтобы это не разрушало проект и изменения вносились быстро и дешево.
- Клиент или его представитель должен быть постоянно доступен и открыт для общения, отвечать на вопросы команды проекта.
- Разработчики и другие участники проекта постоянно общаются и обмениваются информацией, бюрократия сведена к минимуму, люди высокоорганизованны и действуют заодно (не нужно принуждать к труду).
- Веб-проект релизится часто, итерациями в 2-3 недели. В тестировании активное участие принимают Посетители сайта.
Очевидно, чтобы такое «поперло», нужны самоорганизованные люди в команде, профессионалы своего дела и лидер, поддерживающий данную суперкреативную атмосферу от атак деспотирующих, преследующий личные корыстные цели бюрократов и т.п. Иначе, при любом хлопке — все снова разбегутся по офисным столам и начнут бросаться письмами и страдать буквоедством.
Клиенту, ориентированному на результат, данный процесс очень удобен, т.к. веб-решение можно менять и развивать постоянно, не отставая от конкурентов — иначе Клиент становится заложником ТЗ, как написал год назад, так и сделаем. Если команда сильная с прогнозируемой производительностью, то Клиент постепенно начинает эффективно планировать ближайшие релизы веб-решения.
С другой стороны, очень резко увеличивается техническая сложность решения, т.к. поддержка постоянно меняющейся системы в состоянии «технического здоровья» (когда ты знаешь, что ее можно уверенно развивать дальше, и стоимость внесения изменений не начнет расти экспоненциально) — задача не для слабонервных и требует высокой квалификации разработчиков.
Для управления качеством такой системы (нередко без формальной техдокументации) используется арсенал эффективных методик:
- Автоматизированные модульные (unit) тесты. Программисты создают код, тестирующий их код.
- Функциональные тесты или автоматизированные приемочные тесты — тестируются выполненные фичи и процессы.
- Релиз веб-проекта быстро вводится в эксплуатацию. Посетители быстро тестируют решение и оно за короткий срок переходит из beta в адекватное требованиям состояние.
- На всех этапах производства используется чеклисты. Суть проста — некогда писать и читать многостраничные руководства, чтобы «выжить», нужно выполнить данные пункты не задавая лишних вопросов. Прямая аналогия с боевым уставом.
Очевидно, что т.к. такой процесс разработки балансирует на грани «управляемого хаоса», а иначе работать часто не позволяет рынок, значимую роль в обеспечении порядка и предсказуемости принадлежит максимальной автоматизации тестирования, дополняемой контрольными списками (чеклистами). Система должна уметь проверять сама себя и быстро выявлять критичные ошибки — а также мы должны знать что и где нужно быстро проконтролировать (если это сложно автоматизировать) на разных этапах производства: от верстки до эксплуатации под нагрузкой.
Здоровая эволюция данного процесса обычно протекает по следующему сценарию:
- За 2-3 недели проектируется и выпускается новый релиз веб-решения
- Анализируется опыт итерации(ий) и вносятся улучшения в чеклисты разных этапов производства
- Часть костылей, поставленных в предыдущих итерациях — переписывается
- Новые модули системы покрываются сеткой модульных и функциональных тестов
Со временем, процесс развития веб-проекта стабилизируется, вносить изменения становится «не так страшно» — их ждут, система постоянно обновляется, улучшается, относительно здорова не только снаружи, но и внутри. Наступает фаза «эффективного мира», которую остается блюсти — т.к. любой перекос может сбросить производство либо в хаос либо начнется бестолковая формализация и рост издержек.
Для закрепления успеха, достигшие данного уровня нередко внедряют цикл непрерывной интеграции. Для этого необязательно использовать специализированный софт, можно ограничиться группой простых скриптов и горячими сердцами энтузиастов в команде.
Подробнее о чеклистах
Мы бегло повторили эволюцию методик разработки веб-проектов (да и не только «веб») и увидели, что в настоящее время никто, как правило, не выделяет достаточно времени для формальной методичной разработки систем (однако «водопад» и матрицы зависимостей продолжают эксплуатироваться в отраслях, где цена ошибки очень высока — при строительстве домов, мостов, самолетов, при разработке ПО для здравоохранения в США и т.п.), поэтому команды выживают и борются со страхом используя ограниченный набор высокоэффективных инструментов, один из которых — чеклист.
Чеклисты обычно составляются опытными сотрудниками, системными и бизнес-аналитиками, функциональными менеджерами. По мере накопления интеллектуального багажа компании в базах знаний, развиваются и совершенствуются и чеклисты. Суть проста — сэкономить время и деньги, не позволив сотрудникам непроизвольно (а иногда и произвольно) наступать на грабли 2 и более раз.
Пример элементарного чеклиста для программиста:
- Пойми, что нужно реализовать. Если остаются вопросы, тряси аналитика/менеджера/клиента до победного конца.
- Подумай как это реализовать. Не торопись кодировать. Составь логическую модель данных, пару тройку диаграмм UML — отражающих как логику, так и поведение системы.
- Посоветуйся с ведущим разработчиком.
- Спроектируй таблицы базы данных. Обсуди с коллегой/рук.отдела.
- Подумай, как ты будешь тестировать систему.
- Вспомни паттерны проектирования, может что-то из них тебе пригодиться.
- Закодируй функционал, раньше или сразу пока помнишь напиши юнит-тесты.
- Юнит-тесты должны выполняться перед добавлением кода в основной репозиторий
- Опиши логику в вики.
Каждый пункт — может быть ссылкой на методику в wiki.
Ничего вроде сложного, но как часто многие из этих пунктов — игнорируются.
А когда дело касается чеклистов по подготовке веб-проекта к нагрузочному тестированию или обслуживанию серверов… Там столько важных мелочей, которые повторяются из проекта в проект. Люди часто говорят, что помнят их — на самом деле опыт показывает, что не помнят, пропускают важные моменты и занимаются «наступанием на грабли» из проекта в проект, на одно и то же, тратя кучу времени. Не зря опытные руководители проектов закрывают этапы/релизы только при наличии оформленных ответственными сотрудниками чеклистов-отчетов: начиная от верстальщиков, заканчивая системными администраторами.
Монитор качества — в 11 версии платформы Битрикс
При разработке веб-проекта на коробочной платформе «1С-Битрикс: Управление сайтом» можно использовать любой из вышеперечисленных процессов. При этом снижаются следующие риски:
- Разработчикам не обязательно иметь «высшую степень посвящения»: сертификат ZCE и в деталях разбираться в ООП и паттернах проектирования. Все самое сложное находится в ядре платформы, разрабатывается и тестируется внутри компании Битрикс. Программисту PHP и верстальщику достаточно обладать базовыми навыками, минимальным опытом и пройти обучающие курсы (можно уложиться в несколько дней).
- Не нужно заниматься актуализацией документации к системе, т.к. платформа очень подробно описана в официальной документации как для клиентов, так и для разработчиков. Нужно только описать доработки/изменения функционала, выполненные при интеграции веб-проекта.
- Тестировщикам не нужно тестировать всё веб-решение. Платформа тщательно тестируется внутри компании. Необходимо лишь тестировать доработки/изменения функционала. Это существенно сокращает сроки и риски.
Тем не менее, даже работая в таких близких к идеальным условиях, если не соблюдать известные требования к интеграции — можно превратить веб-проект в хаос, который крайне тяжело и дорого поддерживать и развивать. Мало того, отсутствие порядка в коде и архитектуре сильно демотивирует специалистов, начинается текучка кадров — что еще больше усугубляет ситуацию с развитием веб-решения.
Для защиты команд разработчиков от вышеперечисленных рисков в платформу с 11 версии встроен «Монитор качества».
Для сдачи релиза веб-проекта требуется пройти процедуры автоматизированного и ручного контроля на всех этапах производства: от верстки до развертывания на хостинге или облаке и нагрузочного тестирования.
Каждый тест может находиться в нескольких состояниях, часть тестов, особенно рутинных — автоматизирована:
Руководитель проекта или разработчик, по сути, должен для сдачи релиза/итерации «позеленить» дерево тестов — выполнив все тесты и автотесты:
Когда релиз сдан, это видно на рабочем столе и списке отчетов по тестированию:
Особо хочу выделить чеклист для «продвинутых» разработчиков. Данные пункты будут особенно востребованы в Aglle/XP командах, уделяющих серьезное внимание качеству кода и архитектуре:
Команды разработки могут добавлять свои обязательные и необязательные пункты чеклиста и автотесты, например кастомизировать проверку CodeStyle, корректность интеграции с системой контроля версий, наличию и покрытию кода UnitTests и документации в стиле PHPDocumentor:
Факт модификации ядра и библиотек платформы также проверяется автоматизированно:
Идеи на будущее
Разработка, как творческий процесс, должна приносить удовольствие. Тогда и веб-проекты не будут рождаться мертвыми и страшными, и поддерживать их будет легче и интересней :-)
Чеклисты, покрывающие весь процесс разработки на платформе Битрикс, расширяемые внутренними чеклистами команд — мы сделали. Это серьезно снизит риски, связанные с недостаточным знанием и пониманием платформы и вообще «правильных практик» и позволит командам на ретроспективах совершенствовать процесс, добавляя новые пункты в «Монитор качества».
Многие интересные задачи, среди которых прозрачная и эффективная интеграция с распределенными системами контроля версий (Mercurial, git), поддержка средств сборки типа phing, поддержка многоступенчатых сред разработки (dev, testing, stage, production), поддержка систем непрерывной интеграции, поддержка эффективной работы географически распределенных команд — активно обсуждаются.
Искренне надеюсь, что «Монитор качества» позволит командам раскрыть внутренний потенциал, сосредоточиться на творческом процессе разработки и совершенствовании архитектуры, станет своего рода базой знаний, полученных на ретроспективах.
По поводу «устаканивания» в сознании выигрышной стратегии обеспечения достаточного качества сайта… Убежден, что за выделение времени на детальное проектирование и формализацию при разработке сложных и больших веб-решений (или рефакторинге/переписывании таких систем) — нужно бороться, иначе качество не обеспечишь и в производстве начнется хаос. Для средних проектов при наличии «открытого современного» Клиента хорошо подойдет Итерационная методология. Для небольших проектов отлично себя зарекомендовали Гибкие методологии. Не бойтесь экспериментировать и идти вперед. Удачи!
habr.com
Программа мониторинга качества внедрений | SP-ArtGroup
У всех партнеров компании 1С-Битрикс, участвующих в программе «Контроль качества внедрений» могут размещать у себя на сайте значок участника:
Монитор качества содержит рекомендации экспертов компании 1С-Битрикс для выполнения качественной интеграции веб-проекта, начиная с фазы настройки шаблонов дизайна и заканчивая нагрузочным тестированием и организацией аудита безопасности.
Цель программы - помочь партнерам наладить системный подход к вопросам качества. Важной составляющей такого подхода является получение постоянной независимой обратной связи от клиентов.
Зачем нужен контроль качества проекта?
Плюсы для клиента:
- Уверенность в качестве веб-решения, так как его проектирование, интеграция дизайна, разработка, настройка безопасности, нагрузочное тестирование и настройка на максимальную производительность выполнялись по рекомендациям от экспертов «1С-Битрикс»;
- Снижение рисков и затрат на дальнейшее развитие веб-проекта;
- Снижение стоимости и объема технической поддержки веб-проекта;
- Наличие структурированного списка работ по проекту.
Плюсы для разработчика:
- Использование лучших методик проектирования, интеграции, разработки, обеспечения безопасности, настройки под нагрузку и деплойинга веб-проекта на BitrixFramework
- Возможность расширить базовую методику своими инструментами, адаптированными к своему профилю задач: «высоконагруженный магазин», «решение для авиации», «надежный биллинг», «раздача медиаконтента» и другие
- Снижение рисков и сроков интеграции веб-проекта на BitrixFramework за счет использования последовательного стандартизированного процесса, представленного Монитором качества
Выполнение программы сводится к прохождению 2х этапов.
Этап 1. Сдача проекта через Монитор качества:
- Мы всегда уточняем у клиента, не против ли он поучаствовать в данной программе;
- Наш специалист тестирует проект встроенными тестами в административном разделе сайта и выполняет все необходимые рекомендации по оптимизации и улучшению работы сайта;
- Мы обязательно предупреждаем клиентов о звонке из компании 1С-Битрикс и уточняем удобное время для звонка.
- Результаты тестирования направляем в 1С-Битрикс вместе с контактной информацией клиента;
Этап 2. Анкетирование:
- Специалисты 1С-Битрикс звонят клиенту и задают ему 9 вопросов по заранее известной и для всех случаев одинаковой анкете;
- Клиент дает оценку от 1 до 5 баллов по каждому вопросу;
- Возможна оценка «не применимо», если вопрос не актуален для данного проекта;
- В некоторых случаях будут записывать комментарии клиента к оценке.
Проблемы некачественного внедрения
Для большого числа разработчиков и клиентов ключевым вопросом является контроль качества внедрения. Иногда проблемы появляются не сразу, а через определенное время эксплуатации веб-проекта. Именно тогда, когда клиент ожидает максимальной отдачи – могут выявиться существенные недостатки.
Примеры проблем некачественного внедрения:
- Некачественное внедрение: не используется «Эрмитаж», для внесения изменений на сайте нужно переключаться в административный интерфейс; внесенные изменения отображаются не сразу, так как не используется управляемое кеширование;
- Риски безопасности: оставленные тестовые учетные записи со слабыми паролями, недостаточная настройка модуля «Проактивная защита», политик безопасности;
- «Страшно» добавлять новый функционал и развивать проект: код не оформлен в компоненты, нарушены принципы модульности;
- Низкая производительность проекта: из-за некорректных настроек «софта и железа», несоответствия параметров системы рекомендациям «Панели производительности», «Проверки сайта»;
- Потеря возможности обновлений: из-за модифицированного ядра и прямых запросов в коде к базе данных;
- и другие проблемы.
В продуктах «1С-Битрикс» веб-разработчик получает возможность провести доскональную проверку сайта перед сдачей, а клиент – уверенность в качестве сборки проекта.
Если у вас есть сайт созданный на платформе 1С-Битрикс и вы хотите быть уверенными в его работоспособности
sp-artgroup.ru
Качество сборки сайта, мониторинг используемых компонентов
При сдаче проекта клиенту или при приемке его на обслуживание мы обязаны сделать аудит качества сборки сайта.
Нужно проверить все ли сделано качественно и согласно стандартам разработки 1С-Битрикс, а при приемке очень хотелось бы получить максимум информации о продукте, на поддержку которого мы подписываемся.
Один из пунктов аудита это довольно ресурсоемкая задача по проверке используемых компонентов на страницах сайта.
Раньше эта задача выполнялась в ручную, через просмотр кода страниц, либо при помощи эрмитажа, но все равно приходилось открывать каждую страницу, просматривать и что важно — ничего не пропускать!
C маленькими сайтами дела обстояли более-менее сносно, но на проверку больших уходило слишком много времени, а качество этой проверки страдало из-за большого объема проверяемых файлов.
В ходе обучения на третьем курсе академии 1С-Битрикс я познакомился с возможностью написания своих тестов для встроенного мониторинга качества БУС.
И тут родилась идея — «почему бы не сделать автоматический тест, который проверит все файлы и выдаст отчет?».
Создание мониторинга используемых компонентов для CMS 1С-Битрикс.
Я написал не хитрый скрипт который сначала по маске ищет и сохраняет пути на файлы, а затем парсит их и строит отчет, который в конечном итоге отображается в результатах мониторинга качества БУС. Настройки маски довольно простые, меня интересуют все файлы с расширением.php, лежащие в любой папке кроме /bitrix/*, потому что по корпоративным стандартам это единственное место где запрещено что-либо писать без особой на то надобности.
Тест автоматически запускается, если нажать на кнопку «Начать тестирование». Либо его можно запустить, как и любой другой, из диалогового окна теста.
После сканирования файлов, тест будет автоматически завершен, если использованы только стандартные компоненты битрикса, либо провален. В любом случаи можно нажать на ссылку «подробный отчет» и увидеть сводную таблицу.
Таблица разбита на блоки, каждый из которых соответствует файлу в котором был найден вызов компонента. Блок озаглавлен путем до файла, а в строках ниже располагается следующая информация:
- Адрес расположения файла (возможно будет упразнено в новой версии).
- Строка файла в которой вызван компонент.
- Пространство имен компонента, если оно отлично от «bitrix», то будет подсвечено красным.
- Компонент — его системное название.
- Шаблон
Таким образом мы за 10–20 секунд получаем информацию на сбор которой ранее уходило до половины рабочего дня.
Следующим шагом будет запаковка данного решения в модуль, а затем заливка в маркетплейс для того чтобы было удобно устанавливать на различные проекты студии.
klondike-studio.ru
Система контроля качества внедрений от компании 1С-Битрикс
Каждый день мы совершаем несколько покупок, некоторые из них весьма недорогие. А некоторые, наоборот, весьма дорогостоящие. Вне зависимости от того, что мы покупаем, мы хотим получиться качественный продукт. Если мы заправляемся, то, как правило, на «проверенных» заправках. Если покупаем продукты, то смотрим на изготовителя и дату производства. А покупка таких вещей, как мобильный телефон или ноутбук, сопровождается длительным процессом изучения предложений на рынке. Выбирая товар, мы не хотим, чтобы он оказался некачественным: никто не хочет встать посреди дороги на заглохшем автомобиле, отвозить в ремонт только что купленный гаджет или получить пищевое отравление. Задача становится сложнее, когда речь идет о виртуальных вещах, например, о программном обеспечении: мобильном приложении или сайте.
В этой статье мы поговорим о качестве сайта и о том, как получить качественный продукт за свои деньги. Качество — это сложное понятие, которое имеет разный смысл в разных контекстах. В данной статье мы будем понимать под качеством совокупность свойств сайта, обуславливающих его пригодность удовлетворять потребности владельца сайта.
К типовым потребностям владельца сайта отнесем следующие:
- Сайт должен выполнять то, для чего он создавался. Сообщать об услуге, продукте или событии. Продавать товары или услуги. Или просто рассказать о вашей компании потенциальным клиентам.
- Система управления сайтом должна позволять редактировать контент сайта без помощи специалиста. При этом на этапе проектирования сайта необходимо сообщить разработчику, какой контент на сайте вы бы хотели менять часто, а какой редко или никогда.
- Технологии и платформы, которые выбраны для реализации вашего сайта, должны позволять легко добавлять новый функционал или модифицировать имеющийся.
- Программное обеспечение, используемое для разработки и работы вашего сайта, равно как и сам сайт, должны быть безопасными как для клиента, так и для владельца сайта.
Для того, чтобы сделать вывод о качестве проведенных работ, необходим набор инструментов, а также навыков по их применению на практике. Кроме того, такая проверка потребует больших затрат времени. Зачастую убедиться в качестве выполненных работ можно только с привлечением квалифицированных специалистов. В случае, когда разработанный для вас сайт является сложной информационной системой и вы не уверены в своих силах, вы можете заказать аудит проекта у одной из фирм, специализирующихся на таких работах, например, у нас. Если же вы располагает свободным временем и желанием, вы можете попробовать выполнить аудит самостоятельно. Итак, начнем.
Первое в чем надо убедиться — это то, что сайт работает.
Перечень устройств и средств, на которых должен работать ваш сайт, должен быть перечислен в техническом задании. Например, это могут быть только настольные компьютеры и/или мобильные устройства. Как правило, отдельно оговаривается список браузеров, в которых должен работать сайт. Если в техническом задании такого перечня нет, то это говорит скорее о том, что подрядчик не уделяет достаточного внимания проблемам кроссплатформенности и кроссбраузерности. Студии, профессионально занимающиеся разработкой веб-приложений, как правило, имеют актуальный список оборудования и программного обеспечения на котором гарантируется корректная работа разрабатываемого продукта. Кроме того, такие студии обязательно проводят тестирование на кроссплатформенность.
Если такой список есть, то используйте его, в противном случаем можете воспользоваться нашим. Перед приемкой проекта попробуйте основные сценарии использования своего сайта (регистрация в личном кабинете, оформление подписки, покупка, обратная связь) в разных браузерах и на разных платформах. Если вы заметите какие-то ошибки, то зафиксируйте их при помощи скриншотов и/или скринкастов. Составьте подробное описание проблемы и передайте разработчику. Эта работа займет у вас несколько часов, но не будет лишней и сэкономит вам много времени и сил в дальнейшем, при функционировании проекта в реальных условиях.
Убедившись, что внешне сайт работает как надо, вы можете задаться вопросом — «А насколько качественный код внутри моего приложения?».
Справедливости ради отметим, что актуальность этого вопроса завит от того, как вы собираетесь использовать свой сайт. Если это лендинг, сайт визитка или корпоративный сайт, то качество кода не имеет принципиального значения. Дело в том, что такие сайты, как правило, крайне редко модифицируют или дополняют. Сайт существует 2-4 года, а затем вы просто заказываете новый сайт, потому что хотите быть в тренде. Если же для вас разработали интернет-магазин (или витрину), портал или информационную систему, то дело обстоит иначе. В такие программные продукты изменения вносятся достаточно часто. При этом стоимость внесения изменений напрямую зависит от качества кода исходного продукта. В своей практике мы сталкивались с такими ситуациями, когда незначительное расширение функционала приводило к необходимости полностью переписывать определенный модуль. Таким образом, в определённых случаях качество исходного кода может быть крайне важно.
Оценить качество кода - весьма сложная задача. Подавляющее число студий не проводят операции контроля качества кода. Это происходит по нескольким причинам. Во-первых, число специалистов, способных проводить такие работы ограничено и стоят их услуги весьма дорого. Во-вторых это занимает много времени, а сроки реализации проектов, как правило, изначально имеют недооценку. Другими словами, на это просто не хватает времени и бюджета.
Как можно оценить качество выполнения проекта, не будучи специалистом?
Компания «1С-Битрикс» предлагает свое решение этой проблемы (для любых проектов, разработанных на CMS «1C-Bitrix»). Называется оно — «Программа мониторинга качества внедрений». Суть программы в следующем: после окончания работ по проекту разработчик выполняет дополнительный этап — «Сдача проекта по монитору качества».
На этом этапе разработчик последовательно проходит серию тестов (66 тестов, из которых 20 обязательных). При прохождении тестов затрагиваются вопросы правильности интеграции дизайна и качества разработки, производительности, безопасности, размещения на хостинге. «Монитор качества» — специальный инструмент, встроенный в административную панель сайта (портала). Если ваш проект сдан по программе контроля качества внедрений, то результаты вы сможете просмотреть на странице /bitrix/admin/checklist_report.php?ID=2&lang=ru. Несмотря на то, что всего часть тестов является обязательной, хорошим знаком будет то, что сданы все тесты, даже необязательные.
Сдача проекта по монитору качества не может служить гарантией того, что сайт написан идеально. Но в тоже время вы можете быть уверены, что при создании сайта на базе CMS «1С-Битрикс» использованы лучшие практики, рекомендованные разработчиками CMS: шаблоны сайта корректно установлены в систему, сайт правильно настроен на хостинге, хостинг, в свою очередь, корректно сконфигурирован, вся система (хостинг и сайт) не имеет критических уязвимостей.
Дополнительно к тестированию технической части сотрудники компании «1С-Битрикс» проводят анкетирование клиента по телефону.
Другими словами, они будут общаться с вами. Это является дополнительным стимулом для исполнителя выполнить работу на высоком уровне. Подробнее о программе контроля качества решений вы можете почитать тут.
Таким образом, если в качестве системы управления контентом используется «1С-Битрикс», при заключении договора постарайтесь добавить в него пункт о том, что проект должен быть сдан по программе контроля качества внедрений. А также не забудьте проверить, есть ли в техническом задании на разработку сайта перечень устройств и ПО, на которых ваш сайт должен корректно работать. Наличие двух этих пунктов говорит о том, что студия уделяет внимание вопросам качества разрабатываемых продуктов.
Алексей Вахняк
Директор по стратегическому развитию, whatAsoft
whatasoft.net
Проверка качества сборки сайта - Битрикс-Эксперты bitrix.expert
В статье будет рассмотрена значительная часть способов проверки качества: что-то может сделать менеджер, не подгружаясь в программный код, а для некоторых проверок нужен технически подкованный специалист с большим опытом. Очень важно не доверять проверку качества посторонним людям, а потратить время и научиться делать её самостоятельно. Ведь в конечном итоге, лучший способ сэкономить - это поручить работу тем людям, которые умеют делать действительно качественный продукт.
Памятка менеджеру
Как показывает практика, очень важно научиться отслеживать корректность работы механизма кэширования.Механизм кэширования в Битрикс - один из основных. Без него система превращается в страшного неповоротливого монстра, генерирующего страницы по 2-3 секунды, что некорректно. Плохие разработчики часто врут, оправдывая своё незнание этого механизма. Не будьте чересчур доверчивы. Ниже мы расскажем, как проверять работу за разработчиками.Мы расскажем, как используя визуальные инструменты 1С-Битрикс проверить работу механизма кэширования на сайте.
Войдите на сайт как администратор и включите отображение статистики:
На странице появятся вот такие блоки, показывающие статистику работы каждого компонента
При правильно настроенном кэшировании число запросов при повторной загрузке страницы должно равняться НУЛЮ:
При этом, если нажать на кнопку "Сбросить кэш"
То запросы в статистике снова появятся
Итак, ещё раз:зайдите под административным аккаунтом, включите отображение статистики и убедитесь, что при повторной загрузке той же страницы запросов к серверу не делается.Наличие Ajax-механик на странице не является оправданием неработающему механизму кэширования. Все вышеописанные действия должны быть выполнимы.
Тимлиду
Монитор качества
Честное прохождение стандартного монитора качества занимает порядка 4-5 часов, но содержит действительно хорошие проверки и инструкции.
Справка
Монитор качества содержит порядка 66 тестов, из которых только порядка 10 будут для Вас неактуальны.
Часть тестов проходится автоматически, а часть придётся произвести вручную.
Особенно ценно наличие вкладки "рекомендации" у каждого из тестов
Честно пройти тест будет полезно даже опытному разработчику. Что уж говорить про того, кто недавно начал покорять тонкости системы.
Мастер интернет-магазина
На прохождение мастера у Вас уйдёт от 1,5 до 5 часов, на даже опытный разработчик найдёт в нём полезные для себя аспекты.
Автотесты от "Артикул Медиа"
http://marketplace.1c-bitrix.ru/solutions/articul.checklist/Модуль содержит специфический, но полезный набор тестов.
Возможно, Вы не используете в качестве репозитория GitHub/Bitbucket, как это делает Артикул, но обратите внимание хотя бы на их тесты для контента, они стоят того:
Кстати, исходные коды решения выложены на BitBucket, так что Вы можете легко модифицировать и использовать их!
Собственные автотесты
Написать свои тесты намного проще, чем кажется. Этому посвящена глава в курсах Битрикс, и сложность скорее заключается в том, чтобы найти идеи для тестов, достаточно технологичные для исполнения, и достаточно полезные, чтобы за них имело смысл браться.Мы составили для Вас список идей, которые могут Вам пригодиться.
1 - Проверка наличия в .parameters.php всех переменных шаблона - если это условие не выполняется, контент-менеджер может случайно стереть часть необходимых настроек с страница сайта сломается. Базовая проверка легко осуществляется проверкой с помощью регулярного выражения всех файлов компонента.
2 - Наличие лишних шаблонов компонентов - если это условие не выполняется, то в проекте разрастается куча дублей, и архивных папок. Поддерживать такой проект очень трудно. У автора статьи есть заготовки, не обёрнутые в автотест, свяжитесь, если захотите реализовать эту идею.
3 - Отсутствие незакомментированного вывода ошибок - если это условие не выполняется, на каких-то страницах будет выводится отладочная информация, что не есть хорошо.
4 - Оценка уникальности контента (в %) и поиск полных дублей.
5 - Дубли тегов. Очень частая ошибка, возникающая из-за несоблюдения РеГиСтРа написания букв в тегах. Очень легко проверяется и сводится на нет, а с небольшим усложнением логики позволяет решать и более сложные проблемы (пробелы, апострофы и т.п.)
6 - Поиск битых ссылок и картинок
7 - Проверки, связанные с требованиями по переходу проекта между отделами компании (проверка правил вёрстки, размещения файлов, наличия определённых настроек и т.п.) - удобно для упрощения перехода проекта из отдела в отдел.
Юнит-тестирование
Юнит-тестирование не нужно при сборке сайтов.Но оно может пригодится при разработке типовых решений и модулей на D7 (в том числе модулей для Битрикс-24)Если это интересно Вам, прочитайте статью на Хабре.
Код ревью
Большинство ошибок джуниоров типичны, например:- не обнулённые переменные- не обработанные ошибки, например, если производится поиск элемента/элементов по условиям, но не рассматривается ситуация, когда элементы не найдены.- отсутствие обработки входных данных - очень нудное, но крайне необходимое, когда речь, например, заходит о взаимодействии двух систем- не учтённые XSS, SQL уязвимости- компоненты не на классах- отсутствие phpDoc в самописных компонентах- некорректно размещённые шаблоны компонентов. Не все возможные способы размещения одинаково корректны и удобны для эксплутации- нечитаемый, непонятный код (такой, как в старых компонентах и модулях Битрикс ;) ). Вопреки распространённому заблуждению, код должен писаться для людей, а не для машин.
К сожалению, не существует никакого способа борьбы с ними, кроме регулярного код-ревью и личного общения с разработчиками, которые эти ошибки допускают. Но есть и хорошие новости: в среднем джуниор перестаёт делать грубые ошибки через 2-3 месяца регулярного код-ревью и воспитания.
bitrix.expert
|
| ||||
|
| ||||
| |||||
| |||||
|
| ||||
| |||||
| |||||
|
| ||||
|
| ||||
|
| ||||
|
| ||||
|
| ||||
| |||||
|
|
xn--80ahcjeib4ac4d.xn--p1ai
