ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Методология функционального моделирования. – М.: by sedimentation from the vacuum and arc category are ИПК Издательство стандартов, 2001. – 50 с. united in 3 stages and each stage is in detail described, using methodology of modeling of IDEF0. 3. Кане М.М. Системы, методы и инструменты менеджмента качества: учебное пособие / М.М. Кане, Keywords: technological process, coatings obtained Б.В. Иванов. – СПб.: Питер, 2008. – 560 с. by vacuum-arc discharge, controlled parameters, IDEF0 modeling methodology. 4. Технология вакуумной ионно-плазменной об- работки: учебное пособие / В.В. Будилов, Р.М. Киреев, References: С.Р. Шехтман. – М.: Изд-во МАИ, 2007. – 155 с. 1. Budilov V.V., Yagafarov I.I., Yansaitova M.I. 5. Черемных С.В. Моделирование и анализ си- Reserch of dependence of microhardness and phase стем. IDEF-технологии: практикум / С.В. Черемных, structure of a covering of TiN on an arrangement of И.О. Семенов, B.C. Ручкин / М.: Финансы и стати- details in the vacuum chamber at sedimentation from plasma of the vacuum and arc category. The strengthening стика. – 2006. – 192 с. technologies and coverings. 2017, Volume 13. No. 1. pp. 20–23. 2. State Standard 50.1.028-2001 Information Structurally Functional Model of the Technological technologies of support of life cycle of production. Process of Coating Deposition Obtained by Methodology of functional modeling. Publishing and Vacuum-arc Discharge printing complex «Standards Publishing House». Moscow, 2001. 50 p. Yansaitova M.I., graduate student of the Ufa aviation 3. Kane M.M., Ivanov B.V. Systems, methods and technical university; Republic of Bashkortostan, Ufa instruments of quality management: manual. Piter. St-Petersburg, 2008. 560 p. e-mail: [email protected] 4. Budilov V.V., Kireev R.M., Shekhtman S.R. Technology of vacuum ion-plasma processing: manual. Summary. In this work technological process of Publishing house of the Moscow aviation institute. drawing the coverings received by sedimentation from Moscow, 2007. 155 p. the vacuum and arc category on the basis of creation of 5. Cheremnykh S.V., Semyonov I. O., Ruchkin B.C. structurally functional model is considered. Operations of Modeling and analysis of systems. IDEF technologies: prac- technological process of drawing the coverings received tical work. Finance and statistics. Moscow, 2006. 192 p.

Реализация процесса тестирования в Agile-методологиях academquality.ru, ql–journal.ru О.В. Ерина Введение Процессы разработки программного обеспе- исполнительный директор чения (ПО), основанные на гибкой методологии ООО «Спейс-О Технологии»; г. Томск разработки ПО Agile, становятся очень попу- лярными среди компаний-разработчиков ПО. e-mail: [email protected] Основные принципы гибкой методологии изло- жены в Манифесте Agile [1]. Но, как будет рас- Аннотация. В статье приведен анализ реализации смотрено ниже, Манифест Agile не дает явных процессов тестирования в Agile-методологиях: Agile Mo- указаний по организации процесса тестирова- deling, Agile Unified Process, Agile Data Method, Essential ния в проекте, применяющем гибкую методоло- Unified Process, , Feature Driven Dev- гию разработки. Разработка требуемых указаний elopment, Getting Real, Open UP, Scrum, . Проана- предполагает изучение имеющихся наработок по лизирован мировой опыт в области организации про- теме и проведение собственного анализа процес- цесса управления качеством программного обеспечения в рамках Agile. На основе общих для всех Agile-подобных са управления качеством в рамках гибких мето- характеристик был составлен и аргументирован пере- дологий разработки. чень техник тестирования, подходящих всем гибким ме- В данной статье рассмотрим следующий на- тодологиям разработки программного обеспечения. учный вопрос: «Как организовать процесс тести- Ключевые слова: гибкие методологии разработки, рования в рамках гибкого процесса разработки тестирование программного обеспечения, качество про- с учетом имеющихся мировых исследований по граммного обеспечения. данной теме?»

