Хочу стать тестировщиком, но не понимаю в чем заключается работа?
записывают показатели... и это всё что я понял
Если ты учишься, то нету никакого деления на фронт или бек? на языки? А как выглядит тестирование например бэка? Где всё это найти?
Тестирование - это проверка чего-либо на соответствие требованиям. Более общий термин - контроль качества. Оно есть везде - любая выпускаемая продукция должна соответствовать каким-то требованиям. В ПО требования к нему пишутся в ТЗ, соответственно задача тестера - проверить, что программа соответствует всем требованиям, изложенным в ТЗ. Написано, что кнопка должна быть зеленой - тестер проверяет, что она зеленая. ПО тоже бывает разное - десктопное, мобильное, веб, бэк, сервисы, прошивки для МК и прочее. И тестируется оно тоже по-разному. Кроме того, существуют разные методики тестирования, разные сервисы, приложения и библиотеки для тестирования.

Да, но это лишь часть работы ведь, а как там остальное тестирование выглядит? 
Так и выглядит - запускается приложение и по шагам проверяется, делает ли оно то-то и то-то или не делает, соответствует оно таким-то требованиям или нет. И повторяется кучу-кучу раз. Например: "кнопка должна быть зеленой", "сервис должен отдавать список пользователей по такой-то ссылке", "сайт должен открываться за 500 мс" и прочее. Чем больше система - тем больше тестов, чем больше разработчиков - тем чаще изменения, и тем чаще необходимо проходить все тесты и их все больше и больше. Вручную выполнять такое тестирование слишком дорого - для этого придумали автоматизацию тестирования. В нормальном рабочем процессе эти самые тесты пишут либо сами разработчики конкретных модулей либо сами тестеры при поддержке разработчиков. И, соответственно, есть какая-то веб-страничка, показывающая какие тесты система проходит, а какие - нет. Но, даже при наличии автоматических тестов - все равно остается много ручной работы, которую может выполнить только человек: оценить удобство использования, найти не очевидное применение или баг и прочее-прочее.
Привет. Суть в работы в том, чтобы минимизировать критичные для бизнеса баги, иначе - потеря денег.
"Если ты учишься" - смотря где, наверное. Есть слух, что джунов сначала сажают прогонять уже существующие тест-кейсы/ тестировать 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 чаще всего не критичны для бизнеса, их могут "оставить"
-в первую очередь тестируют бэк, верно работающая логика важнее съехавшей кнопки
-тестирование бка "просто так" не покажешь 
Тестирование интересно, но не всегда легко