Разработка мероприятий по повышению конкурентоспособности продукции СП ЗАО "НаучСофт"

В прочие расходам относятся покупка лицензионных программ, техническое обслуживание абонентской цифровой линии, тарифицируемый доступ в сеть Интернет и т.д. Прочие производственные расходы также возросли, особенно в 2008 году - на 17,085 млн. р. по сравнению с 2007 годом. Такое увеличение расходов тесно связано с общехозяйственными расходами.

Затраты на 1 рубль товарной продукции составили 0,475 р., 0,777 ., 0,699 соответственно с 2006 года по 2008 год, что говорит о нестабильности затрат на производство. Резкий скачок которого произошел в 2007 году, а если сравнивать с 2008 годом - то затраты изменились не значительно. Но в любом случаи затраты на производство не превышают планируемой выручки от реализации.

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

Динамика структуры себестоимости за период 2006-2008 года отражена на рисунке 2.

2006г.

2007г.

2008г.

Рисунок 2 - Динамика структуры себестоимости за 2006-2008 гг.

Из рисунка 2 видно, что основная доля затрат приходится на основную заработную плату (не менее 46). В 2006 г. его доля в себестоимости продукции составляла 52%, в 2007 г. - 46%, в 2008 г. - 54%. Высокий процент затрат по данной статье обусловлен специализацией организации - разработкой программного обеспечения на заказ, а для этого необходимы квалифицированные специалисты, труд которых оценивается высоко. Компания является социально направленной.

Высокий процент составляют общехозяйственные расходы (2006 г. - 17%, 2007 г. - 30%, 2008 г. - 21%), что связано, как было указано выше, с улучшением условий труда и закупкой оборудования. Дело в том, что стоимость компьютеров и комплектующих для организации также учитывается в общехозяйственные расходы, что доказывают цифры, представленные выше.

Доля налогов меняется в зависимости от доли затрат на основную заработную плату. Таким образом, при повышении затрат по данному элементу приводит к повышению налога соответственно (2006 г. - 19%, 2007 г. - 17%, 2008 г. - 19%).

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

2.2.3 Структура численности рабочих

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

Профессионально-должностной состав работников компании отражен в таблице 2.2.1

Таблица 2.6 - Профессионально-должностной состав компании СП ЗАО «НаучСофт»

Наименование показателя	2006г., чел.	Уд. вес, %	2007г., чел.	Уд. вес, %	2008г., чел.	Уд. вес, %
Административно-управленческий персонал	10	8,33	10	6,67	12	5,7
Инженеры-программисты	80	66,67	103	68,67	145	69
Менеджеры по продажам	2	1,67	2	1,33	4	1,9
Менеджеры по управлению проектами	10	8,33	15	10	22	10,5
Менеджер по персоналу	3	2,5	4	2,67	6	2,9
Прочий персонал	15	12,5	16	10,66	21	10
Всего списочная численность персонала на конец года	120	100	120	100	210	100

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

Образовательный уровень сотрудников компании очень высокий. 91.5% сотрудников компании имеют высшее образование, в то время как остальные 7.5% имеют незаконченное высшее образование. Возрастной состав сотрудников компании колеблется в промежутке от 21 года до 35 лет.

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

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

2.2.4 Структура заработной платы

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

Важным документом является трудовой договор, который заключается только в письменной форме в двух экземплярах (нанимателю и работнику). Согласно трудовому договору оплата труда сотрудников СП ЗАО «НаучСофт» производится на основе должностных окладов, в зависимости от выполняемых работ (занимаемых должностей). Отнесение выполняемых работ к определенным должностям осуществляется с помощью Единого тарифно-квалификационного справочника должностей руководителей, специалистов и служащих и иными квалификационными справочниками, утвержденными в установленном порядке.

Так как СП ЗАО «НаучСофт» является коммерческой компанией, то государственными актами предусмотрено самостоятельное определение тарифной ставки 1-го разряда. Главным условием при определении тарифной ставки 1-го разряда является установленное государством правило - оклад не должен быть меньше, чем прожиточный минимум.

Тарифная ставка 1-го разряда принята в размере 230 000 руб. Также необходимым условием является определение квалификационного разряда, категории, которая берется из справочника. Для специалистов разной профессии (должности) данный квалификационный разряд варьируется. Тарифные коэффициенты берутся на базе данных квалификационных разрядов из справочных информаций.

