В дебрях водопада
Aug. 29th, 2018 09:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЖутко мучаются проповедники agile, пытаясь изобретать то прототипы, то спиральную модель...
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
Это я сходил на очередную тусовку. DevOps Guru Switzerland: Open Source Performance Test Automation mit JMeter, Selenium und Taurus
Сразу ссылки:
Abstraction level above testing tools: Taurus (http://gettaurus.org/)
Run massively scalable, open source-based tests: BlazeMeter (https://www.blazemeter.com/)
Дальше немного заметок на полях. Частично на английском, потому что так записано в блокноте, а переводить влом.
Пропорция на этот раз была полтора к одному. В смысле, на трёх пришедших извне два организатора. Впрочем, всего народу было меньше двадцати человек.
Очень неудобно в этот Клотен ехать. Особенно отсюда, точнее обратно. Ветки электричек сюда и туда расходятся как раз перед аэропортом. Обратно ехал, вообще, на автобусах.
Заодно в аэропорту набрал туристических брошюр. Первого сентября в Цюрихе ночь музеев. И на этих выходных аэропорт празднует семидесятилетие.
Первый раз вижу, чтобы доклад начинался со шпионажа.
По идее должно было выглядеть по типу:
- Как вы это делате?
- Вот так.
- А надо вот этак.
Но было так:
- Как вы это делаете?
- Вот так.
- Спасибо.
Короче, диалога не получилось.
Увидел интересное добавление к agile версии модели водопада. Development и Test связаны циклом коррекции-изменения.
То есть, все прямоугольнички по новой религией стрелочками в одну сторону, а между тестом и разработкой есть обратная связь.
Ещё десять лет - и додумаются до того, что разработка даёт сообщения об ошибках в дизайн. Дизайн - в сбор требований. А requirements engineering не только получает приказ начинать, но и что-то отправляет обратно прямоугольничку инициации. Например, сообщение "Нафиг-нафиг. Мы с такими пожеланиями только денег сожжём немеряно, но ничего путного в результате не выдадем."
Узнал новое волшебное слово: "Shift Left Model".
Если раньше в начале проекта работали аналитики, потом подключались дизайнеры, потом медленно набирали силу разработка и тестирование, то сейчас предлагается это всё загнать влево. Чтоб не только аналитики радовались, но и тестировщики с разработчиками резвились на сырых требованиях.
Если кто-то скажет, что отсутствие мозгов решили компенсировать грубой силой, тот будет абсолютно прав.
Но, увы, это реалии современной индустрии. Фиг сейчас найдёшь requirements engineer, который скажет "Вы на самом деле хотите раскрасить интерфейс в эти цвета?" или "Вы уверены, что не стоит рассматривать случаи, когда пользователь вводит данные с ошибкой?"
Помнится, двадцать лет назад специалист по IT-договорам, услышав ранних предвестников agile, с удивлением замечал, что для этого клиент должен платить не за сделаннную работу, а за то, что работа делается. Точнее, что-то делается, а что - не понятно.
Время показало, что заказчики под такое найдутся. Толпами. И большими деньгами.
Если им такое нравится, пусть платят.
Несколько интересных фактов:
- Тестирование бывает разрушающее, которое ищет ошибки, и верифицирующее, которое говорит, что ошибок нет. В фармафирмах любят второе. По этой причине практически всё делается вручную и производит гору бумаги.
- Licenses create queues and bottlenecks.
С одной стороны, хорошо, когда все-все-все могут тестировать всё что угодно. С другой - дешевле, если разработчики будут не гонять массивные тесты после каждого маленького изменения, а думать перед тем, как что-то в коде менять.
Мечты... Мечты...
- Чтобы изменить набор тестовых данных в банке надо обратиться к ответственным. И они поменяют. Время это займёт от двух недель до двух лет. (Может человек и преукрасил немного, но цифра правдоподобная.)
- Performance tools report mean values but the interesting part is the distribution of test results.
- Manual test scripts trap: It is simple to create a script that records user's actions but this script is costly to change.
Естественно, в этих замечательных тулах нельзя добавить параметры и случайные отклонения. А, когда один и тот же тест размножается под много клиентов, мы меряем не поведение системы под реальной нагрузкой, а совершенно искусственный случай.
Тысяча клиентов, одновременно выбравших один и тот же пункт в меню, - это не наплыв посетителей, а DOS атака.
- Интересно, что второй докладчик пропагандировал диаметрально противоположный подход: Generate test automation scripts from requirements.
What is wrong with this approach? The word "generate". Miracle is moved to the responsibilities of a business analyst.
Ещё я попытался объяснить людям, что тесты не могут быть слишком хорошими.
Development creates value. Testing eats resources. If tests produce too many errors this errors will be ignored. If this is impossible, developers will blame test scenarios as wrong or irrelevant and as result such "productive" tests will be switched off.
If developers try to be honest with tests that stop them, managers will change this unproductive attitude.
И в заключение лучшее за вчера.
Each advocate of each popular belief in IT is excellent in one aspect: the critique of problems of other beliefs.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(frozen) Re: Я кажется понял... почему вам двоим так не по нутру Ле
Date: 2018-08-31 04:56 pm (UTC)Ваши эти слова, явно свидетельствуют о том,
что сами вы не занимаетесь исследовательской деятельностью.
Иначе знали бы, что при самостоятельных исследованиях чего либо, это "не очень получается отделять полезную информацию от чуши и гениальные озарения от бреда" -- неизбежное зло.
Спросите хоть у того астрофизика.
Мне-то на слово вы не поверите, да мне это и ни к чем, и вас об этом не прошу... хотя это в общем-то "общее место", общеизвестная информация, в сфере мало-мальски связаной с исследованиями.
\\И нельзя сказать, что его деятельность вредна. Надо учитывать базу. Во многих случаях он вносит какой-никакой порядок в полный бардак.
Вот-вот.
(frozen) Re: Я кажется понял... почему вам двоим так не по нутру Ле
Date: 2018-08-31 05:07 pm (UTC)К чему эти реверансы? Я пообщался с проповедником, с учениками и жертвами учения и сделал выводы.
(frozen) Ясно. Панятно.
Date: 2018-08-31 05:45 pm (UTC)Это "при самостоятельных исследованиях чего либо, это "не очень получается отделять полезную информацию от чуши и гениальные озарения от бреда" -- неизбежное зло." -- было у меня общее утверждение.
О котором я и сказал -- что это не мое личное мнение, а тривия исследовательской дейтельности вообще.
И сослался на астрофизика упоминаемого недавно у вас в журнале.
Что он ближе всего, и вроде составляет для вас авторитет, и может подтвердить мои сло... вот это вот утверждение.
Еще раз, я не из своей головы его взял, а из литературы, чтения блогов тех же ученых-исследователей и т.п.
ЭТО не лично мое мнение.
А вы опять про каких-то жрецов и их жертв.
(frozen) Re: Ясно. Панятно.
Date: 2018-08-31 06:00 pm (UTC)Нет, конечно. Я пытаюсь направить мысль в нужное русло.
А вы опять про каких-то жрецов и их жертв.
Да. И надо понять, что я имею ввиду. Это не сложно.
(frozen) Re: Ясно. Панятно.
Date: 2018-08-31 06:14 pm (UTC)Попытка найти комплементарного собеседника -- вэлиант эффорт -- сам таким озадачен.
Но покамест, не смог даже сформулировать необходимых для этого,
ни формализма,
ни граничных условий.
У вас же вижу... все гораздо проще. "если кукла вышла плохо -- назову её дурехой" %)
\\А вы опять про каких-то жрецов и их жертв.
\\Да. И надо понять, что я имею ввиду. Это не сложно.
Это -- Не Сложно. НеРелевантно. (да, с моей наглой личной т.з. %))