Функциональное тестирование программного обеспечения на примере мобильных приложений (Характеристика процесса тестирования)

Содержание:

Введение

Платформа Android в последние годы является лидером рынка операционных систем, занимая по состоянию на 2015 год 59 % рынка операционных систем и 89,4 % рынка мобильных платформ по всему миру. Соответственно, все больше компаний, стремясь увеличить количество пользователей своих сервисов, уделяют особое внимание именно этой платформе. Именно открытость исходного кода ОС Android позволила этой платформе завоевать такие позиции на рынке. Однако, разнообразие устройств приводит к печальным последствиям в плане поддержки этих устройств, а также программного обеспечения на них. Производитель не может позволить себе обновлять устаревшее устройство до последней версии ОС ввиду экономических причин, и, как это часто бывает, для побуждения пользователя купить новое устройство с новейшей версией ОС и техническими характеристиками. Разработчики ПО так же не поддерживают все устройства на всех версиях ОС, но разрабатывают приложения под нужды, в первую очередь, устройств,занимающих лидирующие позиции на рынке.

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

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

Объектом исследования в курсовой работе является программное обеспечение.

Предметом исследования – процесс тестирования программного обеспечения на примере мобильных приложений.

Целью исследования является выявление особенностей процесс тестирования программного обеспечения на примере мобильных приложений.

Для достижения поставленной цели сформулированы следующие задачи:

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

Методологической основой исследования являются учебная и методическая литература, статьи в периодической печати и Интернет-ресурсы.

Теоретические аспекты тестирования программного обеспечения

• 1. Сущность и необходимость тестирования программного обеспечения

Процесс тестирования играет важную роль в проектах, связанных с разработкой программного обеспечения (ПО). Руководители консалтинговых компаний, которые занимаются созданием и внедрением новых информационных продуктов, заинтересованы в обеспечении качественного выполнения этого вида работ. Несмотря на то, что успех проекта зависит от многих факторов, правильная организация процесса тестирования существенно влияет на подготовку качественного программного обеспечения. [2, с.102; 3, с.16]

Время проведения тестирования зависит от выбранной модели жизненного цикла (ЖЦ) программного обеспечения. Как правило, исключая водопадную модель ЖЦ ПО, планирование тестирования начинается в самом начале IT-проекта, когда совместно с заказчиком уже определены требования к будущему ПО. Готовится план тестирования и, согласно требованиям, тест кейсы, по которым будет проводиться проверка программного обеспечения. Специалисты пришли к выводу, что информация обо всех найденных ошибках обязательно должна быть сохранена, это значительно облегчает работу команды тестирования. Несмотря на продолжающиеся дискуссии о возможности применении других средств, обычно в компаниях используют багтрекинговую систему для создания, хранения, просмотра и модификации сведений о багах. От выбора функционального и удобного багтрекера зависит уровень взаимодействия команды тестирования и разработчиков, а также качество исполнения процесса тестирования. В данном случае рассматривалась система трекинга багов (СТБ) для среднестатистической небольшой компании. Таких фирм достаточно много на российском рынке, чаще всего, они параллельно занимаются несколькими проектами и осуществляют техническую поддержку. В ходе работы использовался алгоритм выбора программного обеспечения, его основные этапы показаны на рисунке 1. [5, с. 177]

Рисунок 1. Алгоритм выбора ПО

Таким образом, решалась задача многокритериального вывода, применялась методика MuSCoW для выделения более значимых показателей. Эта консалтинговая методика подразумевает, что есть 4 вида критериев – обязательные (must have), менее важные, но желательные показатели (should have, would have), а также показатели, которых не должно быть (won’t have). [6, с.213; 7, с.174]

