Тестирование IT-систем *

В предыдущих частях работы (Часть 1, Часть 2) мы разобрали, что такое линейный конгруэнтный метод (ЛКМ), и как на его основе работает функция Rnd(), вшитая в скриптовый язык VBA, созданный Microsoft. Именно эта функция и "ответственна" за генерацию псевдослучайных чисел. Мы поняли, как ведет себя функция, если в качестве ее аргумента ввести число меньшее либо равное 0. Также мы выяснили, что эта функция работает с мнимым и реальными значениями своих аргументов, также мы поняли, как соотносятся некоторые мнимые значения аргумента функции с их реальными значениями.

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

В статье — эволюция поисковиков и практические хаки для работы: скрытые операторы, малоизвестные команды Яндекса и Google, промпты для Perplexity и Gemini, техники точной фильтрации и ИИ-подходы.

Рассказываю, как превратить 5 кликов в один и получить выдачу с точностью SQL.

Мне нравится Scaled Agile Framework (SAFe), и я вброшу вам несколько идей по тестированию с точки зрения этого фреймворка.

Часто вижу, что во многих компаниях одной из ключевых метрик является количество найденных тестировщиком дефектов. Хочу донести мысль: от этой метрики можно смело отказаться и жить в прекрасном мире Agile-разработки! 🚀

🤯 Когда вы начинаете считать баги, найденные тестировщиком, происходит вот что:

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

В этой статье мы разберемся:

• чем отличаются методологии «черного», «серого» и «белого ящика»;

• какую из них выбрать под конкретные риски;

• как подготовиться к тестированию, чтобы не тратить деньги впустую;

• и почему даже «зеленый» отчет сам по себе — не повод выдыхать.

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

Это история о попытке создать новую логику.

О попытке, рожденной в эпоху, когда фракталы Мандельброта казались ключом ко всей природе. Я, логик по образованию, увидел аналогию: если математические "монстры" оказались фракталами, то, может быть, логические парадоксы — это тоже фракталы?

Я построил концепцию, где смысл — не точка, а процесс, бесконечный и самоподобный. Но концепция осталась без семантики.

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

Qwen, стремясь к формализации, строил сложные системы. DeepSeek, как строгий судья, разрушал их одну за другой, обвиняя в "иллюзии формальности" и "магии".

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

Это — отчет с поля боя за семантику.

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

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

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

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

В этой статье я покажу, как построить гибкий и масштабируемый подход к тестированию фильтрации с помощью Playwright + TypeScript, используя: Page Object Model, Data-driven testing, конфигурацию фильтров и кастомные фикстуры.

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

Сегодня рассмотрим недавно вышедшую модель ChatGTP-5.

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

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.

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

Почти пять лет работаю в Т-Банке, где с нуля организовал тестирование в своей команде. За это время я успел пройти путь от ручного до автоматизированного тестирования, встроить и автоматизировать нагрузочное тестирование и многое другое. 

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

Всем привет! Меня зовут Семён Эйгин, я бэкендер в Авито, люблю опенсорс и периодически что-то туда контрибьючу. В этой статье разбираемся с моками и выбираем самый удобный инструмент (не обязательно лучший!). Это достаточно холиварная тема, хотя при подготовки статьи я не ожидал, что она окажется настолько спорной — у каждого разработчика своё мнение на этот счёт. Чтобы узнать моё и высказать своё — переходите под кат!

Привет, Хабр! Меня зовут Константин Бессонов, и я — ведущий инженер-тестировщик в компании «Столото», где уже шесть лет участвую в тестировании и управлении процессами.

Эта статья — моя история о том, как я пришёл в тестирование без опыта, как готовился к собеседованиям, какие ошибки совершал, а главное — как за несколько лет вырос от новичка до руководителя группы. В процессе пути сталкивался с волнением перед первым релизом, автоматизировал процессы через Postman, осваивал SQL, Linux и понял, что в IT важны не только навыки, но и желание учиться.

