Рассмотрим с точки зрения производительности варианты размещения логики по заполнению модели для трёх-уровневой и четырёх-уровневой архитектур при использовании различных технологий взаимодействия между уровнями на стеке .NET (Web API, Web API OData, WCF net.tcp, WCF Data Services).
Привет!
Приглашаем всех разработчиков, тестировщиков, мобильных разработчиков, дизайнеров и менеджеров разработки на супер it-событие весны — 8 апреля в Екатеринбурге пройдет шестая конференция DUMP. Доклады будут идти в 7 секциях: FrontTalks, Serverside, Mobile, Web-design, DevOps, Тестирование, Management.
Мы доделываем итоговую сетку и обговариваем детали последних докладов, но 80% программы готово. Билет сейчас стоит 4500 рублей, но уже через неделю будет дороже.
Welcome!
Читать полностью »
Добрый день!
Меня зовут Евгений, я руководитель тестирования облачных решений Acronis, и я хочу рассказать вам о том, как у нас всё это устроено.
Вообще, QA — это почти как КГБ: нас не всегда видно, но мы есть везде. Мы участвуем в процессах, начиная с самых ранних этапов, когда ещё идёт обсуждение техтребований, их доработка, черновое прототипирование фич. QA не имеет права голоса, но обязательно объясняет девлиду и программ-менеджеру багоопасные места на основе своего опыта. И, как правило, это объяснение влияет на требования к фиче.
Первый этап: дизайнер, который рисовал фичу в интерфейсе, разработчик, ПМ и QA садятся в одной комнате и Читать полностью »
Несколько лет занимаюсь программированием баз данных и столько же вижу как непросто идет тестирование функционала, реализованного в самой базе. Такая задача требует от тестировщика не только знаний SQL, но, порой, и понимания тонкостей работы тестируемого функционала. А разработчики не всегда стремятся описать свое решение во всех деталях.
Стало интересно — как сейчас тестируется логика базы данных.Читать полностью »
Конференция по тестированию программных систем QA: Conference начнется чуть больше чем через месяц и мы готовы рассказать подробнее про нее. Немного статистики:
Какие темы будут раскрыты:
Итак, докладчики, о которых мы расскажем сегодня:
Хотите подробностей? Заходите под кат.
Читать полностью »
«Когда я только начинала работать в этой сфере, все это было для нас как Дикий Запад — мы были первооткрывателями неизведанных земель. Никто нас ничему не учил» Маргарет Гамильтон.
Это Маргарет. Она пишет код хорошо. Делайте как Маргарет.
А еще:
Под руководством Маргарет Гамильтон писались программы для бортового компьютера КА Аполлон. В один из самых ответственных моментов миссии Аполлон 11 именно работа Маргарет и ее команды предотвратила возможный срыв высадки на Луну. За три минуты до прилунения сработало несколько аварийных сигнальных устройств. Компьютер был перегруженн входящими данными – в стыковочной радарной системе произошло непроизвольное обновление счетчика, что привело к запросу на выполнение компьютером большего числа операций, чем он был способен обработать. Благодаря устойчивой архитектуре компьютер продолжил свою работу: в разработке бортового ПО использовался подход асинхронного исполнения (asynchronous executive). Процессы с высоким приоритетом (критичные для прилунения) могли прервать низкоприоритетные процессы.
«После расстыковки командно-служебного и лунного модулей выключатель радара стыковки был поставлен в неправильное положение из-за ошибки в инструкции для астронавтов, радар посылал ошибочные сигналы бортовому компьютеру. Обработка ложных сигналов занимала 15% машинного времени. Бортовой компьютер (точнее, вшитое в него ПО) оказался достаточно разумным для того, чтобы распознать, что на выполнение запрашивается больше операций, чем должно. Далее он выслал оповещение, означавшее для астронавта следующее: «Я перегружен бОльшим количеством задач единовременно, чем предусмотрено, и я продолжу выполнять только наиболее важные, то есть те, что необходимы для прилунения...» По сути, компьютер был запрограммирован на большее, чем просто распознавание ошибочных состояний. В ПО был предусмотрен полный набор программ по восстановлению. В данном конкретном случае реакцией ПО было приостановить работу низкоприоритетных задач и перезапустить (re-establish) наиболее важные. Если бы компьютер не распознал эту проблему и не принял восстановительные меры, я не уверена, что Аполлон 11 совершил бы успешную посадку на Луну.» Маргарет Гамильтон
«Девушка молоток!
Но я бы не хотел себе такую жену, ибо смотрелся бы на ее фоне жалко, хоть и программист… LOL»
Коммент с GeekTimes
18 февраля в Москве, мы традиционно провели нашу ежегодную конференцию по решениям Microsoft в области управления жизненным циклом разработки программного обеспечения. В этом году ALM Summit состояла из основного трека и круглых столов, на которых были затронуты следующие тематические направления:
Как обычно, мы транслируем и записываем конференцию.
И рады сообщить, что записи доступны для просмотра!
Читать полностью »
Waterfall
Заказчик сообщает, что хочет блинов. Компания выделяет проджект менеджера, который говорит: «Говно вопрос! Наша компания специализируется по производству блинов! Мы сделаем вам офигенских блинов за две тысячи человеко-часов!»
Далее начинается аналитическая фаза. Бизнес-аналитик берет эксперта, и они денно и нощно заседают в офисе заказчика, потребляют халявный кофе и пончики, а также тщательно записывают бизнес-требования вплоть до толщины блинной корочки с точностью до микрона. Документы записываются на фирменных бланках компании, после чего заверяются подписью директора компании-заказчика, директора компании-исполнителя, стороннего консультанта по блинному производству, а также печатью Папы Римского. После окончания аналитической фазы на проект остается 1000 часов.
Продолжаем нашу серию заметок по статическому анализатору кода Kiuwan.
Данный класс инструментов исследует текст программ на предмет выявления в них каких-то известных шаблонов уязвимостей, ошибок, неточностей, неэффективных действий и многого другого. Откуда берутся эти шаблоны, мы писали в прошлый раз. Для каждого языка программирования эти шаблоны будут свои в силу понятных отличий в синтаксисе, но будут и общие правила качественного кода, типа избегать использования повторяющихся блоков кода.
Однако, не всегда этих шаблонов и правил хватает для оценки определенных качеств написанной программы. В каждом конкретном случае может понадобиться свой определяющий параметр. Например, нам важно убедиться, нет ли в написанной банковской программе скрытых транзакций копеечек на чей-нибудь счет. Или проверить, что не используются никакие недопустимые внешние библиотеки. В этом случае, нам просто необходимо иметь возможность заставить анализатор проверять не только штатные шаблоны, но и наши дополнительные правила.
Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.
Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).
Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.
Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.
Читать полностью »