Список программного обеспечения и его оценка по выделенным критериям проводилась с помощью экспертов в области тестирования. При подведении итогов применялся метод взвешенной оценки, учитывающий важность каждого показателя. Наиболее весомым и значимыми специалисты признали «Usability» и «Простоту освоения». Дело в том, что во время проекта возможна частичная или полная смена коллектива, как тестировщиков, так и разработчиков. Новый сотрудник должен легко освоить функционал багтрекера, чтобы как можно быстрее начать выполнять свои обязанности. Критерий «Простота освоения» важен для сотрудников, которые совмещают роли на проекте. Например, в целях оптимизации, консультанты могут быть задействованы в процессе тестирования. Поэтому, чем логичнее и проще устроена система трекинга багов, тем меньше сроки ее изучения. Следующим критерием была названа «Полнота функционала», в это понятие входит весь набор необходимых work items, то есть таких рабочих элементов, как user story, task, bag, test case, test suite. А также 120 наличие статусов, приоритетов и других показателей, которые необходимы для эффективной работы с дефектами ПО. «Надежность» – достаточно важный показатель, который критичен для любых реально работающих систем, в том числе и багтрекинговых. «Требования к аппаратному обеспечению (АО)» достаточно средние, больших ресурсов не требуется. «Поддержка работы с несколькими проектами» – выделяется особенно, так как компании чаще всего ведут работу по большому количеству проектов и всю информацию по дефектам необходимо хранить в багтрекере. «Учет рабочего времени» – отражает количество временных ресурсов затраченных на ту или иную ошибку. «Генерация отчетов» довольно важный показатель, так как для test lead, менеджера проекта, высшего руководства необходимо иметь полные и исчерпывающие сведения о процессе тестирования. Языковой барьер нередко является большой проблемой в ходе проекта, поэтому лучше иметь СТБ с функцией поддержки нескольких языков. «Наличие интеграции с email, мессенджерами» – для команды проекта важно иметь постоянный доступ к информации, ресурсам системы, так как успешное завершение проекта зависит, в том числе, и от оперативности реагирования персонала на то или иное событие. «Методическое обеспечение» также играет не последнюю роль, качественное описание структуры и наличие правил работы с багтрекером значительно упростит его освоение пользователями. «Поддержка и применение в РФ» – это залог обеспечения ее работоспособности системы, возможность технической поддержки. Затем нами были рассмотрены представленные на рынке, как opensource, так и проприетарные решения. Изначально стоимость, то есть финансовый критерий не определен, важно выбрать программное обеспечение, которое более всего соответствует названным показателям. Приобретение платной системы или использование СТБ с открытым кодом зависит от политики и финансовых возможностей компании. На рынке представлено большое количество программного обеспечения в области тестирования, нами были оценены Bugzilla от компании Mozilla Foundation, Trac от Edgewall Software, Atlassian JIRA компании Atlassian Software Systems, Test Rail Gurock Software, MantisBP от Mantis, Redmine разработчика JeanPhilippe Lang. Итоги сравнения приведены в таблице 1.

Таблица 1 - Матрица критериев по выбору системы трекинга багов

Исходя из полученных баллов, наилучшие показатели у ПО Atlassian JIRA. За ней следуют системы Bugzilla и Redmine. Несмотря на то, что Bugzilla опередила JIRA по критерию «Простота освоения», эта система значительно уступает по второму наиболее важному показателю «Usability». Redmine в целом была оценена ниже, чем две другие СТБ, в том числе и по двум значимым критериям. Система Trac, которая по сумме баллов находится на последнем месте, тем не менее, отмечена достаточно высоко по «Простоте освоения» и «Usability». Однако Trac проигрывает другим ПО в «Полноте функционала», а также не поддерживает работу с несколькими проектами. Названные критерии также учитываются при выборе багтрекера, им присвоены высокие коэффициенты. Именно поэтому эта система не была включена нами в список отобранных. Bugzilla и Redmine – open source решения, а Atlassian JIRA – проприетарное ПО, но на сайте разработчика представлен и тестовый вариант. Окончательное решение следует принимать исходя не только из финансовых возможностей компании. Необходимо провести экспериментальную проверку и сравнить лидирующее программное обеспечение, чтобы на практике убедиться в точности результатов исследования.

• 1. Характеристика процесса тестирования

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

– если дымовое тестирование прошло неудачно, вы отправляете приложение на доработку;

– если же удачно, то вы переходите к следующему виду тестирования - регрессионное тестирование.