В таблице 2.7 приведен расчет месячного фонда заработной платы сотрудников компании СП ЗАО «НаучСофт» проекта IBM (Consul).

Исходя из данных таблицы 2.7, годовой фонд заработной платы сотрудников составляет 64792700 руб. Кроме начисления заработной платы в компании начисляются пособие по больничным листам, пособие на детей до 3-х лет, заработная плата за дни отпуска, расчет компенсации за неиспользованный отпуск при увольнении и др.

2.3 Анализ системы менеджмента качества в компании СП ЗАО «НаучСофт»

2.3.1 Принципы обеспечения качества

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

Концепция обеспечения качества ПО основывается в «НаучСофт» на внутренних показателях качества, мировом опыте создания качественного ПО и стандартах серии ИСО 9000, и направлена на то, чтобы помочь НаучСофт использовать системный подход к качеству.

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

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

Таблица 2.7 - Месячный фонд заработной платы

Наименование показателя	квалифика-ционный разряд	тарифный коэффициент	тарифная ставка 1-го разряда, руб.	Количество человек	Должностной оклад, р.	Выплаты по действующему премиальному положению	Месячный фонд заработной платы, р.
						%	Сумма, р.
административно-управленческий персонал	15	3,48	350000	2	1218000	40	487200	3410400
инженеры-программисты	11	2,65	350000	30	927500	40	371000	38955000
менеджеры по продажам	11	2,65	350000	1	927500	40	371000	12985000
менеджеры по управлению подпроектами	12	2,84	350000	8	994000	40	397600	11132800
менеджер по персоналу	13	3,04	350000	1	1064000	40	425600	1489600
прочий персонал	8	2,17	350000	8	759500	40	303800	8506400
Итого:				50				64792700

Концепция обеспечения качества НаучСофт использует следующие основные принципы обеспечения качества:

а) Качество базовой версии на 99% закладывается в процессе написания требований, проектирования, тестирования, т.е. в процессе разработки ПО. Конфигурация ПО может существенно изменяться в процессе эксплуатации. Поэтому для обеспечения гарантий качества осуществляется контроль конфигурации ПО в течение всего его жизненного цикла.

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

в) Учитывая интеллектуальный характер проектирования и разработки ПО, СМК ориентируется прежде всего на стимулирование заинтересованности разработчиков в обеспечении высокого качества ПО и повышении своего профессионального уровня.

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

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

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

- постоянно совершенствовать и повышать результативность системы менеджмента качества (СМК) НаучСофт, соответствующей требованиям стандарта ISO 9001:2000;

- разрабатывать конкурентоспособную продукцию, соответствующую требованиям настоящих и потенциальных заказчиков

- определять стратегические цели и подтверждать приверженность качеству личным примером и участием в обеспечении функционирования СМК

- вовлекать всех работников в постоянное улучшение своей деятельности

- принимать и использовать Систему Стандартных Процессов, регулирующих всю деятельность НаучСофт

- принимать решения на основе объективных данных и информации

- развивать взаимовыгодное сотрудничество с поставщиками.

В «НаучСофт» разработана, документально оформлена, внедрена и поддерживается в рабочем состоянии система менеджмента качества, в соответствии с описанием в настоящем документе для обеспечения выполнения требований заказчиков и достижения соответствия с требованиями СТБ ИСО 9001-2001 и DIN EN ISO 9001:2000 (TGA). Постоянно в соответствии с процедурой SOP-8511 проводятся мероприятия по повышению ее результативности. Своей деятельностью предприятие демонстрирует способность постоянно обеспечивать выпуск продукции, которая соответствует требованиям потребителя и законодательным требованиям, и подтверждает возможность удовлетворить потребителя.

В соответствии с требованиями СТБ ИСО 9001-2001 и DIN EN ISO 9001:2000 (TGA) в «НаучСофт»:

