Size: a a a

2020 September 28

YP

Yuriy Podporinov in QA juniors
Степа Фомичев
Если, вдруг, система стагнирует, то, скорее всего, и мануальщики уже не пригодятся)
ну тут не соглашусь полностью))) система допустим может не развиваться в плане вёрстки (UI), а развиваться в плане бека и написания новых методов для каких-то модулей, да и вообще переход разных модулей в другое исполнение (к примеру, переписали модуль на другом ЯП, начали использовать другой механизм взаимодействия). Вот тут и надо будет и модульное, и интеграционное делать, хотя для конечного пользователя может показаться, что ничего и не поменялось
источник

СФ

Степа Фомичев... in QA juniors
Если система развивается в плане бэка , то юуай может упасть или сломаться в любом патче
источник

СФ

Степа Фомичев... in QA juniors
Получается, необходим регресс
источник

И

Иисус in QA juniors
А как бы ты описал наиболее точно (но лаконично) ад-хок тестирование и насколько оно полезно?
источник

YP

Yuriy Podporinov in QA juniors
Степа Фомичев
Если система развивается в плане бэка , то юуай может упасть или сломаться в любом патче
плавали - знаем))) я про то, что есть ли смысл будет автоматизировать UI при таком подходе? UI взял как наиболее видимый пример, который большинство и хотят автоматизировать
источник

СФ

Степа Фомичев... in QA juniors
Yuriy Podporinov
плавали - знаем))) я про то, что есть ли смысл будет автоматизировать UI при таком подходе? UI взял как наиболее видимый пример, который большинство и хотят автоматизировать
Ну да, автоматизируешь юуай один раз(он же не меняется), и при каждом обновлении бэкенда запускаешь регресс
источник

AG

Andrew Gasov in QA juniors
Yuriy Podporinov
а можете привести примеры, можно простые — я хочу разобраться в данном вопросе, не даёт он мне покоя
Ну смотрите.
Автоматизация - это инструмент, не более того. Тут нет какой-то идеалогической составляющей и догмы, когда надо а когда нет.
Это чисто практический вопрос.

Пример. Есть контрактное тестирование API.
Что оно из себя представляет? Отправил CURL с известной заранее схемой - получил ответ, сравнить схему (набор полей).
Повторить так для всех эндпоинтов в API.

И тут есть сразу несколько моментов:
1) Скорее всего тебе придется делать эти проверки регулярно, например при каждом релизе, что бы проверить, что контракт API не сломался.
Чем больше релизов - тем чаще проверять, тем больше человеческих ресурсов надо. Масштабируется плохо.

2) Процесс тестирования не сильно-то отличается от написания автотестов на эту логику (сформировать запрос, отправить, сравнить схему).

3) Компьютер очевидно лучше справляется со сравнением жсонов, чем человек.
Ну, мало кто будет это делать вручную, а если ты потом копипастишь JSON в какой-нибудь инструмент, показывающий diff с ожидаемым - проще написать 10 строчек кода.

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

СФ

Степа Фомичев... in QA juniors
Что я точно бы автоматизировал ещё - это тесты на апи) руками, обычно, долго и часто, писать тесты легко(в отличие от юай)
источник

YP

Yuriy Podporinov in QA juniors
Степа Фомичев
Ну да, автоматизируешь юуай один раз(он же не меняется), и при каждом обновлении бэкенда запускаешь регресс
а не проще ли вручную проверить именно те модули, которые потенциальная фича может аффектить, не запуская громадину-систему из контейнеров на виртуалке, запускающие браузеры и тыкающие селениумом по кнопочкам?
источник

СФ

Степа Фомичев... in QA juniors
Yuriy Podporinov
а не проще ли вручную проверить именно те модули, которые потенциальная фича может аффектить, не запуская громадину-систему из контейнеров на виртуалке, запускающие браузеры и тыкающие селениумом по кнопочкам?
Не то что ты, но, возможно, и тот кто эту фичу писал может не знать, где и как аукнется его изменение
источник

AG

Andrew Gasov in QA juniors
Если ты можешь получить то же качество проверки, не запуская UI\E2E тесты - не запускай E2E тесты.
источник

YP

Yuriy Podporinov in QA juniors
Andrew Gasov
Если ты можешь получить то же качество проверки, не запуская UI\E2E тесты - не запускай E2E тесты.
вот, у меня вот вопрос один такой и всплыл — е2е UI тесты — это зло или как?)
источник

AG

Andrew Gasov in QA juniors
Yuriy Podporinov
вот, у меня вот вопрос один такой и всплыл — е2е UI тесты — это зло или как?)
Это инструмент.
источник

AG

Andrew Gasov in QA juniors
Со своими плюсами и минусами.
источник

AG

Andrew Gasov in QA juniors
Плюсы:
Эти тесты максимально приближены к пользовательским сценариям и проверяют их.

Минусы:
Медленные и сложно поддерживаются.
источник

AG

Andrew Gasov in QA juniors
У меня почему-то создается впечатление, что я просто пересказываю эту статью:
https://martinfowler.com/articles/practical-test-pyramid.html
источник

АБ

Арсений Батыров... in QA juniors
Вот, только хотел сказать, что может сразу показать людям пирамиду тестирования?)
источник

YP

Yuriy Podporinov in QA juniors
Andrew Gasov
Плюсы:
Эти тесты максимально приближены к пользовательским сценариям и проверяют их.

Минусы:
Медленные и сложно поддерживаются.
то есть, по факту, каждый сам/политика компании решают, какие тесты будут, отталкиваясь от своих нужд?
источник

A

Anna (terrajanis) in QA juniors
Yuriy Podporinov
а не проще ли вручную проверить именно те модули, которые потенциальная фича может аффектить, не запуская громадину-систему из контейнеров на виртуалке, запускающие браузеры и тыкающие селениумом по кнопочкам?
Если это все ранается где-то отдельно, то можно хоть каждый запускать - оно никому не мешает 🤷🏻‍♀️
источник

AG

Andrew Gasov in QA juniors
Yuriy Podporinov
то есть, по факту, каждый сам/политика компании решают, какие тесты будут, отталкиваясь от своих нужд?
Нет. По факту то, какого уровня тесты вам стоит использовать зависит от того, что именно должны проверять эти самые тесты.
источник