Home

Перевод: Алексей Лемешко

Источник: Steve McConnell, Construx Software Builders, P.O. Box 6922, Bellevue, WA 98008.
E-mail: stevemcc@construx.com — WWW: http://www.construx.com/stevemcc/

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

Автор: Сергей Юдин

Опубликовано с согласия www.phpinside.ru

С момента проведения конференции в Киеве в мае 2005 года прошло достаточно много времени. Тогда мы (я и Павел Щеваев) постарались приложить максимум усилий для популяризации идеи TDD среди PHP-разработчиков. За время после конференции мы намного продвинулись вперед в плане TDD, и взгляд на некоторые вещи у нас изменился. Я признаю, что мой доклад на тему «Целесообразность модульных тестов» получился немного однобоким. Вообще на конференции было очень много сказано о плюсах тестирования, как здорово тесты помогают в разработке и рефакторинге, в профессиональном развитии программистов, но слишком мало – о минусах. О минусах и очень больших минусах тестирования, которые могут проявиться, если трактовать и использовать TDD неправильно.

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

Автор: Артём Ваулин

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

Существует множество различных способов для достижения этих целей. В рамках же данного монолога хотелось бы немного поговорить о КАЧЕСТВЕ. Не о каком-то абстрактном качестве из Большой Советской Энциклопедии (или из Модных Западных Стандартов), а о том реальном КАЧЕСТВЕ производимых, разрабатываемых и внедряемых нами продуктов и услуг, которое позволяет сделать эти самые продукты и услуги лучшими и, как следствие, приближает нас к заветным целям.

Автор: Панкратов Вячеслав

Классификация задач и ролей в тестировании, основанная на методологии RUP.

Вокруг ролей и задач, связанных с тестированием и обеспечением качества, сложилось несколько противоположных идейных течений, которые усердно культивируются носителями этих идей. Точки зрения во многом противоположны, во многом противоречивы. Тестирование видится с одной стороны каким-то полумеханическим процессом, который не требует особенной квалификации: тестировщика видят эдаким «кликальщиком», который просто гоняет приложение, ждёт пока оно «упадёт», потом радостно сообщает об ошибке и продолжает в том же духе. В последнее время, надо отдать должное, появляются материалы о тестировании и качестве, выходят в свет книги, развиваются сайты посвящённые этому направлению — это направление мысли постепенно сходит на «нет». С другой точки зрения, которую, наверное, культивируют отчасти и сами тестировщики (в самом широком смысле этого слова), тестирование — это процесс, покрытый множеством неопределённостей, трудно формализируемый и поддающийся оценкам. Если же к тестированию добавить автоматизацию, которая по оценкам тех, кто внедрял инструменты и решения для тестирования, требует больших (по сравнению с ручным тестированием) трудозатрат и говорить об оценке качества продукта, направление тестирования получается совсем непрозрачным для стороннего наблюдателя, а порой и для самих тестировщиков и QA.

Автор: Максим Уваров

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

Источник: журнал BetterSoftware (October 2005)
Перевод: Артём Ваулин

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

Автор: Гринкевич Сергей

Оригинальная публикация

Что такое Web-логи?

Любой пользователь, работающий с Интернет приложением, подвергается постоянному наблюдению. За ним следит не только ФСБ (для тех, кто занервничал, читая эти строки, поясняю - это шутка), но и многие участники Глобальной паутины. Это не люди, а электронные компоненты виртуального пространства. И их великое множество. «Стада» совершенно различных серверов, прокси, фаерволов, коммутаторов, маршрутизаторов и т.п. Везде, где вы побывали, остаются «следы» вашего присутствия. Не исключение и Web-сервер на котором работает ваше Web-приложение.

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

Источник: журнал BetterSoftware (October 2005)
Перевод: Артём Ваулин

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

Автор: Вячеслав Панкратов

Материал впервые опубликован в журнале «Открытые Системы» #02/2007

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

Автор: Андрей Грищенко

Источник публикации: DFT.RU

Менеджер внешних проектов отдела игровых и мультимедийных продуктов фирмы «1С», рассуждает о том как делаются игровые проекты.

Статья рассказывает о разных подходах к созданию программных проектов («каскад», RUP, MSF, экстремальное программирование), а также сравнивает разработку игр с созданием «обычного» ПО и кинофильмов.

Итак, больной вопрос: что же мы делаем — хорошо продаваемый продукт, товар, или мы делаем игру своей мечты?

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

Итак, делаем хорошие игры!

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

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