А картинки у всех отсутствуют на этом сайте или только у меня?

Вот уж действительно, "Страшная правда о юзабилити"!
Нарочно не придумаешь. :)

В общем, опять тестировщики не могут найти общий язык с разработчиками. :)

А виноват, как обычно, тот, кто организует процесс.

Медленно работает сервис? Значит нужно купить ещё один мощный сервер, чтобы программа работала быстро... Иногда это оправдывается тем, что дешевле купить сервер, чем оплачивать много-много часов рабочего времени разработчика, который оптимизирует свое, ранее написанное медленное поделие. Так почему бы не писать быстро сразу?

Потому что писать быстро сразу тоже может оказаться дороже, чем купить новый сервер.

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

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

Для того чтобы начать думать над быстродействием своей программы разработчик сначала должен понять, что его программа работает медленно. Запуская программу на быстром сервере он никогда этого не поймет.

Так у вас ведь есть тестовый сервер, на котором вы обнаружили проблему! Посадите возле него разработчика, пусть попользуется и поймёт.
Низкая производительность - это только одна из проблем. Дав разработчику медленное оборудование, вы действительно забудете об этой проблеме, потому что её заслонит куча других.

Ага, запустил компилятор и ушёл курить. Вернулся, исправил ошибку, и опять курить. А тут, глядишь, и рабочий день закончился. Мне так приходилось работать одно время (правда, я не курю, приходилось чай пить с девочками).

У разработчика должна достаточно быстрая рабочая станция, чтобы не тормозила разработку. А ещё у него должны быть чёткие требования к производительности до начала проектирования.

А ещё у компании должен быть тестировщик с отдельным сервером, позволяющим эти требования проверить.

Это уже давно не философский вопрос, а организационный.

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

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

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

Замедление разработки.
Пропущенные разработчиком баги из-за удлинения итерации (не командной, а личной итерации разработчика).
"Оптимизация" тех частей, которые в реальности оптимизировать не надо.
Уход разработчика из-за невыносимых условий работы, наконец. :)


Архитектура программы (в той части, которая определяет производительность) должна разрабатываться исходя из тех условий, в которых эту программу предполагается эксплуатировать. А не из условий, которые есть на столе у программиста.

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

Разработчик, передавая сервис на нагрузочные тесты, понятия не имеет быстрый он сервис написал или медленный. И нам (нагрузочному тестированию), приходится открывать глаза разработчику.

А должен бы знать. Если требования по производительности сформулированы сразу, то она должна быть заложена ещё на этапе проектирования.
Если требований нет, то и спроса с разработчика быть не может.

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

Я не уверен, что "оптимизация на ходу" - это вообще оптимизация. Над оптимизацией производительности нужно очень хорошо думать вперёд, а не задним числом.

УРАААА!!!!! Есть еще люди со сходными проблемами!!!!!!

А я по наивности думал, что эта проблема осталась далеко в прошлом. И даже, может быть (позволял я себе мечтать), этому уже учат в университетах - в смысле тому, что средство управления версиями такой же неотъемлемый инструмент разработки, как текстовый редактор или компилятор. (Хотя о чём это я... сейчас же навострились на интерпретаторах всё писать.)

Уговорить упрямого разработчика использовать VCS очень трудно. Нужно применять к нему (к ней) административное правило: чего нет в репозитории, того не существует. Использовать по максимуму административный ресурс (боже, неужели это я пишу?), не брезгуя даже ударами ниже пояса, намекая лично разработчику на его профессиональный уровень.

Короче. Не хочешь использовать контроль версий - вон из профессии!

Слишком общее описание ситуации, трудно определить, кто кому и что должен.

Но в общем случае, если у вас есть ТЗ и договор, а в них ничего не сказано об особенностях реализации, то об этом и надо говорить с заказчиком.

Должен ли Разработчик согласовывать детали технического решения с Заказчиком?

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

Имеет ли право Заказчик потребовать это на заключительной стадии?

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

Неужели такое бывает в регламенте взаимодействия?

Если такие регламенты где-то и существуют, то они не работают.

Нет, не все зануды.

Некоторые - гении.

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

А какой стиль изложения вы предпочитаете? Вам нужны инструкции о том, какими техниками, приёмами и инструментами пользоваться? Или что-то более философски-концептуальное?

Если нужны инструкции, можно начать с книги Глеба Архангельского Тайм-драйв: Как успевать жить и работать. Это что-то вроде карманного справочника.

Чуть более подробно принципы тайм-менеджмента "разжёваны" в книгах Джулии Моргенстерн, например, этой: Тайм-менеджмент. Искусство планирования и управления своим временем.

Если же хочется чего-то философского, то можно почитать Стивена Кови, например Главное внимание - главным вещам. Но до неё нужно дозреть imho.

Всем привет.

Заранее извиняюсь если не в тот раздел или подобная тема уже есть, найти не удалось.