Открыв систему отслеживания ошибок, следует перепроверить дефекты, которые разработчики перевели в статус «Исправлено», «Отклонено», «Нет возможности воспроизвести» и т.д. Заметим, что статусы «Отклонено» и «Нет возможности воспроизвести» для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию. Покончив с закрытием и переоткрытием дефектов, идёт переход к основной работе - централизованному тестированию по тест кейсам. Когда все, что было запланировано, пройдено, тестировщик имеете результаты прогона тест кейсов, бaг репорты, вопросы к аналитикам и заметки на полях своих тетрадей. Основываясь на всем этом, составляется отчет по проведенному тестированию и отправляется на проектную группу. Подобный процесс проходит от версии к версии, и через какое-то время результаты тестирования сойдутся, с прописанными в плане тестирования критериями окончания тестирования. На этом основная работа, связанная непосредственно с тестированием, окончена [1, с.12].

Тестирование ПO является одной из технических способов контроля качества и включает в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов [3, с.15]. Необходимое условие: тестирование не возможно без объекта тестирования, отсюда получаем первое условие: наличие объекта тестирования, доступного для проведения испытаний. Далее, чтобы тестирование все же состоялось, нам нужен исполнитель, значит, вторым необходимым условием будет наличие исполнителя, причем им может быть, человек или машина, или комбинация человек и машина.

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

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

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

Оно решает несколько основных задач:

– дает уверенность в качестве конечного продукта, подтверждает, что все заявленные функциональные требования реализованы, приложение им соответствует и не имеет ошибок в программном коде;

– подтверждает, что приложение способно выполняться во всех заявленных режимах и на всех поддерживаемых ОС или Web-браузерах корректно;

– гарантирует, что хранимые и обрабатываемые данные надежно защищены от постороннего доступа и "взлома";

– определяет, какая максимальная нагрузка на сервер, локальную сеть, БД может быть корректно обработана приложением;

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

• 1. Уровни тестирования

Стандарт ISO / IEC 25010:2011 (ГОСТ Р ИСО / МЭК 25010 - 2015) определяет качество программного обеспечения как степень соответствия системе заявленных и подразумеваемых потребностей различных заинтересованных сторон. В соответствии со стандартом модель качества программного продукта включает восемь характеристик:

• функциональная пригодность;
• уровень производительности;
• совместимость;
• удобство пользования;
• надёжность;
• защищённость;
• сопровождаемость;
• переносимость (мобильность) [11].

Выделяют следующие уровни тестирования:

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

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

Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

Часто для свободного и открытого программного обеспечения стадия альфа - тестирования характеризует функциональное наполнение кода, а стадия бета - тестирования — стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям [10].

Следует различать статическое и динамическое тестирование.

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях анализируется не исходный, а промежуточный код (такой как байт - код или код на MSIL) [10]. Статический анализ всегда быстрее всех остальных методов анализа.

Динамический анализ предполагает запуск реальной программы [9] и анализ функционирования программы и ее артефактов.

Анализ факторов, влияющих на процесс тестирования

• 1. Зависимость процесса тестирования от аппаратных характеристик устройства

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

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

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

3. Размер и разрешение экрана Важнейший параметр для любого приложения. От размера экрана зависит размер и положение элементов пользовательского интерфейса, поэтому надо уделить особое внимание устройствам с минимальными и максимальными параметрами экрана. На устройствах с минимальными параметрами экрана (для нынешнего рынка это порядка 3.5 дюймов и VGA - разрешение) возможны наложения элементов друг на друга, что делает невозможным использование этих элементов. На больших же экранах и разрешениях (для рынка сейчас это 12 дюймов и QHD - разрешение) элементы могут быть настолько малы, что пользователь просто не будет способен попасть по ним пальцем. Поэтому в процессе обеспечения качества ПО стоит учитывать эти параметры, и создавать элементы с динамическими размерами, которые подстраиваются под любые размеры и разрешения экрана.

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

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

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

• 1. Зависимость процесса тестирования и документирования ошибок от использования аппаратных и программных средств управления устройством

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

1. Сворачивание приложения.

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

1. Выгрузка приложения.

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

1. Смена ориентации.

Типичной ошибкой является смещение элементов UI, выход их за рамки дисплея, и пр.

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

• 1. Взаимодействие приложения с ОС и другими приложениями. Особенности воспроизведения критических ошибок

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

1. Взаимодействие плееров.

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

1. Приложения по умолчанию.

