Разработка и запуск нового продукта - это всегда риск. Зайдет, не зайдет. Все зависит от возможностей (люди, деньги), компетенций, опыта, да и в целом понимания, зачем все это делать. Даже самая детально проработанная стратегия может в итоге провалиться. Главное понимать, в чем реальная польза продукт, тогда и процесс разработки пойдет увереннее.

С таким подходом мы пришли в 2019 к разработке готового решения для автоматизации торговли на маркетплейсах - RDV Маркет. Сделали его на бессмертной системе 1С. Ее мы знаем от и до, и убеждены, что для запуска нового проекта с точки зрения бизнеса - это наиболее подходящий вариант. Но об этом позже. Пока расскажем, как все начиналось, и к чему в итоге привело.

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

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

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

В этом руководстве я покажу, как протестировать использование внешнего API с помощью Python моков.

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

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.

Что вообще такое, эта матрица компетенций?

Как ее использовать QA менеджеру?

Как ее строить?

Зачем ее строить?

Причем тут грейды?

Все это мы узнаем в этой статье, без душных терминов (почти).

Привет, я Алексей, QA Automation Engineer в команде «Интеграции» в Петрович-ТЕХ. Занимаюсь разработкой фреймворка автоматизированного тестирования сервисов интеграции, для REST и SOAP. 

Наблюдение: когда приходишь на собеседование на должность Junior QA Automation, то обязательно просят разработать автотесты для API. Звучит логично, но не так уж и просто: когда только начинаешь свой путь в автотестировании, тебе не всегда очевидно, как должен выглядеть рабочий тестовый фреймворк, из чего он должен состоять, как правильно написать тесты, а к ним тестовые данные. «Сырые» тесты, которые описывают в книгах и разных источниках – не всегда выручают.

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

Надеюсь, статья будет интересна начинающим авто-тестировщикам и тем, кто уже разрабатывает автотесты для API.

Дисклеймер: этот туториал написан преимущественно для студентов, изучающих Пролог. Если вы человек практического толка, то, скорее всего, вы не найдете здесь ничего полезного.

Выделяют три основные парадигмы программирования: императивное, функциональное и логическое. Императивное — это про C/C++, Java, Golang, Javascript и тд. Я даже могу сказать "C подобный, значит императивный". Функциональное — это про Haskell, F#, Lisp, ленивые вычисления, чистые функции и т.д. Но что такое логическое программирование? Какие задачи оно решает и на чем программировать? Не уже ли логическое программирование способно доказать любую математическую теорему? Или как?

Это статья — туториал по логическому программированию на Пролог для чайников.

Туториал будет интересен в первую очередь:
1. Любознательным
2. Студентам, которым приходится изучать Prolog в вузе

Я постарался лаконично, понятно, без излишних приступлений и отступлений научить основам программирования на Пролог.

Говоря о разработке сайтов с использованием CMS 1C Bitrix вопрос покрытия тестами поднимается редко. Главная причина в том, что большинство проектов обходится штатным функционалом, который предоставляется системой - его сложно (да и, в общем-то, незачем) тестировать.

Но со временем проект разрастается, появляется необходимость интеграции со сторонними сервисами и службами (платежные системы, API служб доставки и другие), либо же разрабатывается все более и более специализированный функционал. И чем дальше, тем больше объем кода, контроль за которым лежит уже на разработчике.

Это и является предпосылкой для внедрения в CMS механизма тестирования.

Не с начала

Много вы знаете инструментов тестирования, которые умеют:

• Получать шаги на языке Gherkin сразу из того, что накликал пользователь?
• Создавать видео-инструкции автоматически, с субтитрами, black Jack'ом и Еленой?)
• Создавать *.feature файл на английском языке в румынском интерфейсе, для пользователя, говорящего на итальянском?

Об этом доступно и наглядно (с картинками) в этой статье, не переключайтесь...

Вступление

Данная статья представляет собой обзор созданного в недрах OpenSource инструмента тестирования прикладных решений 1С под названием vanessa-automation. Данный проект является прямым продолжением широко известного в узких кругах проекта vanessa-behavior (fork был создан на версии 1.1.131). Кстати, существуют и другие fork'и.

Контекст

Как бы не было приятно думать, что каждый читатель этой статьи на habr знает 1С, все таки, обманываться не вариант. Потому не рискну продолжить, не сформировав у читателя представления о платформе 1С и ее возможностях, используемых в vanessa-automation (далее va или Ванесса).

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

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

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

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

Про Flutter вспоминают тогда, когда нужно быстро сделать красивое и отзывчивое приложение сразу для нескольких платформ, но как гарантировать качество «быстрого» кода?
Вы удивитесь, но во Flutter есть средства для того, чтобы не только обеспечить качество кода, но и гарантировать работоспособность визуального интерфейса.
В статье рассмотрим, как обстоят дела с тестами на Flutter, разберем виджет-тесты и интеграционное тестирование приложения в целом.

Статья будет полезна Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчеркнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю.

Привет, Хабр! Статья была ранее опубликована в блоге компании, который сейчас удален. Перевыкладываю, так как считаю, что статья не потеряла актуальность на текущий момент времени.

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

Если повезло, то кандидат знает о необходимости проверки сетевого взаимодействия, но, за редким исключением, его знания ограничены Rewrite или Breakpoints.

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

Привет, меня зовут Даша, я работаю тестировщицей клиентского мобильного приложения в компании Ozon.

Сегодня поговорим о снифферах в тестировании мобильных приложений –– программах для перехвата, анализа и модификации трафика. Пожалуй, самый популярный сниффер из тех, о которых мне доводилось слышать — Charles. Про него уже не раз писали на Хабре, есть довольно детальные разборы. Но не Charles-ом единым! 

После доклада Юры Лучанинова, я решил для себя попробовать Flutter. Чтобы мозг размять, и чтобы было о чем похоливарить с мужиками на кухне. Дело пошло. Я начал смотреть, потом читать, потом писать. И вроде все получается, приложения запускаются, и то что объясняют — понятно, все просто. Но не без “но” — объясняют не все. А поскольку платформа, ЯП, подходы и даже предметная область для меня новые, то подобное вызывает раздражение, ведь у тебя “не запускается”, а ты даже не знаешь что гуглить: Dart/Flutter/Window/Screen/Route/Widget?

Перечитывать всю документацию Dart, Flutter и его виджетов конечно же не хотелось, ведь времени у меня не много, и мне лишь хотелось присмотреться к Flutter. Вот было бы здорово, если бы был небольшой гайд, в котором описано все нужное, но не больше, для понимая и написания не слишком сложных приложений на Flutter!

Когда новичок во Flutter спрашивает, почему какой-то виджет с width: 100 не ширины 100 пикселей, обычно ему отвечают, что надо обернуть этот виджет в Center, верно?

Не надо так делать

Если так отвечать, то к вам будут возвращаться снова и снова, спрашивая, почему какой-то FittedBox не работает, почему этот Column переполнен или как работает IntrinsicWidth.

Сначала объясните, что Flutter компоновка очень отличается от HTML компоновки (особенно, если говорите с веб-разработчиком), а затем скажите, что необходимо запомнить следующее правило:

Ограничения для виджетов объявляются в родителях. Размеры (желаемые) задаются в самом виджете. Позиция виджета на экране устанавливается родителем

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

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

В данной статье я расскажу как мы решали эту задачу.