50 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Методология Agile с точки зрения обмена информацией как с самой командой, так управления качеством ПО и внутри команды. Рассмотрим принципы Agile с точки зрения Данный пункт сильно перекликается с п. 4 процесса тестирования. и означает, что специалисты из команды тестиро- вания (или их представитель) обязательно должны 1. Наивысшим приоритетом является удо- присутствовать на проектных совещаниях и уча- влетворение потребностей заказчика, благода- ствовать в принятии проектных решений. ря регулярной и ранней поставке ценного про- граммного обеспечения. 7. Работающий продукт – основной показа- Очевидно, что самым главным условием удо- тель прогресса. влетворения потребностей заказчика является про- Как было сказано в п. 1, работающий продукт – изводство программного обеспечения с наивысшим определяющий фактор удовлетворенности заказчи- уровнем качества в заданных рамках сроков и бюд- ка работой команды-исполнителя. Задача тестиро- жета, что является основной задачей тестирования. вания состоит в том, чтобы выявить, что наиболее важно для заказчика, и подготовить тесты, доказы- 2. Изменение требований приветствуется вающие, что именно это он и получает [2]. даже на поздних стадиях разработки. Данный принцип означает, что в методологии 8. Инвесторы, разработчики и пользователи Agile тестирование должно гибко реагировать на должны иметь возможность поддерживать по- любые изменения в требованиях и, как следствие, стоянный ритм бесконечно. стоит избегать методик тестирования, требующих Поддержка заданного ритма на протяжении все- фиксации требований, например, таких как рецен- го проекта возможна только при грамотном плани- К ачество и жизнь и ачество зирование. ровании работ, а также при применении методик предотвращения ошибок, которые будут рассматри- 3. Работающий продукт следует выпускать ваться далее. как можно чаще, с периодичностью от пары не- дель до пары месяцев. 9. Постоянное внимание к техническому со- Данный принцип подтверждает мысль преды- вершенству и качеству проектирования повыша- дущего пункта: если работающий продукт должен ет гибкость проекта. выпускаться часто, соответственно, команде, сле- Данный принцип говорит о том, что качество

дующей принципам гибкой методологии, следует производимого ПО является одной из приоритет- 201 применять «легковесные» методики тестирования ных областей приложения усилий со стороны как 8 ’

или методики предотвращения дефектов. руководства проектом, так и всех членов команды. 1

4. На протяжении всего проекта разработ- 10. Простота – искусство минимизации лиш- чики и представители бизнеса должны ежеднев- ней работы – крайне необходима. но работать вместе. Данный принцип подтверждает, что в Agile Для успешной реализации проекта необхо- предпочтительно использование «легковесных» димо, чтобы в переговорах участвовали три сто- методик тестирования. роны: представитель заказчика, представитель программистов и представитель команды тести- 11. Самые лучшие требования, архитектур- рования [2]. ные и технические решения рождаются у самоор- ганизующихся команд. 5. Над проектом должны работать мотиви- Самоорганизующиеся группы – это сотрудни- рованные профессионалы. Чтобы работа была ки, которые не нуждаются в контроле и руковод- сделана, создайте условия, обеспечьте поддержку стве со стороны вышестоящего менеджера. Дан- и полностью доверьтесь им. ный принцип подразумевает, что распределение Мотивации персонала (в том числе и сотрудни- задач и контроль результата производится само- ков отдела тестирования) посвящены многие тру- стоятельно участниками процесса, а именно – раз- ды [3], т.к. только заинтересованный в результате работчиками, тестировщиками, аналитиками и т.д. специалист сможет обеспечить наивысший уро- Такой подход возможен при условии качествен- вень качества результата своей работы. ного превентивного планирования, а также при высоком уровне мотивированности участников 6. Непосредственное общение является наи- процесса, поэтому данный принцип перекликает- более практичным и эффективным способом ся с п. 5, гласящим, что положительная мотивация

51 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

