Архив за день: 04.04.2011

Потребительские кредиты: система взаимных подставок

Добавить комментарий

Потребительские кредиты: система взаимных подставок
Любому рядовому получателю кредитов известно, что, несмотря на все рекламные заявления банков, получить кредит «в течении одного часа» и даже «в течение одного дня» не так-то просто. В любом объявлении банка всегда есть маленькая симпатичная строчечка: «Банк вправе отказать в получении кредита без объяснения причин».
А если потребительский кредит и выдается, то либо под залог, либо под поручительство, либо есть еще какие-то особые условия.
А что такое «поручительство»?.. Это когда получатель кредита фактически решает свои проблемы либо за счет кого-то из родственников, либо за счет кого-то из друзей. То есть, прямо говоря, подставляет их.
Любой банк, особенно тот, который активно выдает потребительские кредиты – это все та же ростовщическая контора. Деньги для банка – это вовсе не «товарный эквивалент», а основа самого бытия и самая главная ценность во вселенной. Соответственно, преумножение денег – самая главная цель для банка.
Поэтому при любом раскладе выданные взаймы деньги банк хочет получить назад не только в полном объеме, но и с процентами. Иначе смысл всей жизни для банковских работников, читай – ростовщиков – будет потерян. И если вдруг у заемщика начнутся проблемы с отдачей кредита, банк без всяких сомнений совершит «наезд» на поручителей заемщика.
Если ситуация станет совсем плохой, банк обратится в суд, и, в соответствии с судебным решением, заемщику придется иметь дело уже не с банком, а с судебным приставом.
Что произойдет в этом случае?..
С одной стороны на заемщика будет воздействовать пристав, с другой – подставленный заемщиком любимый родственник или уже бывший друг.
И в этой ситуации у многих заемщиков возникает соблазн обратиться еще в какое-нибудь кредитное заведение, чтобы взять деньги еще и там, и целиком погасить задолженность. Очень ведь хочется, чтобы и пристав отстал, и бывший друг или родственник перестал взывать к совести.
А это кредитное заведение, вернее, сотрудник этого заведения с сожалением может сказать заемщику, что лично ему оно кредит выдать не может, ибо вся информация о неблагонадежности заемщика уже пошла по всем банкам. И этот сотрудник намекнет заемщику, что он может взять кредит на имя какого-нибудь другого человека, надо только сообщить этому кредитному заведению паспортные данные этого человека.
Это будет именно намек, а не прямая рекомендация. Сотрудники этих заведений люди опытные. Свой базар фильтровать умеют.
Но из этого намека проистекает соблазн. А с соблазнами бороться, как известно, очень сложно.
В общем, по кривой дорожке взаимных подставок сейчас в нашей стране уже прошли и продолжают идти очень многие люди.
Вот об этом буквально сегодня мы и беседовали с дочерью моих давних знакомых. Эта девушка закончила юрфак и устроилась на работу как раз в службу судебных приставов. Но выдержала она там только несколько месяцев и уволилась. Сейчас пока дома сидит, на шее родителей, думает, что делать дальше.
Конечно, сидеть на шее родителей не хорошо. И ничего плохого в работе судебных приставов нет. Более того, эта служба совершенно необходима для нормального функционирования государства.
Но почему-то дочери моих знакомых было там нехорошо, не по себе как-то было. Мысли какие-то в голову стали приходить, мучительные. Неправильные, может быть.
Она вот теперь вообще предлагает просто запретить выдачу потребительских кредитов как таковых. В законодательном порядке. Она говорит: «Наркотики же запрещены? Азартные игры на деньги – ну, казино там всякие – тоже запрещены. А соблазн получить какую-нибудь финтифлюшку вот прям щас – это тот же наркотик. И еще какой!..»
И возникает ощущение, что в этих ее неправильных мыслях есть какая-то глубинная правота…

О человеческих половинках.

Добавить комментарий

Прочитал в блоге знакомой сильно царапнувшие глаз строчки: «Я здесь в поисках своей второй половинки… Но все больше прихожу к мысли что я родилась целой»

А зачем ищут свою половинку? Ведь сейчас век торжества рациональности и эгоизма. Сейчас стало обыденно обеспечивать себя самостоятельно. Самостоятельно развлекать и ублажать. Самостоятельно совершенствоваться – что в добродетелях – но чаще в пороках. Всегда можно найти компанию, где тебе рады и где тебя не могут терпеть. Союзы стали непрочны, но и поиск временного партнера существенно упростился. Век одиночества и прагматизма.
Тем не менее, очень многим душно и тошно в таком обществе. Душу ведь не обманешь – она в отличие от ума и логики жаждет кое – чего другого, не менее важного, чем достаток, развитие и удовольствия.
А что такое вообще – найти свою половинку? Выскажу и я свое мнение по этому совершенно бесконечному вопросу.

