а кто должен делать аналитику? специально обученный специалист по зеленым отметкам?

возможно вам придется выставить тербования самим, начинте с размера запроса, например 1kb, 100kb, 1mb и т.д. у вас будет превый критерий

размер максимума

Ссоры в личку, иначе будет бан. Разговаривайте конструктивно.

а можно те же кейсы запустить 1000 раз и получить нагрузку а как интерпретировать результаты? что это дает? почему 1000? где статистика? что прямо все-все автотесты, что есть, надо запустить 1000 раз? Получается просто абстрактная нагрузка ради нагрузки. Не привязанная даже к требованиям бизнеса.

все сводится к тому, что вам надо свести систему к одному критерию а дальше играться с потоками

все сводится к тому, что вам надо свести систему к одному критерию а дальше играться с потоками

речь немного о другом шла.

все сводится к тому, что вам надо свести систему к одному критерию а дальше играться с потоками

но спасибо )

Перформанс напрямую не связан с количеством людей.

Зато связана статистика по которой строятся выводы о перфомансе, их повторимость, непротиворичивость (корректное стандартное отклонение, распределение итд)

Зато связана статистика по которой строятся выводы о перфомансе, их повторимость, непротиворичивость (корректное стандартное отклонение, распределение итд)

Нет, с количеством людей это тоже никак не связано. Это связано с количеством прогонов теста.

вопрос) описание : “Если в уведомлении нет свойства <m>, то указываем строку nnnn”, если есть такое описание, то передавать в своиствах m пустое значение это правильная проверка?

Встречный вопрос: что значит "правильная"?

Встречный вопрос: что значит "правильная"?

есть ли смысл такое проверять? и что бы вы прверяли

Да, любые входные параметры имеет смысл проверять на их отсутствие и пустые значения.

Да, любые входные параметры имеет смысл проверять на их отсутствие и пустые значения.

просто получился баг когда передаю пустые параметры работает не верно) и разраб говорит что понял эту формулировку как именно отсутствие, получается размытая формулировка?

Отсутствие параметра != пустой параметр. Другое дело, что в рамках описания выше логика должна быть одинаковой.

Нет, с количеством людей это тоже никак не связано. Это связано с количеством прогонов теста.

В оригинальном сообщении, на которое я отвечал не тебе, шла речь о том, что проводить ручками, один человек или 100 не особую роль играет

В оригинальном сообщении, на которое я отвечал не тебе, шла речь о том, что проводить ручками, один человек или 100 не особую роль играет

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

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

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

Речи про "стандартная практика" там не было. Всё зависит от цели, системы и ожидаемого результата. Для некоторых кейсов рук более, чем достаточно.

И вольюм крайне сложно проводить "ручками", а пефоманс ручками - совершенно стандартная практика.

И вольюм крайне сложно проводить "ручками", а пефоманс ручками - совершенно стандартная практика.

не читал остальной тред, но что значит "перфоманс ручками"?

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

не читал остальной тред, но что значит "перфоманс ручками"?

Вот и я задаюсь тем же вопросом Это фраза не моя

я понял, я просто отвечал на последнее

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

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

Зависит от уровня абстракции.

От 0 до бесконечности раз это ручками или хотя-бы циклом в минипрограмме?

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

От 0 до бесконечности раз это ручками или хотя-бы циклом в минипрограмме?

А между прогонами постусловия выполняем ручками? Сбор результата, очистка кеша, проверка что система ещё жива после предыдущего прогона

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

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

ээээ, а можно норм описать?

Ну, т.е. это всё ситуативно. Условно, у меня сейчас в отладке деплой скрипт который даёт разброс +- 5-6 секунд при выполнении. Соответственно любое качественное изменение, не вписывающееся в статистическую погрешность дает видный на глаз прирост лучше\хуже.

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

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

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

В этом мире нет "никак нельзя".

без скриптов и записи данных без вмешательства человека - это не перфоманс, а хреноманс

В этом мире нет "никак нельзя".

ненавижу людишек, слава роботам (но это для другого чята, кнеш)

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

меряем скорость загрузки фотошопа секундомером?

меряем скорость загрузки фотошопа секундомером?

Скорость загрузки фотошопа, как раз таки, смысла замерять руками нет. Повторяемость высокая, выборка нужна большая и разная (железозависимость и вот это всё). Пример, когда хватает рук, выше уже приводил.

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

У нас есть разделение критичности на severity и priority. Одно - критичность техническая, приложение не реагирует на тапы, им нельзя дальше пользоваться, второе - критичность для конечного юзера, у какой части пользователей и насколько подгорает от бага. Судя по описанию, одно у вас низкое или среднее, а другое высокое.

Опытные товарищи меня тут могут поправить

У нас есть разделение критичности на severity и priority. Одно - критичность техническая, приложение не реагирует на тапы, им нельзя дальше пользоваться, второе - критичность для конечного юзера, у какой части пользователей и насколько подгорает от бага. Судя по описанию, одно у вас низкое или среднее, а другое высокое.

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

Скорость загрузки фотошопа, как раз таки, смысла замерять руками нет. Повторяемость высокая, выборка нужна большая и разная (железозависимость и вот это всё). Пример, когда хватает рук, выше уже приводил.

а применение эффектов фотошопа встроенных на картинки?

Разве критичность определяется не попоболью для конечного пользователя? severity и priority - это, скорее совокупность оценок, которые позволяют определить в итоге, как срочно нужно решить проблему.