сотрудников – мощный инструмент повышения Agile. А именно, по мнению Э. Бааха, QA-специа- качества работы всей команды. листы должны: 1) мыслить масштабно и понимать QA не толь- 12. Команда должна систематически анали- ко как «testing», но и как верификацию всех процес- зировать возможные способы улучшения эф- сов проекта, в частности, на соответствие принци- фективности и соответственно корректировать пам Agile (либо другой методологии, используемой стиль своей работы. командой-разработчиком), выступая в качестве Команда тестирования, как часть команды agile-инспектора; разработки должна систематически искать пути 2) оценивать требования и документацию, что- совершенствования процесса тестирования, тес- бы убедиться, что в докумнтах отсутствует двой- но взаимодействовать с программистами и заказ- ственность понимания и все требования ясны; чиком, помогать заказчику формулировать свои 3) оценивать пользовательские истории (user st- требования и искать лучшие пути обеспечения ка- ories) и убедиться, что они совпадают с бизнес-требо- чества, созданного по требованиям, функционала ваниями и имеют достижимые критерии приемки; системы и нефункциональных характеристик. 4) участвовать в написании автотестов; Отметим, что в данном манифесте ничего не 5) работать с рисками, которые могут возник- сказано в явном виде об обеспечении качества нуть со стороны QA; производимого ПО. Если рассмотреть наиболее 6) стремиться к предупреждению дефектов, популярные процессы разработки, основанные на используя современные техники/методологии (на- принципах Agile, то можно убедиться, что в них пример, TDD). процесс тестирования также описан либо весьма Ф. Хэйер в своей книге «Agile testing» [5] акцен- поверхностно, либо не описан вообще (табл. 1). тирует внимание читателя на таких уже известных техниках и методологиях как квадранты тестиро- Таблица 1. вания и TDD. Наличие описания процесса тестирования Л. Криспин, Дж. Грегори в книге «Гибкое те- в Agile -методологиях стирование. Практическое руководство для тести- Описан ли процесс Методология ровщиков ПО и гибких команд» также задались тестирования вопросом оптимального управления качеством Agile Modeling – с помощью участия QA-специалистов в макси- Agile Unified Process – мально возможном количестве процессов проекта Agile Data Method – и с применением техники квадрантов тестирова- Essential Unified Process – ния [2]. Extreme Programming + После изучения имеющегося мирового опы- Feature Driven Development + та рассмотрим вопрос самостоятельно и выделим academquality.ru, ql–journal.ru основные характеристики Agile-процессов. Getting Real – 1. Итеративность процесса. При этом обяза- Open UP + тельным условием является создание работающего Scrum – прототипа системы на каждой итерации. Kanban – 2. Переменчивость требований. 3. Фокус на техническом совершенствовании системы. Тем не менее, многие пункты манифеста пред- 4. Тесное взаимодействие всех членов команды. по лагают, что процесс тестирования на проекте, Теперь рассмотрим, какие из уже существу- в котором применяется методология Agile, должен ющих решений управления качеством ПО могут быть продуманным и понятным всем членам ко- быть успешно применены в рамках процессов манды. Agile. В табл. 2 показано, какие из методик тести- рования обеспечат выполнение основных харак- Организация процесса тестирования терисик Agile: в Agile-процессе Следует отметить, что процесс тестирования Вопрос тестирования ПО в рамках гибких методо- должен быть четко спланирован, т.к. наличие логий слабо освещен в мировой литературе, но, тем не плана особенно необходимо в условиях неопре- менее, обратимся к существующему мировому опыту. деленности и меняющихся требований. На этапе Э. Баах в своей книге «Agile Quality Assuran- планирования (который должен быть реализован ce» [4] подробно рассматривает особенности про- в первой итерации) осуществляются действия, цесса контроля качества ПО в рамках методологии направленные на определение целей тестирова-

52 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Таблица 2. Методики тестирования

Техническое Тесное Переменчивость Интерактивность совершенствование взаимодействие требований системы команды

TDD + + FMEA + + PRAM, SST, PRisMa + + + Квадранты + + + + тестирования ния, и описание задач тестирования для достиже- TDD можно отнести к динамическим видам ме- ния данных целей [3]. тодов предупреждения дефектов. Во-вторых, на каждом этапе/уровне/итерации 2. FMEA – это методология проведения анали- разработки ПО должен осуществляться монито- за и выявления наиболее критических шагов про- ринг прогресса по процессу тестирования (напри- изводственных процессов с целью управления ка- мер, посредством метрик процесса тестирования чеством продукции [7]. и метрик продукта). Суть процесса FMEA заключается в сборе и ана- В-третьих, необходимо применять «легковес- лизе потенциальных дефектов и принятии мер по ные» методики тестирования, основанные на ри- предупреждению данных дефектов. Сбор информа- сках. Например, такие как: ции о потенциальных угрозах может быть осущест- К

• Pragmatic Risk Analysis and Management влен посредством следующих инструментов: жизнь и ачество (PRAM); • привлечение экспертов в области риск- • Systematic Testing (SST); менеджмента; • Product (PRisMa) [3]. • использование стандартных шаблонов из Применение данных техник позволяет предот- базы рисков; вратить появление дефектов в создаваемом про- • анализ ретроспективы проектов; дукте и, как следствие, сократить расходы произ- • «мозговой штурм».

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

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

например следующие: лить больше времени на тестирование данных об- 8 ’ 1. TDD (описанное в экстремальном програм- ластей потенциального скопления дефектов либо 1 мировании) – Test Driven Development (разработка обратиться к автоматизации для увеличения объ- через тестирование) – это техника разработки про- ема покрытия кода в потенциально «проблемных» граммного обеспечения, которая основывается на областях. повторении очень коротких циклов разработки: FMEA можно отнести к статическим видам ме- сначала пишется тест, покрывающий желаемое тодов предупреждения дефектов. изменение, затем пишется код, который позволит Любой проект следует завершать регламенти- пройти тест, и наконец проводится рефакторинг руемыми действиями: нового кода к соответствующим стандартам [6]. • проверка, что запланированные результаты Т.е. процесс TDD выглядит следующим образом: достигнуты; • как только сформулированы требования • закрытие отчетов о дефектах (инцидентах) к компоненту/функции системы, программист соз- или внесение изменений в записи по каждому из дает юнит-тест, проверяющий работу данного компо- «открытых» дефектов (инцидентах); нента/функции, в этот момент тесты не будут прохо- • завершение и архивирование тестового обе- дить успешно, т.к. код компонента еще не написан; спечения, тестового окружения и инфраструктуры • далее непосредственно реализуется код ком- тестирования для последующего использования; понента/функции и запускается тест, на теперь уже • анализ полученных уроков для определения в написанном и соответственно существующем изменений, необходимых для будущих проектов; коде компонента/системы; • использование собранной информации для • исправление ошибок осуществляется до тех повышения зрелости процесса тестирования. пор, пока юнит-тест не завершается успешным ре- Отметим, что для показательности эффективно- зультатом. го управления качеством ПО необходимо использо-

53 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

вание метрик процесса (метрики риска и метрики 6. URL: http://agiledata.org/essays/tdd.html. прогресса) и метрик продукта (метрики дефектов). 7. URL: http://www.kpms.ru/Implement/ Qms_FMEA.htm. Заключение Несмотря на ограничения в применении тех или иных методов тестирования в рамках Agile про- Realization of the Testing Process цесса, описанных выше, команда вправе применять in Agile-methodology любые из существующих методов тестирования, как статических, так и динамических, если сможет O.V. Erina, Executive director of LLC «Speys-O адаптировать их в рамках гибкой методологии без Tekhnologii»; Tomsk потери качества конечной продукции. e-mail [email protected] Как было сказано выше, методология Agile на- бирает обороты популярности, но компаниям-раз- Summary. In article the analysis of implementation работчикам ПО следует тщательнее продумывать of processes of testing is provided in Agile- methodologies: Agile Modeling, Agile Unified процесс тестирования, т.к. от него напрямую за- Process, Agile Data Method, Essential , висит качество производимого ПО. Несмотря на Extreme Programming, Feature Driven Development, слабую освещенность процесса тестирования ПО в Getting Real, Open UP, Scrum, Kanban. International experience in the field of the organization of process методологии Agile, современные методы тестирова- of quality management of the software within Agile ния позволяют «скомпоновать» успешную методо- is analyzed. On the basis of the general for all Agile- логию управления качеством ПО. like characteristics the list of the techniques of testing suitable for all flexible methodologies of was made and reasoned. Литература Keywords: flexible methodologies of development, 1. URL: http://agilemanifesto.org/iso/ru/manifes- testing of the software, quality of the software. to.html. References: 2. Криспин Лайза. Гибкое тестирование. Прак- тическое руководство для тесировщиков ПО и гиб- 1. http://agilemanifesto.org/iso/ru/manifesto.html. 2. Crispin Laisa, Gregory Janet Flexible testing. ких команд / Криспин Лайза, Грегори Джанет. – М: Practical guidance for software testers and flexible Изд-во Вильямс, 2016. – 464 с. commands. Publishing house Williams. Moscow, 2016. 3. ISTQB Syllabus Advanced Level, 2012. 464 p. 3. ISTQB Syllabus. Advanced Level. 2012. 4. «Agile Quality Assurance. Deliver Quality Sof- 4. Baah A. Agile Quality Assurance. Deliver Quality tware – Providing Great Business Value» by Anthony Software. Providing Great Business Value. 2016. Baah, 2016. 5. Heuer F. Agile testing. An Qverwiew. 2014. 6. http://agiledata.org/essays/tdd.html. 5. «Agile testing. An Qverwiew» by Florian Heu- 7. http://www.kpms.ru/Implement/Qms_FMEA. academquality.ru, ql–journal.ru er, 2014. htm.

54