Что такое пше в кадрах

Смирнов_для цитаты на сайте.jpg

Друзья, приветствую. На связи Игорь Смирнов, генеральный директор компании «КонсультантКиров».

Ну что же, вот и пришло время объявить главный HR-слёт года. Слёт всех тех, для кого актуальна работа в новых условиях. Всех тех, кто не собирается жить прошлым, а готов активно осваивать HR-тренды новой эпохи.

Встречайте: третий год на образовательной площадке «КонсультантКиров», но каждый раз совершенно новая — ОБЛАСТНАЯ НЕДЕЛЯ «HR И КАДРЫ»: профессиионалы43.рф.

Наша 10-дневная бесплатная (да, я считаю, что эти знания должны быть доступны всем) тематическая неделя пройдёт 15–24 мая. И я вам скажу, что опыт, знания, открытия, которыми наши спикеры хотят поделиться, ещё никогда не кипели так интенсивно.

А теперь переходим к делу! Программа потрескивает от объёма, но, как известно, мы живём в эпоху перемен — и оставить Вас без руководства к действию мы не можем.

15 мая. Вебинар эксперта Государственной инспекцией труда по Кировской области «Профилактические визиты и контрольно-надзорная деятельность ГИТ в 2023 году». Дорожная карта по изменениям для работы в 2023 году.

16 мая. Вебинар HR-аналитика HeadHunter Анны Осиповой «Как испортить вакансию: типичные ошибки работодателей». Рекомендации по составлению вакансий для хороших откликов.

17 мая. Семинар преподавателя Учебно-методического центра «КонсультантКиров» Елены Суслопаровой «ТОП-5 вопросов по персональным данным». Инструкция, как не попасть на штрафы.

18 мая. Вебинар управляющего кадрового агентства Life Job, директора по найму в федеральной b2b компании Анна Шумайловой «Как перестать страдать от проблем с персоналом. Решение проблем с персоналом «один раз и навсегда». HR-стратегия на 2023 год по найму, удержанию и поддержке сотрудников.

22 мая. Вебинар психолога федерального проекта «Наставничество», руководителя психологического Центра «Два Крыла» (г. Киров) Артема Скобелкина «Гореть работой, а не на работе. Профилактика выгорания персонала». Неочевидные, секретные и авторские методики борьбы с выгоранием.

23 мая. Семинар преподавателя Учебно-методического центра «КонсультантКиров»Марины Халявиной «Воинский учет в организации». Проверяем процедуру, вносим корректировки, говорим про новые обязанности из-за закона «об электронных повестках».

24 мая. Мастер-класс бизнес-тренера «КонсультантКиров» Анны Ильиной «Жизнь и работа в турбулентное время».Инструменты для жизни на высоких скоростях.

Участие бeсплатное, но обязательно нужно пройти регистрацию на профессиионалы43.рф.

— Вы можете участвовать в каждом образовательном событии или выбрать интересные для себя.

— Записи всех занятий останутся навсегда, и Вы сможете вернуться к ним по мере необходимости.

— Кстати, все зарегистрированные участники смогут пройти тест профзнаний (ничего каверзного, все вопросы из практики) и попасть в 20-ку лучших по профессии или ТОП-10 студентов в категории «HR и кадры» в Кировской области.

Ну что же, как по мне, так областная Неделя «HR и кадры» — это главное профессиональное событие для кадровой службы!

Проверка ГИТ: когда ждать инспектора и на кого распространяется мораторий

Государственная инспекция по труду (ГИТ) следит за тем, как компании и ИП соблюдают трудовое законодательство, для этого периодически приходит с проверками. Что и как будут проверять контролирующие органы и к кому точно не придут в 2022 году, расскажем в статье.

Какие проверки ГИТ на 2024 год ожидать работодателям

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

Плановая проверка ГИТ

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

Образец заявления можно скачать здесь.

Будет ли в 2024 году проверка ГИТ именно в вашей компании, легко узнать на сайте Роструда , посмотрев план проверок на год. Такую проверку ведомство может заменить инспекционным визитом, который применяют с 2021 года (ст. 56 Закона от 31.07.2020 № 248-ФЗ ). Он длится один день, перед этим трудовая инспекция связывается с компанией и просит предоставить необходимые документы.

