Если бы только правило Гудхарта включали в программу обучения экономистов, то бестолковых менеджеров было бы немножко меньше.
Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
Я еще несколько раз перечитал ваш ответ, и понял что же меня при первом прочтении резануло: по вашей логике продукт со сломаным логином можно выдавать пользователю? И зачем оно ему если он даже зайти в систему не сможет?
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Ну у нас такая ситуация, что не мы выполняем тесты мы их только пишем и анализируем результаты. Инструмент у нас самописный и приложение embedded. И результат автоматизированных тестов мы получаем только на следующий день, хотя новый билд у ручных тестировщиков уже сегодня, и соотв. информация «рабочий» ли билд известна уже сегодня. Т.е автоматизация не перед ручным тестированием, а после ручного смоук теста. Да, после. И все были бы рады, если бы автоматизация могла предоставить общую картину состояния билда, а она и предоставляет, только заказчик собирает все результаты в общий процент и смотрит на него. А контекстов штук двенадцать, разные команды, все пишут свои тесты. Кроме того у нас кроме красного результата есть еще и желтый, желтый результат не отображается в статистике, и не я это придумал. Вобщем все весьма и весьма грустно.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.
Стабильность тестов в моем понимании это когда тесты на одной и той же версии продукта выдают при повторном выполнении один и тот же результат. Результат может быть и красным, но он не должен изменяться при повторении. Если тесты всегда выдают стабильный красно-зеленый результат — на доверии это скажется негативно. Значит обеспечив стабильность мы еще не обеспечили доверие. Так же если все тесты всегда зеленые это тоже скажется на доверии негативно. Может они и не тестируют ничего.
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши UI тесты описывают пользовательские сценарии, сам «предмет теста» как я его называю, практически всегда в порядке, в 85% случаев ломается что-то вокруг, и тесты перестают работать. И это хорошо. Т.е. тесты ненадежные. Мы обмотали наш продукт красной проволкой и смотрим где эта проволока порвется. Получается как в том анекдоте, что «по дырочкам никогда не рвется». И пусть. Главное чтобы тесты реагировали на изменения.
А вообще я не доверяю тестам ни своим ни чужим. Всегда есть что-то что я не учел, пусть это даже пробел в спецификации. Тесты всегда недостаточно хороши. Так что такая категория как доверие, она слишком человеческая, чтобы применять ее в техническом плане. Я доверяю автоматизации тогда когда она находит ошибки в ПО. Находит — хорошо, не находит — плохо. А полагаюсь я на автоматизацию каждый день иначе я бы просто был не в состоянии даже близко проверить столько конфигураций
Вообще хочу отметить что часто когда статьи (а я их читал достаточно) говорят об автоматизации тестирования, как правило не разделяют виды тестирования. Получается что тезисы безоговорчно равноприменимы ко всем видам тестирования. На практике это не так. И нужно и важно выделять специфику разных видов автоматизированного тестирования.
Например: «Тесты должны быть независимы друг от друга. Их можно выполнять в любой последовательности».
Для юнит-тестов это высказывание может быть верным. Там подготовка теста (Setup) не сильно влияет на время прогона.
Но UI тесты, (приемочные тесты, где мы проверяем кусок фунционала в качестве пользователя) могут отклоняться от этого правила потому, что тесты должны быть быстрыми. Если я каждый раз буду заходить в свой раздел приложения перед началом проверки, то это будет занимать больше половины всего времени.
Я руководствуюсь принципом — тест должен делать только то что является предметом теста. Вход в раздел является тестом, и выполяется первым. После этого не нужно выполнять вход. Поэтому у меня тесты идут друг за другом. И это нормально. Упал вход, все тесты за ним посыпались — разрабы чинят вход. Потому что иначе пользователь до нижележащего фунцкионала просто не доберется. Все честно. Я мог бы исхитриться и обойти процедуру входа для последующих тестов, но это бы исказило пользовательский сценарий. Для сравнения: я мог бы выполнять вход перед каждым тестом, но если он сломан результат будет тем же. В первом случае первый тест покажет что вход не был выполнен, а последующие за ним тесты покажут что подраздел не найден. Во втором случае все тесты покажут что вход не был выполнен. Красных тестов будет что так что эдак одинаково.
Вобщем, для каждой задачи свой подход. Нельзя сваливать всю автоматизацию в одну кучу. И это главная проблема среди проблем автоматизации.
Когда мы в позиции где наш день состоит из переговоров чуть больше чем полностью, то никакая электронная почта конечно не даст нужной скорости оборота информации. Хотя может из-за того что такие как мы звоним им без передыху, они и не успеввают ответить на емейл.
Если у нас распределенная команда в разных часовых поясах, то мы вовсе не можем в переговорах рассчитывать на режим реального времени.
Я замечал случаи когда согласования ведут в комментариях JIRA. Там можно зафиксировать позиции участников, критический анализ выдвинутых предложений и предпочтительное решение. Там же менеджер проекта может отписаться идет ли решение в работу. Все шаги задокументированы.
Если провести анализ заранее, и предоставить участникам про и контра — то согласование сведется к да или нет.
А совещания без предварительной подготовки участников на мой взгляд имеют существенный недостаток. Участники не пропитались задачей, а «на ходу» только единицы умеют блестать умом. Поэтому я предпочитаю два совещания, на первом ввести в курс дела и назначить второе совещание где участники могут выразить свое обдуманое(!) мнение по вопросу и будет принято решение. Мне думается, что качество принятых решений вещь все-таки немалозначимая.
По телефону удобно задавать вопросы типа: «Сергей Иванович, у нас на складе три тонны неучтенного железа, завтра ревизия, что делать?». Все остальное нужно пытаться интегрировать в процесс.
Это верно, однако работает и в обратную сторону. У нас на работе в основном дергают меня. А я, в силу характера, крайне редко отказываю в помощи. Звонить я тоже не люблю, но если иначе задачу не решить я буду звонить хоть в Белый Дом. Некоторые мои коллеги говорят, что не могли бы работать дома вообще — слишком много соблазнов. Зато на работе они каждые пять минут пялятся в телефон или смотрят какую-нибудь чушь на ютубе. Как ни пытался понять так и не понял как с таким подходом можно вообще преследовать какие-то цели. А они видимо и не преследуют.
Я наоборот предпочитаю обмениваться информацией через письмо. Это раз, дает возможность сформулировать мысль, и 10% сообщений становятся ненужными на стадии написания. И два, читающий может обратить внимание на это сообщение когда ему удобно. Т.е. я не буду вырывать его из потока.
В моей работе практически нет таких вопросов которые требовали бы безотлагательного, сиюминутного решения. Если такие возникнут мне придется серьёзно спросить себя: «А какого хрена ты тянул с этим, Алексей?»
лично у меня незаконченые задачи роятся в голове как, скажем, бабочки. Чем их больше тем больше мой мозг занят обновлением «ячеек памяти» по всем незавершенным задачам. Если их (задач) становится слишком много, мозгу нехватает пустого места чтобы свободно размышлять, не отвлекаясь на «прерывания». В этой ситуации я заметил, что элементарно делегировать задачу может оказаться полезным. Делегированная задача перестает занимать место в голове, и освобождается место для мыслительного «замаха». Было такое, тупил над простенькой задачкой. Передал ее коллеге, с дедлайном на 5 дней, решит — хорошо, пусть не идеально но оно будет работать (приносить пользу), и станет одной проблемой меньше. Не решит — вместе глянем что к чему. На следующий день ко мне пришло озарение и задача решилась за полчаса. Озарение пришло, потому что я освободил место в голове. Это не тоже самое что и вываливание задач в дневник или багтрекер «для себя». Разница в том, что передав задачу другому, над ней уже будет вестить какая-то полезная работа. А если записать задачу для себя, она будет лежать мертвым грузом, пока я не обращу на нее свое внимание. Значит мне придется об этой задаче помнить и вся польза от такого манёвра сойдет на ноль. Получается делегирование ценнее для личной продуктивности чем ведение журнала личных задач.
как-то смотрел документальный фильм про людей которые больны неспособностью к принятию решений (не вспомню сейчас ни названия фильма, ни болезни). Даже простой бытовой выбор превращается в пытку, например выбор продуктов в магазине. Так в этом фильме говорилось, что принятие решений для мозга — очень энергозатратный процесс и он пытается этого избегать. А приметы, правила, эвристики — упрощают оценку ситуации.
Я подумал, что и к таким сообщениям (емейлам) нужно относиться осторожно и сперва убедиться в достоверности информации. Ведь скомпрометированый сервер может только того и ждать, что ты придешь и начнешь менять пароль.
зацепился за слово «обгон». Мне кажется что обгон может присходить только в одном случае, если это экстренные службы. Все остальные робомобили двигаются со скоростью потока. Полоса для грузового транспорта и две полосы для легкового причем левая полоса не быстрее средней. Если водитель любой машины может «потребовать» от машины двигаться быстрее чем рассчитаное компьютером оптимальное значение, то человеческий фактор как всегда все испортит.
получается фронт между теорией разумного замысла и теорией эволюции просто плод «узкого» мышления и тех и других, никакого фронта нет, это все тот же самый «слон» которого одни трогают за хобот а другие за хвост. Есть над чем подумать. Спасибо.
<поток бессвязных мыслей>
Как мне думается человек синтезирует знание из существующих знаний, поэтому не может произойти такого, что человек придумает что-то абсолютно уникальное. Такое случается, но все тогда говорят что это чушь и ерунда.
Например, если бы ученым древности поставили задачу организовать одновременное очное обучение двадцати миллионов человек, то никакая видетрансляция им бы в голову просто не могла бы прийти. А если бы и пришла, пылилась бы такая мысль в черновиках.
Все что не вписывается в рамки нашей мировоззренческой базы мы склонны отметать.
Есть понятия точные названия которых есть только в каком-то одном языке мира. А что нужно чтобы научить машину оперировать явлениями не цепляясь за их названия?
Т.е машина не сможет свободно творить потому, что человек определяет критерии оценки того что она творит. Наш проф. по математике вообще говорил, что информация существует потому, что есть люди (т.е. те кто ее как таковую воспринимают)
</поток бессвязных мыслей>
Была у меня тоже когда-то мысль, что при посещении вебстраницы телефон может загружает что-то вроде апплета — т.е. практически нативное приложение которым можно пользоваться без установки. Вот бы было чудесное перерождение умершей технологии ява-апплетов, думал я.
Парадокс конечно нехилый: ст 138 УК РФ «Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений»
Получается на ФСБ можно будет подать за это в суд по части второй «То же деяние, совершенное лицом с использованием своего служебного положения.» А на провайдера по части первой.
А на писателей и утвердителей закона за склонение людей к массовым беспорядкам (по их собственному закону). Ведь граждане теперь просто обязаны выйти на улицы и устроить демонстрацию из-за такого антиконституционного закона.
Еще напомнило: шифрование против монтировки xkcd.com/538
Лучшие решения получаются когда пытаются устранить причину, а не следствие. Чтобы добраться до первопричины можно воспользоваться методом Тойоты — «пять почему».
Сразу оговорюсь, я не силён в физике, но прихожу к выводу: нужно сделать так, чтобы теплоотток у ручек был ниже чем теплоприток. Теплоотток происходит из-за теплопроводимости металла руля. Я бы рискнул теплоизолировать ручки от руля теплоизолирующим материалом. И/или теплоотражающим.
В DevOps входят к примеру, услуги по устройству процесса интеграции и автоматизированного тестирования, хостинга и техподдержки инфраструктуры и т.д и т.п Это все обеспечивается с помощью людей и программного обеспечения, которое, нужно настроить, написать, отладить, поддерживать, мигрировать и т.п. Вся эта инфраструктура имеет жизненный цикл и является такой же «dеliverable» — грубо говоря программной «плюшкой» которая каждый день выкатывается из «печи», но для разработчиков. Т.о. IT-инфраструктура для программного проекта имеет все те же свойства, которые имеет продуктивный код в продукте конечного потребителя. Это значит к ней применимы те же требования которые предьявляют к коду — качество, надежность, удобство использования и т.п… Поэтому k DevOps уместен тот же подход как к разработке программного продукта для клиента, несмотря на то, что конечный пользователь DevOps — это разработчик.
В школе почему-то решения, не противоречащие заданию, но не соответствующие типовому решению не принимают.
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ∈ Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.
Почитав про когнитивные искажения и антипаттерны вообще начинашь верить в то, что картофельный клубень куда рациональнее человека.
То что другая команда за 200 километров от нас после такого фейла чинит логин в срочном порядке не значит что все курят, все работают дальше, над своим функционалом. У нас такая система что для работы мы можем откатить сторонние артефакты назад, и проапдейтить свою ветку и работать с работающей версией логина.
У нас некоторые по три-четыре недели артефакты не обновляют.
И тесты у меня не совсем все друг за другом идут, а только шаги пользовательских сценариев, Один пользовательский сценарий у кого-то это один тест, а у меня test-suite (тестовый набор). Kаждый шаг в них это свой тест, чтобы в тест-репорте видно было с какого места последовательность запнулась. На каждый сценарий (тестовый набор) свой setup и teardown. T.e. их можно рапараллелить по тестовым наборам. Но не каждый тест в отдельности.
Чтобы вы представляли масштаб, то над чем мы работаем по обьему функционала схоже с ванильной Android OS. Наша работа только несколько компонент во всей системе.
Ну да, можно сказать, что заказчик не серьезно подходит к автоматизации.Ведь она даже в бюджет команд не заложена. Чистая прихоть заказчика.
Так что, как правильно все проходили а в жизни по разному бывает. И добрых книжных истин хватает везде, а информации как же люди справляются в жизни — об этом в основном никакой информации.
Меня просто не устраивает когда догму пытаются втюхать так как будто вот только так и правильно. Как правильно разрабатывать об этом десятилетиями спорят, наверное потому что серебрянной пули нет. Так и тут.
Но спасибо вам за ответ, здравая мысль она вдохновляет.
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши UI тесты описывают пользовательские сценарии, сам «предмет теста» как я его называю, практически всегда в порядке, в 85% случаев ломается что-то вокруг, и тесты перестают работать. И это хорошо. Т.е. тесты ненадежные. Мы обмотали наш продукт красной проволкой и смотрим где эта проволока порвется. Получается как в том анекдоте, что «по дырочкам никогда не рвется». И пусть. Главное чтобы тесты реагировали на изменения.
А вообще я не доверяю тестам ни своим ни чужим. Всегда есть что-то что я не учел, пусть это даже пробел в спецификации. Тесты всегда недостаточно хороши. Так что такая категория как доверие, она слишком человеческая, чтобы применять ее в техническом плане. Я доверяю автоматизации тогда когда она находит ошибки в ПО. Находит — хорошо, не находит — плохо. А полагаюсь я на автоматизацию каждый день иначе я бы просто был не в состоянии даже близко проверить столько конфигураций
Например: «Тесты должны быть независимы друг от друга. Их можно выполнять в любой последовательности».
Для юнит-тестов это высказывание может быть верным. Там подготовка теста (Setup) не сильно влияет на время прогона.
Но UI тесты, (приемочные тесты, где мы проверяем кусок фунционала в качестве пользователя) могут отклоняться от этого правила потому, что тесты должны быть быстрыми. Если я каждый раз буду заходить в свой раздел приложения перед началом проверки, то это будет занимать больше половины всего времени.
Я руководствуюсь принципом — тест должен делать только то что является предметом теста. Вход в раздел является тестом, и выполяется первым. После этого не нужно выполнять вход. Поэтому у меня тесты идут друг за другом. И это нормально. Упал вход, все тесты за ним посыпались — разрабы чинят вход. Потому что иначе пользователь до нижележащего фунцкионала просто не доберется. Все честно. Я мог бы исхитриться и обойти процедуру входа для последующих тестов, но это бы исказило пользовательский сценарий. Для сравнения: я мог бы выполнять вход перед каждым тестом, но если он сломан результат будет тем же. В первом случае первый тест покажет что вход не был выполнен, а последующие за ним тесты покажут что подраздел не найден. Во втором случае все тесты покажут что вход не был выполнен. Красных тестов будет что так что эдак одинаково.
Вобщем, для каждой задачи свой подход. Нельзя сваливать всю автоматизацию в одну кучу. И это главная проблема среди проблем автоматизации.
Если у нас распределенная команда в разных часовых поясах, то мы вовсе не можем в переговорах рассчитывать на режим реального времени.
Я замечал случаи когда согласования ведут в комментариях JIRA. Там можно зафиксировать позиции участников, критический анализ выдвинутых предложений и предпочтительное решение. Там же менеджер проекта может отписаться идет ли решение в работу. Все шаги задокументированы.
Если провести анализ заранее, и предоставить участникам про и контра — то согласование сведется к да или нет.
А совещания без предварительной подготовки участников на мой взгляд имеют существенный недостаток. Участники не пропитались задачей, а «на ходу» только единицы умеют блестать умом. Поэтому я предпочитаю два совещания, на первом ввести в курс дела и назначить второе совещание где участники могут выразить свое обдуманое(!) мнение по вопросу и будет принято решение. Мне думается, что качество принятых решений вещь все-таки немалозначимая.
По телефону удобно задавать вопросы типа: «Сергей Иванович, у нас на складе три тонны неучтенного железа, завтра ревизия, что делать?». Все остальное нужно пытаться интегрировать в процесс.
Я наоборот предпочитаю обмениваться информацией через письмо. Это раз, дает возможность сформулировать мысль, и 10% сообщений становятся ненужными на стадии написания. И два, читающий может обратить внимание на это сообщение когда ему удобно. Т.е. я не буду вырывать его из потока.
В моей работе практически нет таких вопросов которые требовали бы безотлагательного, сиюминутного решения. Если такие возникнут мне придется серьёзно спросить себя: «А какого хрена ты тянул с этим, Алексей?»
А котики — это «Пятый Элемент». :)
Как мне думается человек синтезирует знание из существующих знаний, поэтому не может произойти такого, что человек придумает что-то абсолютно уникальное. Такое случается, но все тогда говорят что это чушь и ерунда.
Например, если бы ученым древности поставили задачу организовать одновременное очное обучение двадцати миллионов человек, то никакая видетрансляция им бы в голову просто не могла бы прийти. А если бы и пришла, пылилась бы такая мысль в черновиках.
Все что не вписывается в рамки нашей мировоззренческой базы мы склонны отметать.
Есть понятия точные названия которых есть только в каком-то одном языке мира. А что нужно чтобы научить машину оперировать явлениями не цепляясь за их названия?
Т.е машина не сможет свободно творить потому, что человек определяет критерии оценки того что она творит. Наш проф. по математике вообще говорил, что информация существует потому, что есть люди (т.е. те кто ее как таковую воспринимают)
</поток бессвязных мыслей>
Парадокс конечно нехилый: ст 138 УК РФ «Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений»
Получается на ФСБ можно будет подать за это в суд по части второй «То же деяние, совершенное лицом с использованием своего служебного положения.» А на провайдера по части первой.
А на писателей и утвердителей закона за склонение людей к массовым беспорядкам (по их собственному закону). Ведь граждане теперь просто обязаны выйти на улицы и устроить демонстрацию из-за такого антиконституционного закона.
Еще напомнило: шифрование против монтировки xkcd.com/538
Сразу оговорюсь, я не силён в физике, но прихожу к выводу: нужно сделать так, чтобы теплоотток у ручек был ниже чем теплоприток. Теплоотток происходит из-за теплопроводимости металла руля. Я бы рискнул теплоизолировать ручки от руля теплоизолирующим материалом. И/или теплоотражающим.
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ∈ Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.