Всем хорош pytest, но его терминальный вывод можно сделать ещё полезней. Наверняка для этого есть готовые плагины и даже фреймворки. Но можно сделать и самостоятельно. А попутно разобраться в хуках и создании плагинов, увидеть основы ООП в действии и по достоинству оценить открытость кода pytest.

Всем привет! Нагрузочные тесты за 5 минут (ну почти).

Не так давно делился историей о том, как решали проблему E2E автотестов в маленьком проекте. Продолжим историю).

Для автоматизации тестирования веб‑приложений существует множество инструментов. Они помогают разработчикам и тестировщикам повысить эффективность своей работы и снизить рутину. Сегодня рассмотрим два популярных фреймворка: Selenium и Playwright. Взвесим все плюсы и минусы, а вывод вы сделаете сами. Всем привет. Меня зовут Никита. Я работаю разработчиком в «Совкомбанк Технологии». Решил поделиться своим мнением о фреймворках Selenium и Playwright. Оговорюсь сразу. Данная статья носит исключительно образовательный характер, не ставит своей целью рекламу и не являются частью коммерческих продуктов компании. Ну, как вы понимаете, нет мне никакого смысла рекламировать тот или иной фреймворк. Поехали!

Привет, Хабр! Меня зовут Татьяна Ошуркова, я разработчик и системный аналитик. Не так давно у меня вышла статья Не базовые навыки. Как расширить свои возможности и найти новые подходы в работе, где я поделилась различными навыками и инструментами, которые могут быть полезны не только разработчику, но также и системному аналитику.

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

Привет, Хабр! Меня зовут Максим, я инженер по автоматизации тестирования в компании 1221СИСТЕМС и хотел бы поделиться своим опытом и рассказать путь настройки автотестов от минимального рабочего состояния до масштабного проекта. Поделюсь тем, какие инструменты я внедрил для улучшения процессов на нашем проекте.

У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только один тестировщик.

Рассказываю о своём опыте тестирования как единственного тестировщика на проекте. И удалось ли мне справится с такой нагрузкой работ.

Всем привет!

Сегодня хочу поделиться с вами тем, как «съесть слона» по кусочкам на моем личном опыте.. Эта статья будет полезна бизнес и системным аналитикам, которые сталкиваются с масштабными проектами и задачами, требующими декомпозиции. 

Немного о предыстории

Представьте, что у вас есть масштабный проект: разрабатываемое приложение предназначено для девяти компаний и состоит из шести компонентов (или модулей, или подсистем). В проекте задействованы три мини-команды, каждая из которых включает фронтенд и бэкенд-разработчика, аналитика и тестировщика.

Основная задача — декомпозировать и описать задачи для всех членов проектной команды.

Меня зовут Ксения и я уже более 7 лет в IT. В данной статье хочу разобрать, что такое «классы эквивалентности» со стороны математического анализа — со стороны точной науки.

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

Мы все любим пробовать новые инструменты, но ненавидим их поддерживать и обновлять. Это касается всего: операционных систем, приложений, API, пакетов Linux. Больно, когда наш код перестает работать из-за обновления, и вдвойне больно, когда обновление было инициировано не нами.

В разработке API вы рискуете сломать код ваших пользователей с каждым новым обновлением. Если API -- ваш основной продукт, то обновления будут ещё более пугающими.

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

Я расскажу на нашем примере, насколько глубока кроличья нора и как сильно можно упороться на пути к идеальному версионированию.

Привет, Хабр!

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

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

Давайте узнаем, как хватать и чем траффик.

В питоне очень много полезного и интересного синтаксического сахара. Настолько много, что у неподготовленных пользователей может случиться сахарный диабет. Здесь вы увидите несколько уникального для питона синтаксического сахара, его примеры правильного и неправильного применения.

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

Что такое требования и какими
они бывают?

Требования – это любое условие, которому
должен соответствовать конечный продукт,
все его возможности, ограничения и логика
системы. Они создаются в процессе
проработки задания на разработку/
модернизацию программного обеспечения.
Требования делятся на функциональные и
нефункциональные, а также на явные и
неявные (самые коварные). Причем,
неявные требования необходимо
переводить в явные, так как определения
неявных требований нигде не прописаны, а
значит их наличие чревато разночтениями и
недопониманиями внутри команды, из-за
чего, в будущем разработка может
столкнуться с проблемами.
Функциональные требования описывают, что
должна делать система. Они включают в
себя:
1. Бизнес-требования;
2. Функциональные требования;
3. Пользовательские требования;
4.Системные требования.

Нефункциональные требования описывают,
как именно должна работать система и
почему. Они включают в себя:
1. Бизнес-правила;
2. Правила взаимодействия с внешними
интерфейсами;
3. Метрики качества;
4. Ограничения.

Что делать QA-специалисту,
если требований нет или почти
нет?
В случае если Вам не повезло и требования
на проекте не отвечают необходимым
критериям, а может быть их и вовсе нет, то
нам необходимо вовремя обнаружить
проблему с требованиями и взяться за ее
решение.
Требования можно искать в различных
источниках:
1. Проектная документация;
2. Заказчик и Заинтересованные лица;
3. Сегмент рынка бизнеса, схожие проекты;
4. Эксперты в отрасли;
5. Интернет и СМИ;
6. Законодательство;
7. Логика и здравый смысл;
8. Жизненный и профессиональный опыт;
9. Коллеги и профессиональное комьюнити.

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

Наша цель – разработать скрипт, работающий в фоновом режиме и позволяющий активировать голосовой ввод в любом приложении простым нажатием кнопки. После отпускания кнопки скрипт мгновенно преобразует речь в текст и автоматически вставит его в активное поле ввода. Таким образом, мы получаем возможность голосового ввода практически в любом вашем приложении.

Приятного прочтения!

История о том, как мы развивали наш CI процесс для монолитного Python-репозитория с авто тестами, возникавшие проблемы и примеры их решений. Поговорим о Docker, линтерах, Allure TestOps и многом другом.

Всем привет! Меня зовут Екатерина и я QA-специалист в компании SimbirSoft. Я уже 7 лет занимаюсь обеспечением качества IT-продуктов, и за это время прочитала множество книг и пособий. Многим книгам по QA уже много лет, а новинки появляются достаточно редко. В январе 2024 года на русском языке вышел «Идеальный тестировщик» Кристин Джеквони — поэтому я сразу обратила внимание на эту книгу. Поделюсь с вами своей оценкой и выводами — что в ней есть полезного и чего не хватило.

В этой статье я расскажу о генераторе документации Sphinx, с помощью которого можно автоматически создавать документацию для модулей Python. Кроме того, я буду использовать шаблон проекта Cookiecutter Data Science в Visual Studio Code (VS Code), поскольку он легко интегрируется в Sphinx и имеет стандартизированную структуру директорий. Официальное пособие по использованию Sphinx — отличный ресурс для пользователей, которые хотят углубиться в детали. А моя статья — это краткое руководство по началу работы с этим инструментом.

Тестировщик с 50-летним стажем Александр Александров рассказывает про количественное управление процессом тестирования: какие метрики в ИТ-проектах бывают, как можно спрогнозировать количество дефектов в коде и зачем вообще оценивать результаты тестирования по численным KPI.

Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям. 

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

Всем привет! На связи Наталья Данилина и Иван Чечиков из Звука. В этой статье мы хотим поделиться опытом внедрения snapshot-тестов для web-приложения — расскажем, что это такое и для каких задач применяется.

Подробности – под катом.