Не вижу смысла хранить пароли локально, чтобы не увеличивать возможность утечки того же файла или же, что может быть хуже — потери этого файла со всеми паролями. Сгенерил и забыл.

mpw.leopard.in.ua/ — пользуюсь Master Password. Не сильно удобны пасворд менеджеры, да и не хочется доверять свои пароли облачному сервису.

mshelper майнера не могли поймать? У самого Air с точно такими характеристиками и на High Sierra.

Попробуйте по классике как с Windows: забекапить данные и установить систему с нуля.

youtu.be/-p6WWRarjNs

Чому ми вирішили, що жертвувати потрібно саме скоупом, а якість ставимо на перше місце?

Что вы подразумеваете под «жертвой скоупа»? Есть команда, она делает (предположим) 20 «estimation point» в неделю. Например скоуп на две недели. Команда может сделать 40 «estimation points» за скоуп. Никто не будет просить их перерабатывать (хотя зависит от компании и как она относится к людям). Значит если пришла задача, у которой приорит самый высокий — она добавляется в текуший скоуп и, что логично (поскольку у этой задачи есть свой estimation point), поскольку все тех же поинтов 40, то задачи внизу «вытесняются» (переходят) на следующий скоуп. Они не умирают на каком то жертвенном алтаре.

Може потрібно пожертвувати або дедлайном, aбо таки якістю?

Ни тем не другим, если вы заботитесь о продукте. Приоритет и расчет, что команда успеет до дедлайна без потери качества. Каждая компания сама определяет свой стандарт качества, от которого она ниже не опускается. Так что «нет тестов» — это может быть такой стандарт качества от этой организации/команды, а не какая то проблема.

Глобально, замовник спочатку пріоритезує між собою скоуп/час/якість

Не знаю что значит «между собой», но нужно приоритизировать вместе с ним (многие клиенты не знаю даже как это верно сделать). И уж точно клиенты не создаю скоуп — они только говорят что им требуется и какие сроки.

Не розумію тих, хто говорить, що тести — завжди must have

Не всегда — почитайте комментарии, тут уже писали про «прототипирование».

Про село и ламборджини — не уловил связь со статьей. В данном случае во время планирования сыну не донесли, что ему нужен трактор.

Якщо ви зафіксуєте API спілкування різноманітних систем/підсистем/модулів між собою, то це й буде ваш аналог тесту

Теряете гибкость в изменения под новые требования.

А ще якщо й зробите слабкозв’язану архітектуру замість сильнозв’язаної, то будь-які зміни в модулях не будуть вимагати тестування функціональності, що вже існує, бо вони не впливають один на одне

Или просто отвалятся эти модули — они же слабосвязаны, кто это заметит?

Виносимо по максимуму все в DSLs (domain specific languages), та отримуємо код, який буде схожий на конструктор LEGO, збирай що завгодно. Якщо не подобається DSL, переходимо до патерну «конфігуруйце», коли сам код пишеться один раз, потім тільки конфігурується.

Это не решает проблему кода без ошибок. Если DSL содержит ошибки, будете делать поверх него еще DSL?

Якщо не подобається DSL, переходимо до патерну «конфігуруйце», коли сам код пишеться один раз, потім тільки конфігурується.

Это позволяет изменятся только в тех пределах, куда позволяет конфигурация. В итоге требование получается — «А давайте напишем систему так, чтобы, когда нам что-то понадобится, оно там уже было» (подсказка — код и есть таким видом «конфигурации»)

Маленька помилка призводить до краху всього

Возможно Вам нужно указывать про какие системы вы говорите. Учитывая в последний год хайп на микросервис архитектуру (что не отменяет тестов) уже меньше ведет к подобным проблемам.

Коли починаєш розповідати, що є підходи та методології, які мінімізують ті самі негативні наслідки, які начебто мусять виявляти тести, на тебе дивляться як на дурника, який щось там верзе

Расскажите про эти подходы и методологии, многие могут не знать о них.

А зачем связывать «вылизывание», «разработка замедленными темпами» и «правильный процесс разработки». При правильном процессе — нужна другая фича, без проблем. Сдвигаем эти на другую итерацию и делам фичу, которая нужна первой (и да, тут тесты никто не отменял — смешно будет, если на демо инвестору упадет эта фича и он из-за этого и уйдет). Это приоритет, а не «слоники побежали» (без тестов).

И опять я возвращаюсь к основной теме в статье — если заказчику надо все и сразу?

И как, 9 женщин рожают ребенка за месяц?

Никогда не сталкивались с моментом — если в итерации Х не будет такой фичи то итерации Х + 1 просто не будет?

Каждый день. Нет денег на N фич — значит делаем только те, на которые хватает. Приоритезируйте с клиентом. Многие хотят фейсбук за $100, это не повод делать «плохо».

Так это же проблема в процессах и людях, а не в тестах.

Не понятно, почему тесты рассматриваются как отдельная сущность от функционала. TDD, BDD — тесты и есть часть фичи или функционала. Не пишите тесты — значит не пишите функционал. Нужно успеть к дедлайна? Сокращайте набор фич к нему, а не качество продукта.

Ну тут спорить не буду — пусть человек занимается тем, чем нравится. Главное, чтобы эта «специализация» была востребована.

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

Да можно даже аналог github.com/...​.js/blob/master/README.md чтобы ловить нестабильные кейсы.

Подготовить тестовые данные, дернуть API, посмотреть что там в БД записалось.

Это все ещё могут сделать интеграционные и системные тесты.

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

Хотите сказать, что мануальный QA проверяет качество кода и тестов? Я имею ввиду качество именно написанного кода, а не только качество, как получился функционал этой фичи.

даже предложить, как можно улучшить разработанную функциональность.

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

Это учитывается ещё до написание кода через планинг покер командой

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

TDD, BDD, code review — таска уже покрыта тестами и проверена другими инженерами перед принятием в бранч. Зачем тут QA?