В чем практический смысл тестирования?

Смотрю ролики по программированию, по тестированию - юнит тесты, модульные тесты и т.д.
Насколько я понимаю, тестирование эмулирует работу/вызовы компонентов системы с заданными значениями и проверяет ответ. Если ответ верный - то тест пройден. Проще говоря a+b=c. Если на входе a=2, b=2, c=4 - тест пройден, иначе нет.
Это теория, теперь практика.

Сегодня зашел в игру Overwatch 2 (крупный издатель, 35 миллионов аккаунтов). После обновления в игре баг - из за текста иконка лиги сдвинулась вниз.
63921f0bbf1bf830192298.jpeg
(Есть и другие баги...)
Какие тесты нужно было сделать, чтобы предотвратить этот баг? Баг, скорее всего возник из за изначальной ошибки проектирования - не ограничили длину текста, не поставили позицию иконки поверх текста, жестко не привязали иконку и т.д.
Но этот баг не отследить.

Предположим, что можно написать тест - если иконка вышла с формы - баг, тест не пройден. Но таких иконок +100500.
Это уйма тестов.
Приложение просто обрастет тестами в геометрической прогрессии. Миллион взаимодействий, зависимостей, комбинаций.

Так в чем практический смысл тестирования? Где оно нужно, когда даже крупнейшие компании допускают явные баги на главном экране игры (а там про команды с миллионными бюджетами).
  • Вопрос задан
  • 266 просмотров
Пригласить эксперта
Ответы на вопрос 5
@mayton2019
Bigdata Engineer
У багов есть разный impact. Или степень влияния на качество продукта. Вот какое влияние сдвинутых иконок?
Я думаю их увидели только жители стран которые используют перевод с английского и этот перевод оказался на несколько символов длинее оригинала из-за чего произошел развал дизайна. Можно сказать что аудитория некоторых стран ощутила легкое неудобство.

Тоесть impact - так себе.

А что будет если программист 3Д графики допустил ошибку, которая приводит к крашу игры? Тут влияние посильнее. Я-бы сказал что это провал релиза. Как такое пропустили тестировщики (автоматизаторы или ручники) неважно) - ХЗ. Но тут важно срочно бежать в студию и выкладывать на steam экстренное обновление игры. И счет идет не на недели а на считанные дни. Кое-кому из отдела разработки и тестирования придется провести несколько безсонных ночей перед багфиксом.

Вот в этом и есть практический смыл тестирования. Тестировать важные части логики.
Ответ написан
Комментировать
@LJ322
Я редко когда слышал о тесте непосредственно вёрстки, а там где она была, то тестили снепшотами какие-то отдельные статические части.

Я полюбил тесты после того, когда лично убедился, что они в разы облегчают отладку и поддержку кода. Допустим есть какой-то компонент, который в процессе разработки растёт и увеличивается. Сначала он простой и там надо смотреть как меняется пара значений в зависимости от пары аргументов. Затем он расширяется и начинает взаимодействовать с другими компонентами. И вот со временем получается большая структура с тысячей аргументов и сотнями состояний (в общем). Например функционал оформления кредита в банке, состоящий из 5 шагов. Под него написаны тесты. И вам надо внедрить новое свойство на 2 шаге, которое будет ещё в 3 местах менять другие значения. Запуская тесты, вы либо видите, что всё ок, либо видите на каком этапе что отвалилось. И не приходится в ручную перебирать всевозможные варианты

Так же тесты помогают лучше понять какую задачу выполняет код (хорошие тесты могут заменить документацию)
Ответ написан
Комментировать
@bacon
Это уйма тестов.
И если от этой уймы, написать хоть какой-то процент тестов, то этот процент можно выполнять автоматически, в любое время, при любых изменениях кода, теперь сопоставь это с ручным тестированием. Ну и сравнить юнит тесты и визуальные проверки даже и не стоит, разная сложность.
Ответ написан
Комментировать
vabka
@vabka
Токсичный шарпист

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

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

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

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

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


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

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

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

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

Где исправлять баг дороже, чем его отловить.

Например, вы программируете микроконтроллер. Случился критический баг - покупайте новый.
Или вы делаете базу данных. Баг = утечка данных пользователей = всем наплевать...
Или вы разрабатываете нейросеть, а потом в международном журнале вас уличают в обмане и тормозят научную карьеру.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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