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

Власть - в изменении стандартов работы

Пользователи спасибо скажут к моменту, когда вы уволитесь уже из компании, увы

типо того

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

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

Качество продукта, оно ж не на упаковке кода в коробку начинается, а с блеска в глазах того, кто придумал чем пользователя осчастливить в этот раз

привет Константин, как можно протестить базу на перформанс?

Привет, Дмитрий!
Я постараюсь ответить, только уточню одну мелочь. Это относится к сообщению выше или просто способ пингануть был?

Вообще, если вкратце, если есть ощущение что производительность БД недостаточно, и её можно улучшить, лучше начать с профилировщика (встроенного в выбранную СУБД или стороннего продукта) и получить информацию о том, какие виды запросов наиболее "проблемные", а так же, отчёты, помогающие определить "мусор" вроде неиспользуемых таблиц или неправильно настроенных индексов.
Причиной возникновения проблем производительности может быть работа не напрямую с базой, а через различные фреймворки, автогенерация кода у которых не всегда идеальна.

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

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

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

😉 именно так, эт только на словах легко типа тест план сделал, в конфлуенс записал все и сидишь такой

Ab темтирование уже пробовали?

немного, не в моем департаменте, и там где оно есть, оно не поставлено на рельсы, а весьма хаотичного характера

Прислал тут разработчик ответ на вопрос 😂

У вас разработчик с дефектом

Не ) он очень хороший ) просто бывает общаемся мемами )

Он наоборот за, чем больше качественных тикетов, тем лучше )

Друзья! 15 февраля в эту субботу, в 12-00 ждем вас на пятых Московских максимально романтических посиделках автоматизаторов! Место проведения — кафе «Point Coffee&Food» на Садовнической набережной 75.
https://comaqa.by/2020/02/14/comaqa_moscow_lean_coffee_5/