Хочу добавить, что контрольные карты Шухарта работают только для статистически управляемых процессов. То есть для таких величин, вариации в которых обусловлены исключительно трушным рандомом, а любая вариация обусловленная не природой рандома уже рассматривается как "специальная причина".
В айтишечке процессы в основном "статистически неуправляемые". Нет однотипных задач, вариации (в т.ч. в длительности выполнения задач) обусловлены не фактором случайности, и т.д.
JIRA рисует не контрольную карту Шухарта, конечно же. Это какая-то другая контрольная карта. Либо не контрольная карта вовсе, и её не следует называть контрольной картой.
Есть небольшой нюанс. Это всё справедливо для тех компаний, которые согласны тестировать на реальных пользователях, приняли осознанное решение это делать. Эти компании сознательно готовы пропускать баги в прод, получать баг-репорты от пользователей.
Потому как автоматизация не может найти все проблемы в продукте, и если у вас QA занимаются только выстраиванием процессов и автоматизацией проверок, то реальные пользователи будут находить реальные баги.
Работа службы поддержки в таких компаниях тоже должна быть выстроена соответствующим образом.
Зачем целенаправленно повышать точность оценок? Ведь неточность / вариативность оценок отражает неидеальность / вариантивность реального мира разработки. Можно выставить требования к называемым цифрам, но это не изменит реальный мир и не сделает его более идеальным, чем он есть.
Если нам всё-таки понадобилось повысить точность оценок, то какими средствами этого достигать?
значение инпута, который имеет id «weightedEstimatedValueId» может устанавливаться путем выполнения яваскрипта, причем длительного давольно, поэтому тут есть вот такой слип
Вот и нужно подождать, пока значение инпута изменится с текущего на ожидаемое. Это и будет условие, которого «нет».
Хабы — это же не тэги. Я, например, на хабы подписываюсь. Не на все, а только на те, которые мне интересны. С трудом представляю себе кейс, когда человек подпишется только на UEFI тематику.
В первую очередь это может быть крайне сложного реализовать именно из-за организационного противостояния, но надо уметь доказывать. Мне это удалось, на примере самых опасных вредоносов — шифровальщиков.
Но ведь отбирание прав администратора от шифровальщиков не спасает… Вирус замечательно зашифрует всё, до чего сможет дотянуться, и под обычным пользователем.
Хочу добавить, что контрольные карты Шухарта работают только для статистически управляемых процессов. То есть для таких величин, вариации в которых обусловлены исключительно трушным рандомом, а любая вариация обусловленная не природой рандома уже рассматривается как "специальная причина".
В айтишечке процессы в основном "статистически неуправляемые". Нет однотипных задач, вариации (в т.ч. в длительности выполнения задач) обусловлены не фактором случайности, и т.д.
JIRA рисует не контрольную карту Шухарта, конечно же. Это какая-то другая контрольная карта. Либо не контрольная карта вовсе, и её не следует называть контрольной картой.
Да, для каких-то задач она подходит лучше.
Не знаю поможет или нет, но можно установить плагин YAML by RedHat
Потому как автоматизация не может найти все проблемы в продукте, и если у вас QA занимаются только выстраиванием процессов и автоматизацией проверок, то реальные пользователи будут находить реальные баги.
Работа службы поддержки в таких компаниях тоже должна быть выстроена соответствующим образом.
Патамушта.
У меня вопрос, вы тестировали продукты Microsoft?
Использование em уже не актуально…
https://benfrain.com/just-use-pixels/
http://kyleschaeffer.com/development/css-font-size-em-vs-px-vs-pt-vs/
blog.jetbrains.com/pycharm/2015/11/python-3-5-type-hinting-in-pycharm-5
fightingforalostcause.net/content/misc/2006/compare-email-regex.php