Ответ на пост «Настоящие тестировщики»2
Подушню, эту хуйню.
Вот у этого канала канешна есть смехуечки, но во основе своей гиперболизированная шляпа, которая к реальности не имеет отношения.
Разберем по уму эти "ахуительные истории" тестеров:
Случай набер Уно.
а) Невозможно положить все из-за 1 дампа. Прод один сервер, тест другой сервер, база 1С вообще в отдельной кладовке. Тут нужно в серверную с базуки ебнуть или уборщицу тетю Валю просить из розетки выключить.
б) Сам сценарий вполне возможен, но для разработки или симуляции, такая шляпа дальше не уйдет - потому что вычисляется еще до вывода в ОПЭ.
Как работает:
Во фронте по форме указывают определенный элемент поля и кол-во символов, и вот тут ошибка и может возникнуть. Фронт указывает формат стринга, дав возможность пользователю вбивать любое кол-во символов в поле.
НО при передачи в бек, эта ситуация сразу создает дамп системы. И просто не обрабатывает кейс, потому что в беке сама табличная часть с этим атрибутом будет идти с конкретным числом символов. Систему это не положит, вычисляется тестировщиком на уровне разработки или симуляции.
И да, сценарий реалистичен, но для этого под эту задачу должно быть 3 или 4 табуретных сотрудников.
*табуретный аналитик - он ставит задачу и описывает тех. часть.
*табуретные разрабы - фронтер и бекендер, оба используют динамический тип данных в юзер-полях. Комбо, если это один и тот же человек.
*табуретный тестировщик - который все проморгал и протащил по всем базам.
Случай набер Дос.
Это вообще не возможная ситуация, в рамках логистическо-финансовых систем.
Потому что любой возврат - будь он автоматическим, или ручным. Виртуальным или физическим. Всегда будет проходить ручную проверку. И при оформлении самого возврата, и при перемещении запаса на складе, и при формировании документов и т.д.
Случай набер Трэс.
Понятно что пиздеж, но как и все остальное в канале - максимально гипербализирован.
В IT-середе за мою практику было куча дебильноидиотских ситуаций, с логическими тупиками, изобретательностью пользователей и "неубиваемым" оптимизмом заказчика.
И дикие истории эта не шляпа выше, а что-то типа "приняли чувака сверхпиздабола в команду, который в течении полугода водил за нос всех от команды до заказчика, по итогу уйдя в закат и оставив ровным счетом ни-ху-я, хотя было куча встреч, проверок и прочего", или "мигрировали в новую систему, произошла мисскоммуникация и бекап поехал в этот же день - по итогу проебано было все, восстановить удалось меньше половины" и т.д.
Какой-то ты слишком категоричный, явно недостает опыта.
Банальнейший пример из реальной практики. Тут прям долбаебизм бесконечной степени по всем фронтам, конечно, но сам факт:
- фронтендер по приколу запихал в форму создания сущности около 40 мб текста. На проде
- ни на фронте, ни на бэке почему-то небыло проверки на максимальный размер данных
- бэк на самом деле был микросервисным, поэтому этот запрос после валидации полетел в каффку
- каффка немного прихуела от такого набора данных и начала немного тормозить, но пока ничего критичного
- один из сервисов был написан дебилом, и падал от обработки такого сообщения без нормальной ошибки
- в сервисе обработки ошибок почему-то подумали, что пересоздать упавшую задачу - хорошая идея. При этом старая из каффки не удалялась, а падающий сервис пытался обработать и её, и каждую пересозданную задачу
Таким образом простые 40 мегабайт обычного текста в простой формочке положили сервис с 80к пользователей (на тот момент) и оборотом в несколько десятков миллионов рублей.
А вы говорите, один дамп систему не положит
P.S. ситуация реальная. Дима привет, не надо больше делать карательное тестирование на проде