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

Привет, Хабр! Я Александр Непомнящих, QA в СберМаркете. Мы с командой кодим программу лояльности, которая позволяет списывать в заказах бонусы «Спасибо», а также запускать различные акции с повышенным начислением бонусов. 

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

Если вы занимаетесь тестированием, заходите под кат — расскажу, как мы в итоге автоматизировали процесс до 1 команды в Rails-консоли.

Прекрасный момент: система написана, часть тестов автоматизирована, отчеты сгенерированы и даже выявлено несколько дефектов. Выдыхаем и будем думать о дальнейших планах: увеличить тестовое покрытие, добавить стабильности и что-то делать с логированием. Стоп, подождите, вы про логи? Заряжаем ELK, агенты сбора, выделяем ресурсы. Как нет ресурсов? Так, может быть, rsyslog в конце концов? И его нельзя? Звучит как тестовая задача на собеседовании, однако можно ли в такой ситуации обойтись без дополнительных инструментов, да еще и интегрировать работу с логами в систему автоматизации тестирования?

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

Здесь я расскажу про Logcat в Android Studio, какие у него есть возможности, как его кастомизировать и использовать по максимуму, с практическими советами в каких ситуациях та или иная фича может вам пригодиться. Материал будет полезен как начинающим тестировщикам, так и матёрым разработчикам, ведь это универсальный инструмент, ускоряющий работу, если знать о всех его хитростях.

Введение

Добрый день! Меня зовут Анастасия, я QA-инженер команды бэкофиса в «Финаме». С 2022 года занимаюсь тестированием бэкофисных и торговых систем финансовых компаний. До перехода в QA работала в эксплуатации и поддержке торгово-клиринговой системы СПБ Биржи. Моя сильная сторона — глубокое понимание бизнесовой части тестируемого продукта, о важности чего мы и поговорим в этой статье.

Идея

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

Содержание

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

Чуть-чуть обо мне

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

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

Кто такой этот ISTQB и зачем его сдавать

ISTQB - некоммерческая организация, занимающаяся определением различных принципов развития сферы тестирования ПО, таких как структура и правила аккредитации, сертификации и т.п. (с сайта RSTQB)

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

Зачем сдавать? Судя по вакансиям, в России данная сертификация не очень популярна, но для своего собственного развития и возможности в будущем претендовать на трудоустройство на международном рынке, оно того стоит.

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

В любой разработке рано или поздно появляются тестовые стенды — отдельные инсталляции тестовой сборки вашей разрабатываемой системы, с тестовыми данными и тестовыми же учетными записями. Именно отсюда происходит знаменитое «admin/admin», которое вбивал в поля авторизации наверное каждый разработчик.

Теперь представьте что у вас в разработке не один проект а скажем 50, часть из которых требует нескольких стендов. Знакомо?

