Home

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

Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.

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

Краткое описание:

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

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

Эти и другие вопросы я постараюсь осветить в своей статье.

Автор: Дмитрий Ручко

Данная статья была подготовлена на основе доклада, сделанного автором на конференции SQA-2 (http://sqa2conf.blogspot.com/) в октябре 2007 года.

Целью данной статьи является желание дать людям верное представление о том, что же такое «автоматизированное тестирование» и с чем его «едят».

Введение

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

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

Автор: Владислав Орликов

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

Сэкономил – значит заработал, – утверждает пословица.

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

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

Автор: Елена Беляева

The paper is devoted to the training program for Software Quality Assurance (SQA) engineer created in Motorola, St.-Petersburg software center to prepare SQA engineers to fulfill their responsibilities. The paper will provide the stages how the training program was formed. We will describe approaches we used for the mentoring program and the effectiveness of the training program.

Авторы: Александров Александр, Галай Анатолий,  Милькова Ясна

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

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

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

Автор: Юрий Горюнов

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

Автор: Новичков Александр

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

Основные вопросы:

• Действительно ли надо проходить сертификацию?
• Что даст сертификация?
• Какие средства инструментальной поддержки выбрать?
• Можем ли мы сами достичь уровня 3?

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

С чего начинать внедрение изменений в работу компаний или подразделений по разработке информационных систем: с выбора инструмента или адаптации методологии?

Чем универсальнее система или инструмент и чем выше требования к её конфигурированию под потребности конкретного процесса, тем сложнее отталкиваться от Инструмента как от Решения, которое предлагает ответы в вопросах методологии.

Автор: James Bach

Перевод: С.Гольдберг (републикация www.bcc.ru)

Известно, что SEI (Software Engineering Institute in Carnegie Mellon University) основан Министерством Обороны США, чтобы управляться с десятками миллионов долларов ежегодно. Обитатели SEI — знатоки официальных военных процессов, и имеют ресурсы для оповещения мира о своей деятельности. Еще известно, что CMM (Capability Maturity Model) — это широкий и более глубокий набор утверждений, составляющих хорошую практику разработки ПО. Резонно спросить, откуда эти утверждения пришли и действительно ли они полны и корректны.

Автор: Alistair Cockburn

Перевод: Перевод: К. и А. Максимовы, maxkir.com

Как только мы пытаемся разобраться, «из чего же состоит методология», сразу становится понятно, что методологий должно быть много. При этом для каждого конкретного проекта «оптимальной» будет одна какая-то методология. Более того, все люди обладают разными склонностями, которые обусловлены их жизненным опытом, страхами и принципами. При выборе методологии особое внимание нужно уделять трем основным факторам: размеру команды разработчиков, критичности проекта для компании и его приоритетности. Помимо этого, на результат будут оказывать влияние как культурные ценности команды, так и индивидуальные характеристики ее членов. В этой статье описаны структура и опыт использования этих принципов в проектных разработках.