Ну если автоматизатору разработчик говорит что тест кейсы не совсем валидны и верны то явно не наоборот ))

Ну если автоматизатору разработчик говорит что тест кейсы не совсем валидны и верны то явно не наоборот ))

#question #test_design #manual #automation #bus_factor
Чат, есть вопрос по тест-дизайну,

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


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

Это была ситуация, а теперь вопросы:
1) не вносит ли автоматизатор бас фактор. создавая тесты, в дизайне которых ручные тестировщики не участвуют
2) не лучше ли научить тестировщиков руками тест-дизайнить так, чтобы вопросов от разработчика таких не было (другими словами, тестировщики должны используя белый ящик и классы эквивалентности нарезать тест-кейсов минимально допустимое количество)
3) Не кажется ли вам расхождение автотестов от существующих тест планов бомбой замедленного действия?Даже если они time efficient

А какое ограничение запущенных эмуляторов одновременно на одной машине? Я так подразумеваю что количество агентов у этого ci равно единице?

#question #test_design #manual #automation #bus_factor
Чат, есть вопрос по тест-дизайну,

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


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

Это была ситуация, а теперь вопросы:
1) не вносит ли автоматизатор бас фактор. создавая тесты, в дизайне которых ручные тестировщики не участвуют
2) не лучше ли научить тестировщиков руками тест-дизайнить так, чтобы вопросов от разработчика таких не было (другими словами, тестировщики должны используя белый ящик и классы эквивалентности нарезать тест-кейсов минимально допустимое количество)
3) Не кажется ли вам расхождение автотестов от существующих тест планов бомбой замедленного действия?Даже если они time efficient

одни говорят тесткейс кривой, другие, что автоматизация кривая)

У нас вот сейчас на одной машине запущен гитлаб раннер для CI.
И в нем настроено что параллельно может выполняться 4 джобы.
Обычно бывает так, что идет 4 пайплайна параллельно на разные коммиты ( и в каждом пайплайне должен быть запуск тестов)

Но вот как это сделать красиво я пока не знаю.

А ограничения по запуску симуляторов на машине в целом нет. (желательно не больше 4 т.к. нагрузка будет на машину приличная + вопрос в стабильности самих юай тестов)

Или можно подумать о том, чтобы как-то в самом CI ограничить параллельное выполнение тестов?

в этом и боль, потому что я не хочу писать тесты, которые идут в разрез тест-дизайна ручного тестирования, UI тесты близки к ручному тестированию. Автоматизация -- она про замену ручного/машинным. Другими словами, я бы научил ручных тестировщиков понимать что откуда растет в коде, чтобы сделать минимальное количество проверок / сочетаний и чтобы они описали этот подход в тест-плане,

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

Привет! Подскажите пожалуйста, не получается сделать запуск XCUITests через xcodebuild (fastlane) в CI (на каждый коммит)

Уже много разных инструментов перепробовал: (bluepill, fastlane-plugin-test-center)
Хотелось бы пока сделать так: чтобы тесты шли на одном симуляторе (для одного пайплайна) и чтобы таких пайплайнов параллельно было несколько
но проблема сейчас в том, что параллельно могут еще пайплайны идти (а симулятор получается занятым "первым" пайплайном)
поэтому например для второго пайплайна тесты на стартанут

Поделитесь пожалуйста как сделать запуск тестов чтобы работал для нескольких симуляторов одновременно?
(нужное поведение у меня получается сделать через fastlane-plugin-test-center - он для каждого пайплайна клонирует симулятор и потом его удаляет - но там у меня получается только для двух симуляторов в одном пайплане сделать, а хотелось бы один)

не, кмк автоматизация совсем о другом, там и возможности другие) там где ты в ручном пишешь, что соап надо дернуть 3 раза по граничным значениям, автоматически ты можешь пихнуть весь набор из 1к наборов в 100 потоков и за 10 секунд все пройдет)

не, кмк автоматизация совсем о другом, там и возможности другие) там где ты в ручном пишешь, что соап надо дернуть 3 раза по граничным значениям, автоматически ты можешь пихнуть весь набор из 1к наборов в 100 потоков и за 10 секунд все пройдет)

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

Земля пуховик с таким подходом

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

Вам знакомо понятие тест дизайн в принципе?