- определены необходимые процессы системы менеджмента качества на предприятии (их последовательность и взаимодействие указаны в приложении В. Управление процессами осуществляется не только в отношении процесса разработки ПО, но по отношению ко всем процессам, необходимым СМК.;

- разработаны, утверждены и внедрены обязательные документированные процедуры, описывающие конкретные процессы и способы деятельности (перечень процедур и методик СМК приведен в приложении Б);

- в Программе качества утверждены конкретные цели в области качества предприятия и подразделений на заседании ЭСК в соответствии с процедурой SOP-8511 и необходимые ресурсы и информация для обеспечения функционирования и мониторинга процессов, определены критерии оценки результативности процессов и методы достижения запланированных результатов;

- мониторинг, измерение и анализ процессов проводятся в соответствии с требованиями процедур и требованиями раздела 8.2.4 данного Руководства по качеству;

- проводится анализ результативности всех видов деятельности предприятия на основании процедуры SOP-8511, с учетом утвержденной Политики в области качества, показателей и целей в области качества;

Все документы системы менеджмента качества «НаучСофт» являются доступными для всего персонала. Предприятие не передает сторонним организациям выполнение какого-либо процесса, влияющего на соответствие продукции требованиям. Компания «НаучСофт» разработала серию документированных процедур СМК, которые соответствуют требованиям СТБ ИСО 9001 и DIN EN ISO 9001:2000 (TGA). Подробность описания процедур зависит от профессионализма сотрудников, вовлеченных в связанную с СМК работу, сложность этой работы, а также методы, используемые для ее выполнения.

Комплект документов системы менеджмента качества «НаучСофт» согласован с основными потребителями и применяется для установления и доведения до работников требований, методов системы менеджмента качества. Он включает в себя:

- политику и цели в области качества;

- руководство по качеству;

- документированные процедуры (см. документы перечисленные в приложение Б);

- положения о подразделениях, должностные инструкции;

- техническую документацию, нормативные документы и инструкции;

- записи по качеству.

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

Требования к процессу разработки ПО определяются процедурами разработки для того, чтобы процесс соответствовал СТБ ИСО 9001, а также принципам качественной разработки ПО, принятым в «НаучСофт».

Права и обязанности персонала «НаучСофт», требования к квалификации персонала, а также взаимодействие между персоналом определяются должностными инструкциями.

Управление документацией

Вся документация, используемая в «НаучСофт», должна проходить идентификацию и актуализацию. Руководители подразделений и процессов обеспечивают:

- проведение проверки документов СМК на адекватность, включая проверку на адекватность требованиям ISO 9001 до их выпуска, последующий анализ и актуализацию по мере необходимости;

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

- идентификацию документов и управление их рассылкой.

Руководители подразделений и процессов несут ответственность за ведение и управление всеми записями, ведущимися в подразделениях и процессах. Информацию о необходимости актуализации документов руководители процессов и подразделений получают:

- по результатам внутренних аудитов, отчетов о выявленных несоответствиях документации (для документов предприятия), по результатам внешних аудитов,

- из решения ЭСК;

- от соответствующих организаций (для документов внешнего происхождения).

Требования к управлению документами относятся ко всем отделам НаучСофт. Контроль разработки, своевременной актуализации и выполнения требований к СМК и требований нормативных документов выполняется представителем руководства по качеству. Управление документацией включает:

- планирование разработки\актуализации документов;

- разработку документов;

- обеспечение адекватности документов и внесение изменений;

- согласование документов;

- утверждение документов;

- учет и публикацию документов;

- хранение документов;

- отмена и изъятие документов;

Структура документации СМК компании предоставлена на рисунке 3.



Рисунок 3 - Структура документации СМК

2.3.3 Ориентация на заказчика

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

При получении от заказчика запроса о проведении работ проводится анализ требований заказчика, при проведении которого обеспечивается:

- адекватное определение и документирование требований заказчика,

- устранение любых различий между требованиями заказчика и возможностями «НаучСофт» выполнять контракт,

- согласование с заказчиком всех спорных и неясных вопросов.

Анализ контракта на разработку и передачу в собственность ПО проводится руководителем проекта. После уточнения всех требований заказчика и устранения разногласий «НаучСофт» готовит проект (техническое задание). Для проведения разработки и передачи в собственность ПО необходимо заключение контракта. Контракт анализируется ответственным менеджером по маркетингу.

Генеральный директор утверждает техническое задание после того, как контракт согласован с заказчиком и ответственным персоналом «НаучСофт». Утвержденный контракт передается заказчику для утверждения. Последовательность выполнения анализа требований заказчика к разработке ПО определяется в SOP-5201, Ориентация на заказчика.

2.3.4 Политика в области качества

Политика «НаучСофт» в области качества разработана руководством предприятия и является основой для постановки целей в области качества, обязывает постоянно совершенствовать и повышать результативность системы менеджмента качества «НаучСофт». Политика обсуждена и одобрена на заседании ЭСК. Политика в области качества согласована с целями компании и направлена на удовлетворение требований и ожиданий заказчиков. Представитель руководства по качеству отвечает за:

- обеспечение понимания сотрудниками политики в области качества,

- проведение ее в жизнь на всех уровнях компании.

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

Руководители всех уровней отвечают за реализацию конкретных целей, установленных в политике. Выполнение политики проверяется при внутреннем аудите СМК.

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

Цели в области качества определяются, исходя из Политики в области качества «НаучСофт». Руководство предприятия обеспечивает, чтобы цели в области качества были измеримыми, включая цели, относящиеся к продукции.

Цели в области качества «НаучСофт» на конкретный год утверждаются на заседании ЭСК, оформляются приложением к протоколу ЭСК и доводятся до персонала предприятия. Достижение поставленных целей направлено на:

- завоевание лидирующих позиций в области разработки ПО;

- соответствие системы менеджмента качества требованиям стандарта ISO 9001:2000;

- выпуск качественной конкурентоспособной продукции и поставку ее потребителю в установленные сроки.

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

2.3.5 Планирование развития СМК

Планы совершенствования СМК (Программа качества) разрабатываются на основе проведения анализов функционирования СМК со стороны руководства, предложений руководителей процессов и подразделений и разработанных целей в области качества, проектных планов.

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

При разработке новых документов системы менеджмента качества (либо при внесении изменений в действующие документы) проверяется их соответствие целям предприятия в области качества и осуществляется анализ взаимосвязей процессов и документов между собой, что гарантирует сохранение целостности системы менеджмента качества. Все документы СМК обязательно рассматриваются менеджером процессов и членами ЭСК. Разрабатываются также следующие документы:

- программа социального развития «НаучСофт»,

- программа по качеству,

- план и программа внутренних проверок качества,

- план подготовки персонала и т.д.

Программа социального развития составляется раз в год заместителем генерального директора по общим вопросам, утверждается генеральным директором и содержит основные направления развития социальной сферы «НаучСофт» (создание комфортных условий труда для сотрудников, организация оздоровительного отдыха сотрудников и т.д.).

Годовая программа по качеству ежегодно составляется Советом по качеству (работу координирует директор по качеству) на основании запланированных Целей Компании на данный год. Программа по качеству утверждается генеральным директором.

2.3.6 Управление качеством и постоянным улучшением

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

- является частью политики в области качества,

- отражено в целях в области качества,

- является частью действий, предпринимаемых по результатам проверок,

- стимулируется возможностями, выявленными в ходе анализа данных,

- является результатом корректирующих действий, когда предпринятые действия исправляют новую проблему,

- всегда является результатом предупреждающих действий,

- необходимый результат анализа со стороны руководства.

Корректирующие действия применяются для предотвращения повторного возникновения несоответствий. Процесс использования корректирующих действий для решения проблем описан. Описание включает руководство по:

- анализу несоответствий, включая жалобы заказчиков

- определению причины несоответствий

- оценке необходимости в корректирующих действиях для предотвращения повторного возникновения несоответствия

- определению необходимых корректирующих действий

- выполнению корректирующих действий

- регистрации выполнения корректирующих действий в соответствии с SOP-4241,

- верификации результативности предпринятых корректирующих действий

Корректирующие и предупреждающие действия применяются в «НаучСофт» для устранения причин выявленных и потенциальных несоответствий. Требования к идентификации, изучению и устранению причин, а также анализу результативности выполненных корректирующих и предупреждающих действий относятся ко всем отделам «НаучСофт».

Генеральный директор и технический директор анализируют результативность корректирующих и предупреждающих действий. Руководители проектов анализируют и устраняют причины выявленных и потенциальных несоответствий в своих проектах. Корректирующие и предупреждающие действия могут быть инициированы:

- отчетами о результатах внутренних аудитов качества,

- информацией о рекламациях и предложениях заказчиков,

- отчетами о результатах внешних аудитов,

- материалами заседаний Экспертного совета по качеству,

- результатами анализа эффективности СМК,

- результатами анализа проектов на разных этапах разработки.

Для устранения несоответствий, выявленных в ходе внутренних аудитов качества, руководитель проверяемого отдела готовит план корректирующих действий или определяет корректирующие действия в протоколе о несоответствиях. По результатам корректирующих действий представитель руководства готовит информацию об устранении несоответствий, выявленных в ходе внутренних аудитов качества и посылает информацию руководителям «НаучСофт» для анализа.

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

Результаты проверок деятельности «НаучСофт» второй стороной (заказчиком) и третьей стороной (органом по сертификации), а также совместных проверок с «НаучСофт» оформляются в виде отчетов. Для устранения выявленных в результате этих проверок несоответствий в базе данных «Аудит» руководителями подразделений, в деятельности которых обнаружены несоответствия, составляется план корректирующих мероприятий.

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

3. Направления повышения конкурентоспособности продукции СП ЗАО «НаучСофт» и оценка ее эффективности

3.1 Предпосылки для оптимизации тестирования

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

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

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

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

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

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

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

Проект IBM (Consul) компании «НаучСофт» разрабатывает, тестирует и проводим последующую техническую поддержку сложного программного продукта, предназначенного для обеспечения безопасности корпоративных сетей. Продукт используют различные банки западных стран, поэтому требования к качеству и надёжности очень высокие. На данный момент разрабатывается новая версия с интеграцией ещё одного продукта по сетевой безопасности. Также продукт будет портирован на иные операционные системы (Linux и Unix). Поэтому уже можно представить объём работа по написанию программного кода и проведению тестирования. Разрабатываемая версия уже содержит около 2000 дефектов. На проекте есть команда тестировщиков, которая в свою очередь разбиты на небольшие под-проекты, которые занимаюся различными видами ручного тестирования отдельных частей программного продукта. Объём работа очень велик, человеческих ресурсов порой не хватает. Поэтому вопрос оптимизации тестирования крайне важен.

3.2 Оптимизация ручного тестирования с помощью программного программного продукта «Rational Manual Tester»

Ручное тестирование по-прежнему является самым популярным методом тестирования программного обеспечения. Тем не менее, ручное тестирование можно улучшить. В данном руководстве будет показано, как с помощью Rational Manual Tester можно оптимизировать документирование ручного тестирования, его выполнение и сбор результатов. Также будет описан процесс оценки возможностей, которые IBM Rational Manual Tester позволяет добавить к проектам ручного тестирования.

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

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

Далее будет описано, как можно использовать IBM Rational Manual Tester для выполнения следующих задач:

- ясного и краткого документирования процесса выполнения ручного тестирования;

- возможности общего использования содержимого тестирования в нескольких тестах;

- помощи проводящим тестирование в выполнении обычных операций, подверженных ошибкам - ввод и проверка данных;

- точного выполнения и записи результатов ручного тестирования.

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

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

Рисунок 4 - Пользовательский интерфейс

В окне Rational Manual Tester имеется пять основных вкладок:

а) в центре находится вкладка Editor. Редактор используется для документирования ручного тестирования. По умолчанию в редакторе открывается файл с именем «untitled.rmt»;

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