Человек, каким бы ни был он цельным и самодостаточным – нуждается в дополнении. Именно этим во многом объясняется союзы противоположностей, но все же чаще сходств. Такие союзы редко бывают равнозначными, равноправными и проче-математически, логически «равными». Как перчинка в супе, одна составляющая такого союза придает ему законченность и совершенство. Масса ключа невелика по сравнению с массой двери – но это две необходимые составляющие. Когда таких дверей много и они, как и ключики сосредоточены не на одной стороне – такой союз может считаться гармоничным.
Возможно и негармоничное дополнение. Например, красавицу очень даже дополнит чудовище, хотя даже в сказке его быстро перештамповали ))
Кроме дополнений – любой человек нуждается во взаимодействии. Не просто по принципу «ты мне – я тебе» а на гораздо более доверительном и скрытом от посторонних глаз уровне. При этом, это должен быть человек своего поколения, понимающий именно тонкости психологического состояния. Именно в этом есть риск неравных по возрасту браков, когда что увлечения, что радости, что трудности имеют разные «весовые коэффициенты». Именно поэтому не все можно доверить родителям и детям. Не то чтобы это было плохо или стыдно. Просто это будет непонято, непрочувствованно в «правильной» пропорции и кондиции. И даже советы не будут восприняты в полной мере. Тонкости ошеломляюще незначительны – но безошибочно чувствуемы.
Наконец, объединение двух половинок дает в сумме более чем один. Такая вот семейная арифметика. Даже буквально, потому что нормальный, неущербный союз немыслим без детей, которые уже образуют свое поколение со своими тонкостями. Счастлива семья, где взаимопроникновение всего достаточно глубоко. Именно такие союзы и прочны и долговечны. Наконец, совсем правильно, когда дополнение и взаимодействие приносят результаты в виде творчества, развития и приобретения совместных интересов и увлечений, совместных дел. Именно это – скрепляющая основа любого союза, который без постоянной работы постепенно становится чисто формальным.
О человеческих половинках.

Много чего еще можно дополнить в рассуждениях о половинках более чем целого. Что-то не вспомнил, о чем – то забыл, а большинство и не знал. Желающие всегда смогут возразить, дополнить или прибавить что-либо новое. Вселенная чувств бесконечна. И это хорошо, иначе она была бы уязвима для холодных и омертвляющих чувства логики и целесообразности.

Тестирование программных продуктов

Добавить комментарий

Тестирование программных продуктов
Справедливости ради, стоит отметить, что российские реалии обеспечения качества в целом, далеки от западных, где под этим термином подразумевается обеспечение качества процессов компании, ведущих в конечном итоге к максимизации удовлетворенности клиента, и относится это понятие не только к IT сфере, а к бизнесу в общем его смысле. Данные стандарты предоставляются несколькими организациями, в частности ISO и IEEE

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

Усредненная структура компании, занимающейся разработкой программного обеспечения, выглядит следующим образом:
Маркетинговая служба. Занимается исследованием рынков, требований потенциальных заказчиков и расчетом соответствующих рыночных рисков. После перечисленных исследований, отдел подготавливает соответствующую документацию, в котором общими словами и требованиями, описывает продукт, требующий разработки и внедрения на рынок. Данная документация носит название MRD, т.е. Market Requirement Document
Служба документации. Занимается подготовкой документации различных видов, начиная от руководств по продукту, заканчивая конкретизацией документа MRD, называемого PRD — Product Requirement Document.
Служба разработки. Занимается непосредственно разработкой архитектуры приложения и его кода. Ядро компании и, часто, самый многочисленный отдел в ней. На основе PRD разрабатывается т.н. "дизайн-спецификация", описывающая общие принципы имплементации каждой выделенной части продукта.
Служба тестирования. Отдел, о котором пойдет речь в данной статье. Занимается проверкой корректности различных частей продукта на каждой стадии его разработки. В маленьких компаниях, численностью до 15 человек, выделять специальный отдел тестирования не имеет особого смысла, т.к. подобные команды разрабатывают малобюджетные, высокооборачиваемые продукты, и могут позволить себе быстрое тестирования средствами самих разработчиков. В случае, когда компания разрабатывает большое количество продуктов, либо продукт один, но масштабный, без отдельного департамента по тестированию не обойтись