Вот чего я никогда не понимал, так это зачем нужны и severity, и priority.

Вот чего я никогда не понимал, так это зачем нужны и severity, и priority.

Потому что это разные метрики.

боянный же вопрос: severity - это критичность для работоспособности функционала в продукте или продукта в целом, priority - это как всегда значимость для релиза/приоритетность для исправления

@alexejv фас!

никто еще не скинул?) https://www.youtube.com/watch?v=No0oyF5dQXY

например, если наш продукт крэшится при запуске ворда, то северити будет "критикал" ибо продукт полностью неработоспособен в практически дефолтной конфигурации системы, но приорити может быть (если у нас от 1 до 3 вниз) - 2 или даже 3, если у нас есть куча глюкавого функционала, а до релиза ещё 5 спринтов и в текущем спринте/итерации мы можем просто ворд не запускать

например, если наш продукт крэшится при запуске ворда, то северити будет "критикал" ибо продукт полностью неработоспособен в практически дефолтной конфигурации системы, но приорити может быть (если у нас от 1 до 3 вниз) - 2 или даже 3, если у нас есть куча глюкавого функционала, а до релиза ещё 5 спринтов и в текущем спринте/итерации мы можем просто ворд не запускать

Я бы поставил приорити minor, а северити удалил бы из воркфлоу проекта, как ненужное что-то. Но это ладно, я скорее всего-то чего-то не понимаю. Видео посмотрю, спасибо.

никто еще не скинул?) https://www.youtube.com/watch?v=No0oyF5dQXY

Спасибо

Я бы поставил приорити minor, а северити удалил бы из воркфлоу проекта, как ненужное что-то. Но это ладно, я скорее всего-то чего-то не понимаю. Видео посмотрю, спасибо.

тестировщик не вправе ставить приоритет для фикса, приоритет - это для менеджмента/триэйджа/бизнеса

триэйдж это кто?

тестировщик не вправе ставить приоритет для фикса, приоритет - это для менеджмента/триэйджа/бизнеса

Грустно быть тестировщиком в вашем мире.

триэйдж это кто?

https://en.wikipedia.org/wiki/Triage )))

Грустно быть тестировщиком в вашем мире.

в любом мире, никто, кроме бизнеса не может сказать - нужен ли этот фикс или нет

Я видимо как QA Lead/PM больше сужу уже, извините)

в любом мире, никто, кроме бизнеса не может сказать - нужен ли этот фикс или нет

Окей, значит моего мира не существует. Как скажете.

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

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

нет

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

ERROR: S client not available

И в разработку тоже, и в продакт

то есть бизнес - это строго и сугубо про бабло

если тестировщик будет думать или принесёт фикс этого бага бабло или нет - это тож фцплм

Вот чего я никогда не понимал, так это зачем нужны и severity, и priority.

Лет 10 назад Александр лобач об этом уже все сказал. На текущий момент его статья - лучшая.

Бизнес - это система, а про бабло там только часть.

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

но принесёт ли бабло эта фича или этот багфикс или нет - это не задача тестирования

Конечно, а задача разработчика - транслировать тз в код. :)

иначе высокий риск пропуска или недооценки реально значимых багов

но принесёт ли бабло эта фича или этот багфикс или нет - это не задача тестирования

Не знаю с какого сообщения мы стали говорить про бабло, но изначально было про ценность

А ценность это не только бабло, но и удобство, виральность, эстетическое удовольствие

Конечно, а задача разработчика - транслировать тз в код. :)

задача программиста - дизайнить и имплементировать идею в рабочий продукт путём написания кода

что вы ещё хотите от программиста то?

красивый хороший код)

Я много чего хочу от разработчика. И от QA тоже много чего хочу. Поэтому существую в реальности, которой не существует и радуюсь нормально работающим процессам разработки.

А ценность это не только бабло, но и удобство, виральность, эстетическое удовольствие

ценность для бизнеса - это бабло, неважно - прямые продажи или покупка сервисов через рекламу

Причем половина этих "хочу" - далеко не технические.

Как же тут некоторые любят заниматься терминологической софистикой )

Причем половина этих "хочу" - далеко не технические.

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

Это вопрос к тому, кто работает со столяром. Я предпочитаю работать с теми, кто приходит на работку не код писать, а делать продукт.

Пока получается норм. :)

Это вопрос к тому, кто работает со столяром. Я предпочитаю работать с теми, кто приходит на работку не код писать, а делать продукт.

а что в это входит? в эти задачи

В том числе оценка того, как сделанное\несделанное повлияет на бизнес.

В том числе оценка того, как сделанное\несделанное повлияет на бизнес.

то есть вы хотите, чтобы дев и кьюа сели анализировать рынок и пока не разберутся с аспектами, трендами, конкурентами и кучей аналитики - не садились за имплементацию?

дешевле нанять одного бизнес аналитика

а знание экономики и психологии для дев и кьюа тож обязательно?

то есть вы хотите, чтобы дев и кьюа сели анализировать рынок и пока не разберутся с аспектами, трендами, конкурентами и кучей аналитики - не садились за имплементацию?

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

Коммуникации, и вот вся эта херня.

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

ценность для бизнеса - это бабло, неважно - прямые продажи или покупка сервисов через рекламу

а вот если у вашего продукта на главной опечатка, это приносит бабло или уносит?) репутация компании занимает не последнее место )