Size: a a a

QA — Автоматизация

2019 December 12

O

Oleg in QA — Автоматизация
Роман Нагаев
я знаю что они проверяют, но не уверен что этого достаточно, например взаимодействие с бд не проверяется, и непонятно, стоит ли этим заниматься или нет
в ИТ база в любом случае должна быть, настоящая или in-memory. Мокать конекторы к базе с помощью мокито в ИТ не следует. То есть в ИТ не надо лезть внутрь приложения и что-то там менять.
источник

А

Алексей in QA — Автоматизация
Stanislav P
хм... есть юнит тесты, написать свои юнит тесты?) ну ок
Тут речь идет про интеграционное тестирование же
источник

А

Алексей in QA — Автоматизация
Роман Нагаев
я знаю что они проверяют, но не уверен что этого достаточно, например взаимодействие с бд не проверяется, и непонятно, стоит ли этим заниматься или нет
обязательно проверять на живой базе
источник

РН

Роман Нагаев in QA — Автоматизация
Stanislav P
работу с базой реальную лучше и проще проеврить через API... наверное
юнит тесты так и реализоываны интеграционных нет у меня нет проблемы это реализовать, есть проблема выбрать что конкретно я тестирую, если интеграционные тесты то что подавать на вход, что ждать на выход, вот у меня есть 4 слоя

на контроллере два варианта, ошибка есть, ошибки нет
в сервисе ещё две проверки на бизнес логику
в репозитории ещё пара проверок перед доступом к данным

и того 2*2*2 уже 8 кейсов и их количество растёт экпоненциально, нужно выбирать тлько часть
источник

РН

Роман Нагаев in QA — Автоматизация
Алексей
Или забить на проверки разрабов, и писать свои. Так как реиспользование кода и логики юнит тестов частенько ведет к реиспользованию ошибок, допущенных в юнит тестах.
я и есть разраб)
источник

А

Алексей in QA — Автоматизация
Роман Нагаев
да, но дело в том что вариантов данных которые я могу положить в бд много и от них зависит то что я смогу протестировать, я не могу выбрать из этого большого множества кейсов те которые для меня важны
Сначала сам, или с помощью бизнеса приоритезируешь сервисы, которые должны быть протестированы. От этой приоритезации выбираешь первую пачку тесткейсов, которые надо проверить на системе в сборе. Дальше расширяешь покрытие. Сценарии для тесткейсов стоит брать не путем обхода ветвей дерева возможных путей, а из сценариев поведения пользователей, так покрытие будет захватывать максимально часто используемые цепочки действий
источник

O

Oleg in QA — Автоматизация
Роман Нагаев
юнит тесты так и реализоываны интеграционных нет у меня нет проблемы это реализовать, есть проблема выбрать что конкретно я тестирую, если интеграционные тесты то что подавать на вход, что ждать на выход, вот у меня есть 4 слоя

на контроллере два варианта, ошибка есть, ошибки нет
в сервисе ещё две проверки на бизнес логику
в репозитории ещё пара проверок перед доступом к данным

и того 2*2*2 уже 8 кейсов и их количество растёт экпоненциально, нужно выбирать тлько часть
я ж говорю, не думай по ветвлениям в коде. У тебя на вход приходит какой-то джсон. В нем какие-то данные. Сделай перечисление всех разных вариантов наборов данных с приоритезацией по бизнесу.
источник

А

Алексей in QA — Автоматизация
Роман Нагаев
я и есть разраб)
разраб в смысле разраб системы, или разраб юнит тестов? Если разраб системы - наймите отдельного куа. Если разраб юнит тестов - то это смешение ролей. юнит тесты пишутся разрабами по принципу - добавил фичу, добавить и юнит тесты на нее. Тестированию лучше туда не лезть, кроме как ревью тестов в пул реквесте, чтобы особо одаренные не коммитили тесты assertTrue(True)
источник

РН

Роман Нагаев in QA — Автоматизация
Алексей
Сначала сам, или с помощью бизнеса приоритезируешь сервисы, которые должны быть протестированы. От этой приоритезации выбираешь первую пачку тесткейсов, которые надо проверить на системе в сборе. Дальше расширяешь покрытие. Сценарии для тесткейсов стоит брать не путем обхода ветвей дерева возможных путей, а из сценариев поведения пользователей, так покрытие будет захватывать максимально часто используемые цепочки действий
спасибо, записал, это близко к тому что я ищу)
источник

РН

Роман Нагаев in QA — Автоматизация
Oleg
я ж говорю, не думай по ветвлениям в коде. У тебя на вход приходит какой-то джсон. В нем какие-то данные. Сделай перечисление всех разных вариантов наборов данных с приоритезацией по бизнесу.
вопрос в том какой именно json, там десятки полей и в каждом поле может быть куча значений, у меня нет принципа по которому я смогу выбрать какой-то конкретный жсон из этой кучи
источник

РН

Роман Нагаев in QA — Автоматизация
Алексей
разраб в смысле разраб системы, или разраб юнит тестов? Если разраб системы - наймите отдельного куа. Если разраб юнит тестов - то это смешение ролей. юнит тесты пишутся разрабами по принципу - добавил фичу, добавить и юнит тесты на нее. Тестированию лучше туда не лезть, кроме как ревью тестов в пул реквесте, чтобы особо одаренные не коммитили тесты assertTrue(True)
я разрабатываю и систему и тесты, qa есть но он не занимается автотестами
источник

MK

Mem Kekovich in QA — Автоматизация
слишком сложно
разраб не умеет писать тесты или что?
источник

ON

Oleg Nazarov in QA — Автоматизация
Роман Нагаев
я разрабатываю и систему и тесты, qa есть но он не занимается автотестами
самое время начать ему заниматься автотестами)
источник

РН

Роман Нагаев in QA — Автоматизация
Mem Kekovich
слишком сложно
разраб не умеет писать тесты или что?
да, я не умею)
накодить тесты могу
накодить хорошие - нет, потому что не могу измерить хорошоие они или нет
источник

РН

Роман Нагаев in QA — Автоматизация
Oleg Nazarov
самое время начать ему заниматься автотестами)
это моя задача)
источник

MK

Mem Kekovich in QA — Автоматизация
Роман Нагаев
да, я не умею)
накодить тесты могу
накодить хорошие - нет, потому что не могу измерить хорошоие они или нет
берете тз - делаете тесты по тз
источник

А

Алексей in QA — Автоматизация
Роман Нагаев
я разрабатываю и систему и тесты, qa есть но он не занимается автотестами
ну лучше найдите куа для интеграционных тестов. Все таки разрабу обычно есть чем заняться, кроме интеграционных тестов системы. Да и фактор замыленного глаза - когда разработчик кода сам его полностью тестирует - могут быть ошибки из-за отсутсвия взгляда со стороны
источник

РН

Роман Нагаев in QA — Автоматизация
Mem Kekovich
берете тз - делаете тесты по тз
формализованного тз нет, максимум это дерево функций
источник

O

Oleg in QA — Автоматизация
Роман Нагаев
да, я не умею)
накодить тесты могу
накодить хорошие - нет, потому что не могу измерить хорошоие они или нет
дизайн тестов и "накодить" вещи малосвязанные. Для того что бы подставить разные данные кодить ничего не надо. А проблема видимо только в этом. Есть кто-то со стороны бизнеса? ПО, аналитик? Он может помочь с кейсами.
источник

РН

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