Всем привет! Меня зовут Костя Гусев @nevoy, и в М.Видео-Эльдорадо моя команда развивает внутренние и партнёрские продукты. Перед тем, как поменять ассортимент или цены на полках 1 300 розничных магазинов, мы должны убедиться, что новое товарное предложение, как минимум, не приведёт к оттоку текущих покупателей, а еще лучше – привлечет новых. Для проведения подобных экспериментов мы пересмотрели подход к A/B-тестированию с учетом нашей офлайн-специфики, о чем и хотим рассказать в этой статье.
Привет! Меня зовут Татьяна Дерягина, я QA-инженер из команды мобильного тестирования в СберМаркете. Моя команда работает дистанционно, находясь в разных городах России. Хочу рассказать, как как мы адаптировались к процессу тестирования, без большого количества реальных девайсов и не потеряли качество продукта.
В этой статье я поделюсь своим опытом создания Telegram Bot-а для автоматизации тестирования.
Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. При создании списка проверок мы попросили помощи у команды информационной безопасности, отдельная благодарность Дмитрию Терёшину за проведённую встречу с подробным разбором всех кейсов. Его интересную статью по работе утилиты CheckKarlMarx можно увидеть здесь.
В конце концов получили из кейсов самые опасные области атак на приложение с точки зрения безопасности, взяли high-сценарии и добавили их к себе в список чек-листов для регрессионного тестирования. Так родилась идея рассказать в статье, что популярного и интересного можно добавить в список кейсов для регресса в любой компании.
Речь пойдет о том, какие проверки безопасности и какие кейсы мы советуем добавить при регрессионном тестировании. Проверки, описанные в этой статье, — это не все проверки, которые проводятся у нас, их, конечно же, больше, но рассказывать обо всех проверках небезопасно, поэтому тут всего лишь небольшая их часть, которую следует учитывать при тестировании безопасности приложения. Также не забываем о документах о неразглашении определенных данных.
Привет, Хабр! Каждый день тысячи программистов трудятся не покладая рук. Они пишут код, контактируют между собой и, как и любой человек, совершают ошибки. Проблемы в коде могут повысить уровень рисков и стать критическими для компании. И с целью выявления таких ошибок специалисты проводят анализ кода.
Привет, Хабр!
Вам наверняка знакома ситуация, когда обновления, которые необходимо выкатить, — это россыпь отдельных файлов, которую надо соединить, протестировать на всех видах продуктов и поддерживаемых ОС, а потом загрузить на серверы, чтобы апдейты получили конечные пользователи.
Но что, если обновлений насчитывается 250+ типов? А если поддерживаемых ОС — порядка 250? И для тестирования требуется 7500+ тестовых машин? Такой вот типичный хайлоад. Который должен постоянно масштабироваться…
Я — Иван Лауре, менеджер по тестированию в «Лаборатории Касперского». Именно так, как я описал выше, выстроено «выкатывание» у нас. В этой статье я расскажу о центральной части всего процесса — как мы тестируем обновления для более чем 500 уникальных версий ПО, да и саму распределенную систему тестирования. Не сомневаюсь, что наш опыт будет вам полезен.
Привет, меня зовут Антон Фурсов, и я занимаюсь автоматизацией тестирования в Pixonic. Сегодня поговорим про уже набившую уже всем оскомину автоматизацию тестирования. В последнее время стало модно внедрять ее везде и всюду, но в геймдеве она до сих пор встречается не так часто — из-за специфики самой сферы.
В этой статье хочется поднять наболевшую для большинства тестировщиков тему – это доступы к тестируемым программным продуктам. Не всегда доступы к ПО предоставляют тестерам здесь и сейчас. И именно поэтому сотрудники вынуждены ждать начало этапа STLC, относительно к этапам работ проекта именно из-за такой проблемы.
Время идет, сроки становятся все короче и короче, а тестировщику еще не предоставили возможности «познакомиться» с программой. Конечно, тестер задастся вопросом: «А как я успею изучить ПО и уж тем более протестировать, если у меня нет доступа к нему?». Здесь я вам отвечу, что изучить и протестировать – можно. Даже без входа в приложение.
Всем привет! На связи Николай Мезинов, разработчик фронтенда в продуктовой команде DevPlatform. Хочу поделиться опытом, как мы ускоряли прохождение e2e-тестов на Cypress в пайплайнах GitLab.
Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье хочу вольно порассуждать о схожести моделей когнитивной деятельности в тестировании ПО и расследовании уголовных дел. Мне кажется, у этих сфер много общего — например, оба процесса представляют из себя исследование результатов неправильного поведения, причин и следствий такого поведения и документирование результатов.
Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент.
Всем привет, я Никита Мунтян, QA Load Engineer в inDriver. Пришел в компанию в 2020 году развивать направление нагрузочного тестирования. В первую очередь познакомился с коллегами, выстроил план работы и начал планомерно выстраивать процессы и технические решения.
Тогда передо мной было пустое поле — делай как хочешь и как видишь, возможностей для творческой реализации много. Оставалось понять, что хотят увидеть от нагрузки, и какой подход использовать. Мы решили делать Load as a Service, об этом и расскажу под катом.
Всем привет! На связи Макеева Анастасия. Я лидирую автоматизацию тестирования проекта витрин в Утконос Онлайн.
Ввиду сложившейся ситуации система управления тестированием, которую мы используем, вот-вот с нами попрощается: действие лицензии скоро закончится.
Недавно нашей команде выпала возможность попробовать систему управления тестированием Test IT.
Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»
Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.
Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.
После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)
Как известно, основной проблемой в тестировании является отчетность по прогонам. Некоторые компании собирают данные в отдельном хранилище. Вместо того, чтобы вручную организовывать хранение, было решено сохранять их в Test IT. Такие данные как: исход, время выполнения и количество автоматизированных кейсов позволяют разделить тесты на выборки и дать оценку покрытия автотестами.
Лонгрид посвящается любителям CLI в знак солидарности лучшего эмулятора терминала на OS Android, который испытывает «кошмарную» монополию Google.
В данной работе вербализация пойдет о нижеизложенном со всеми остановками:
[+] глубоко настраивать средý (флэшка, виджет, стиль, зеркала и конфиги);
[+] управлять серверами через ssh;
[+] скачивать ролики/отрывки с YouTube;
[+] нарезать видео, создавать gif;
[+] воспроизводить текст/музыку/радио прямо в CLI;
[+] нарезать mp3-бигфайлы (аналогов приложений на Android попросту нет), и склеивать аудиофайлы;
[+] редактировать документы;
[+] проверять орфографию: как текстовых файлов, так и различных статей по url, например, проверка орфографии статей на Habr-e;
[+] генерировать словари различной сложности со скоростью Си;
[+] создавать блок-схемы; графики; облако слов и даже 3D-визуализацию;
[+] заниматься Data Science на Android-мощностях;
[+] тестировать интернет соединение/интерфейс (требуется частично Root);
[+] сниффить/сканировать сети (требуется частично Root);
[+] запускать и управлять TOR-сетью (deleted);
[+] управлять приложениями и процессами в ОС Android (требуется Root);
[+] анализировать память;
[+] защищать любые данные от случайного редактирования/уничтожения (требуется Root);
[+] автоматически шифровать и бэкапить по ночам любые данные в своё облако;
[+] чекать username(s) и e-mail(s);
[+] проводить аудит безопасности (об опасности сердить скрипт-кидди с их любимыми: «сниффить, парсить, брутить, дампить, сканить, фишить»);
[+] работать с электропочтой;
[+] изучать UNIX/shell;
[+] программировать на Android (на выбор пользователя. В Termux портированы несколько интерпретируемых и компилируемых языков программирования);
[+] запускать python/php/npm скрипты в т.ч. в одно касание с рабочего стола;
[+] работать с криптографией, стеганографией и цифровыми подписями;
[+] парсить данные;
[*] и даже запускать GNU-GUI-софт из CLI.
Всем привет! Сегодня мы поговорим об интеграционном тестировании платежного шлюза, но перед этим расскажу немного про нашу команду и наш проект. Мы (ContactPay) — самостоятельный финтех-стартап внутри QIWI, строим высокопроизводительный отказоустойчивый платежный шлюз и соответствуем стандартам безопасности PCI DSS.
Как платежный шлюз мы интегрированы со множеством внешних API, это могут быть и платежные системы, и сторонние сервисы мониторинга, антифрода, KYC (know your customer) и так далее.
Как финтех — работаем с большим количеством финансовых данных, и нам важны и сохранность, и консистентность и безопасность данных. Исходя из требований к нашему продукту у нас есть высокие требования к нашему коду, поэтому мы определили критичные для нашего проекта метрики кода и стараемся поддерживать их на высоком уровне.
Мы стараемся писать корректный код с наименьшим количеством багов. Код должен быть читаемым, самодокументируемым и поддерживаемым. Кроме того, он должен быть безопасным, так как мы финтех и у нас PCI DSS, это накладывает определенные требования к безопасности. А ещё код должен быть тестируемым.
Сегодня мы поговорим о двух метриках — корректность и тестируемость. Одна метрика напрямую влияет на другую, через тестируемость мы добиваемся корректности в том числе, мы проверяем, насколько код ожидаемо работает.
Перед тем как говорить об интеграционном тестировании, нужно понять, какой процесс мы будем тестировать. Рассмотрим сценарий интеграционного тестирования из жизни. Это сценарий выставления счета, на самом деле процесс проходит в несколько этапов, но мы рассмотрим в посте первые две стадии этого сценария.