Я на него в году в 2017-м, кажется, буквально подписку оформил, как во время онное. 1993-й был годом, когда многие подписки отмерли, потому что инфляция, разруха etc. Мне казалось, что произошел ренессанс, что раз в месяц я буду с интересом читать сводки БИНТИ и, возможно, новые заметки "из календаря Ю.Б.", и вообще следить за наукой, мгм, попивая кофеëк.
Был дико (дичайше?) разочарован. Журнал уныл, много ниочëмных интервью с медленно дышащими старцами роснауки, ненужные, а потому и неинтересные очерки каких-то событий… Новости с полей науки были куцыми.
Начиная с 1971 года японское агентство по науке и технике каждые пять лет проводит опрос ведущих учёных о том, какие крупные открытия ожидают нас в будущем. В 1992-ом результаты очередного опроса среди 2385 респондентов уложились в книгу объемом 800 страниц.
Выдержки из нее:
1998 год: будет найдена замена фторированным углеводородам в холодильниках и аэрозольных баллончиках. Эти вещества разрушают озоновый слой атмосферы.
1999 год: будут созданы крупномасштабные системы оптической связи.
2000 год: будет создана полупроводниковая система памяти для ЭВМ со скоростью поиска нужной информации в одну наносекунду (миллиардная доля секунды).
2001 год: появится экономичный способ переработки городских отходов в полезные материалы.
2002 год: появятся микросхемы, каждая с памятью объемом один гигабит (4000 книг).
2003 год: будет найден способ очистки дымов и выхлопных газов от окислов азота. Появятся упаковочные материалы, быстро разлагаемые без остатка на свалке микробами. Будет получена вакцина от СПИДа.
2006 год: будет найден способ лечения СПИДа. Станет возможным предсказание вулканических извержений за 2-3 дня.
2007 год: будет найден метод предотвращения метастазов рака.
2008 год: метод ограничения выбросов двуокиси углерода, вызывающий парниковый эффект.
2009 год: обнаружение генов, вызывающих рак и расшифровка механизма образования опухолей.
2010 год: способ предсказания землетрясений как минимум за неделю. Роботы-сиделки в больницах.
2013 год: лекарство, предотвращающее рак.
2015 год: лекарство от болезни Альцгеймера.
После 2020 года: управляемая термоядерная реакция.
RTM — это не бюрократия, а навигатор тестировщика.
Это очередной аналитический инструмент аналитиков, которые требования пишут. Тестировщикам эти матрицы можно не показывать, лучше тестировать с RTM не будут. Им лучше про импакт анализ рассказать и смотреть, как все начинают с энтузиазмом, а затем бросают, потому что очень сложно такие матрицы соответствия поддерживать. Да и заблуждений они генерируют много.
Я провожу обучение по автоматизации тестирования, и 80% студентов приходят из ручного тестирования. … Этот тренд говорит о простом факте…
…что вы чаще видите людей, которые хотят шагнуть в автоматизацию.
Если бы вы преподавали английский, то вы чаще всего видели бы людей, которые хотят шпрехен ин енглезнэ, а не автоматизаторов. И это было бы трендом, который говорил бы о простом факте…
Помню, как первые тесты на Selenium, которые я видел, падали чаще, чем запускались.
А я помню, как в 2011-м (15 лет назад) мы сутками писали автотесты на Selenium RC, и они падали так же рэндомно, как и современные на плэйрайте. У нас сейчас автоматоры напряглись запускать тесты в параллель в несколько потоков, им даже дали на это отдельный сервер… и всё равно они все больше занимаются расследованием причин падений тестов. Они решают абсолютно те же задачи, которые мы решали в 2011-м, просто инструменты другие.
Что-то не так в самой природе автотестов, их нельзя жестко выносить в отдельный поток разработки…
Если ты написал код, ты понимаешь, как он должен работать, можешь быстро проверить базовые сценарии и выявить очевидные ошибки.
Нет.
Ну, не совсем.
Тестировать код и тестировать приложение — это разное тестирование, их природно невозможно смешивать. В одном человеке преобладает или одно умение, или второе, поэтому у нас есть в принципе разные професии.
Хорошо протестированный программистом код вообще не означает, что приложение будет работать как надо. Это природное ограничение, оно связано с тем, что программист решает отдельные задачи, а не весь проект — условно делает отдельные колёса, а не весь транспорт. Можно исключительно хорошо протестировать отдельное колесо, можно протестировать его базово, но много ли в этом смысла, если нам надо, чтобы вся машина ехала и выполняла общие задачи этого еханья?
Вы правильно подразумеваете, что сделанное надо протестировать хотя бы в общем, но для этого у программиста заранее должно быть установлено более общее, широкое видение проекта и ответственность «за проект», а не за «отдельное колесо». Обычно такое видение есть у менеджеров (СТО по-вашему) и не всегда, но бывает у тестировщиков, которые воспринимают проект более общее, потому что обобщающе воспринимают требования, тогда как простой «установщик колёс» от такой ответственности прячется. Логично же.
Многие люди, кто даже давно работают в ИТ, действительно иногда считают, что тестировщики — это такие странные программисты, которые не пишут код сами, а только тестируют чужой.
Средний программист а) живет в мифологии того, что всё то, что шаблонизировано — управляемо, и б) слабо понимает, что значит «тестировать приложение» и чем/как занимаются тестировщики. Он видит только репорты о дефектах и логично подразумевает, что это смысл их работы (простая логика же, уровня «пчела → мёд»), а могли бы заниматься тем, что интересно самим программистам — тестировать их интересный код…
Если сильно обобщать, то упомянутые тестировщики тестируют приложение, а не чужой код. Уразуметь эту разницу большинство программистов начального или среднего уровня неспособны и (усредненно) обстоятельства их к этому не принуждают. Большинство тестировщиков действуют так же тупо, но это эффективное поведение, поэтому таким оно будет всегда.
Да, действительно.
Конкатенированием отдельных операций объявления переменных и присваивания им значений в одну строку. На большее понимание не претендую.
Обнять
Приподнять
Насадить на кол (или на черенок лопаты)
Вы про дацзыбао не знаете, что ли?
Прям просится:
INTEGER :: user_age = 30REAL :: pi_approx = 3.14159CHARACTER(LEN=20) :: user_name = "John Doe"Ты не модный ©
Я на него в году в 2017-м, кажется, буквально подписку оформил, как во время онное. 1993-й был годом, когда многие подписки отмерли, потому что инфляция, разруха etc. Мне казалось, что произошел ренессанс, что раз в месяц я буду с интересом читать сводки БИНТИ и, возможно, новые заметки "из календаря Ю.Б.", и вообще следить за наукой, мгм, попивая кофеëк.
Был дико (дичайше?) разочарован. Журнал уныл, много ниочëмных интервью с медленно дышащими старцами роснауки, ненужные, а потому и неинтересные очерки каких-то событий… Новости с полей науки были куцыми.
Журнал работает и сегодня, но непонятно зачем.
Журнал «Наука и жизнь» #5 1993
Начиная с 1971 года японское агентство по науке и технике каждые пять лет проводит опрос ведущих учёных о том, какие крупные открытия ожидают нас в будущем. В 1992-ом результаты очередного опроса среди 2385 респондентов уложились в книгу объемом 800 страниц.
Выдержки из нее:
1998 год: будет найдена замена фторированным углеводородам в холодильниках и аэрозольных баллончиках. Эти вещества разрушают озоновый слой атмосферы.
1999 год: будут созданы крупномасштабные системы оптической связи.
2000 год: будет создана полупроводниковая система памяти для ЭВМ со скоростью поиска нужной информации в одну наносекунду (миллиардная доля секунды).
2001 год: появится экономичный способ переработки городских отходов в полезные материалы.
2002 год: появятся микросхемы, каждая с памятью объемом один гигабит (4000 книг).
2003 год: будет найден способ очистки дымов и выхлопных газов от окислов азота. Появятся упаковочные материалы, быстро разлагаемые без остатка на свалке микробами. Будет получена вакцина от СПИДа.
2006 год: будет найден способ лечения СПИДа. Станет возможным предсказание вулканических извержений за 2-3 дня.
2007 год: будет найден метод предотвращения метастазов рака.
2008 год: метод ограничения выбросов двуокиси углерода, вызывающий парниковый эффект.
2009 год: обнаружение генов, вызывающих рак и расшифровка механизма образования опухолей.
2010 год: способ предсказания землетрясений как минимум за неделю. Роботы-сиделки в больницах.
2013 год: лекарство, предотвращающее рак.
2015 год: лекарство от болезни Альцгеймера.
После 2020 года: управляемая термоядерная реакция.
Это очередной аналитический инструмент аналитиков, которые требования пишут. Тестировщикам эти матрицы можно не показывать, лучше тестировать с RTM не будут. Им лучше про импакт анализ рассказать и смотреть, как все начинают с энтузиазмом, а затем бросают, потому что очень сложно такие матрицы соответствия поддерживать. Да и заблуждений они генерируют много.
Это не называется «матрица трассируемости» само по себе, надо указывать, что на что трассируется.
У автора есть план статей и он обязан следовать своему плану.
А вдруг будет удачная война, которая покроет все эти расходы?!
Кажется, Сэм Альтман не очень любит Дарио Амодеи, но хотя бы дальновидно не забыл перелогинится перед тем, как накатать раздраженный текст.
ИТ-директор не поднял себе Snipe-IT для учета всех железяк?!
Гуд.
Прям зер гуд.
ОСТАНОВИСЬ! Эксперты бросают habr из-за ЭТОГО! Просто перестань! Хватит! Ферботен!
…что вы чаще видите людей, которые хотят шагнуть в автоматизацию.
Если бы вы преподавали английский, то вы чаще всего видели бы людей, которые хотят шпрехен ин енглезнэ, а не автоматизаторов. И это было бы трендом, который говорил бы о простом факте…
А я помню, как в 2011-м (15 лет назад) мы сутками писали автотесты на Selenium RC, и они падали так же рэндомно, как и современные на плэйрайте. У нас сейчас автоматоры напряглись запускать тесты в параллель в несколько потоков, им даже дали на это отдельный сервер… и всё равно они все больше занимаются расследованием причин падений тестов. Они решают абсолютно те же задачи, которые мы решали в 2011-м, просто инструменты другие.
Что-то не так в самой природе автотестов, их нельзя жестко выносить в отдельный поток разработки…
Сорян, но быгыгы. Ровно то же самое говорили в 2012-ом.
И в 2017-м.
И в 2020-м.
Нет.Ну, не совсем.
Тестировать код и тестировать приложение — это разное тестирование, их природно невозможно смешивать. В одном человеке преобладает или одно умение, или второе, поэтому у нас есть в принципе разные професии.
Хорошо протестированный программистом код вообще не означает, что приложение будет работать как надо. Это природное ограничение, оно связано с тем, что программист решает отдельные задачи, а не весь проект — условно делает отдельные колёса, а не весь транспорт. Можно исключительно хорошо протестировать отдельное колесо, можно протестировать его базово, но много ли в этом смысла, если нам надо, чтобы вся машина ехала и выполняла общие задачи этого еханья?
Вы правильно подразумеваете, что сделанное надо протестировать хотя бы в общем, но для этого у программиста заранее должно быть установлено более общее, широкое видение проекта и ответственность «за проект», а не за «отдельное колесо». Обычно такое видение есть у менеджеров (СТО по-вашему) и не всегда, но бывает у тестировщиков, которые воспринимают проект более общее, потому что обобщающе воспринимают требования, тогда как простой «установщик колёс» от такой ответственности прячется. Логично же.
Средний программист а) живет в мифологии того, что всё то, что шаблонизировано — управляемо, и б) слабо понимает, что значит «тестировать приложение» и чем/как занимаются тестировщики. Он видит только репорты о дефектах и логично подразумевает, что это смысл их работы (простая логика же, уровня «пчела → мёд»), а могли бы заниматься тем, что интересно самим программистам — тестировать их интересный код…
Если сильно обобщать, то упомянутые тестировщики тестируют приложение, а не
чужойкод. Уразуметь эту разницу большинство программистов начального или среднего уровня неспособны и (усредненно) обстоятельства их к этому не принуждают. Большинство тестировщиков действуют так же тупо, но это эффективное поведение, поэтому таким оно будет всегда.