Из новых видов плановых проверок в 2022 году появилось наблюдение за тем, как соблюдают требования закона. Инспекторы запрашивают информацию в фондах, анализируют отчетность, которую сдают компании и ИП, и по результатам направляют письменное предупреждение или инспектора для проверки по факту. Например, если в отчетности фигурируют много договоров ГПХ, это знак для инспекторов «взять компанию на карандаш».

По виду инспекционные мероприятия делятся на документарные и выездные. Еще бывает рейд и выездное обследование.

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

Рейд проводится только по согласованию с прокуратурой. Под проверку попадают все, кто управляет объектом, который будут инспектировать, и те, кто там работает (ст. 71 Закона № 248-ФЗ). В рейдовый осмотр попадают не только производственные объекты, но и административные здания, в которых несколько компаний арендуют помещения.

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

Внеплановая проверка ГИТ

О внеплановой проверке трудовая инспекция предупреждает за 24 часа. Инициируют ее если:

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

Внеплановая проверка всегда выездная. Если сотрудник компании погиб или пострадал в результате работы, то проверяющие придут без предупреждения (ч.17 ст. 10 Закона от 26 декабря 2008 г. № 294-ФЗ) Также в случае, если работник написал заявление о нарушении его трудовых прав или о том, что компания в целом не соблюдает трудовое законодательство. Но если он подал заявление анонимно, в этом случае ГИТ не проводит внеплановую проверку.

Что проверяет трудовая инспекция и как подготовиться

Документы, которые будут смотреть в процессе проверки ГИТ не изменились. Обычно это информация:

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

Если инспекторы придут с плановой проверкой, то сообщат об этом за три дня, поэтому есть время подготовиться, привести в порядок бумаги и изучить информацию в проверочных листах (Ст. 53 закона № 248-ФЗ от 31.07.2020). По ним работники контролирующего органа будут задавать вопросы.

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

С 11 марта 2022 года вступили в силу новые проверочные листы (Приказ Роструда от 01 февраля 2022 г. №20 ). Количество проверочных листов сократили. Теперь их будет 78. Появились и новые листы: по ведению и хранению бумажных трудовых книжек и формированию электронных трудовых; по дистанционным работникам; по привлечению к дисциплинарной ответственности. Увеличили также и список вопросов в проверочных листах.

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

Мораторий на проверки в 2023 году

В конце 2023 года правительство продлило мораторий на проверки до конца 2024 года (Постановление Правительства РФ от 14.12.2023 N 2140 ).

Напомним, что 2022 году правительство ввело мораторий на проверки бизнеса в связи со сложной для страны экономической обстановкой (Постановление Правительства от 10.03.2022 № 336 ).

Однако ГИТ может прийти с внеплановой проверкой даже в мораторий при массовой невыплате зарплаты – свыше 10 процентов среднесписочной численности или более 10 человек (ПП РФ от 10.11.2022 № 2036).

Важно! Мораторий на проверки в 2024 году не распространяется на проверки прокуратуры, военкомата, ФНС, Роскомнадзор, МВД. Эти ведомства к вам могут прийти с проверкой, несмотря на мораторий.

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

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

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

ОПТИМИЗАЦИЯ ВРЕМЕННЫХ ЗАТРАТ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА С ПРИМЕНЕНИЕМ ТЕХНОЛОГИИ GIT Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Иванников Дмитрий Владимирович, Копий Анна Александровна

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

SOFTWARE PRODUCT TESTING TIME OPTIMIZATION WITH GIT TECHNOLOGY USAGE

The purpose of this scientific work is to reduce the lifetime of a program defect by using automated testing. Testing is an integral part of software product development. The testing process itself consists not only of the search for defects in the developed system, but also of their tracking. Error tracking is the process of recording the stages of a defect’s life cycle from occurrence to its complete elimination. This process can be formalized and automated well. The authors of this paper suggest decomposing the error tracking process into its individual components. The decomposition of the error tracking process shows that the errors liquidation speed depends on the final decision on the choice of the person responsible for the shortcomings in the system. The choice of the person responsible is an extremely important stage in correcting a defect in the system, because error correction is the only part in the defect life cycle that cannot be automated. Therefore, the incorrect choice of the responsible person can greatly increase the time of correction of the error. To solve this problem, it is proposed to use the technology of the Git version control system. This system was created to track and record changes in the software development process. This paper proposes to identify the authors of the defective code using the functionality of the Git system and use this information for a more targeted selection of the person responsible for the existing defect in the program. Together with automated tests, this solution brings an increase in the defect liquidation speed, which positively affects both the quality of the product and the speed of development.