Всем привет! Меня зовут Сергей Герасимов, я – Senior QA Manual Engineer (да, хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

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

Всем привет! Я Вера, инженер по обеспечению качества в Т-Банке. Работала в разных командах и направлениях. Стараюсь всегда расширять свои знания и узнавать что-то новое.

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

Перед командой стояла задача создать схему действий для внедрения и настройки нагрузочного тестирования в проектах. Схема должна подходить для всех проектов и быть удобной для использования. Это статья об истории создания и развития автоматизированной системы Cosmos. 

Проверка кода (Code Scanning) автоматически обнаруживает ReDoS-уязвимости, но исправить их бывает не всегда просто. В этой статье описана 4-х этапная стратегия исправления багов ReDoS.

Открытая архитектура RISC-V активно развивается: в стандарт добавляются новые расширения и инструкции, разрабатываются новые ядра и SoC. Поскольку многие компании видят перспективы архитектуры и готовы использовать ее в продакшене, создается программный стек для высокопроизводительных вычислений — RISC-V HPC (High Performance Computing). Прогресс сопровождает формирование нового тренда — OpenHPC. Он заключается в технологической независимости от решений коммерческих компаний. Причем это относится не только к ПО, но и к железу. 

Чтобы концепция OpenHPC реализовывалась быстрее, нужно, чтобы к инициативе присоединилось как можно больше компаний, помогающих в развитии экосистемы решений для RISC-V HPC. Меня зовут Андрей Соколов, я инженер-программист в компании YADRO. В R&D-команде мы поставили перед собой задачу: изучить, как можно поддержать архитектуру RISC-V со стороны библиотек линейной алгебры BLAS и LAPACK. Тестирование одной из open source-библиотек привело нас к интересным открытиям, о которых я расскажу под катом. 

Привет! Меня зовут Илья, я продуктовый аналитик в Samokat.tech. 

Делать A/B-тесты – довольно привычная вещь для аналитиков. Но как быть, если нужно провести эксперимент в физическом мире? Какие особенности и ограничения есть в офлайне? Как выбирать и оценивать метрики? 

Давайте расскажу на примере – как мы пробовали доставлять заказы Самоката ещё быстрее.  

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

Разработка 1D-модели системы подвески автомобиля

Исследование возможностей и границ применения научных технологий и программного обеспечения как в привычной области работы, так и в новых сферах – это один из ключевых приоритетов современной индустрии. Мы продолжаем серию статей о математическом моделировании, раскрывая еще одно направление применения программного обеспечения REPEAT.
Сегодня перед вами результат проекта "Школа Моделирования" – 1D-модель системы подвески автомобиля. Автор статьи, студент РГУ им. Косыгина – Алексей, который работал над этим проектом, используя наши инструменты и технологии, что стало хорошим тестом для их универсальности и гибкости применения.

Ссылка на телеграм-канал REPEAT: https://t.me/repeatlab

Привет,  я Костя — QA Lead в tekmates. В статье расскажу про частые ошибки в планировании тестировании мобильных и веб- приложений, и, конечно, как их избежать. Кроме советов также покажу интересные кейсы: например, с помощью каких инструментов автоматизации мы сократили работу в рамках регресса с 2 часов до 20-25 минут.

Итак начнём. Вот какие проблемы я вижу.

В 2021 году я выпустила свою первую книгу по тестированию — «Курс молодого бойца». Заняло у меня это 4.5 года! И я решила поделиться своим опытом в цикле статей:

Часть 0. Как начать и не бросить

Часть 1. Работа с фриланс-художниками

Часть 2. Поиск издательства

Часть 3. Редактура и выпуск (мы тут, последняя статья цикла!)

Сегодня я расскажу, как проходит выпуск книги после того, как вы нашли издательство, заключили договор и доделали книгу. Казалось бы, максимум месяц и книга уже в руках, да? Не-е-е-т, там всё сложнее =))

Я хочу поделиться, как оно бывает. Потому что со стороны кажется, что такого, а как заглянешь под капот — у-у-у-у… Поэтому я опишу, какие этапы включает в себя выпуск книги, и сколько времени это заняло нас. И как постоянно что-то шло не так, буквально на каждом этапе =))

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

Если вызывали пояснительную бригаду по уязвимостям, она приехала. Я Миша Козлов, в Positive Technologies отвечаю за продукты по анализу инфраструктуры и детектированию уязвимостей. Вместе с командой экспертов делаем так, чтобы компании узнавали все о своих активах, искореняли shadow IT и уязвимости, и чтобы в итоге недопустимое становилось невозможным. В этой статье расскажу о том, какие бывают уязвимости, как их используют киберпреступники и каких брешей нужно бояться больше всего.

Компонент «Предотвращение утечек API» расширяет функциональность ПО «Структура API» в области мониторинга скомпрометированных секретов (токенов) с дальнейшей возможностью блокировки таких токенов путём создания виртуальных патчей.Он предоставляет следующие возможности:

В конце прошлого года мы представили TestY, тест-менеджмент систему с открытым исходным кодом, которую разработала команда YADRO на замену TestRail.

Сегодня на связи я, Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TMS TestY. После первого текста о нашей системе вы обращались к нам с вопросами и пожеланиями. Некоторые предложения мы уже планировали в новый релиз, но были и те, что мы взяли в работу именно благодаря вашей обратной связи. В этой статье расскажу о фичах, вышедших в релизе 1.3, и отвечу на вопросы о TestY в комментариях.

Хабр, привет! Уже по традиции я, Александр Леонов, ведущий эксперт лаборатории PT Expert Security Center, рассказываю про трендовые уязвимости месяца.

Всего их было четыре:

1️⃣ уязвимость, приводящая к удаленному выполнению кода в многоплатформенном опенсорсном инструменте для сбора и обработки журналов Fluent Bit (CVE-2024-4323);

2️⃣ уязвимость, приводящая к удаленному выполнению кода в корпоративной веб-вики Confluence (CVE-2024-21683);

уязвимости Microsoft, связанные с 3️⃣ обходом функций безопасности в Windows MSHTML Platform (CVE-2024-30040) и 4️⃣ повышением привилегий в Windows DWM Core Library (CVE-2024-30051).

Колесо крутится, но хомячок подписки помер. Оно просто крутится.

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

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

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

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