1. в моей жизни было 2 вуза. Один из них очень известный и престижный в нашем крае. Так же у меня хватает друзей и знакомых, которые учатся (учились) в разных ВУЗах нашей страны. Практикующих преподавателей мало!
2. Из 1 => Не во всех вузах преподают "работники Sun". Мне почему-то кажется, что таких заведений немного

Ну вот видите, Ваш начальный топик уже можно исправить на "не стоит идти в ВУЗы с плохими предподавателями". Звучать будет совсем иначе.

3. Книга лишь источник теории. спрашиваю я у коллег, у знакомых, которые на интересующем меня вопросе "собаку съели". прежде всего я сталкиваюсь с реальными проблемами на работе, которые вызывают кучу вопросов. и ответы на эти вопросы будут мне полезны. и эти ответы я запомню надолго, потому все они связаны с моей работой, я знаю, что они РЕАЛЬНО мне пригодятся. (интересно какой вуз тестировщиков (специалистов по тестированию\качеству) готовит-то?)

Вобще я слышала, что стали вводить дополнительные курсы в вузах. И знаю, что дипломы на эти темы защищают.

насчет компиляторов интересно. и кто ж это за люди, которые "делали компиляторы" и преподавали этот предмет в вузе?

В ВУЗах, помимо преподавания, идет исследовательская деятельность, по которой отчитываются (ну если профессура там не решила совсем штаны за зарплату просиживать). Плюс еще со времен Советского союза и до наших дней были и идут правительственные и военные заказы на разработку чего-нибудь, в том числе ПО. Некоторые создали фирмы, тесно завязанные на ВУЗ, кто-то остался "просто командой", т.к. громкий пиар многим просто не нужен - у них и так есть заказы.

а что понимается под "в тот момент двигал это направление" (визуальное моделирование)?

Развивали теорию, разрабатывали соответствующее ПО, решали при помощи всего этого задачи, писали статьи и диссертации.
Просто последние пару лет не знаю, чем конкретно они занимаются, т.к. тема большая и с фундаментальных вещей легко соскочить в прикладные.

а, кстати, где у меня обощение идет? я написала "в основном"

Вы еще в своем первом посте обобщили.
Сами написали: "не понима... была... не понравилось".

Для того, чтобы въехать в программирование, не обязательно заниматься чистой математикой. А мозг можно тренировать и играя в карты, например.

Ню-ню... Приходит потом товарищ на собеседование и на вопрос об n-арных деревьях заявляет, что он знает только бинарные... в книге все примеры только на них были
А расширить количество узлов сам не может. И что он в итоге напрограммирует?

не скажу, что на лекции получаешь много больше практики и книг. почему? потому что преподаватели в основном теоретики! :) по кр мере на ИТ-специальностях. думаете "админы" преподают Сетевые технологии? или программисты, работающие на реальной работе хотя бы по 3 часа в день, преподают ТЯП (да даже то же функциональное программирование, или 1с программирование, или разработку сайтов, или даже VBA, а что уж говорить про моделирование систем)? оч сомневаюсь. вот как я могу что-то спросить у человека и быть уверена в верности ответа, если он сам не пробовал все это применять в работе и жизни?

Я не думаю, я знаю, что так не везде и не всюду.
Поэтому правильнее написать "в МОЕМ вузе преподавали только теоретики, поэтому я считаю, что в ДАННЫЙ вуз на лекции ходить не надо".
А обобщать на примере одного вуза - слишком громкое заявление. У нас и java читали работники Sun. И теорию компиляторов те люди, который делали эти компиляторы. И визуальное моделирование тоже читал тот, кто в тот момент двигал это направление.

PS: Кстати, а у книги Вы как спрашиваете?

Утрируете. Предположим вы берёте в кредит автомобиль. Вы отличаете "стоимость владения" от "суммы выплаты по кредиту"?

Утрирую я только в кроссовках :) Просто пару лет просматриваю форум, на котором о кредитах очень много и многие общаютсяс разбором полетов... и про стоимость владения большинство знает и учитывает, пусть не в терминах, но на интуитивном уровне точно. А не учитывает как раз таки крупные траты, которые возникают регулярно, но в разных областях... И именно оценка стоимости одежды, полетел комп, вдруг оказалось, что надо купить посуду, стоматолог, с друзьями в ресторане загуляли, ДПС штрафанул пару раз и т.п. до бесконечности.
Ну не замечают этого... и именно на этом все сыпется.
Либо личный героизм, когда сознательно идут на жесткое сокращение расходов, типа, полгодика потерпеть можно, а там зарплату поднимут или халтуру найду, ЗАТО иномарка (марку сами подставьте)... или что там еще.

Например, два раза решал с разной степенью вовлечённости в процесс, вопросы с поиском новой квартиры сотруднику и помогал с переездом - не потому что я такой офигенно добрый, мне просто надо, чтобы человек работал, а не ломал голову когда его семью и вещи выбросят в коридор.