Текст научной работы на тему «ОПТИМИЗАЦИЯ ВРЕМЕННЫХ ЗАТРАТ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА С ПРИМЕНЕНИЕМ ТЕХНОЛОГИИ GIT»

Оптимизация временных затрат тестирования программного продукта с применением технологии Git

Иванников Дмитрий Владимирович

студент 1 курса аспирантуры кафедры УИТС ФГБОУ ВО МГТУ «СТАНКИН» г. Москва, Россия, ivannikov.dmitry.v@gmail.com Копий Анна Александровна

студентка 2 курса магистратуры кафедры УИТС ФГБОУ ВО МГТУ «СТАНКИН» г. Москва, Россия, ncopiy@ya.ru

Введение: Целью настоящей работы является уменьшение времени жизни недостатка программы с помощью автоматизированного тестирования. Тестирование является неотъемлемой частью разработки программного продукта. Сам процесс тестирования состоит не только из поиска дефектов в разрабатываемой системе, но также из их учета. Учет ошибок — это процесс фиксации этапов жизненного цикла дефекта от возникновения до полной его ликвидации. Данный процесс хорошо поддается формализации и автоматизации. Авторами данной работы предлагается декомпозировать процесс учета ошибок на отдельные его составляющие. Декомпозиция процесса учета ошибок показывает, что от финального решения о выборе ответственного за недостаток в системе зависит скорость исправления найденной ошибки. Выбор ответственного является исключительно важной стадией исправления дефекта в системе, поскольку исправление ошибки является единственной частью в жизненном цикле найденного дефекта, которая не поддается автоматизации. Следовательно, некорректный выбор ответственного может сильно увеличивать время исправления ошибки. Для решения данной проблемы предлагается использовать технологии системы контроля версий Git. Данная система была создана для отслеживания и фиксации изменений в процессе разработки программного обеспечения. В настоящей работе предлагается выявлять авторов дефектного кода с помощью функционала системы Git и использовать эту информацию для более таргетированного выбора ответственного за существующий недостаток в программе. В совокупности с автоматизированными тестами данное решение приносит увеличение скорости исправления недостатка в системе, что позитивно сказывается как на качестве продукта, так и на скорости разработки.

КЛЮЧЕВЫЕ СЛОВА: построение процесса тестирования; разработка программного продукта; системы контроля версий; тестирование программного продукта; git.

Назначение тестирования — это в первую очередь поиск ошибок [1]. Ошибки — это не соответствие ожидаемому поведению программы. Отсюда следует вывод, что перед разработкой любого программного продукта необходимо документально зафиксировать его ожидаемое поведение. Такие документы принято называть постановкой программного обеспечения [2]. Данные документы является ключевыми для отдела тестирования, так как на их основе создаются тест-кейсы — списки действий, каждое из которых проверяет определенную часть спецификации проекта [3].

Таким образом, компания обеспечивает полный цикл разработки программного продукта, включающий в себя: определение потребностей пользователей, постановка задачи, разработка функционала, тестирование, исправление ошибок, предоставление конечным пользователям нового функционала [4]. Перечисленные этапы имеют циклический характер, поскольку разработка программного продукта ведется итеративно. Этап тестирования заключается не только в поиске ошибок, но и в дополнении существующих тест-кейсов, тесном взаимодействии с управляющим проекта и командой разработчиков и, что самое важное, учете ошибок. Учёт ошибок — это довольно ресурсоемкий процесс, который в среднем может отнимать до половины всего времени выделенному отделу на одну итерацию тестирования [5].

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

Организация базового процесса тестирования программного продукта

