В качестве альтернативы хотели предложить «Битрикс24». Наша команда разрабатывает софт для управления бизнесом. В сервисе доступны инструменты для совместной работы и общения команды в офисе и на удаленке:
Корпоративный мессенджер
Видеозвонки
Документы
Диск
Таск-трекер
А еще в «Битрикс24» есть бесплатный тариф без ограничений по количеству пользователей и времени использования.
Конечно, готовим дистрибутив или облачный портал, как тестовую среду, в зависимости от ситуации. В ночной прогон, например, робот полностью все готовит сам, собирает дистр, ставит его. В процессе производства текущих обновлений днем, смок-тест, например, не ставит свой дистр, а может ходить вообще по любому облачному порталу, подготавливая лишь необходимые данные для UI-теста.
Почему вы решили, что применяете гибкие методологии разработки?
Этапы, конечно, есть. Не разработав начальную версию продукта (или отдельно верстки, дизайна, логики), мы не сможем провести первую итерацию тестирования или первичного контроля реализованной части.
Разработчики тестируют определенный набор кейсов. Набор кейсов для проверки, конечно, на много меньше чем тот, что имеют тестировщики.
Разработчики пользуются любыми тестами, которыми захотят. Всю UI-автоматизацию и тестирование осуществляет отдел автоматизированного тестирования.
4-й ваш пункт я не понял. Автоматизацией занимается у нас отдел автоматизированного тестирования. Они же делают чек логов прогона тестов.
Разработчик сам не способен, ему нужен секретарь?
Согласен с вами, хочу со временем передать эту часть разработчикам =). Пока, как историческое наследие, это делают ребята из отдела автоматизации.
Есть php-файл с набором методов для работы с сущностями продукта: создание задач с предустановленными параметрами, создание лида, удаление поста в ЖЛ и т.д. На каждый тестируемый модуль. Необходимые параметры создания сущности мы передаем через гет-параметры (что делаем, с какой сущностью, какие параметры у сущности или действия). Далее процесс автотестирования прецедента, например, удаления задачи выглядит так:
1. Робот дергает через урл наш php-файл, передав туда метод очистки старых демо-данных. Имена сущностей у нас предопределены, поэтому всегда знаем, что относится к тестовым данным, которые необходимо очистить
2. Робот дергает через урл наш php-файл, передав через гет необходимый набор параметров: создаем задачу, с крайним сроком, с id ответственного номер такой-то, и т.д.
3. Робот через UI идет по сценарию: переходит в список задач. У созданной выше задачи кликает на пункт меню «Удалить». Проверяет, что задачи в списке нет
Ночные сборки с запуском тестов это и есть CI, на сколько могу судить.
И да, и нет. «Красивый» классический CI он же как: разработчик коммитит код или банч исправлений, сразу же стартует сборщик. А там и автотесты стартуют, а потом, в случае ошибки, разработчик уведомляется об этом. А потом итерация повторяется.
У нас, в силу некоторых особенностей, есть элементы CI, представленные как раз в ночных сборках.
Смок тест 32 часа? Да даже есть 8 (ночь) все равно как-то не тянет. Или какие тесты вы запускаете ночью? На картинке с видами тестирования у вас регресс в колонке с ручным. Наверное, только полный регресс может столько времени занимать
Нет-нет, смок тесты по крупным модулям, например CRM, идут максимум 1,5-2 часа. Это, пожалуй, самый большой модуль с множеством важных бизнес-кейсов. Средний смок тест идет 15 минут.
Ночью стартуют большие прецедентные тесты, вообще все что есть, по всем модулям. Днем — смотрим по ситуации. И можем обойтись только смок тестом или пускаем параллельно с ручной проверкой большой сценарный тест.
До того, как тестировщики получают готовый продукт или версию обновления, происходят множественные итерации проверок на этапе создания: первичное соответствие ТЗ, соответствие дизайну, верстке, реализованная логика.
Андрей, приложение «1С-Битрикс: кассы» — это коннектор между интернет-магазином на «1С-Битрикс» и ККМ.
Конечно же, вы устанавливаете стоимость (с НДС внутри цены, С НДС сверху или с разными ставками НДС) для каждого из товаров внутри админки, а потом цены с выбранным параметром идут на «печать» в чек.
Так как ставка НДС может быть разной, то в 1С-Битрикс НДС рассчитывается для каждой строки чека.
В административной панели сайта можно настроить ставку НДС как для всего каталога товаров, так и для каждого товара в отдельности.
Соответственно, в чеке мы будем печатать корректный НДС, с учетом возможностей ККМ и законодательства.
Правильно. Нет отдельного закона от 1 февраля. Есть — 290-ФЗ от 3 июля 2016 к 54-ФЗ и этапы изменений, в нем прописанные, вплоть до 1 июля 2018 года.
С 1 февраля, в соответствии с ним, ФНС больше не будет регистрировать старые кассовые аппараты с ЭКЛЗ.
А с 1 июля 2017 года вступят в силу все изменения, описанные в статье.
Привет!
В качестве альтернативы хотели предложить «Битрикс24». Наша команда разрабатывает софт для управления бизнесом. В сервисе доступны инструменты для совместной работы и общения команды в офисе и на удаленке:
Корпоративный мессенджер
Видеозвонки
Документы
Диск
Таск-трекер
А еще в «Битрикс24» есть бесплатный тариф без ограничений по количеству пользователей и времени использования.
Больше информации о функциях можно найти по ссылке: https://www.bitrix24.ru/features
Привет!
Спасибо за включение нашего сервиса в подборку.
В «Битрикс24» также есть видеозвонки, корпоративный мессенджер, таск-трекер и совместная работа с документами :)
Больше информации о функциях можно найти по ссылке: https://www.bitrix24.ru/features/
С уважением, команда «Битрикс24»
Этапы, конечно, есть. Не разработав начальную версию продукта (или отдельно верстки, дизайна, логики), мы не сможем провести первую итерацию тестирования или первичного контроля реализованной части.
Разработчики тестируют определенный набор кейсов. Набор кейсов для проверки, конечно, на много меньше чем тот, что имеют тестировщики.
Разработчики пользуются любыми тестами, которыми захотят. Всю UI-автоматизацию и тестирование осуществляет отдел автоматизированного тестирования.
4-й ваш пункт я не понял. Автоматизацией занимается у нас отдел автоматизированного тестирования. Они же делают чек логов прогона тестов.
Согласен с вами, хочу со временем передать эту часть разработчикам =). Пока, как историческое наследие, это делают ребята из отдела автоматизации.
Есть php-файл с набором методов для работы с сущностями продукта: создание задач с предустановленными параметрами, создание лида, удаление поста в ЖЛ и т.д. На каждый тестируемый модуль. Необходимые параметры создания сущности мы передаем через гет-параметры (что делаем, с какой сущностью, какие параметры у сущности или действия). Далее процесс автотестирования прецедента, например, удаления задачи выглядит так:
1. Робот дергает через урл наш php-файл, передав туда метод очистки старых демо-данных. Имена сущностей у нас предопределены, поэтому всегда знаем, что относится к тестовым данным, которые необходимо очистить
2. Робот дергает через урл наш php-файл, передав через гет необходимый набор параметров: создаем задачу, с крайним сроком, с id ответственного номер такой-то, и т.д.
3. Робот через UI идет по сценарию: переходит в список задач. У созданной выше задачи кликает на пункт меню «Удалить». Проверяет, что задачи в списке нет
И да, и нет. «Красивый» классический CI он же как: разработчик коммитит код или банч исправлений, сразу же стартует сборщик. А там и автотесты стартуют, а потом, в случае ошибки, разработчик уведомляется об этом. А потом итерация повторяется.
У нас, в силу некоторых особенностей, есть элементы CI, представленные как раз в ночных сборках.
Нет-нет, смок тесты по крупным модулям, например CRM, идут максимум 1,5-2 часа. Это, пожалуй, самый большой модуль с множеством важных бизнес-кейсов. Средний смок тест идет 15 минут.
Ночью стартуют большие прецедентные тесты, вообще все что есть, по всем модулям. Днем — смотрим по ситуации. И можем обойтись только смок тестом или пускаем параллельно с ручной проверкой большой сценарный тест.
До того, как тестировщики получают готовый продукт или версию обновления, происходят множественные итерации проверок на этапе создания: первичное соответствие ТЗ, соответствие дизайну, верстке, реализованная логика.
Конечно же, вы устанавливаете стоимость (с НДС внутри цены, С НДС сверху или с разными ставками НДС) для каждого из товаров внутри админки, а потом цены с выбранным параметром идут на «печать» в чек.
В административной панели сайта можно настроить ставку НДС как для всего каталога товаров, так и для каждого товара в отдельности.
Соответственно, в чеке мы будем печатать корректный НДС, с учетом возможностей ККМ и законодательства.
Проверяйте апдейты
С 1 февраля, в соответствии с ним, ФНС больше не будет регистрировать старые кассовые аппараты с ЭКЛЗ.
А с 1 июля 2017 года вступят в силу все изменения, описанные в статье.