ФОРУМ 01' (17) 2016
Корпоративный журнал компании ЦНТУ "Динамика"
Корпоративный журнал компании ЦНТУ "Динамика"
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
специальная программа по введенным<br />
нами алгоритмам. В этом случае тестирование<br />
занимает куда меньше времени.<br />
Например, проверка модели Ми-8 у нас<br />
уже полностью автоматизирована.<br />
Мы создали специальный сайт со статистикой<br />
результатов всех проверок по<br />
всем проектам. На нем в виде графиков,<br />
таблиц и других данных можно посмотреть,<br />
как тестировался каждый конкретный<br />
проект, увидеть список выявленных<br />
недостатков, был ли недостаток<br />
выявлен впервые или нет и пр. и пр.<br />
Есть, конечно, и проблемы, без них не<br />
бывает, проблем нет только у тех, кто<br />
ничего не делает. Не всегда хватает трудовых<br />
ресурсов на автоматизацию, нужно<br />
больше людей, а производственных<br />
помещений не хватает. Ждем открытия<br />
нового корпуса для расширения.<br />
Ф.: На какой стадии создания ПО надо<br />
начинать тестирование? Непосредственно<br />
перед этапами инсталляции<br />
и отладки, или еще раньше?<br />
А.П.: Тестирование ПО ведется на всех<br />
этапах, начиная с создания исполняемого<br />
файла. Как результат создается документ<br />
с результатами проверок, протокол с заключением<br />
о готовности. В процессе доработки<br />
ПО может дорабатываться документация,<br />
алгоритмы тестирования, даже<br />
пульты и другое «железо» тренажера.<br />
Для безлитерной продукции начинаем<br />
тестировать ПО после этапа РКД, как говорится,<br />
«до победного». Дальше наше заключение<br />
используется для допуска тренажера<br />
к приемо-сдаточным испытаниям,<br />
после чего идет исправление несоответствий<br />
и повторное тестирование уже после<br />
завершения предварительных испытаний.<br />
Следующее тестирование проходит<br />
уже после государственных испытаний,<br />
непосредственно перед отправкой тренажера<br />
заказчику. Предполагается, что<br />
крайним звеном перед отправкой продукта<br />
являемся мы, потому что именно наш<br />
отдел должен давать заключение о готовности<br />
ПО. Получается, что мы стоим на<br />
страже качества, как перед испытаниями<br />
изделий, так и перед их отправкой.<br />
Ф.: Будет ли процедура тестирования<br />
обязательной для всех без исключения<br />
программных продуктов, выпускаемых<br />
«Динамикой»? Или тестирование<br />
будет касаться только вновь разрабатываемых<br />
продуктов, и не будет<br />
производиться в отношении серийных<br />
изделий?<br />
А.П.: Процедура тестирования будет<br />
проводиться для всех продуктов, выпускаемых<br />
«Динамикой». Для литерной<br />
продукции тестирование проводится<br />
также перед приемо-сдаточными испытаниями,<br />
ОТК будет учитывать наше заключение<br />
при принятии решения о допуске<br />
продукта к отправке. Более того,<br />
помимо ПО, разрабатываемого в «Динамике»,<br />
подразумевается еще входной<br />
контроль ПО, созданного соисполнителями.<br />
Например, сейчас мы проводим<br />
тестирование учебных компьютерных<br />
классов в сотрудничестве со специалистами<br />
компании «Амулет». Мы даже получили<br />
уже от них благодарственные отзывы<br />
о нашей работе. Это всегда приятно,<br />
это в очередной раз говорит нам, что<br />
мы делаем важную и полезную работу.<br />
Ф.: Существуют стандарты, касающиеся<br />
процедур тестирования ПО, существуют<br />
различные уровни тестирования<br />
— компонентное, интеграционное,<br />
системное, приемочное и пр.<br />
На какие уровни тестирования будет<br />
делаться основной упор?<br />
А.П.: Мы проводим комплексное тестирование,<br />
в режиме «черного ящика».<br />
При наличии ресурсов, есть наработки<br />
для проведения нагрузочного тестирования.<br />
Это очень важно. Вообще,<br />
мы исходим из специфики производимой<br />
продукции, всю теорию тестирования,<br />
в том числе международные стандарты,<br />
такие как IEEE, нельзя использовать<br />
бездумно, это может привести к<br />
плачевным результатам, и тестирование<br />
будет только во вред. Можно потратить<br />
ресурсы на ненужные действия и не заметить<br />
главного. При выборе методов<br />
мы всегда спрашиваем себя, а приведет<br />
ли это к нашей основной цели — улучшению<br />
качества ПО, или это ненужные<br />
телодвижения, которые могут только<br />
все сделать дороже и дольше? Это нужные<br />
вопросы, необходимо их всегда держать<br />
в уме.<br />
Ф.: Можете рассказать о планах<br />
дальнейшего развития отдела?<br />
А.П.: Возможно расширение нашего<br />
нового подразделения в зависимости от<br />
исполняемых функций. Тестирование<br />
АСО, тестирование ПО на пригодность<br />
к использованию (здесь понадобится отдельный<br />
специалист по интерфейсам<br />
пользователя), тестирование на удобство<br />
и эргономику ПО — задач очень много.<br />
При достижении максимальной эффективности<br />
внутри компании возможно<br />
и расширение деятельности отдела, связанное<br />
с тестированием продуктов других<br />
компаний, фактически — выделение<br />
компетенций, связанных с тестированием<br />
ПО, в отдельное направление деятельности.<br />
В этом случае отдел контроля<br />
и тестирования ПО из «обеспечивающего»<br />
подразделения может превратиться<br />
в «добывающее» — время покажет, как<br />
будут развиваться события.<br />
Беседовала<br />
Светлана ПОПОВЬЯН<br />
22 <strong>ФОРУМ</strong> 1 (<strong>17</strong>) / <strong>2016</strong>
Change language