в) рядом с вкладкой Outline находится вкладка Recent Files. На этой вкладке отображаются рабочие файлы, что позволяет легко открывать последний использованный тест или его результаты;

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

д) внизу справа расположена вкладка Properties. На ней содержится дополнительная информация о тестировании, отображаемая в редакторе.

Типы операторов тестирования. Ручные тесты могут содержать четыре типа операторов. Каждый тип операторов отмечен значком, расположенным перед оператором в редакторе тестов.

а) Шаг -- Шаг - оператор, выдающий тестировщику инструкции на выполнение какого-либо действия.

б) Точка проверки -- Точка проверки - оператор, выдающий инструкции пользователю проверить определенное поведение тестируемого приложения. Примеры типичных операторов точки проверки: «Убедитесь, что кнопка Login появляется в верхнем правом углу» или «Приложение возвращает дату в формате мм/дд/гг?». При выполнении теста, содержащего точки проверки, необходимо вводить результаты для каждой точки проверки;

в) Точка отчета -- Точка отчета представляет собой точку проверки высокого уровня. Она часто используется для высокоуровневого или сводного запроса об успешном или неуспешном выполнении всего теста;

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

Ускорение запуска процесса создания теста. Существует несколько способов ускорить использование Rational Manual Tester. Если уже имеются проводимые вручную тесты, документированные в Microsoft Word или Excel, их можно импортировать в Rational Manual Tester.

