Привет. Суть в работы в том, чтобы минимизировать критичные для бизнеса баги, иначе - потеря денег.
"Если ты учишься" - смотря где, наверное. Есть слух, что джунов сначала сажают прогонять уже существующие тест-кейсы/ тестировать UI. На мой вкус, UI - самая скучная ветвь тестирования. Если ты манульный тестировщик - деления не языки нет.
По тестированию бэка - буду опираться на архитектуру REST API (иногда буду неверна в выражениях - не бейте палками) - весь ui сайтов - это, по сути, удобный для обывателя интерфейс для взаимодействия с базой данных/сервером. Например, ты заходишь в ВК на свою страницу - на сервер летит GET запрос
https://vk.com/al_profile.php?__query=адресс_стран...
vk.com - это хост
al_profile.php - это эндпоинт
? - начало параметров (query)
__query - ключ
адресс_страницы - значение
и тд
- мы нажимаем на кнопочки пользовательского интерфейса (в примере: моя страница) - при ее нажатии летит запрос на сервер (на который мы редко обращаем внимание) - сервер этот запрос обрабатывает и мгновенно выдает ответ, который посредством нехитрой магии превращается в html страницу.
Пользователь запросов не видит, но он обязательно заметит, если вместо свой страницы он увидит страницу другого пользователя.
Если очень грубо говорить - тестирование бэка - проверка того, что мы получим от сервера именно тот ответ, который ожидаем. Но это очень грубо (и не правдиво).
Если общение между клиентом и сервером можно увидеть, например, через devTools (какие запросы посылаем, что получаем) - общение между микросервисами, микросервисами с базой, микросервисами и чем угодно еще - этого "просто так" не увидеть. Логика работы веб(-сайта/приложения) скрыта от глаз, но если в ней "что-то пойдет не так" - с вероятностью 99% пользователь это заметит (и, возможно, ошибка будет настолько критичной, что больше не захочет пользоваться продуктом).
Для того чтобы удостовериться, что веб (-сайт/приложение):
-работает так, как задумано
-не "ломается" при внештатных ситуациях
-данные не теряются
-и т.д. - существует тестирование бэкенда.
Используются такие инструменты, как: Postman/SOAP UI; СУБД, cистемы логирования, брокеры очередей и т.д.
Проверяем: а получил ли сервер запрос/ а работает ли апи/ а сохранились ли данные в базу/ а как сохранились данные в базу/ а передал ли микросервис задание в очередь/ а что если...
На ютубе больше видео про "кнопочки съехали" по нескольким причинам:
-баги на ui чаще всего не критичны для бизнеса, их могут "оставить"
-в первую очередь тестируют бэк, верно работающая логика важнее съехавшей кнопки
-тестирование бка "просто так" не покажешь
Тестирование интересно, но не всегда легко