Прежде чем вплотную подойти к особенностям профессии инженера по тестированию, необходимо ознакомиться со средой его обитания. С ключевыми терминами, с целями и задачами, а также со сложившимися стереотипами, заложниками которых, многим инженерам приходится становиться в силу начальной стадии развития данного направления в России. Основными "друзьями" специалиста в рассматриваемой области являются "баги", "тесткейсы", "бактрэкинговые системы", а также "инструменты автоматизации". Баг (Bug-жук) — ошибка, отклонение работы приложения от ожидаемого. Легенда появления этого термина говорит о том, что некие американские инженеры, разбирающиеся с поломкой электронного утсройства, обнаружили, что виной всему стал мотылек, застрявший между контактами. Дальнейшее развитие QA-индустрии согласилось с лаконичностью и информативностью термина, в наши дни прочно засевшего в сленге IT-специалистов. Чтобы как-то формализовать подход к тестированию, структурировать его, зафиксировать степень покрытия и получить базу, на которую можно ссылаться при предъявлении претензий свзанных с появлением багов, тестировщики пользуются т.н. тесткейсами. Тесткейс (Test Case — тестовый случай) представляет собой формализацию юзкейса (use case — последовательность шагов, рассматриваемая в рамках стандартного использования приложения) с целью зафиксировать отклонение или неотклонение результата от ожидаемого. Количество тесткейсов на один продукт может исчисляться сотнями и даже тысячами. Каждый такой случай покрывает определенный процент функциональности приложения, а итог в идеале должен стремиться к 100%. Для того, чтобы собрать статистику, зафиксировать ошибки и провести их от стадии открытия до стадии исправления и закрытия, инженеры по тестированию (строго говоря, не только они — данный инструмент является ядром взаимодействия между отделами) пользуются т.н. бактрекинговыми системами (Bug Tracking — отслеживание багов). Такие системы, часто представляют собой сервера с веб-интерфейсом, имеющие широчайшие возможности по структуризации контента. В общих чертах процесс использования данных систем сводится к следующей последовательности:
Инженер по тестированию, выполняя тестовые мероприятия (будь то выполнение тесткейсов, либо просто "игра" с тестируемым приложением) обнаруживает поведение, отличное от ожидаемого.
Обнаружив баг, инженер заносит информаци о нём в багтрекинговую систему. Система присваевает ему статус "New".
Далее процесc зависит от используемой системы, а так же от её настройки. Т.к. ошибка, занесенная в систему, должна переместится в чью-либо зону ответственности, необходимо определить пользователя, на которого ошибка будет переведена (assigned). Этот процесс может проходить как автоматически (в результате анализа системой входной информации об ошибке) так и вручную (при просмотре списка ожидающих багов менеджером проекта, например)
Запись об ошибке передается программисту для исправления (to be fixed). Программист принимает решение, которое может обернуться как минимум четырьмя исходами: согласиться с тем, что данное поведение приложения ошибочно и исправить его; не согласиться с тем, что это ошибка, и отправить запись обратно в отдел тестирования со статусом "Not A Bug" при этом обосновав своё решение; отправить ошибку обратно в отдел тестирования со статусом "Can Not Reproduce" при невозможности воспроизвести данный результат на своей копии приложения; отправить запрос дополнительной информации, вовлеченному пользователю (Info request).
После того, как баг приходит обратно в отдел тестирования, инженеру необходимо провести верификацию его текущего статуса. В случае исправления ошибки, тестировщику необходимо как минимум пройти описанный тесткейс и убедиться что на новой версии приложения, результат описанных действий равен ожидаемому. В случае статуса "Not A Bug" необходимо либо согласиться с этим (получив консультации заинтересованных лиц), либо не согласиться и отправить ошибку обратно разработчикам. При верификации статуса "Can Not Reproduce", необходимо убедиться, что проблема всё ещё существует, а также в том, что шаги её достижения были описаны верно.
После верификации баг отправляется менеджеру отдела тестирования в статусе "To Be Closed". Менеджер принимает решение о финальном закрытии или незакрытии данной ошибки

Описанный процесс в теории тестирования называется жизненным циклом бага. Весь жизненный цикл ошибки отражается в багтрэкинговых системах, в последствие позволяющий накопить статистику по ошибкам, провести их анализ и сделать соответствующие выводы. Стоит также отметить, что при занесении бага в систему отслеживания жизненного цикла, одним из свойств новой записи становится приоритет данного бага, который может измениться в процессе эволюционирования этой записи. Стандартно выделяют четыре приоритета: Low, Medium, High и Critical. Имея перед собой статистику по текущему проекту, можно определить критерий выпуска релиза. Обычно, обязательным критерием является отсутствие багов с приоритетами Critical и High на момент сдачи проекта. Отношение к остальным багам сугубо индивидуально для каждой компании. Такие ошибки могут исправляться как внутри текущего релиза, так и в следующих версиях продукта, если того требует рыночная ситуация.

В каждой компании существует свой подход и свои традиции тестировани, продиктованные структурой продукта, взглядами руководства, имеющимися в наличии техническими средствами и т.д. Тем не менее, можно выделить общую часть в той или иной степени, Читать далее →