А еще скажите, как лучше групировать тесткейсы? По тематике дейтсвий или как действия располодены на сайте?

Зависит от того, какую цель преследует эта группировка.
Вообще, я искренне верю, что тест кейсы не должны быть сгруппированы по какому-то критерию.
Они должны обладать Н параметров, по которым можно делать фильтрацию/group by.

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

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

Я понимаю о чем вы.
Я к тому, что «false negative тест может вести к проблеме», а false positive гарантировано к ней ведёт. ;)

Это не значит, что flaky тесты это хорошо и не нужно стараться делать тесты стабильными.
Это значит, что стабильные тесты - не самоцель. ;)

false positive гарантированно приведет к такому эффекту, если в проверке написать assert true. если более-менее обдуманные проверки, то должны какие-то проблемы отловить

Простите, но это аргумент из цикла «нормально делай - нормально будет».
Потому что точно так же можно сказать «более-менее обдуманные ожидания не дают false negative результаты».

Как я уже говорил выше, любой ассерт имеет шкалу чувствительности.
Чувствительность может проявляться минимум в двух измерениях.
По «ширине»: более общая проверка будет более чувствительной к любым изменениям, более точечная - менее чувствительной.
И по строгости: чем больше строго мы проводим проверку (чем больше количество точек измерения и точнее сравнение), тем более чувствительным будет тест.

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

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

Банальный пример, хотя и не совсем про тестирование.
Н-ное время назад мы с командой пилили нейросеточку для распознавания заболеваний по КТ/МРТ/рентгенам.
И с точки зрения продукта, нам лучше было бы дать тысячу false-positive срабатываний (когда мы детектим заболевание там, где его нет), чем false-negative (когда оно есть, а мы его пропускаем как здорового).
За счёт этого чувствительность и веса принятия решения были очень сильно смещены в сторону «гиперчувствительности».

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

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

И «зависит от того, какая функциональность проверяется» - ровно то, про что я говорил.

Я знаю ребят, которые просто ставили авто-ретрай на тест, если кнопочка почему-то не отрисовалась.
А через три месяца по чистой случайности узнавали, что кнопочка не отрисовывается, когда приходит битый конфиг А/Б теста, а происходит это в одном из N случаев.
И тесты не «флакали», они ловили реальную проблему.
Просто между «разобраться почему падает» и «сделать тесты стабильнее» - выбрали второе.

И я не говорю «а давайте тратить время автоматизатора в любой непонятной ситуации».
Любая трата времени должна иметь понятную цель и быть приоритезирована.
Просто надо понимать, что нестабильными тесты может делать как работа тестов, так и работа приложения.
И работа автоматизатора не в том, что бы сделать тесты стабильно зелёными.
А в том, что бы делать тесты показательными.

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

Всем привет, есть ли тут начинающие тастировщики в поисках "а чтобы потестить реального?

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


Задачу ставим научиться работать в команде и подтянуть навыки программирования

вам лучше, наверное, в @qajuniors спросить

Спасибо

Кто-нибудь использовал codemagic для прогона интеграционных тестов? Хотелось бы задать несколько вопросов
Я использовал встроенный воркфлоу редактор, но тесты падали с ошибкой java.net.URISyntaxException: Illegal character in opaque part at index 2: и указанием файла манифеста ассетов. Кто-нибудь сталкивался с подобным?
Есть ли какие-то еще пути для прогона интегро тестов в кодмеджике?

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

мало данных.

Что интересует? Я до этого терминалы не тестировал, вообще не представляю что и к чему

У нас была такая штука - проблема была в генерации РОS файла. Вместо одного два улетало

но надо бы понимать как у вас это работает и с чем связано