Зачастую малые компании обходятся без отдела тестирования [6]. Действительно, на первых итерациях разработки, реализация минимального жизнеспособного продукта требует небольшого количества тест-кейсов [7]. Необходимое время на их проверку также невелико, что позволяет разработчикам самостоятельно проверять функционал приложения. Однако это становится экономически неэффективным в случае, если время, необходимое на тестирование, занимает полноценный рабочий день разработчика. В таком случае отдел разработки дополняют отделом тестирования, обеспечивая тем самым более качественную проверку конечного продукта [8].

Следующим этапом развития тестирования в рамках компании является автоматизация тестирования, которая освобождает отдел тестирования от ручного прохода тест-кейсов в пользу использования автоматических инструментов тестирования [9].

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

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

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

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

Анализ временных затрат при проведении процесса тестирования

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

Tdlt = N * (Tatr + Trp + Tdpp)

• Tdlt — время жизни дефекта в ПО

• N — количество итераций, требуемых для полного устранения недостатка

• Tatr — время выполнения автоматических тестов

• Trp — время подготовки отчета об ошибке

• Tdpp — время анализа программистом причин возникновения недостатка, выявления методов его исправления, а также время на исправление

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

К первой группе относятся следующие метрики: Tatr, поскольку является изначально автоматизированным процессом; Trp, поскольку возможно реализовать систему автоматического учета ошибок с составлением отчетов [14].

Вторая же группа включает в себя как минимум один параметр, предполагающий непосредственное участие человека: Tdpp. Данное время зависит не только от компетенций исполнителя, но и от уровня вовлеченности в настоящий проект [15]. В случае если разработчик был ранее не знаком с работой модуля, где обнаружился недостаток, это время будет больше, чем время, необходимое более вовлеченному разработчику. Следовательно, уменьшение этого времени может быть достигнуто в двух случаях:

1. При увеличении уровня вовлеченности разработчиков во все модули разрабатываемой системы,

2. При более таргетированном выборе ответственного за ошибку.

Средство учёта ошибок с применением технологии Git

Критические ошибки зачастую сопровождаются отладочной информацией — трассировкой стека (stack trace), которая представляет собой последовательный набор активных кадров стека в момент возникновения исключительной ситуации и совокупной информацией о возникшей проблеме (рис. 1) [16].

Traceback (most recent call last) :

File 1 ‘main.py», line 8, in

e — ZeroDivisionError(‘division bv zero’)

File 1 ‘/honie/a/Worksoace/oaaer/f ile2. i ._», line 7, in calculate

res. .append(division(i, n — i))

res — [0.0, B.16666666666666666, 0. Л, 0.75, 1.3333333333333333, 2.5, 6.B]

File 1 14, line 2, in division

ZeroDivisionError: division by zero

Рис. 1. Stack trace исключительной ситуации в программе на языке программирования Python

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

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

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

Система контроля версий Git изначально предназначена для последовательной фиксации изменений в коде в рамках разработки ПО [18]. Каждое выделенное изменение обладает рядом характеристик [19]:

• автор изменения (имя, email)

Данные характеристики можно включить в перечень локальных аргументов в стековом кадре (рис. 2).

Traceback Cmost recent call last): File «main.py», line 9, in calculateilS, 7)

calculate = e = ZeroDivisionErrort’division by zero’) File «/home/a/’i4orkspace/paper/file2. py». line 7, in calculate res.append(division(i, г — i)) blame = ■

‘пате’: ‘First Programmer1, «message1: «Fix division’,

1commit_with_branch_or_first_tag’ : 10.1.5 ‘, ■date’: ‘2020-05-07102:17:07+03:00’

res = [0.0, 0.Ii6666666i66i6666, 0.4, 0.75, 1.3333333333333333, 2.5, 6.0] rng = 10

File «/home/a/’i’lorkspace/paper/filel. py». line 2, in division return x / у blame = ■

‘пате’: ‘Second Programmer’, «message1: ‘Add calculate method’, ‘commit_with_branch_or_first_tag’: ‘0.1.Э’, ‘date’: ‘2020-04-08T22:14:12+03:001

ZeroDivisionError: division by zero

Рис. 2. Расширенный stack trace исключительной ситуации в программе на языке программирования Python.

