Хочу стать тестировщиком, но не понимаю в чем заключается работа?

Видел как тестируют сайт, браузер меняют в размере, сдвигается интерфейс, записывают показатели... и это всё что я понял. А меня интересует вот что:

Если ты учишься, то нету никакого деления на фронт или бек? на языки? А как выглядит тестирование например бэка? Где всё это найти?

Понятно что на курсах, но чтобы на них пойти я и должен понять, надо оно мне или нет, поэтому разбираюсь. На ютубе все ток сайтики тестят "о смотрите кнопочка съехала, записываем показатель". Да, но это лишь часть работы ведь, а как там остальное тестирование выглядит?
  • Вопрос задан
  • 438 просмотров
Пригласить эксперта
Ответы на вопрос 2
VoidVolker
@VoidVolker
Разработчик ПО и IT-инженер
записывают показатели... и это всё что я понял
Если ты учишься, то нету никакого деления на фронт или бек? на языки? А как выглядит тестирование например бэка? Где всё это найти?

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

Да, но это лишь часть работы ведь, а как там остальное тестирование выглядит?

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы