85
соответствующими управляющими данными, процедурами использования и
обработки.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной
функции или метода. Это позволяет достаточно быстро проверить, не
привело ли очередное изменение кода к регрессии, то есть к появлению
ошибок в уже оттестированных местах программы, а также облегчает
обнаружение и устранение таких ошибок.
Когда дана положительная оценка по всем метрикам статического
анализатора кода, специалист по тестированию в каждой из команд
приступает к проведению созданных тестов на новый функционал, и после
прохождения данных тестов, проводится регрессионное тестирование.
Регрессионное тестирование (англ. regression testing, от лат. regressio —
движение назад) — собирательное название для всех видов тестирования
программного обеспечения, направленных на обнаружение ошибок в уже
протестированных участках исходного кода. Такие ошибки — когда после
внесения изменений в программу перестаёт работать то, что должно было
продолжать работать, — называют регрессионными ошибками (англ.
regression bugs).
Регрессионное тестирование включает в себя new bug-fix — проверка
исправления вновь найденного дефекта, old bug-fix — проверка, что
исправленный ранее и верифицированный дефект не воспроизводится в
системе снова, а также side-effect — проверка того, что не нарушилась
работоспособность работающей ранее функциональности, если её код мог
быть затронут при исправлении некоторых дефектов в другой
функциональности. Обычно используемые методы регрессионного
тестирования включают повторные прогоны предыдущих тестов, а также
проверки, не попали ли регрессионные ошибки в очередную версию в
результате слияния кода.
86
Из опыта разработки ПО известно, что повторное появление одних и тех
же ошибок — случай достаточно частый. Иногда это происходит из-за
слабой техники управления версиями или по причине человеческой ошибки
при работе с системой управления версиями. Но настолько же часто решение
проблемы бывает «недолго живущим»: после следующего изменения в
программе решение перестаёт работать. И наконец, при переписывании
какой-либо части кода часто всплывают те же ошибки, что были в
предыдущей реализации.
Поэтому считается хорошей практикой при исправлении ошибки создать
тест на неё и регулярно прогонять его при последующих изменениях
программы. Хотя регрессионное тестирование может быть выполнено и
вручную, но чаще всего это делается с помощью специализированных
программ, позволяющих выполнять все регрессионные тесты автоматически.
В некоторых проектах даже используются инструменты для автоматического
прогона регрессионных тестов через заданный интервал времени. Обычно
это выполняется после каждой удачной компиляции (в небольших проектах)
либо каждую ночь или каждую неделю.
20
На всех циклах тестирования, специалисты по тестированию могут
находить дефекты в программном обеспечении. При работе с дефектами, они
руководствуются регламентом работы с дефектами, разработанным для ИТ-
подразделения компании (приложение 5)
Все тесты, которые будут выполнять специалисты по тестированию после
выполнения юнит-тестов, разрабатываются на основе пользовательских
историй или требований. Эти тесты определяются в тестовые наборы,
которые относятся к проверке той или иной функциональности. После
выполнения тестов проводится анализ их выполнения, анализ найденных
дефектов и составляется отчет о тестировании в свободной форме, в котором
20
WikiPedia https://ru.wikipedia.org/wiki
87
выносится вердикт о допустимости или недопустимости передачи продукта
конечным пользователям.
В целом, процесс работы с тестами выполняемыми специалистами по
тестированию можно представить согласно Рисунка 10
Рисунок 10 Процесс тестирования специалистами по
тестированию в компании ЗАМПА
Основным критерием качества предложено считать наличие дефектов в
программном обеспечении. Так, в случае если после очередной итерации
разработки, программное обеспечение содержит хотя бы один блокирующий,
критический или важный дефект – продукт не поставляется конечным
пользователям. Если же таковых дефектов нет, но есть более 10-ти дефектов
уровня средний и низкий (в совокупности) – продукт так же не передается
конечным пользователям.
Инструментом для хранения тестовой модели (наборы тестов)
предлагается использовать специализированное программное обеспечение
HP ALM, которое позволяет отслеживать покрытие тестами функционала,
оценивать трудозатраты на их выполнение, вести отчетность и т.д. В
качестве системы регистрации дефектов – рекомендовано использовать
имеющуюся в компании инфраструктуру продукта JIRA – для удобства
88
работы разработчиков. В случае необходимости, импорт данных JIRA – HP
ALM легко настраивается.
При использовании описанного подхода, можно существенно добиться
повышения качества разрабатываемых компанией продуктов, что позволит
компании улучшить клиентский опыт, и исключить репутационные риски.
Так же, использование систем JIRA и HP ALM существенно позволит
увеличить «прозрачность» процесса обеспечения качества для бизнеса, что
снимет проблему недопонимания между разработкой и бизнесом.
ЗАКЛЮЧЕНИЕ
В данной выпускной квалификационной работе приведен
теоретический и практический материал по теме «Организация ИТ-
подразделения на предприятии ЗАМПА». Компания ЗАМПА является
достаточно интересным представителем современного бизнеса, в котором
ИТ-подразделение не только занимается поддержкой ИТ-инфраструктуры
для бизнеса, но и само активно участвует в создании продукта, ценности,
который в свою очередь является источником основного дохода
предприятия. С учетом этой специфики и описанных в работе проблем,
связанных с деятельностью ИТ-подразделения и его взаимоотношений с
высшим менеджментом предприятия, рассмотрены и предложены к
внедрению сервисный и процессный подход, которые взяты за основу
библиотеки лучших практик в сфере управления ИТ-службами на
предприятиях - ITIL. Так же были рассмотрены и предложены к внедрению
самые современные и прогрессивные практики и рекомендации по
разработке программного обеспечения – Scrum и Agile, а равно рассмотрены
важные вопросы обеспечения качества программного обеспечения.
89
В практической части был проведен анализ текущей ситуации на
предприятии, в ходе которого были обнаружены существенные недостатки в
организации ИТ-подразделения на предприятии. Выявлены причины
недопонимания менеджментом компании работы ИТ-подразделения. В
работе было выдвинуто предложение по реорганизации и
совершенствованию устройства ИТ-подразделения на предприятии в части
процессов управления ИТ-инфраструктурой, разработкой программного
обеспечения и обеспечения качества производимого ПО. Преимущества
выбранных подходов к решению проблем в ИТ-подразделении предприятия
были обоснованы соответствиями ожидаемых результатов от изменений
требованиям бизнеса и соответствие предлагаемого решения лучшим
мировым практикам. Данная работа написана на основе реального проекта,
все предложенные изменения были приняты и внедрены на предприятии в
течении 3 месяцев. Благодаря этому получилось достигнуть следующих
результатов :
Предприятие полностью избавилось от проблемы взаимоотношений
между бизнесом и ИТ. Что привело к созданию более креативной
атмосферы в компании и увеличению производительности ИТ-
подразделения;
Удалось вывести разработку программного обеспечения на новый
уровень и решить проблему с неудовлетворительным качеством
выпускаемого ПО. Снизить количество жалоб на дефекты ПО от
конечных пользователей;
Начать вести деятельность по разработке новых продуктов;
Более эффективно распределить нагрузку на персонал ИТ-
подразделения;
Создать более простую и эффективную ИТ-инфраструктуру
предприятия;
Выстроить понятные и простые процессы по управлению в зоне ИТ-
подразделения.
90
Из этого следует, что задачи, поставленные в начале работы, были
достигнуты также, как и достигнута цель.
91
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Логунов Д.В. “Внедрение сервисного подхода к
управлению небольшим ИТ-подразделением.” Школа IT-менеджмента
РАНХиГС при Президенте РФ 2011
2. ГОСТ ИСО 9000-2011 (ISO 9000-2005)
3. ITIL-Certified-ITIL-Foundation-2011-Study-Notes
4. Wikipedia, https://ru.wikipedia.org/wiki/
5. Публикация в журнале Компьютер пресс, сентбярь 2006,
«Что такое ITIL» Наталья Елманова
https://compress.ru/article.aspx?id=16572
6. «ITIL Service Strategy» («Стратегия сервиса»), ISBN 978-0-
11-331045-6
7. «ITIL Service Design» («Проектирование сервиса»), ISBN
978-0-11-331047-0
8. «ITIL Service Transition» («Передача сервиса»), ISBN 978-0-
11-331048-7
9. «ITIL Service Operations» («Эксплуатация сервиса»), ISBN
978-0-11-331046-3
10. «ITIL Continual Service Improvement» («Постоянное
улучшение сервиса»), ISBN 978-0-11-331049-4
11. Agile manifesto http://agilemanifesto.org/principles.html
12. Кочешков Андрей, Публикация в журнале «Финансовый
директор», Ноябрь 2017, «Все что вам нужно знать про методологию
SCRUM» https://fd.ru/articles/158926-metodologiya-scrum-17-m11
13. Сергей Терехов, публикация на сайте http://terekhoff.org и
http://qa-lab.org
14. Neon Rain interactive – Agile for all https://www.neonrain.com