Если документации к существующим тестам нет, можно документировать тестирование в Editor. Пакет Rational Manual Tester имеет многофункциональный текстовый редактор, позволяющий подробно документировать процесс ручного тестирования.

Многофункциональное редактирование текста

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

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



Рисунок 5 - Применение различных шрифтов

Рисунок 6 - Добавление изображений

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

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

Точки проверки отмечены значком . В зависимости от области применения в тестировании может быть ноль, одна или несколько точек проверки. Как правило, предложения точек проверки начинаются с такого текста, как «check that...» или «verify that...» или они содержат вопрос к тестировщику.

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

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

Автоматический ввод данных. Одна из самых распространенных проблем, связанных с ручным тестированием, - это ошибки оператора. Особенно часто ошибки оператора происходят в приложениях, требующих ввода значительного объема данных. Пакет Rational Manual Tester позволяет сократить количество ошибок ввода данных, обеспечивая автоматизированный ввод данных во время проведения тестирования. При создании теста данные, которые требуется вводить при его выполнении, хранятся в инструкциях теста. Во время создания теста мастер извлекает данные, которые требуется вводить, непосредственно из тестируемого приложения. Альтернативно данные можно ввести непосредственно в свойства шага тестирования. При выполнении тестирования вместо ручного ввода данные в тестируемое приложение можно вставить из окна выполнения ручного тестирования. Преимущество использования автоматизированного ввода данных заключается в повышенной точности и скорости выполнения тестирования.

