Vasya Da_Gama, Не всегда у тестировщиков есть ТЗ (хотя обычно бывает) Тестируют они согласно плану ) * занимается последнии 2-а года доработкой различных АБС, как аналитик*
AlTk Я это видил два года, (в банке Топ10 в России).. Как человек, который ставит подпись в акте тестировая
НАРОД. Вы вообще о чем? Вы тему топика иногда читаете вообще? каждая интересная тема заканчивается флудом
ну только. если все грамотные до невозможности и первые в состоянии правильно всё написать, а вторые - правильно прочитать. На практике же, консультации проходят как ДО или ВО ВРЕМЯ, так и задолго ПОСЛЕ подписания акта приемки. Косяки ж возможны не только системные, но и связанные с человеческим фактором - кодер нажал не ту кнопку и т.п. Поэтму уж тестировать то ведущие обязаны по любому. Был случай года 3-4 назад: программер немного накосячил с выпиской счетов, и контора 3-4 месяца недополучала прибыль, хотя все акты были подписаны: и о тестировании и о передаче в пром.эксплуатацию. Набежало 2 млн, пока кто-то из клиентов не поинтересовался "а чего это счета меньше стали? У вас скидки?" к сожалению, подписи профессиональных идиотов ни фига не весят. А если начальник департамента подписал - значит всё проверено на высшем уровне. Собственно, тут вопрос в отвественности - если бы начальники потом огребали по самое "не хочу" при обнаружении косяков, тогда б они и сами бы смотрели и ведущих спецов бы на тестирование приглашали. Хотя...по сути то твой пример - это мероприятие по подписанию, ты уверен, что до этого весь департамент не горбатился на тщательном тестировании?
Абсолютно. Зайдешь в гости - расскажу состав приемной комиссии - обхохочешься. Причем все было как положено - "Программа и методика приемных испытаний" (цитирую по памяти, порядок слов в наименовании документа мог быть и другим) была в наличии со всем подписями. Заявленый функционал-то был, но вот реализация была пёранальной. добавлено через 1 минуту Скорее всего на самом раннем - ну кто пишет в эксплуатационных документах "Включить ПК" ?
Mix А разве тестировщик должен выевлять ошибки в модели? (да и может ли он это сделать вообще?). Модель делает аналитик (он же за нее и отвечает), тестировщик тестирует, что все работает согласно выбранной модели ) (то что модель может быть неправильная, это не проблема тестировщика) добавлено через 3 минуты Для примера у нас акт подписывают 1) Начальник Управления тестирования + непосредственно исполнитель тестирования. 2) Аналитик(человек, который писал задание) он же менеджер проекта. 3) Програмист. 4) Начальник отдела, который будет эксплуатировать эту доработку.(если доработка важная, то и его начальник (начальник управления)......
Я как бы об этом речь и вел, когда на тестирование назначили профессиональных идиотов. Как ни странно на испытания самолета назначают лучших летчиков, а вовсе не тех кто может по максимуму на земле потыкаться по панели приборов. Еще раз повторю вопрос. В какой момент в таком случае будут выявлены ошибки модели? Мой прогноз - уже после начала продуктивной эксплуатации.
Без понятия. Твои идеальные представления о том, как всё должно быть устроено. В реальной жизни всё очень далеко от идеала.
Mix, Когда как (смотря что за ошибка модели). В общем случае, все будет выявленно на тестирование, но не тестировщиком . В тестирование участвует заказчик (он же будующий пользователь системы) и аналитик (он же автор задания на разработку) именно они могут увидеть(а могут и не увидеть ), что реализация модели, не совпадают с тем, что хотел заказчик (увидет это заказчик (или аналитик), так как именно они, а не тестировщик, понимает что требовалось от модели).
А я даже могу объяснить, почему. Во-первых, потому что заказчик внутренний; во-вторых, потому что IT-менеджмент хромает. Первое и второе взаимосвязаны. IT в таких организациях сидит на зарплате. Премии? Ну, может быть и премии, но природа этих премий в основном столь же бюрократична, как и общий стиль руководства. Я не хочу при этом сказать, что люди не работают - они работают, но работают впустую. Процесс ради процесса. Заказчик тоже особо не заинтересован в плодотворной работе. В бюрократической организации инициатива наказуема. Ответственностью играют в футбол. Организации очень повезёт, если она заполучит толкового IT-менеджера. Но у них нервы тоже не железные, насколько я знаю. А теперь представьте себе другой вариант: консалтинговая фирма и собственник бизнеса один на один. Да ни дай Бог что-то не будет работать, как надо - тебе просто никто не заплатит. Если вы будете работать без детальнейшим образом проработанного и согласованного ТЗ - вы будете вечно работать забесплатно. Вы будете исполнять нескончаемый поток пожеланий, фишек и фенечек, улучшений, неожиданно открывшиеся идеи по автоматизации неожиданно вспомнившихся бизнес-процессов и т.д. и т.п. Рынок заставит делать всё "идеально", а не начальник. А знаете вот ещё, почему НИКОГДА компания-внедренец не общается с IT-отделом, а выходит напрямую на людей, кровно заинтересованных в продуктивности бизнеса? Правильно. Потому что IT сидит на зарплате и им лишний гемор в пелодку не нужен. Это на 99% истина. Задумайтесь. Я никого не хочу обидеть, но всё-таки задумайтесь.
tulkas, 1. попрошу обращаться на Вы 2. мне непонятна Ваша логика. как Вы на основании моего утверждения о том, что у Вас неправильные должностные инструкции, так как в них не говорится о том, что вам необходимо в процессе эксплуатации выявлять ошибки/недочеты программного обеспечения и информировать об этом руководство делаете Вывод о том, какие у меня идеальные представления. ладно, про логику закончим. мои представления и мои утверждения основывается как раз на собственном опыте работе и опыте работы моих знакомых/ коллег. устройство и организация работы зависит от вас, а не от кого-то. ПС. и не надо нравоучительным тоном говорить как в реальной жизни все устроено, я все-таки постарше Вас буду, да опыта, скорее всего, у меня побольше будет. ППС. Mix, плюс один. Ярик, тестирование начинается с момента проектирования. добавлено через 32 минуты Vasya Da_Gama, естати, никто не мешает и даже нужно эти рыночные отношения выстраивать также и при внутренних заказчиках, все равно нужно управлять UC, OLA и SLA. а, договорные отношения тоже не идеальны, они выявляют новые проблемы, например тут делаем, а тут за деньги, так как договором не предусмотрено, ну это уже обсуждалось в одной из тем про аутсорсинг
итересно было бы почитать. не застал. скажем так: я понимаю твою позицию. относительно чего, правда, загадка , но понимаю, ибо гуманитарно мыслю. я сам не дружу с IT, если честно. "из IT в экономику можно, а из экономики в IT сложно" (с) не помню чей.
AlTk, А как это? (*молодой еще...может что не знает..) может мы немного разное понимаем под тестированием..
Ярик, Фаза планирования: На фазе планирования производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Основные задачи и сферы ответственности тестировщиков на фазе планирования: оценка дизайна; требования тестирования; план и календарный график тестирования.
AlTk ААА...*испугался что как-то не так работает ).. Ну это да, но хз почему Вы считаете это тестированием. Да, на этапе проектирования производится оценка сроков и требований к тестированию (зы, но по хорошему, это не потому, чтоб тестировщику было легко, а для того, чтоб посчитать затраты и выставить счет Клиенту .. Вообще еще могу добавить, что при написании ТЗ, аналитик (ну по хорошему, да и по ГОСТ 34) должен указывать, что вот эту итоговую цифру, которую мы тут получим, можно проверить вот так (алгоритм проверки). Чисто потому, что тестировщик не экономист, и может не знать экономический смысл всей схемы.
да уж... спецы там что надо. подружку папа устроил... "по кридитному делу" (орфография автора сохранена)
Зы. в 80% общаюсь именно с ИТ отделом (а работаю именно в консалтинге-внедренце). Да первоночальная общая договоренность идет с директором компании (тех-директором). Но обсуждение уже конкретных деталий (как внедрять-в каких объеамх - какое оборудование - как работать итд) это ТОЛЬКО с Ит- отделом. (странно было бы это обсуждать не с ИТ)..Так как обсулуживать это все потом ИТ, потдерживать на месте ИТ, работать с этим ИТ, да и они разбираются в ИТ вопросах, так с кем, как не с ними обсуждать то.. Да в обсуждении участвуют еще и те, кто непосредственно заказывают (бизнес), но ИТ есть всегда (в той или иной степени)... Про ТЗ полностью согласен
да неужели? даже они участвуют? гнать их поганой метлой! добавлено через 7 часов 43 минуты p.s. это был сорказм добавлено через 7 часов 48 минут сАрказм, извините
BSClient используется многими банками. Например ВТБ. Я согласен, что реализация убогая Приходилось настраивать в том числе и от ПКБ. И вообще нормальные банки ушли на интернет-банк. Типа IBANK2 на Java (Бинбанк использует его и кажется ВолгоПромБанк). PS: Я не работник ПКБ, и вообще банка добавлено через 2 минуты Зато теперь ясно кто представляет ПКБ на форуме добавлено через 3 минуты Используйте Парус или ИнфоБухгалтер
Ярик, да не аналитик, а тестировщик, тес-ти-ров-щик! ПС. а вообще, да, в вашем банке тоже что-то не так работает.
Там же мозг сломать можно Особо бухгалтеру который с ним работает: 1) Все на английском 2) Интерфейс абсолютно не интуитивный 3) Соответственно без поллитры т.е. инструкции не разобраться.
artemii, кстати да. и если следовать логике PenisEnlarger, то тогда уж стандартный клитент нужно делать не под 1С, а под MS Outlook.
Я препочитаю стиль общения, принятый в интернете. Надо быть немного проще. Может не будем меряться... опытом и возрастом? Это не всегда показатель. Насмотрелся я уже на некоторых старых опытных айтишников... Я как раз не занимаюсь поучением, в отличие от большинства остальных. Я знаю какой должна быть идеальная модель разработки ПО. Максимально соответствие ей я видел в ЦБ. За что им честь и хвала. В основной массе - всё намного хуже, даже не смотря на наличие всех соответствующих инструкций. Сидя здесь в Волгограде на достаточно средней должности, по-моему, глупо пытаться менять существующую систему и указывать высокому начальству на недостатки в организации. Кроме раздражения это ничего не вызовет. Это как минимум. Можно и огрести по-полной. Надо принимать систему какая она есть и действовать в отведённых рамках. Вот если карьера сложится и удасться попасть в стан людей, влияющих на принятие решений, тогда и имеет смысл реализовывать свои идеи.
Использование pop/smtp imho еще тот бред. Все таки стандартным клиент-банком должен быть IE, Firefox, Opera, Safari (нужное подчеркнуть). Опять же кросс-платформенность. Если у меня клиенты под Linux/FreeBSD почему я должен еще wine использовать.
Это даже умно, но делаться это должно не инициативой снизу, которая у нас, как известно, наказуема, а людьми, у которых на это есть полномочия.