Если честно, расширять платформу языком программирования это действительно сложно и не всегда практично.
У нас есть публичный API, что решает часть потребностей в кастомизации.
Распространение кроликов (в австралии) стало самым быстрым распространением млекопитающего вида в известной истории.
Остров нужен чтобы «кролики» появились и окрепли, а когда они окажутся в «австралии» их уже будет не остановить.
Но подходящей изоляции, кажется, нет.
Однако большинство новых видов появилось в обычных условиях
Да, и сейчас мы наблюдаем расцвет языков программирования. Их много, много новых, и многие из новых хороши.
С разнообразием, как раз, все в порядке.
Просто никто из новичков не станет лидером.
Даже если квантовые вычисления случатся — они будут крайне ограниченными.
Для них будут использовать специальные микропрограммы, как для шейдеров в графике,
которые будут встраивать в программы на обычных языках программирования.
В действительности инновации не происходят внезапно, они тщательно готовятся.
На 1995 пришелся «массовый старт» интернета, при том Dial Up соединения были доступны и ранее.
Возможно я что то упускаю, но в списке «Острова не только для языков программирования»
нет чего то столь же масштабного, по крайней мере такого что еще не «выстрелило».
Возможно я скептик, но сомневаюсь что за углом нас ждет новый, не открытый, континент.
Хорошим примером массового вымирания является LISP.
В 1980-х были очень популярна концепция экспертных систем построенных на LISP,
дело дошло до того что выпускали компьютеры исполняющие его непосредственно (lisp machines).
Но в какой то момент стало понятно что идея тупиковая, и и все довольно быстро прекратилось.
Судя по статье — у вас есть успешный опыт атоматического тестирования.
Неудачный опыт тоже есть :)
Если серьезно, легко дать совет вида «пишите Unit-тесты!». К сожалению вам это вряд ли поможет если не навредит.
Говорить о каком то решении со стороны, не понимая специфики вашей работы, ваших ограничений, в ваших трудностей было бы неосмотрительно.
Вы говорите о ряде проблем:
1. Разработка тестов отнимает время — можете ли вы сократить накладные расходы при этом сохранив пользу от тестов?
2. Нужны разработчики со спец навыками — зачем они нужны? можете ли вы обучить имеющихся разработчиков? можете ли вы нанять необходимых разработчиков?
3. Тесты покрывают не все задачи — какие покрывают а какие нет? есть ли смысл связываться с тестированием ради проверки тех задач которые можно ими проверить? можно ли расширить область действия тестов?
Попробуйте задать себе вопросы в этом роде и подумайте как можно на них ответить.
Лучшее решение ваших проблем можете найти только вы сами.
Вы зря делите полезность тестов для QA по технологическому признаку.
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
билд просто не должнен доходить до QA при красных юнит/интеграционных тестах.
Как такое возможно? QA написавший тест всегда знает о чем он, если он уже покинул команду — есть description
Вы подразумеваете что тесты достаточно хорошо документированы и структурированы — в реальности это не всегда так.
Если у вас тестировщик без комментариев реджектит тикет потому что «упал какой-то тест
По хорошему, задача не должна доходить до ручного тестирования если есть упавшие тесты.
Это элемент культуры разработки, проявление разработчиком уважения к труду ручного тестировщка.
Зачем было создавать 20 тысяч?
Хороший вопрос! Но, мне кажется, не все задают его себе прежде чем написать 20 тысяч тестов :)
Нет, автоматические тесты проверят то что заранее было запланировано проверить.
При ручном тестировании можно сообразить проверить то что никогда раньше не проверялось потому что никто об этом не думал раньше.
Если честно, расширять платформу языком программирования это действительно сложно и не всегда практично.
У нас есть публичный API, что решает часть потребностей в кастомизации.
Остров нужен чтобы «кролики» появились и окрепли, а когда они окажутся в «австралии» их уже будет не остановить.
Но подходящей изоляции, кажется, нет.
Да, и сейчас мы наблюдаем расцвет языков программирования. Их много, много новых, и многие из новых хороши.
С разнообразием, как раз, все в порядке.
Просто никто из новичков не станет лидером.
Даже если квантовые вычисления случатся — они будут крайне ограниченными.
Для них будут использовать специальные микропрограммы, как для шейдеров в графике,
которые будут встраивать в программы на обычных языках программирования.
На 1995 пришелся «массовый старт» интернета, при том Dial Up соединения были доступны и ранее.
Возможно я что то упускаю, но в списке «Острова не только для языков программирования»
нет чего то столь же масштабного, по крайней мере такого что еще не «выстрелило».
Возможно я скептик, но сомневаюсь что за углом нас ждет новый, не открытый, континент.
Я игнорируют только доказательство утверждения непосредственно, но не необходимость доказательства.
Есть тонкая разница.
Было бы куда правильнее привести существенную аргументационную базу в подтверждение базового предположения,
но и безумно занудно, при том.
В 1980-х были очень популярна концепция экспертных систем построенных на LISP,
дело дошло до того что выпускали компьютеры исполняющие его непосредственно (lisp machines).
Но в какой то момент стало понятно что идея тупиковая, и и все довольно быстро прекратилось.
а значит и доверие к ним. Это важно если это достижимо.
Если независимость стоит слишком дорого, можно искать другие технические решения.
То что вы говорите вполне оправдано.
3. Не думаю что это принципиальный вопрос. Могут быть за и против в зависимости от ситуации.
На остальные пункты ответы есть в предыдущей статье.
Неудачный опыт тоже есть :)
Если серьезно, легко дать совет вида «пишите Unit-тесты!». К сожалению вам это вряд ли поможет если не навредит.
Говорить о каком то решении со стороны, не понимая специфики вашей работы, ваших ограничений, в ваших трудностей было бы неосмотрительно.
Вы говорите о ряде проблем:
1. Разработка тестов отнимает время — можете ли вы сократить накладные расходы при этом сохранив пользу от тестов?
2. Нужны разработчики со спец навыками — зачем они нужны? можете ли вы обучить имеющихся разработчиков? можете ли вы нанять необходимых разработчиков?
3. Тесты покрывают не все задачи — какие покрывают а какие нет? есть ли смысл связываться с тестированием ради проверки тех задач которые можно ими проверить? можно ли расширить область действия тестов?
Попробуйте задать себе вопросы в этом роде и подумайте как можно на них ответить.
Лучшее решение ваших проблем можете найти только вы сами.
То что отдельная проверка реализована по принципам unit тестирования, а не как selenium тест,
совершенно не значит что такой тест будет не понятен и бесполезен QA. Может быть этот то что нужно.
Польза от теста ручному тестированию определяется не технологией использованной при
написании конкретного теста, а его осмысленностью и выразительностью.
Точно также, любой тест на любой технологии может быть написал плохо и создавать больше проблем чем приносить пользы.
Тесты это тесты.
Конечно! Жалко не все так делают :)
Хорошо если регрессионное и ручное тестирование идyт из одного источника,
но это далеко не всегда так.
Возможно вы привыкли к хорошему :)
Вы подразумеваете что тесты достаточно хорошо документированы и структурированы — в реальности это не всегда так.
По хорошему, задача не должна доходить до ручного тестирования если есть упавшие тесты.
Это элемент культуры разработки, проявление разработчиком уважения к труду ручного тестировщка.
Хороший вопрос! Но, мне кажется, не все задают его себе прежде чем написать 20 тысяч тестов :)
При ручном тестировании можно сообразить проверить то что никогда раньше не проверялось потому что никто об этом не думал раньше.
В этом разница.
тестирование это исключительно прикладная область.
На эту тему есть отличная книга Perfect Software от Gerald M. Weinberg.
1. Выявить проблемы
2. Определить возможные решения
3. Выбрать из возможных решений целесообразные
4. Воплотить!
P.S. Понимаю что мой ответ вас не устроит ;)