Спойлер: если вы думаете, что в IT можно попасть только с идеальным резюме или опытом программирования — вы зашли не в ту статью.

В этой статье расскажу, как выбрать правильную компанию, найти наставников, развивать soft skills, почему важно записывать всё новое.

Mock-сервисы (или мок-сервисы) — это программные компоненты, которые имитируют поведение реальных сервисов, систем или зависимостей в процессе разработки и тестирования приложений. А мы сделали свой.

Последнее время все чаще появляются продукты, которые скрещивают LLM и TMS — и получается магия! ✨

Свежий пример: ▶️ Gen-A: как искусственный интеллект переворачивает тестирование

Плюсы таких решений очевидны. Минусы тоже есть: у всех свои TMS, конфлюенсы и прочие инструменты. Как это затянуть в свой контур? 🤔

И давайте честно, LLM есть у многих, но не у всех есть AI-команды, которые делают такие красивые большие продукты. А у меня есть ощущение, что стоимость таких продуктов, пока они на волне, как крыло от самолета

Что делать? Есть решение - MCP - Model Context Protocol.

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

В этой статье расскажем, как мы:

● автоматизировали нагрузочное тестирование, сократив ручную работу инженеров на 85%;
● встроили стресс-тесты в CI/CD, чтобы каждая фича доказывала свою устойчивость перед релизом;
● научились предсказывать поведение системы не на глаз, а по данным — даже при росте объемов в несколько раз.

Основан на pluggy. Основная единица pytest - pytest плагин. Написан достаточно интересно. Ключевое слово - “ключевое слово”. Основное взаимодействие в pytest происходит через хуки. Хук это некий этап к которому можно получить доступ к той или иной логики работы. Следуя из названия это некоторые крючки за который можно цепляться вставляя свои заплатки. Начинаются с pytest.

Фикстуры (Fixture) в  pytest это некий аналог мока/сетап tear down в unittests.  Это некие кусочки кода результаты которых могут быть пере использованы. Сами фикстуры реализованы как плагин. 

Как уже говорилось в эта система плагинов полагается на Pluggy. В Pluggy програамма полагается на PluginManager который управляет сохранения спецификаций хуков регистрацией плагинов и вызовом их. Плагины могут регистрировать сами себя в PluginManager.

Когда хук стартуют они вызывают свои имплементации по умолчанию как LIFO очередь - самый поздний элемент вызывается раньше всего. Для изменения этого порядка вызова можно применять trylast or tryfirst свойства в их имплементациях(пример). По умолчанию возвращается результат от всех имплементаций с исключением случая с как  firstresult свойством. В случае свойства firstresult программа возвращает результат первого не None результата. 

Другое интересное свойство имплементации плагина это hookwrapper.  С помощью этого свойства имплементации будут вести себя как обертки над другими хуками с помощью yield.

Вдохнули?

Хуки вызываются 3 способами:

Делюсь опытом сборки отчетов Allure 3, можете стабильного релиза не ждать, он и в beta очень хорош.

Статья синьорская, под капотом все что нужно.

Развитие IT-технологий приводит к очевидному росту различных киберпреступлений, осуществляемых посредством взлома этих самых IT-технологий. Чтобы защищаться от таких посягательств, владельцы программ, сервисов, крупных IT-систем вынуждены самостоятельно заказывать такие взломы у сторонних лиц с целью выявления уязвимостей и их устранения. Такой процесс называется «пентестом», и помимо технической составляющей здесь присутствует очень много юридических нюансов, потому что взламывать – незаконно (сюрприз, да?). Давайте разбираться.

Если вы когда-либо писали автотесты для веб-приложений с элементом canvas, то наверняка знаете, как это может быть непросто. Canvas — это "чёрный ящик", где привычные инструменты UI-тестирования бессильны: внутри нет DOM-структуры, за которую можно зацепиться. При этом на экране canvas может отображать что угодно — от графиков с осями X и Y до сложных анимаций.

Хотите узнать, как автоматизировать тестирование canvas без лишней боли? Давайте разберёмся на простом примере.