Мы говорим о западной и азиатской культурах. Вы приписываете западной культуре свойства азиатской, ссылаясь на анклавы азиатов на западе. Это как минимум глупо.
А что такое западный networking — смотрите на linked in. Это оно и есть, в миниатюре.
Индустрия разнообразна. На каждую хитрую практику всегда найдется множество готовых примеров применения. Только вот на практику экономии на тестировщиках позитивных примеров почему-то нет нигде. Почему ваш опыт не интересен я уже сказал — у вас явно весьма специфичный рынок, где качество и юзабельность продукта далеко не в первой десятке важных критериев.
И почему вы постоянно XP-практики пытаетесь противопоставить ручному тестированию? Они вообще-то совершенно не пересекаются и никак друг другу не мешают, они к разным областям разработки относятся.
Да, им может и год понадобиться. Бывает и такое. Вот пусть и ищут. Пять дней в неделю, восемь часов в день, в поте лица своего. Пока разработчики занимаются своим делом — код пишут, автоматизированные тесты, стресс-тесты, и т.п. А тестировщик должен найти то, что в голову разработчику даже и не придет.
И, да, ваши слова являются бездоказательными, потому как являются обобщением вашего личного опыта, единичного случая. Сравнение вашего опыта с опытом всей остальной индустрии, с опытом компаний неизмеримо более авторитетных чем ваша, будет всегда не в вашу пользу.
Нет. Я же написал — я туп и ленив. Мне нужны пути наименьшего сопротивления при наилучшем результате.
Разработка через тестирование (Test driven development)
Давайте только юнит-тесты не приплетать сюда. Мы про совсем другое говорим.
Сотрудничайте с авторами спецификаций и стандартов.
Думаете, эти люди из Microsoft сами всякие мелкие детали знают лучше, чем они же про них соврали в спецификации? Я с ними сотрудничаю. Полезно. Но не решает проблемы в целом. Полного знания нет ни у кого.
Решается архитектурой проекта.
Не решается. Вы представляете себе, что такое сложность? Почитайте Колмогорова, Чейтина, да хотя бы Эша. Есть такое понятие, как количество информации. Меньше и проще определенного предела без потерь не получится, таково фундаментальное свойство Вселенной.
Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
Это всё способы устранения шума из данных. Таким образом мы получаем чистую информацию. Сложность в чистом виде, без лишних примесей. Для задач, в которых настоящей сложности нет, но есть много шума, это работает идеально. Для случая, когда истинная сложность высока, не поможет ничто. У меня и так всё сделано в виде иерархии из более чем десятка eDSL, каждый из которых туп как пробка и решает свою отдельную маленькую задачу. Никаких текучих абстракций, ничего лишнего — чистейшее математическое выражение самой сути задачи. И эта суть весьма сложная.
Вы говорите, что софт должны тестировать сами разработчики, и что «хорошая архитектура позволяет исключить баги». А чего они, разработчики, натестируют, всем хорошо известно. Так же как и известно, что самые гнусные баги всегда ныкаются в мелких деталях, которые никакая архитектура никогда на 100% учесть не сможет. Даже самая гениальная архитектура, супер-пупер языки с зависимыми типами и верификацией через HOL не защитят от банальной очепятки или от забытого при деплойменте файлишки.
"Разработчики ни при каких условиях не должны заниматься проектированием интерфейсов. Ибо напроектируют такого… На своей шкуре убедился."
Правильно. Ну а кто у вас этим тогда занимается? UX-инженеры? И они не проводят всего положенного по их науке тестирования? Не верю.
Я разве говорил, что тестирование бессмысленно или не нужно?
Да, именно это вы и говорили. Что тестировать можно силами самих разработчиков, и специальных, отдельных людей для этого вовсе не требуется.
Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте.
Основные причины: недостаточно достоверные и полные спецификации на используемые стандарты (как следствие — требуется очень много тестирования, к счастью автоматизируемого, и много reverse engineering), банально очень высокая алгоритмическая сложность (тут больше формальная верификация помогает и автоматизированные тесты), тупость и безалаберность разработчиков (не лечится, меня головой вниз роняли и с тех пор я такой). Этому проекту тестировщики ничем не помогут. Но это специфичный и редкий случай, там даже UI нет. А вот 99% других проектов, с которыми я имел когда либо дело, многое выигрывают от выделенных тестировщиков, не знающих ничего про внутреннее устройство проекта.
Мне понятно, что вам не понятно все, что за пределами вашей узенькой области.
Любой софт такого типа, ориентированный на массового пользователя, обязательно должен тестироваться. Это и есть самая эффективная модель разработки, как показывает практика. Ваш частный случай (причем, исключительно по вашим же словам, а верить вам у меня нет никакого основания) абсолютно ничего не доказывает, кроме разве что того, что или у вас captive market, или вообще рыночные механизмы конкуренции в вашем сегменте не действуют (типично для финансового сектора, особенно в постсовковых странах).
Так же мне понятно, что у вас весьма ограниченные представления о разработке софта вообще. Знаете, узкая специализация ещё никому не шла на пользу.
Вот, скажите, вы можете обвинить, например, Red Gate в неэффективности и проедании бюджета? А у них тестировщиков столько же, сколько и разработчиков (если не больше). В некоторых (наиболее эффективных) подразделениях Microsoft та же картина, кстати.
Это таки ни разу не интерпретатор. Это скриптовый движок, причем довольно таки странный. Ничего, что можно было бы назвать словом «интерпретатор» там нет. Он дергает компилятор (отдельным процессом) и подгружает полученную dll.
Пользователи не жалуются, потому как привыкли. Очень мало софта, который разрабатывается с правильным процессом, с участием UX-engineers, с корректным тестированием. Вот например вы даже не понимаете, что разработчики в принципе, никогда и ни при каких обстоятельствах это тестирование делать сами не могут, и что их вклад даже в само проектирование интерфейса должен быть весьма ограниченным. Никогда человек, знающий хорошо внутреннее устройство какой либо системы не сможет придумать или даже просто оценить хороший интерфейс, понятный тому, кто внутренностей системы не знает и не представляет себе.
"Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем."
Не верю. Абсолютно. Потому как прекрасно знаю, что без тестирования проблемы будут даже в полностью аннотированном, верифицированном коде с абсолютно идеальной архитектурой. Потому как общая архитектура никогда не может учитывать гнусные мелкие честности. Те, которые только при тестировании и выявляются.
Конечно, возможно что ваш продукт просто очень примитивен. Но мне сложно представить себе что-то хоть немного сложнее чем «Hello, world!», что не нуждалось бы в независимом (то разработчиков) тестировании.
Интерпретатор IL может и существует (правда, ни один рабочий мне не попадался, все дохлые и устаревшие). Интерпретатора же языка C# нет, и его было бы весьма непросто написать.
А что такое западный networking — смотрите на linked in. Это оно и есть, в миниатюре.
И почему вы постоянно XP-практики пытаетесь противопоставить ручному тестированию? Они вообще-то совершенно не пересекаются и никак друг другу не мешают, они к разным областям разработки относятся.
И, да, ваши слова являются бездоказательными, потому как являются обобщением вашего личного опыта, единичного случая. Сравнение вашего опыта с опытом всей остальной индустрии, с опытом компаний неизмеримо более авторитетных чем ваша, будет всегда не в вашу пользу.
Нет. Я же написал — я туп и ленив. Мне нужны пути наименьшего сопротивления при наилучшем результате.
Разработка через тестирование (Test driven development)
Давайте только юнит-тесты не приплетать сюда. Мы про совсем другое говорим.
Сотрудничайте с авторами спецификаций и стандартов.
Думаете, эти люди из Microsoft сами всякие мелкие детали знают лучше, чем они же про них соврали в спецификации? Я с ними сотрудничаю. Полезно. Но не решает проблемы в целом. Полного знания нет ни у кого.
Решается архитектурой проекта.
Не решается. Вы представляете себе, что такое сложность? Почитайте Колмогорова, Чейтина, да хотя бы Эша. Есть такое понятие, как количество информации. Меньше и проще определенного предела без потерь не получится, таково фундаментальное свойство Вселенной.
Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
Это всё способы устранения шума из данных. Таким образом мы получаем чистую информацию. Сложность в чистом виде, без лишних примесей. Для задач, в которых настоящей сложности нет, но есть много шума, это работает идеально. Для случая, когда истинная сложность высока, не поможет ничто. У меня и так всё сделано в виде иерархии из более чем десятка eDSL, каждый из которых туп как пробка и решает свою отдельную маленькую задачу. Никаких текучих абстракций, ничего лишнего — чистейшее математическое выражение самой сути задачи. И эта суть весьма сложная.
Правильно. Ну а кто у вас этим тогда занимается? UX-инженеры? И они не проводят всего положенного по их науке тестирования? Не верю.
Я разве говорил, что тестирование бессмысленно или не нужно?
Да, именно это вы и говорили. Что тестировать можно силами самих разработчиков, и специальных, отдельных людей для этого вовсе не требуется.
Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте.
Основные причины: недостаточно достоверные и полные спецификации на используемые стандарты (как следствие — требуется очень много тестирования, к счастью автоматизируемого, и много reverse engineering), банально очень высокая алгоритмическая сложность (тут больше формальная верификация помогает и автоматизированные тесты), тупость и безалаберность разработчиков (не лечится, меня головой вниз роняли и с тех пор я такой). Этому проекту тестировщики ничем не помогут. Но это специфичный и редкий случай, там даже UI нет. А вот 99% других проектов, с которыми я имел когда либо дело, многое выигрывают от выделенных тестировщиков, не знающих ничего про внутреннее устройство проекта.
Любой софт такого типа, ориентированный на массового пользователя, обязательно должен тестироваться. Это и есть самая эффективная модель разработки, как показывает практика. Ваш частный случай (причем, исключительно по вашим же словам, а верить вам у меня нет никакого основания) абсолютно ничего не доказывает, кроме разве что того, что или у вас captive market, или вообще рыночные механизмы конкуренции в вашем сегменте не действуют (типично для финансового сектора, особенно в постсовковых странах).
Так же мне понятно, что у вас весьма ограниченные представления о разработке софта вообще. Знаете, узкая специализация ещё никому не шла на пользу.
"Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем."
Не верю. Абсолютно. Потому как прекрасно знаю, что без тестирования проблемы будут даже в полностью аннотированном, верифицированном коде с абсолютно идеальной архитектурой. Потому как общая архитектура никогда не может учитывать гнусные мелкие честности. Те, которые только при тестировании и выявляются.
Конечно, возможно что ваш продукт просто очень примитивен. Но мне сложно представить себе что-то хоть немного сложнее чем «Hello, world!», что не нуждалось бы в независимом (то разработчиков) тестировании.