Так это проблема в диком рынке аренды. И никакое образование тут не поможет: либо повезло встретиться с нормальным арендодателем, либо нет.

Читали на 4-ом курсе. Первый семестр. Я, наверное, тупой,но в меня теория не влезла. Читал потом сам - наверное оттого и хромаю на эту ногу.

Моя мысль была проста: если брать тоже ООП, то основные формулировки много букв не занимают. А дальше идет процесс осмысления и использования, но уже в рамках других предметов, курсовых и т.п. Не знаю как у Вас, но в моем ВУЗе возможностей было полно.
Вот только с самого начала медитировали над этим избранные, а остальные поняли, что это оказывается нужно, только когда на работу устроились...

вставлю свое имхо: никогда не понимала ВУЗы.

Но на заочном Вы все-таки были :) Кстати, на лекции получаешь гораздо больше... особенно, если преподавателю есть чем поделиться... в книгах этого может и не быть... совсем. :)

Специалист решает проблему не с кодом, а с тем что "ЗП давно не повышали и вообще эта работа заколебала", "кредит на форд фокус оказался неподьёмным, а знакомые больше не одалживают", "опять всё свалилось в какую-то чёрную дыру - нифига не успеваю!!!". Моя логика понятна?

Я лично не понимаю, чем помогут дополнительные лекции человеку, который УЖЕ ПОСЧИТАЛ, что он может прожить на 100 каких-нибудь тугриков, ЗАБЫВ про то, что завтра ему нужно купить новые кроссовки, из-за чего он не уложился в бюджет. Это в лучшем случае, т.е. если он вобще задумался "как жить", а не понесся сломя голову и распихивая локтями остальных, потому как "у друга уже есть!" (при этом большие глаза).
Что ему вобще можно сказать на лекции по этому поводу?

Отлично. Я тоже - лечится будем вместе. Вокруг меня много Специалистов, которые не учатся, которые наступают, которые берут странные кредиты, которые не могут банально понять где заканчивается "творчество" и начинается "задача-время-приоритет-коммитмент" и поди потом донеси до него в тот момент, когда ему стукнет, что так не делаеют! У него много ответов и мне приходится решать его проблему. Что с ними не так? Скажите мне, пожалуйста.

А можете привести конкретный пример? :)

Вы это серьезно что ли? Работодателям нужны конкретный опыт и конкретные скиллс, а гипотетическая образованность это делое десятое. Приблизительно как умение женщины вышивать крестиком в контексте ее привлекательности для совместной жизни.

Образование тренирует мозг. Например, позанимавшись чистой математикой с ее абстракциями, как-то сразу въезжаешь и в программирование с его абстракциями без длительного медитирования.
А вышивание крестиком тренирует терпение, усидчивость, аккуратность и желание делать что-то для людей. Так что зря вы так...



К сожалению долго искать пост от Case, в котором он возмущается(?) 8 часами ОПП, чтобы аккуратно его тут воспроизвести.
Но есть вопрос: а что там вобще АЖ целых 8 часов можно рассказывать? Чего потом не хватало? И лекции читали в последний семестр обучения?

А если требуется посмотреть как составляется этот отчет в системе? Т.е. ситуация такая - данные в БД верны, а выборка не верна. Причем проблема не в алгоритме выборке, а просто кто-то поправил реализацию некоего метода, который используется в отчете?

Все равно должен быть какой-то метод, который начинает весь процесс и объект, который хранит данные. Вот его и надо использовать.
Ежели этого нет, то тут могут быть проблемы архитектуры (например, когда каждое поле формы обслуживается своим селектом и т.п.). В любом варианте при нормальном проектирование пользовательский интерфейс по идее не должен быть тесно и неразделимо завязываться на логику работы. Если это не так, то ква.
Ну и учтите, что я не вижу вашей системы, поэтому все рассуждения теоретические. Если под "как этот отчет выглядит в системе", подразумевается его внешний вид перед печатью и проблема в том, что кто-то напутал с полями и т.п. вещами, которые влияют только на отображение данных, то тут может быть и совсем другая история. И надо использовать совсем другие методы.

Я согласен, это кажется вполне очевидным. Это как я понимаю и есть unit-тестирование. Однако беда в том, что по всей видимости просто выдрать такую процедуру нельзя, хотя бы из-за возможности обращения к методам других классов. А также по той причине, что в нашей системе такие методы компилируются налету в виде байт-кода с помощью java. Но мысль в общем-то понятна.