Автоматизированный ввод данных:

а) в списке Composers приложения ClassicsCD развернуть папку Haydn;

б) выбрать Symphonies Nos. 99 & 101, нажать кнопку Place Order;

в) в окне Login нажать OK;

г) установить курсор в поле Credit Card и ввести номер 1234 5678 1234 5678;

д)переключиться обратно в окно Manual Test.

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

В редакторе теста установить курсор на шаге тестирования: Place the cursor in the credit card number line and use <CTRL> V to paste in the test card number;

Выбрать в меню Manual Tester Capture > Data for Insert;

Открывается диалоговое окно с инструкциями;

Нажать <ATL> <TAB> и переключиться в диалоговое окно switch to the Place an Order в приложении ClassicsCD;

Выделить введенный ранее номер кредитной карты и нажать <CTRL> C для копирования текста в буфер обмена;

Нажать <ALT> <TAB> для переключения в окно инструкций Manual Tester и нажать кнопку OK. Текст вставляется в свойство Paste Data тестирования. При выполнении этого тестирования можно установить курсор в поле кредитной карты и нажать <CTRL> V для автоматической вставки номера кредитной карты. При отсутствии опыта работы с общими методами автоматизации тестирования использование в ручном тестировании автоматизированного ввода данных представляет концепцию инструментального ввода данных, которая широко используется в средствах автоматизации. Если в будущем планируется использовать автоматизированное тестирование, представление об этой концепции упростит переход к автоматизации тестирования.

Автоматизированное сравнение данных. Проверка точности данных, выводимых из тестируемого приложения, представляет собой другую задачу, чреватую возникновением ошибок при ручном тестировании приложений. Пакет Rational Manual Tester имеет встроенный блок сравнения данных, в котором ожидаемые выходные данные сравниваются с фактическими данными, выводимыми из тестируемого приложения. Как и в случае с функцией автоматизированного ввода данных, ожидаемые выходные данные хранятся в ручном тесте. Данная функция позволяет ускорить процесс выполнения тестирования и гарантировать точность проверки данных. В описанных ниже шагах показано, как при выполнении тестирования получить текст, который будет использоваться в автоматизированном сравнении данных. На этот раз для получения данных вместо использования мастера надо вставить данные непосредственно в свойство Verification Point. Для получения данных можно использовать любой метод.

а) Переключиться в окно Place an Order в приложении ClassicsCD и выделить текст Symphonies No. 99 & 101 (см. рисунок ниже);

Рисунок 7 - Окно «Place an Order»

б) Нажать <CTRL> C для копирования данных в буфер обмена;

в) Переключиться в Rational Manual Tester и установить курсор в ручном тестировании на предложении с точкой проверки;