Более двух лет тружусь бизнес аналитиком в банке. Однако никаких стандартных средств (стандартов описания, проектирования и даже средств разработки документации) мы не используем. Хотлесь бы как-то самому образовываться в данной области. Коллеги, с чего посоветуете начать? Какой курс пройти? Может есть какой-то обзорный курс для так сказать наччинающих аналитиков?

Список литературы опубликован в блоге Дениса Бескова.
http://system-analys...alystbookshelf/

Курсы и вебинары для аналитиков проводит, например, УЦ Luxoft, но они по-моему "заточены" под Rational Unified Process.
http://luxoft-traini...ning/school/70/

Задайте этот вопрос на форуме Сообщества аналитиков. Там и курсы подскажут, и инструменты посоветуют, и опытом поделятся. А может быть, вас заинтересуют видеозаписи с семинаров Сообщества.

Получил этот текст сегодня через МойКруг с комментарием "предложили обратиться к Вам".

Это что, новый подход к тестированию? Раскрути спецов на халявную работу?
Или всё тот же старый способ выполнения тестовых заданий, полученных на собеседовании?

Бедный notepad, сколько можно его тестировать. Неужели у рекрутеров такая бедная фантазия? :)

А как можно на конференции поделиться ссылкой на свой профайл?

Например, после Летнего Аналитического Фестиваля я привёз пачку визиток, и потом потратил полдня, разыскивая и устанавливая контакт с этими людьми в соцсетях. (Кстати, нашёл далеко не всех.)

Ну вот, а я всю жизнь был уверен, что SDLC - это протокол канального уровня. Понаплодили сокращений...

Классно придумано!

Может на Хабре стоит попиариться? Сказать мол есть такой проект классный и бесплатный. Нужна мол дизайнерская мысль и рука для логотипа.
Заодно и пользователей прибавится и устойчивость сайта можно проверить :)

Да, кстати, легенду по цветам хотел узнать - что-то желтое, что-то оранжевое.

Не надо пока на хабре. Хаброэффекта сайт не выдержит, кэширование ещё не дописано.
Цвета кислотные, сам знаю. Зато все из таблицы "безопасных цветов". :)

Сайт очень удобный, наглядный и полезный, и да, большое за него спасибо!

Только непонятно, почему, если верить карте, все вебинары проводятся в Сыктывкаре? :)

А где на карте должен быть Интернет? :)

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

Спасибо! Кстати, на страницах учебных центров появилась кнопочка "рекомендовать" для facebook:
http://www.it-map.ru...testing-ru.html

Кстати, на сайте it-map.ru появилась карта. Теперь название домена стало осмысленным.

Вот, например, карта тренингов Software-Testing:
http://www.it-map.ru...testing-ru.html

Вот логотип для сайта я никак не придумаю. Так и висит черновой вариант.

Испытайте сами на своём компьютере и убедитесь как близко математическое ожидание к середине

А что, функция RAND возвращает случайное число?
Или всё-таки псевдослучайное? ;)

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

Да не будут (и не должны) они обращать на это внимания. Эти моменты важны для вас, а не для заказчика. Заказчик не обязан вникать во внутреннее устройство системы. И не "на функционале" системы он зациклен, а на своих проблемах, которые система должна ему решить.

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

Ваши комментарии?

Просто праздник какой-то. :)

А какие проблемы вообще должна решать "система автоматизации бизнеса"? Может, дело в том, что внедряемая система просто не решает этих проблем, а не в наличии SOA и API?

Гхм, Вы не согласны, что система обязана быть модифицируемой и масштабируемой, чтобы смогла просуществовать долгое время в организации.

Вообще говоря, не обязана.

Многие думают, что достаточно получить ТЗ на систему и сделать все как написано в этом ТЗ. Но требования со временем меняются и системы устаревают...

Значит, ТЗ плохое.
Хотя получить хорошее ТЗ действительно невозможно, его можно только разработать совместно с заказчиком. :)

"Током бьёт" и "два раза обжёгся" - это, скорее, недостаток требований к безопасности (2.6.1.5).

Но начинать нужно с самого начала, зреть в корень, так сказать. Где характеристика объекта автоматизации?

Читать ГОСТы, несомненно, полезно и забавно. Но какой раздел ГОСТа помог бы нам справиться вот с этой характеристикой:
Невкусно

Кстати, для тех, кто не понял, речь идёт вот об этом слайдкасте:
http://blogs.uml2.ru...t-Kak-Slaydkast


Фрося, раз уж сегодня пятница - может, зарегистрируетесь в блоге Сообщества и разместите это комментарий там?

Прежде чем делать далеко идущие выводы, не мешает заглянуть в первоисточник. :)

Заражен вредоносным кодом не сам фотоаппарат, а карта памяти, которая идет с ним в комплекте. Активация вируса происходит после подключения Olympus µ Tough 6010 к компьютеру. К каким последствиям приведет заражение ПК этим вирусом, не сообщается.

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