Анализ временных затрат при проведении тестирования с применением разработанной методики

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

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

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

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

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

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

1. Khan M. E. Different forms of software testing techniques for finding errors //International Journal of Computer Science Issues (IJCSI). 2010. Т. 7. №. 3. С. 24.

2. Jebreen I., Wellington R. Understanding requirements engineering practices for packaged software implementation //2013 IEEE 4th International Conference on Software Engineering and Service Science. IEEE, 2013. С. 229-234.

3. Rothermel G. et al. Test case prioritization: An empirical study //Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM’99).’Software Maintenance for Business Change'(Cat. No. 99CB36360). IEEE, 1999. С. 179-188.

4. Alting L. Life cycle engineering and design //Cirp Annals. 1995. Т. 44. №. 2. С. 569-580.

5. Fiaz A. S., Devi N., Aarthi S. Bug Tracking and Reporting System //arXiv preprint arXiv:1309.1232. 2013.

6. Karlstrom D., Runeson P., Norden S. A minimal test practice framework for emerging software o r-ganizations //Software Testing, Verification and Reliability. 2005. Т. 15. №. 3. С. 145-166.

7. Racolta-Paina N. D., Andries A. M. Identifying entrepreneurship readiness for the application of the Lean Startup practices in the service industry-Case study Romania //Ecoforum Journal. 2017. Т. 6. №. 3.

8. Ramler R., Wolfmaier K. Economic perspectives in test automation: balancing automated and manual testing with opportunity cost //Proceedings of the 2006 international workshop on Automation of software test. 2006. С. 85-91.

9. Leitner A. et al. Reconciling manual and automated testing: The autotest experience //2007 40th Annual Hawaii International Conference on System Sciences (HICSS’07). IEEE, 2007. С. 261a-261a.

10. Qing-Biao L. I. U. et al. System and method for rapidly diagnosing bugs of system software : заяв. пат. 11943985 США. 2009.

11. Cristian F. Exception handling and software fault tolerance //Reliable Computer Systems. Springer, Berlin, Heidelberg, 1985. С. 154-172.

12. Hooimeijer P., Weimer W. Modeling bug report quality //Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. 2007. С. 34-43.

13. McKeeman W. M. Differential testing for software //Digital Technical Journal. 1998. Т. 10. №. 1. С. 100-107.

14. Lenarduzzi V. et al. Prioritizing corrective maintenance activities for android applications: An industrial case study on android crash reports //International Conference on Software Quality. Springer, Cham, 2018. С. 133-143.

15. Gregory A. et al. Effects of a professional development program on behavioral engagement of students in middle and high school //Psychology in the Schools. 2014. Т. 51. №. 2. С. 143-163.

16. Schroter A. et al. Do stack traces help developers fix bugs? //2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 2010. С. 118-121.

17. Lee G. L. et al. Benchmarking the Stack Trace Analysis Tool for BlueGene/L //PARCO. 2007. С. 621-628.

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

18. Chacon S., Straub B. Pro git. Apress, 2014.

19. Fry T. et al. A Dataset and an Approach for Identity Resolution of 38 Million Author IDs extracted from 2B Git Commits //arXiv preprint arXiv:2003.08349. 2020.

SOFTWARE PRODUCT TESTING TIME OPTIMIZATION WITH GIT TECHNOLOGY USAGE

Dmitry V. Ivannikov

Moscow, Russia, ivannikov.dmitry.v@gmail.com Anna A. Copiy

Moscow, Russia, ncopiy@ya.ru

Introduction: The purpose of this scientific work is to reduce the lifetime of a program defect by using automated testing. Testing is an integral part of software product development. The testing process itself consists not only of the search for defects in the developed system, but also of their tracking. Error tracking is the process of recording the stages of a defect’s life cycle from occurrence to its complete elimination. This process can be formalized and automated well. The authors of this paper suggest decomposing the error tracking process into its individual components. The decomposition of the error tracking process shows that the errors liquidation speed depends on the final decision on the choice of the person responsible for the shortcomings in the system. The choice of the person responsible is an extremely important stage in correcting a defect in the system, because error correction is the only part in the defect life cycle that cannot be automated. Therefore, the incorrect choice of the responsible person can greatly increase the time of correction of the error. To solve this problem, it is proposed to use the technology of the Git version control system. This system was created to track and record changes in the software development process. This paper proposes to identify the authors of the defective code using the functionality of the Git system and use this information for a more targeted selection of the person responsible for the existing defect in the program. Together with automated tests, this solution brings an increase in the defect liquidation speed, which positively affects both the quality of the product and the speed of development.

