Поделюсь несколькими интересными моментами из своей работы.
У нас сложное монолитное приложение с базой данных на 400+ таблиц. Тестирую белым ящиком, так что вижу код и все запросы, которые написал разработчик.
Была ситуация: разработчик делает выборку из двух таблиц с похожими столбцами, группирует по какому-то столбцу и соединяет их оператором union, после union снова идет какая-то группировка и на выходе сумма, посчитанная в агригируемом поле, не сходится с моими расчетами, причем происходит это не всегда, и я никак не могла доказать разработику, что это баг. Все скидывалось на кривые данные на тестовом стенде, ибо в остальных случаях проблемы не было. Но я не унималась, буквально на части разложила запрос и обнаружила то, что сама уже и не помнила со времен изучения sql. Оператор union при склейке убирает дубли, а так получилось, что после группировок в полученных таблицах могли образовываться одинаковые строки, на что я и наткнулась по чистой случайности. Соответственно, после склейки данных становилось меньше и сумма считалась неверная. И вот пока я ему не ткнула, что хорошо бы поменять на union all, он просто отмахивался от меня. Потом, конечно, он извинился, и я получила порцию комплиментов о своем профессионализме и упертости.
Или вот еще история. Ко мне пришел баг с прода по правам. Некое действие должно было быть разрешено при наличии одного из прав (роль1 или роль2), а оно падало с ошибкой 403 и под 1, и под 2 правом. Причем одно из прав было "админ" - право, которое простым смертным не выдается обычно. И мы с разработчиком вдвоем стали разбираться в коде. В итоге наткнулись на строку типа:
If (hasNoRole (роль1)II hasNoRole(роль2)) { тогда отказать в доступе).
Думаю, можно не пояснять, что функция hasNoRole проверяла отсутствие права у пользователя, и, если оно отсутствовало, возвращало тру. И вот смотрели как бараны на эту строку, ну вроде все же правильно... сразу ошибка не бросилась в глаза. Мы потратили какое-то время, чтобы понять, что проблема в логическом сложении. Баг был пофикшен исправлением одного символа: II на &
А вот совсем недавно я тестировала наш новый сервис для сбора и хранения некоторых метрик из стороннего сервиса. У нашего сервиса не было интерфейса, а только апи. Одна из апи проверяла срок действия токена и возвращала 3 варианта ответов: все ок, токен скоро просрочится, токен просрочен. На 2 последних варианта разработчик впилил 2 разных кода ошибки, один из которых был 418! Если честно, не все статус-коды знаю наизусть, и этот меня смутил так, что я полезла за расшифровкой. Оказалось, этот статус практически не используется, так как был создан как первоапрельская шутка, которая всем так зашла, что код внесли в спецификацию протокола http. По первоначальной шутке на запрос к серверу сделать тебе кофе возвращается ошибка 418 I'm teepot!
Буквально: я чайник. Когда я рассказала эту историю мужу, он сразу спросил, вышло ли это на прод? "Если вышло, снимаю перед этим господином шляпу: за все время своей работы я так и не нашел подходящего случая добавить этот код, хотя всегда хотел". Недавно сервис развернули на продовском окружении, я ничего не сказала разработчику о том, что лучше заменить код ошибки, думаю, он сам понимает все риски. Однако предполагаю, что данными апи в будущем будут пользоваться только наши самописные сервисы, и, я думаю, они разберуться, как обрабатывать этот код)
Или вот еще ситуация. Неожиданно появился баг на фронте, в одной из таблиц, где отображались заказы. В поле "водитель" у некоторых заказов отображалось неверное имя водителя.
Все эти заказы были на одного и того же водителя, но на фронте имя было другое. Проверила в базе данных и в запросе, который тянет данные из бд по заказу. Везде стоит айди правильного волителя. Проверила запрос, который тянет данные имени по айди водителя. Все ок, под целевым айди приходит верный водитель. Проверила другого водителя, имя которого отображалось на фронте, - оказалось, его айди был очень похож на айди верного водителя и он тоже возвращался в массиве данных водителей. Было что-то типа: 512 - верный водитель, 5121 - неверный водитель. Так вот на фронте для отображения имени водителя неверно использовался поиск по массиву полученных айди водителей. Забавный кейс, ведь работало это годами и не было проблем, пока у водителей не совпали вот так айди. А водители у нас хранились как пользователи - просто в группе "водители". То есть вероятность такого совпадения была крайне мала. Но все, что вероятно, рано или поздно всплывет на проде...
И напоследок хотела рассказать историю тестовой бд и количества проблем, возникших лично у меня. У нас на проекте есть тестовая бд, препродовая бд, продовая бд. Так вот тестовая бд - это ооочень старый дамп с прода, и сейчас там живут "демоны", если мы говорим о данных. Они настолько кривые, что тестировать на них новую логику порой очень сложно. Препродовая бд - это более свежий дамп с прода, и считается, что на ней можно тестировать логику, если это требуется на больших массивах данных. И я, как послушный тестировщик, первые полгода все тесты проводила на тестовой бд, в препродовую залезала редко, старалась ничего там не создавать и не менять. Но в один прекрасный день после выхода мною протестированной фичи в прод на проде массово полетели ошибки по критичному функционалу. Все в панике - скорее чинить. А ошибка связана со схемой бд. На проде нет какого-то столбца, который есть на тесте и к которому идет обращение в одном из методов, который используется буквально везде. Я проверяю свои тесты и понимаю, что на тесте ошибок не было, столбец в моей задаче не создавался, разработчик это также подтвердил. Обычно если при разработке вносится изменение в бд, то в комите создается специальный файл с запросами на создание новых сущностей на бд прода, которые выполняются при деплое. Выяснилось, что данный столбец существовал на тестовой бд уже давно, кто-то его создал при разработке, но он ему не пригодился, и разработчик его не удалил!! Мой разработчик его использовал в нашей задаче, будучи уверенным, что на проде он тоже есть. Мне погрозили пальчиком, типа "будь внимательна, проверяй, чтобы все сущности из бд были и на проде". Но знаете, это вообще-то нереально, практически любая фича - это взаимодействие с бд, на проекте 400+ таблиц, в новой фиче может быть несколько сложных запросов к разным таблицам. Прогонять их все каждый раз на проде анреал, к тому же не все запросы на селект. Через некоторое время ситуация повторилась один в один, я не выдержала и закатила скандал. Мол, давайте что-то решать: либо приведем в божеский вид тестовую бд и обяжем разработчиков за собой чистить, что они там насоздавали и что не пригодилось, либо я переношу все свои тесты на препродовую бд, на которой вроде бы пока такой проблемы не наблюдалось. На что наш тим лид мне ответил, что я могу тестировать на препроде. Так и не знаю, передали ли разработчикам мое "пожелание". На тестовую бд я захожу теперь крайне редко, но точно знаю, что там дофига левых столбцов и таблиц так и осталось. Тестирование на бд, отличающейся от прода самой схемой, на мой взгляд, просто мартышкин труд, я лучше уволюсь одним днем, чем буду делать такую работу.
Вот, пожалуй, самое яркое, что сразу вспомнилось. Интересно ваше мнение, особенно касательно бд. Может я не права?