Нет, это не unit-тестирование. Unit-тесты рассматривают объекты в изолированной среде. Для этих целей используются всякие заглушки... например, вместо реального объекта, который подключается к базе данных, берется moc-объект, который просто возвращает "все ок" и к базе не обращается. Их прохождение еще не гарантирует, что все будет работать и в комплексе и с реальными объектами. То, что я описывала - это функциональное тестирование. Чаще всего это применяется к библиотекам. Все необходимое подключается к отдельному приложению (можно и собственного изготовления) и вызываем методы с разнообразными параметрами, смотрим, что возвращает или какой объект изменяет. Даже если Вам придется подключить все, что есть, кроме пользовательского интерфейса - ничего страшного. Эффективность от этой деятельности в некоторых случаях может быть гораздо выше, чем реализовывать это через gui. Все это зависит только от архитектуры и весьма индивидуально. Но если это возможно, то процесс настройки и создания много времени не отнимает.
Сорри, что применила слово "выдирать".. не расчитала.

Все так. Цель вероятно примерно такова - повысить качество и устойчивость ПО. Ясно, что она не достигается только тестированием.
Вторая задача-цель недопустить повторение возникавшей ранее ошибки - к сожалению такая ситуация была. Правда поканичего не документируется и не фиксируется, потому сложно узнать где были ошибки.
Насчет улучшить жизнь, пока я не в состоянии даже примерно оценить, что для этого нужно, и будут ли мои действия столь эффективны

А что именно повысит качество и устойчивость? Работоспособность какого-то отдельного модуля? Если Вы автоматизируете биллинг (что-то там было из нескольких шагов), и что это даст? Только сэкономит время? А сколько? Полчаса работы тестировщика? Или целый день? А там вобще были ошибки за последние полгода или его еще будут существенно изменять? Насколько это критично для системы в целом? На каком уровне там появляются ошибки (только в интерфейсе или в логике работы)?
И еще пачка подобных вопросов.
Иначе можете полгода автоматизировать справочники, хотя никто уже и не помнит, в каком году там нашли последнюю ошибку, да и пользователи их уже не открывают. А все проблемы остались. Ну или бесконечно проверять, что если у пользователя фамилия из 15 букв, начинается с согласной, он работает в отделе1, и вот когда шеф в отпуске, то у нас не создается отчет, потому что программист Вася когда-то сделал в коде опечатку.
Может гораздо интереснее проверить, что на таких-то наборах данных проходит правильная выборка хотя бы для всех старых отчетов, т.к. именно там много ошибок - это более критичный фронт работ. Ну или не мучать TestComplete, если ошибки можно найти быстрее в обход интерфейса. Если правильно определить фронт работ и подобрать нужные методы, то деятельность вскоре будет приносить ощутимые результаты.
Как-то так. :)

Некоторые баги зависят напрямую от порядка предыдущих действий и введенных значений.
Как только обнаружили ошибку, отматываешь в памяти назад все свои действия, добиваешься минимального набора действий для падения/ошибки с момента запуска приложения (но тратить на это полдня не стоит) и записываем последовательности этих действий: на что нажимать, что и куда вводить... ну или более кратко, но чтобы было понятно сразу в чем проблема.

"Как получился этот баг" - ежели хочешь успешно пройти стажировку и расти дальше, то ищи сам. :)

Понятно, думаю, заказчик тут непричем. Скорее ПМ мне не позволяет лезть в эту сторону. Логика по его мнению такова - я буду слишком много времени тратить на разработку подобных тестов, поскольку сначала мне придется узнать структуру данных, понять как там все работает, составить и отладить соответствующие запросы...

На самом деле он не прав, т.к. в реальности все сводится к подзадачам, реализацию которых программист может объяснить за полчаса. (Например, чтобы отчет был виден в базе надо заполнить три-десять таблиц такими-то данными - и тестер уже готов к тому, чтобы их заполнять, если знает SQL). Какие-то процедуры и сценарии можно вобще выдрать из кода и запускать отдельно с разными параметрами - это тоже не отнимет много времени. Вобщем, тут надо донести до ПМ, что при подобном тестировании совсем не обязательно изучать код каждой функции со всеми заморочками, главное - уметь их использовать.
Но с другой стороны, если в базе данных и библиотеках происходят довольно примитивные вещи, то вобщем-то и заморачиваться с этим наверно и не стоит. И определять, есть ли смысл вобще влезать в эти места, нужно с участием программистов.

Но где критерий? Мой ПМ предполагает, что скептизм к автоматизации связан с тем, что нет положительного опыта в силу тех или иных причин. Автоматизация воспринимается как некая ресурсосберегающая технология, поскольку позволит выполнять ее по ночам - раз; не напрагать при этом аналитиков - два; даст возможность самим разработчикам проверять интеграцию разрабатываемой ими функциональности - три; дает комфорт тестировщикам, поскольку они не будут скучать проводя многократное тестирование - четыре...

А критерием может быть только достижение целей, ради которых вобще затевается автоматизация и каждая ее часть, если тестирующих проектов несколько. "Занять чем-то компы и развлечь тестеров" - это просто повод потратить время на изучение вопроса.
Если Вы можете сказать, как именно Ваш нынешний набор тестов резко улучшит жизнь (окупит затраты) в ближайшем будущем, когда они будут реализованы - отлично! Если нет, то надо думать, как бы этого достичь.