Keywords: building a testing process; software product development; version control systems; software product testing; git.

1. Khan M. E. Different forms of software testing techniques for finding errors.International Journal of Computer Science Issues (IJCSI). 2010. T. 7. №. 3. 24 p.

2. Jebreen I., Wellington R. Understanding requirements engineering practices for packaged software implementation. 2013 IEEE 4th International Conference on Software Engineering and Service Science. IEEE, 2013. Pp. 229-234.

3. Rothermel G. et al. Test case prioritization: An empirical study. Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM’99).’Software Maintenance for Business Change'(Cat. No. 99CB36360). IEEE, 1999. Pp. 179-188.

4. Alting L. Life cycle engineering and design. Cirp Annals. 1995. T. 44. №. 2. Pp. 569-580.

5. Fiaz A. S., Devi N., Aarthi S. Bug Tracking and Reporting System. arXiv preprint arXiv:1309.1232. 2013.

6. Karlstrom D., Runeson P., Nordén S. A minimal test practice framework for emerging software organizations. Software Testing, Verification and Reliability. 2005. T. 15. №. 3. Pp. 145-166.

7. Racolta-Paina N. D., Andries A. M. Identifying entrepreneurship readiness for the application of the Lean Startup practices in the service industry-Case study Romania. Ecoforum Journal. 2017. T. 6. №. 3.

8. Ramler R., Wolfmaier K. Economic perspectives in test automation: balancing automated and manual testing with opportunity cost. Proceedings of the 2006 international workshop on Automation of software test. 2006. Pp. 85-91.

9. Leitner A. et al. Reconciling manual and automated testing: The autotest experience. 2007 40th Annual Hawaii International Conference on System Sciences (HICSS’07). IEEE, 2007. Pp. 261a-261a.

10. Qing-Biao L. I. U. et al. System and method for rapidly diagnosing bugs of system software : 11943985 USA. 2009.

11. Cristian F. Exception handling and software fault tolerance. Reliable Computer Systems. Springer, Berlin, Heidelberg, 1985. Pp. 154-172.

12. Hooimeijer P., Weimer W. Modeling bug report quality. Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. 2007. Pp. 34-43.

13. McKeeman W. M. Differential testing for software. Digital Technical Journal. 1998. T. 10. №. 1. Pp. 100-107.

14. Lenarduzzi V. et al. Prioritizing corrective maintenance activities for android applications: An industrial case study on android crash reports. International Conference on Software Quality. Springer, Cham, 2018. Pp. 133-143.

15. Gregory A. et al. Effects of a professional development program on behavioral engagement of students in middle and high school. Psychology in the Schools. 2014. T. 51. №. 2. Pp. 143-163.

16. Schroter A. et al. Do stack traces help developers fix bugs? 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 2010. Pp. 118-121.

17. Lee G. L. et al. Benchmarking the Stack Trace Analysis Tool for BlueGene/L . PARCO. 2007. Pp. 621-628.

18. Chacon S., Straub B. Pro git. Apress, 2014.

19. Fry T. et al. A Dataset and an Approach for Identity Resolution of 38 Million Author IDs extracted from 2B Git Commits. arXiv preprint arXiv:2003.08349. 2020.

НОВЫЕ ФОРМЫ ПРОВЕРОЧНЫХ ЛИСТОВ ГИТ

С 11 марта 2022 года вступил в силу приказ Федеральной службы по труду и занятости от 01.02.2022 № 20 «Об утверждении форм проверочных листов (списков контрольных вопросов) для осуществления федерального государственного контроля (надзора) за соблюдением трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права».

Документом утверждены 78 новых форм.

По ним инспекторы ГИТ проконтролируют порядок:

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

Поверочные листы можно найти ЗДЕСЬ

Что такое пше в кадрах