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

Всем привет! Меня зовут Ренат Дасаев, и я продолжаю рассказ о развитии E2E‑тестирования в Московской Бирже. За два года после публикации первой статьи многое изменилось: мы переупаковали процессы, расширили команду и существенно обновили технический стек. Хотите узнать, как нам удалось масштабироваться и какие инструменты сегодня ускоряют работу? Тогда - эта статья для вас!

«ChatGPT убьёт тестировщиков» — миф или реальность? Рассказываю, как AI уже влияет на сферу QA и почему инженеры не останутся без работы.

(Статья — результат совместной работы с Максимом Степановым)

В прошлой статье мы показали, как тесты помогают найти изъяны в архитектуре. Для этого мы попытались протестировать скрипт на Python, проверяющий погоду. Нам пришлось разбить его на несколько функций в зависимости от зон ответственности, и это позволило написать несколько тестов. Но у них были существенные недостатки:

• Хрупкость

• Зависимость от внешних систем

• Невозможность протестировать пользовательский сценарий в отдельности

• Избыточное покрытие.

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

Как выбрать профиль нагрузки, чтобы результаты тестирования имели смысл? Разбираем 5 практических правил, основанных на SLA, данных с продакшена и прогнозах роста, и объясняем, почему важно учитывать не только клиентские, но и системные метрики.

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

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

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

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

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

В прошлой части уже описали некоторые «внешние» инструменты (ссылка). Сегодня поговорим о возможностях внутри самих тестов.

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

Что нужно, чтобы скомпрометировать данные 27 миллионов абонентов, обрушить акции телеком-гиганта и поставить под угрозу национальную безопасность одной из самых технологически развитых стран мира? Свежий zero-day? Квантовый компьютер? Гениальная социальная инженерия?

Всего лишь веб-шелл, почти три года преступной халатности и один хитрый бэкдор.

Неизвестные злоумышленники с июня 2022 года хозяйничали в критической инфраструктуре крупнейшего корейского сотового оператора. Под катом мы разберем эту громкую историю.

Библиотека функций к Script-fu

Написание кода на Лисп это тестирование, я не знаю(это не значит что их нет, просто я их действительно не знаю) ни одного языка программирования в котором цикл: написание код - проверка(тестирование) был бы таким коротким. Кстати в Script-fu я работаю через буфер обмена, это не удобно! Там есть возможность работать из Емакс, через сервер Scrip-fu, но я эту возможность не использую(приятно видеть консоль), а с обычной схемой или лиспом, работа в передаче кода заключается в нажатии пары клавиш. Лисперы не пишут многостраничные листинги кода, а затем его тестируют, они пишут функцию, выполняют его в интерпретаторе и сразу тестируют. Всё это благодаря наличию в системе REPL. И всё таки не смотря на это настаёт момент, когда требуются отдельные тесты, которые удобно запустить и проверить консистентное состояние программной системы, а то в процессе такого интенсивного создания-тестирования программы всё равно можно что либо опустить, и какая нибудь функциональность да отвалится.

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

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

Всем привет!

С настоящей статьи решил начать своё графоманство на Хабре. Когда‑то писал много и по делу (правда, тематика была иная), поэтому решил вспомнить это занятие. Итак, начнём с незатейливой тематики, а именно — Как я стал тестировщиком… И не просто тестировщиковм, а тестировщиком 1С.

Гордо звучит, а?

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

Когда речь заходит об отказоустойчивости между ЦОДами, метрокластер — почти всегда первое, что приходит в голову. Раньше это был стандарт: один ЦОД падает — второй подхватывает. Все работает, данные не теряются. Вместе с уходом западных вендоров их решения ушли вместе с ними либо появились огромные трудности с их конфигурированием и поддержкой.

С 2024 года у нас на тестовом стенде стоят системы хранения AQ440 от «Аэродиск». Мы их активно «мучаем»: имитируем отказы, нагружаем, меряем задержки, устраиваем испытания на выживание. Наш выбор связан с тем, что это единственное решение (на данный момент), у которого есть поддержка метрокластера. И основной фокус сегодняшнего рассказа — описать сценарии работы этой технологии. Не имитацию, не полумеру, а рабочую схему с реальным переключением между площадками, отказами и всем, что из этого следует.

Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение.

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

В ходе автоматизации тестирования пользовательских интерфейсов зачастую используется такой подход как визуальное тестирование. Он позволяет поддерживать стабильность и отсутствие ошибок в отображении страниц.  

Одним из инструментов, предоставляющих возможность автоматизации данного вида тестирования, является Playwright.

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

Собрал чат-бота, чтобы тот отвечал за меня в Телеграм: без ошибок и пассивной агрессии. Бонусом добавил шифрование логов, whitelist для доступа, историю чатов для персонализации и RAG с автообновлением базы знаний через Git.

В статье — пошаговая инструкция, инсайты и нюансы, которые большинство упускают.

Первая часть из моего цикла исследований, посвященного генерации псевдослучайных чисел в скриптовом языке VBA, используемого в офисных приложениях от Microsoft.

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется. 

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.

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