Из всех стандартных приложений Android, использующих звуковой сервис, лучшим примером может служить приложение «Телефон». Основу взаимодействия телефона и аудиоплеера составляет переключение фокуса между звонком и проигрыванием звука. Приложение телефона сообщает ОС о том, что поступил звонок – значит приложение, проигрывающее звук в данный момент должно отдать фокус телефону для проигрывания мелодии звонка, и поставить на паузу собственный звук. Когда приложение телефона сообщает ОС о том, что звонок завершен – приложение забирает обратно фокус и продолжает воспроизведение с того момента, когда этот фокус был отдан телефону. Если условно принять, что приложение телефона не имеет ошибок, то все связанные с этим ошибки полностью находятся на стороне тестируемого приложения.

1. Взаимодействие с уведомлениями приложения.

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

1. Взаимодействие с уведомлениями сторонних приложений.

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

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

Заключение

Существует множество различных методологий разработки программного обеспечения. Выбор определённой методологии зависит от различных факторов: сложности, объемности проекта, количества человек, участвующих в реализации проекта. Поэтому перед началом работы перед разработчиком встает вопрос о выборе техники разработки программного обеспечения. Среди методов создания программного продукта различают: Agile (XP, Lean, Scrum, FDD др.), Cleanroom, DSDM и др.

К перечисленным методам также относится разработка через тестирование (test - drivendevelopment, TDD). Изобретателем этой методологии считается Кент Бек. Его техника разработки программного обеспечения основывается на повторении коротких циклов разработки, в которых сначала пишется модульный тест, позволяющий покрыть желаемое изменение, затем пишется код, который выполняет действия, с помощью которых проходится данный тест. После успешного прохождения теста осуществляется доработка (рефакторинг) написанного кода

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

Список использованных источников

1. Абрамян, Г.В. Методология формирования и реализации систем интеллектуальной поддержки принятия решения при управлении предприятиями сферы финансов, экономики и образования / Г.В. Абрамян, Г.Р. Катасонова // Перспективы и пути развития образования в России и в мире: Материалы II Международной научно-практической конференции. Махачкала – 2013. - С. 14-21.
2. Алексеев Д.М., Кутняк Н.А. // Защита программного обеспечения от несанкционированного использования // В сборнике: «Синтез науки и общества в решении глобальных проблем современности», часть 3, г. Пенза, 18 февраля 2016 г. С. 21 - 22.
3. Калязина Д.М., Соколов Н.Е., Федорова А.Е., Обоснование выбора платформы для обучения студентов экономических вузов основам Business Process Management // Известия высших учебных заведений. Поволжский регион. Гуманитарные науки, 2014. № 4, С. 211-218.
4. Калязина Д.М. Разработка подсистемы организационного обеспечения информационной системы управления бизнес-процессами (на примере ИС RUNA WFE) // Государство и бизнес. Современные проблемы экономики Материалы VII международной научно-практической конференции, РАНХиГС Северо-Западный институт управления. – СПб.: Издво «Стратегия будущего», 2015. – С. 173-176.
5. Кокунов В.А., Соколов Н.Е., Методология и технология проектирования информационных систем / Н.Е. Соколов, В.А. Кокунов – СПб. – Издво «СкифияПринт». – 2014.
6. Соколов Н.Е., Соколова Е.В. Возможности и ограничения информационных технологий обучения /Н.Е.Соколов, Е.В.Соколова // Новая наука: Современное состояние и пути развития. – 2015. № 42. – С. 101-103.
7. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет - стартапах. / Р.Савин— М.: Дело, 2017. —312 с.
8. Федорова А.Е. Архитектура информационных систем поддержки процесса повышения показателей публикационной активности в вузе // Государство и бизнес. Современные проблемы экономики Материалы VII международной научнопрактической конференции, РАНХиГС СевероЗападный институт управления. СПб. – Издво «Стратегия будущего», 2015. – С. 176-178.
9. Тестирование программного обеспечения - [Электронный ресурс]: Режим доступа: https://ru.wikipedia.org/wiki/Тестирование _ программного _ обеспечения
10. Тестирование программного обеспечения -основные понятия и определения - [Электронный ресурс]: Режим доступа: http://www.protesting.ru/testing/
11. Introduction to Android [Электронный ресурс] / Google, inc., 2016 - Режим доступа: http: // developer.android.com / guide / index.htm