Стабильность тестов в моем понимании это когда тесты на одной и той же версии продукта выдают при повторном выполнении один и тот же результат. Результат может быть и красным, но он не должен изменяться при повторении. Если тесты всегда выдают стабильный красно-зеленый результат — на доверии это скажется негативно. Значит обеспечив стабильность мы еще не обеспечили доверие. Так же если все тесты всегда зеленые это тоже скажется на доверии негативно. Может они и не тестируют ничего.
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши 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
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.
По тому какие человек делает запросы и сколько запросов ему понадобится для ответа, видно, насколько он владеет предметной областью.
Владение профессиональными терминами и правильное их употребление в контексте, с моей т.з. достаточный тест на профпригодность. Человек не знакомый с типографией будет говорить «расстояние между строк» а знакомый — «интерлиньяж», и найдет более качественную информацию. Кроме того сразу видно как человек владеет языком. Сравните: «как сделать интервал между строк другим» и «как изменить межстрочный пробел».
Гуглить почему-то считается моветоном, хотя он экономит время а значит и деньги. Думаю Гуглу надо просто открыть новый сервис: Google Pro — все то же самое, но с обязательной регистрацией, за деньги, и без рекламы. (Для тех кому для имиджа нужно пользоваться только самыми профессиональными инструментами :)
я бы попросил такого уточняльщика повторить все вводные. И если он бы хоть что-то упустил…
У меня был коллега, который писал для проекта полезную тулзу. Там было дерево файлов и нам нужно было видеть дупликаты, я попросил его выделять дупликаты цветом, и возможность удалить выбраный файл. И тут посыпались неожиданные вопросы:
— цвет фона и текста для дупликата
— для нормального файла
— цвет фона и текста при выделении мышкой дупликата
— цвет фона и текста при выделении нормального файла
так хотелось спросить «ты что издеваешься?». Но я знал что он на полном серьезе, и я его очень уважал (и уважаю до сих пор).
Пришлось принять правила игры и… послать табличку эксель с кейсами и цветовыми комбинациями :)
я так понял что смысл задачи в использовании ява функции, вот и подумал что луаджей, она же рефлексией все как бы может достать.
Может задачу не доконца понял. Я смотрю с прагматичной стороны. У нас вот на embedded системе для тестирования самописный интерпретатор синтаксиса питона используют (а приложение на яве) так я тоже сперва спросил, а что не jython. Сказали что много памяти жрет. Ну мне все сразу и ясно стало. Я же никого задеть не хочу, просто пытаюсь усвоить чужой опыт.
А стабильность сама по себе действительно очень важна. У нас были фазы где мы красно-зеленые тесты гоняли чтобы проверить обновления в инструменте. Если все как и раньше — едем дальше.
Другое дело надежность, она определяет вероятность ложного срабатывания (срабатывание это красный результат) Вот надежность она влияет на «доверие». Еще раз, стабильность — одинаковый результат при повторном исполнении в одинаковых условиях, надежность — обратная величина количеству ложных срабатываний. Если стабильность можно проверить повторным прогоном, надежность проверить можно только заглянув в код.
Автоматизация помогает выявить неявные изменения. Это может кому-то показаться странным но несмотря на то что наши UI тесты описывают пользовательские сценарии, сам «предмет теста» как я его называю, практически всегда в порядке, в 85% случаев ломается что-то вокруг, и тесты перестают работать. И это хорошо. Т.е. тесты ненадежные. Мы обмотали наш продукт красной проволкой и смотрим где эта проволока порвется. Получается как в том анекдоте, что «по дырочкам никогда не рвется». И пусть. Главное чтобы тесты реагировали на изменения.
А вообще я не доверяю тестам ни своим ни чужим. Всегда есть что-то что я не учел, пусть это даже пробел в спецификации. Тесты всегда недостаточно хороши. Так что такая категория как доверие, она слишком человеческая, чтобы применять ее в техническом плане. Я доверяю автоматизации тогда когда она находит ошибки в ПО. Находит — хорошо, не находит — плохо. А полагаюсь я на автоматизацию каждый день иначе я бы просто был не в состоянии даже близко проверить столько конфигураций
Например: «Тесты должны быть независимы друг от друга. Их можно выполнять в любой последовательности».
Для юнит-тестов это высказывание может быть верным. Там подготовка теста (Setup) не сильно влияет на время прогона.
Но UI тесты, (приемочные тесты, где мы проверяем кусок фунционала в качестве пользователя) могут отклоняться от этого правила потому, что тесты должны быть быстрыми. Если я каждый раз буду заходить в свой раздел приложения перед началом проверки, то это будет занимать больше половины всего времени.
Я руководствуюсь принципом — тест должен делать только то что является предметом теста. Вход в раздел является тестом, и выполяется первым. После этого не нужно выполнять вход. Поэтому у меня тесты идут друг за другом. И это нормально. Упал вход, все тесты за ним посыпались — разрабы чинят вход. Потому что иначе пользователь до нижележащего фунцкионала просто не доберется. Все честно. Я мог бы исхитриться и обойти процедуру входа для последующих тестов, но это бы исказило пользовательский сценарий. Для сравнения: я мог бы выполнять вход перед каждым тестом, но если он сломан результат будет тем же. В первом случае первый тест покажет что вход не был выполнен, а последующие за ним тесты покажут что подраздел не найден. Во втором случае все тесты покажут что вход не был выполнен. Красных тестов будет что так что эдак одинаково.
Вобщем, для каждой задачи свой подход. Нельзя сваливать всю автоматизацию в одну кучу. И это главная проблема среди проблем автоматизации.
Если у нас распределенная команда в разных часовых поясах, то мы вовсе не можем в переговорах рассчитывать на режим реального времени.
Я замечал случаи когда согласования ведут в комментариях JIRA. Там можно зафиксировать позиции участников, критический анализ выдвинутых предложений и предпочтительное решение. Там же менеджер проекта может отписаться идет ли решение в работу. Все шаги задокументированы.
Если провести анализ заранее, и предоставить участникам про и контра — то согласование сведется к да или нет.
А совещания без предварительной подготовки участников на мой взгляд имеют существенный недостаток. Участники не пропитались задачей, а «на ходу» только единицы умеют блестать умом. Поэтому я предпочитаю два совещания, на первом ввести в курс дела и назначить второе совещание где участники могут выразить свое обдуманое(!) мнение по вопросу и будет принято решение. Мне думается, что качество принятых решений вещь все-таки немалозначимая.
По телефону удобно задавать вопросы типа: «Сергей Иванович, у нас на складе три тонны неучтенного железа, завтра ревизия, что делать?». Все остальное нужно пытаться интегрировать в процесс.
Я наоборот предпочитаю обмениваться информацией через письмо. Это раз, дает возможность сформулировать мысль, и 10% сообщений становятся ненужными на стадии написания. И два, читающий может обратить внимание на это сообщение когда ему удобно. Т.е. я не буду вырывать его из потока.
В моей работе практически нет таких вопросов которые требовали бы безотлагательного, сиюминутного решения. Если такие возникнут мне придется серьёзно спросить себя: «А какого хрена ты тянул с этим, Алексей?»
А котики — это «Пятый Элемент». :)
Как мне думается человек синтезирует знание из существующих знаний, поэтому не может произойти такого, что человек придумает что-то абсолютно уникальное. Такое случается, но все тогда говорят что это чушь и ерунда.
Например, если бы ученым древности поставили задачу организовать одновременное очное обучение двадцати миллионов человек, то никакая видетрансляция им бы в голову просто не могла бы прийти. А если бы и пришла, пылилась бы такая мысль в черновиках.
Все что не вписывается в рамки нашей мировоззренческой базы мы склонны отметать.
Есть понятия точные названия которых есть только в каком-то одном языке мира. А что нужно чтобы научить машину оперировать явлениями не цепляясь за их названия?
Т.е машина не сможет свободно творить потому, что человек определяет критерии оценки того что она творит. Наш проф. по математике вообще говорил, что информация существует потому, что есть люди (т.е. те кто ее как таковую воспринимают)
</поток бессвязных мыслей>
Парадокс конечно нехилый: ст 138 УК РФ «Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений»
Получается на ФСБ можно будет подать за это в суд по части второй «То же деяние, совершенное лицом с использованием своего служебного положения.» А на провайдера по части первой.
А на писателей и утвердителей закона за склонение людей к массовым беспорядкам (по их собственному закону). Ведь граждане теперь просто обязаны выйти на улицы и устроить демонстрацию из-за такого антиконституционного закона.
Еще напомнило: шифрование против монтировки xkcd.com/538
Сразу оговорюсь, я не силён в физике, но прихожу к выводу: нужно сделать так, чтобы теплоотток у ручек был ниже чем теплоприток. Теплоотток происходит из-за теплопроводимости металла руля. Я бы рискнул теплоизолировать ручки от руля теплоизолирующим материалом. И/или теплоотражающим.
Ну грубо говоря на задачу 2+2= _ в школе нельзя ответить 2+2 = x, x< 5, x > 3, x ∈ Z
Во всяком случае в Германии я с этим лично столкнулся. За любой «выпендреж» не соответствующий смыслу задания снижают оценку. А на работе такое поведение в характеристику войдет как, что-то вроде «очень точно понимает поставленную задачу и креативно подходит к ее решению», что будет значит, не в состоянии просто взять и выполнить задачу, а начинает «выдумавать».
Поэтому я в формально согласен с таким утверждением. Но жизненные реалии утверждают обратное.
Владение профессиональными терминами и правильное их употребление в контексте, с моей т.з. достаточный тест на профпригодность. Человек не знакомый с типографией будет говорить «расстояние между строк» а знакомый — «интерлиньяж», и найдет более качественную информацию. Кроме того сразу видно как человек владеет языком. Сравните: «как сделать интервал между строк другим» и «как изменить межстрочный пробел».
Гуглить почему-то считается моветоном, хотя он экономит время а значит и деньги. Думаю Гуглу надо просто открыть новый сервис: Google Pro — все то же самое, но с обязательной регистрацией, за деньги, и без рекламы. (Для тех кому для имиджа нужно пользоваться только самыми профессиональными инструментами :)
У меня был коллега, который писал для проекта полезную тулзу. Там было дерево файлов и нам нужно было видеть дупликаты, я попросил его выделять дупликаты цветом, и возможность удалить выбраный файл. И тут посыпались неожиданные вопросы:
— цвет фона и текста для дупликата
— для нормального файла
— цвет фона и текста при выделении мышкой дупликата
— цвет фона и текста при выделении нормального файла
так хотелось спросить «ты что издеваешься?». Но я знал что он на полном серьезе, и я его очень уважал (и уважаю до сих пор).
Пришлось принять правила игры и… послать табличку эксель с кейсами и цветовыми комбинациями :)
Может задачу не доконца понял. Я смотрю с прагматичной стороны. У нас вот на embedded системе для тестирования самописный интерпретатор синтаксиса питона используют (а приложение на яве) так я тоже сперва спросил, а что не jython. Сказали что много памяти жрет. Ну мне все сразу и ясно стало. Я же никого задеть не хочу, просто пытаюсь усвоить чужой опыт.