г) В правом нижнем углу окна на вкладке Properties имеется свойство с именем Compare Data. Установить курсор в поле Value рядом с этим свойством и нажмите <CTRL> V для вставки ожидаемых данных;

д) Изменим немного эти ожидаемые данные, чтобы показать, как Rational Manual Tester определяет различия при выполнении тестирования. Изменим скопированные данные так, чтобы они немного отличались от текста, отображаемого в тестируемом приложении. Изменим один из номеров симфоний, например, 99 на 94;

Теперь вместе с ручным тестом записано ожидаемое содержимое этого поля. При выполнении этого фрагмента надо выделить текст из тестируемого приложения. Нажать <CTRL> C, программа Rational Manual Tester автоматически сравнивает две текстовых строки.

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

При применении этих же самых принципов к ручному тестированию, степень их успешности изменяется. В большинстве случаев проблема обусловлена тем фактом, что традиционно средства, используемые для документирования ручного тестирования, например, Microsoft Word и Excel, не позволяют выполнить реализацию модулей тестирования или концепцию повторного использования. Таким образом, документирование ручного тестирования часто приводит к продолжительным, сложным в сопровождении тестам, многие из которых могут содержать одинаковые данные для часто выполняемых в приложении действий. Если тесты требуется обновить, группа тестирования должна выполнить поиск во всей документации тестирования, вырезая и вставляя обновления.

Пакет Rational Manual Tester облегчает разработку модульных тестов и их повторное использование и предоставляет простую среду для совместного использования содержимого тестов. Содержимое тестов можно использовать при проведении нескольких тестирований, его также могут использовать различные тестировщики. Благодаря повторному использованию содержимого, группы тестирования могут создавать небольшие модульные тесты. Это позволяет не беспокоиться об обновлении многочисленных сценариев теста при изменении тестируемых приложений. Как правило, используемое содержимое теста можно поместить в палитру Reuse и сделать его доступным для различных тестов, создаваемых различными группами. Работаете ли вы отдельно, в составе небольшой группы или в составе группы тестирования предприятия, данная функция позволяет создавать простые в сопровождении тесты.

Рисунок 8 - Недавние файлы

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

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

Более удачное решение - повторное использовании общих инструкций тестирования. Выполните указанные далее шаги и оцените, как Rational Manual Tester может улучшить сопровождение тестов и обеспечить совместимость благодаря повторно используемому содержимому:

а) Открываем тест;



Рисунок 9 - Вид открытого тестового скрипта

б) Содержимое, организованное в группу, можно разместить на палитре Reuse, чтобы сделать его доступным для повторного использования в других тестах. Можно повторно использовать отдельные предложения или группы предложений;

г) Просмотр шагов тестирования;

Рисунок 10 - Просмотр шагов скрипта

д) Выделить группу «Login» на вкладке Outline и перетащить ее на значок «Reusable Statements», расположенный на вкладке «Reuse» с правой стороны окна приложения. Вкладка «Reuse» должна выглядеть примерно так, как показано на рисунке ниже.

Рисунок 11 - Вкладка «Reuse»

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

е) Перейти в редакторе на вкладку Place_Order. Повторно используйте шаги Login в тестировании Place_Order;

ж) Перейти на вкладку Outline и просмотреть краткое описание тестирования Place_Order;

з) Перетащить папку Login из палитры Reusable Statements на вкладку Outline. Содержимое вкладки Outline должно выглядеть так, как показано ниже.

Рисунок 12 - Вид вкладки Outline

Теперь шаги по регистрации используются в тестировании Place_Order. Если посмотреть на тестирование в редакторе, шаги Login выделены светло-серым фоном, на значках слева от каждого повторно используемого шага находится маленькая стрелка. Это обозначение связанного содержимого. При изменении шагов по регистрации в приложении все тесты, в которых эти шаги используются, автоматически обновляются при обновлении тестирования Login. Если впоследствии потребуется сделать предложения локальными (разорвать связь), нажмите правую кнопку мыши на выделенном предложении или папке и выберите Edit > Make Statement Local.

Запуск теста. При готовности к тестированию приложения, пакет Rational Manual Tester открывает окно выполнения с запросами по каждому шагу тестирования. При выполнении каждого шага можно ввести комментарий, прикрепить файлы (например, снимки экрана) и ввести результаты для каждой точки проверки или отчета. После завершения тестирования результаты хранятся в журнале.