Василий Банников

Смысл - если уже есть компетенции на жаве, а в постмане нет.

Да, нужна.
Какая именно математика - зависит от конкретной предметной области.

Как я понимаю, в ручном тестировании математика абсолютно не задействуется

Что там что там математика используется примерно одна и та же.

Вроде нормально

Ну тебе же прямо в условиях даже подсказу дали - "сосредоточтесь на вводимых значениях".
Значит нужно смотреть на граничные значения.
Из самых очевидных:
-1, 0, +1.
Из неочевидных - можно попробовать посмотреть на формулы, которыми обычно из одной шкалы в другую переводят и на определения каждой из шкал. (например в случае кельвина - он никогда не может быть меньше нуля вроде как)
Также можно посмотреть на разные потенциально проблемные варианты:
1. Добавлять пробелы в начало/конец/середину
2. Добавлять незначащие нули перед целой и после дробной части
3. (пробовать) Добавлять лишние разделители знаков
4. Пробовать вставлять валидное или невалидное значение через ctrl+v
5. Пробовать вводить что-то кроме цифр, разделителя, и знака
6. Пробовать вводить несколько плюсов или несколько минусов
7. Пробовать вводить плюс или минус не перед числом а после или в середине.

Ещё можно попробовать вводить с дробной и без дробной части. Указывать запятую или точку для отделения дробной части.

Проверить нужно граничные значения на всех комбинациях "из-в"

Чтобы не получить комбинаторный взрыв - попробуй использовать pairwise подход.

Чем IMAP как протокол не угодил?

Нет.
Если ваша админка сделана по готовому шаблону - вероятно он уже протестирован без вас.

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

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

Не знаю, какое конкретно требования выдвигаются, но поспешу огорчить по поводу

очень любит играть в различные комп. игрушки.

Тестировать игры и играть в них - это очень разные вещи.
При тестировании нет абсолютно ничего, что радует при обычной игре.

Вообще, если этот человек может нормально пользоваться компьютером и может играть в игры с использованием стандартной периферии, которые придётся тестировать, то да - какихто проблем с работой быть не должно.

Но я бы не зацикливался именно на тестировании игр в частности и на тестировании вообще, ибо есть много других профессий, в которых не обязательно иметь обе руки.

Какие тесты нужно было сделать, чтобы предотвратить этот баг?

Такие дефекты, обычно, отлавливаются при помощи ручного тестирования.

Но искать визуальные баги в тексте в играх - это очень дорогое занятие, тк нужно сценарии прогонять на десятках разных конфигураций (разрешение экрана/масштабирование интерфейса/язык)
=> поиск такого бага до выпуска новой версии будет занимать много времени => это будет очень дорого.
Что вообще не соотносится с его критичностью.

Ещё можно попробовать скриншотное тестирование - может быть будет дешевле в плане человеческих ресурсов, но всё равно очень дорого в плане железных ресурсов и не гарантирует надёжность (скриншотные тесты известны своей нестабильностью), да и не очень популярны они в играх (ибо инструментов нет), и из-за обилия анимаций они будут очень сложны в поддержке.

А так да - тут скорее архитектурная проблема и дизайнер не учёл, как должно работать переполнение строки в этом случае.

Так в чем практический смысл тестирования? Где оно нужно, когда даже крупнейшие компании допускают явные баги на главном экране игры (а там про команды с миллионными бюджетами).

Ты не учитываешь множество других, более критичных дефектов, которые не попали в релиз как раз благодаря тестированию.

Игры тут не самый лучший пример, тк их тестирование несколько отличается от тестирования обычного ПО своей количественной (очень много чего может сломаться) и качественной (много что сложно проверить) сложностью, а также количеством различных граничных значений.
+ в играх есть рандом, который может в неожиданных местах всё сломать.

Интеграционные тесты - иногда могут быть как юнит тесты, но без моков (или почти без моков)

При e2e могут мокаться некоторые внешние зависимости (платёжная система например)

В остальном вроде всё так.

0. Ты, видимо, тестировщик aka QA Engineer
1. Ты столкнулся с дефектом/багом (поведение не совпадает с ожиданием), таким как одно из:
- Ошибка там, где ошибки быть не должно. (Например оставляешь комментарий, а вместо оставленного комментария ты получаешь ошибку, не важно какую)
- Не та ошибка, которая ожидалась, если ожидалась ошибка. (Например ты оставляешь очень длинный комментарий, но вместо "Ваш комментарий слишком длинный" ты получаешь "Произошла неизвестная ошибка")

2. Тебе нужно описать, что ты будешь делать дальше.

3. Тебе нужно написать баг-репорт для этого гипотетического дефекта на английском.

Зависит от процессов в компании.
В принципе нормальной практикой считается, когда разработчик сам хотябы мельком прокликивает основные сценарии перед отправкой в тестирование.

Почти в каждом методе в подготовке (Arrange) необходимо сделать две вещи: занести исходные данные для теста в базу и отправить запрос на авторизацию.

В xunit для такого используется конструктор.
А если это асинхронные вызовы, то интерфейс IAsyncLifetime.
Туда выносится то, что прям никак не отличается от теста к тесту.
А для чистки после выполнения тестов - Idisposable.Dispose

Про мобильное и сафари - оно в первую очередь нуждается в тестировании, но не обязательно в автоматизированном.
И то только если много пользователей сайта/ЦА на нём сидит.

По тому тут вопрос стоит не тем боком.

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