katerinapod
katerinapod Ice bird
Итак, что это за ГОСТы для ПМИ?
1)ГОСТ 24.208-80 «ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ СТАДИИ «ВВОД В ЭКСПЛУАТАЦИЮ»» (http://it-gost.ru/content/view/108/39)
2) ГОСТ 34.603-92 «ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ» (http://it-gost.ru/content/view/57/39/)
3) РД 50-34.698-90 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ » (http://it-gost.ru/content/view/15/41/)
Итак, какие же «кусочки» относятся именно к ПМИ в этих ГОСтах?
1)ГОСТ 24.208-80 «ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ СТАДИИ «ВВОД В ЭКСПЛУАТАЦИЮ»» (http://it-gost.ru):
2. ТРЕБОВАНИЯ К ПРИЕМО-СДАТОЧНОЙ ДОКУМЕНТАЦИИ
2.7. Программа работ
2.7.1. В зависимости от содержания работ установлены следующие разновидности документов:
• программа испытаний;
• программа опытной эксплуатации;
• программа работ приемочной комиссии.
2.7.2. Документ «Программа испытаний» предназначен для определения порядка проведения и объема предварительных испытаний при передаче в опытную эксплуатацию и приемо-сдаточных испытаний при передаче в промышленную эксплуатацию АСУ.
Документ должен содержать:
• состав функций АСУ в целом или ее частей, подлежащих испытаниям, со ссылкой на пункты «Технического задания» на создание АСУ;
• перечень составляющих технического, программного, информационного и организационного обеспечений, подлежащих испытаниям;
• порядок действий при испытании отдельных составляющих обеспечения АСУ и отдельных функций АСУ;
• условия и сроки проведения испытаний;
• порядок регистрации испытаний и выявленных недостатков;
• порядок устранения недостатков и внесения необходимых изменений в техническую документацию;
• указание о форме представления результатов испытаний.
1.14. При испытаниях АС проверяют:
• качество выполнения комплексом программных и технических средств автоматических функций во всех режимах функционирования АС согласно ТЗ на создание АС;
• знание персоналом эксплуатационной документации ц наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования АС, согласно ТЗ на создание АС;
• полноту содержащихся в эксплуатационной документации указании персоналу по выполнению им функций во всех режимах функционирования АС согласно ТЗ на создание АС;
• количественные и (или) качественные характеристики выполнения автоматических и автоматизированных функций АС в соответствии с ТЗ;
• другие свойства АС, которым она должна соответствовать по ТЗ.
1.15. Испытания АС следует проводить на объекте заказчика. По согласованию между заказчиком и разработчиком предварительные испытания и приемку программных средств АС допускается проводить на технических средствах разработчика при создании условий получения достоверных результатов испытаний.
1.16. Допускается последовательное проведение испытаний и сдача частей АС в опытную и постоянную эксплуатацию при соблюдении установленной в ТЗ очередности ввода АС в действие.
2. ПРЕДВАРИТЕЛЬНЫЕ ИСПЫТАНИЯ
2.1. Предварительные испытания АС могут быть:
• автономные;
• комплексные.
2.2. Автономные испытания
2.2.1. Автономные испытания АС следует проводить в соответствии с программой и методикой автономных испытаний, разрабатываемых для каждой части АС.
2.2.2. В программе автономных испытаний указывают: • перечень функций, подлежащих испытаниям; • описание взаимосвязей объекта испытаний с другими частями АС; • условия, порядок и методы проведения испытаний и обработки результатов; • критерии приемки частей по результатам испытаний. К программе автономных испытаний следует прилагать график проведения автономных испытаний.
2.2.3. Подготовленные и согласованные тесты (контрольные примеры) на этапе автономных испытаний должны обеспечить: • полную проверку функций и процедур по перечню, согласованному с заказчиком; • необходимую точность вычислений, установленную в ТЗ; • проверку основных временных характеристик функционирования программных средств (в тех случаях, когда это является существенным); • проверку надежности и устойчивости функционирования программных и технических средств.
2.2.4. В качестве исходной информации для теста рекомендуется использовать фрагмент реальной информации организации-заказчика в объеме, достаточном для обеспечения необходимой достоверности испытаний.
2.2.5 Результаты автономных испытании частей АС следует фиксировать в протоколах испытаний. Протокол должен содержать заключение о возможности (невозможности) допуска части АС к комплексным испытаниям.
2.2.6. В случае, если проведенные автономные испытания будут признаны недостаточными, либо будет выявлено нарушение требований регламентирующих документов по составу или содержанию документации, указанная часть АС может быть возвращена на доработку и назначен новый срок испытаний.
2.3. Комплексные испытания
2.3.1. Комплексные испытания АС проводят путем выполнения комплексных тестов. Результаты испытаний отражают в протоколе. Работу завершают оформлением акта приемки в опытную эксплуатацию.
2.3.2. В программе комплексных испытаний АС или частей» АС указывают: • перечень объектов испытания; • состав предъявляемой документации; • описание проверяемых взаимосвязей между объектами испытаний; • очередность испытаний частей АС; • порядок и методы испытаний, в том числе состав программных средств и оборудования, необходимых для проведения испытаний, включая специальные стенды и полигоны.
2.3.3. Для проведения комплексных испытаний должны быть представлены: • программа комплексных испытаний; • заключение по автономным испытаниям соответствующих частей АС и устранение ошибок и замечаний, выявленных при автономных испытаниях; • комплексные тесты; • программные и технические средства и соответствующая им эксплуатационная документация.
2.3.4. При комплексных испытаниях допускается использовать в качестве исходной информацию, полученную на автономных испытаниях частей АС.
2.3.5. Комплексный тест должен: • быть логически увязанным; • обеспечивать проверку выполнения функций частей АС во всех режимах функционирования, установленных в ТЗ на АС, в том числе всех связей между ними; • обеспечивать проверку реакции системы на некорректную информацию и аварийные ситуации.
2.3.6. Протокол комплексных испытаний должен содержать заключение о возможности (невозможности) приемки АС в опытную эксплуатацию, а также перечень необходимых доработок и рекомендуемые сроки их выполнения. После устранения недостатков проводят повторные комплексные испытания в необходимом объеме.
3) РД 50-34.698-90 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ » (http://it-gost.ru/content/view/15/41/ или www.rugost.com)
(. )
2.14. Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
Как инженеры a1qa проводили приёмо-сдаточные испытания ПО: Часть 1. Теоретическая
Вот уже более двух лет команда a1qa работает на проекте по созданию платежной системы для одного крупного банка. Поначалу задачи нашей команды сводились только к тестированию системы, однако через некоторое время заказчик поручил нам подготовку и проведение приёмо-сдаточных испытаний.
Задача эта нетипичная для тестировщиков. Поэтому мы решили поделиться своим опытом и рассказать, как её грамотно выполнить, оправдав доверие заказчика.
Что такое приёмо-сдаточные испытания (ПСИ)?
Прежде чем выпускать продукт на рынок, заказчик должен убедиться в возможности использования разработанного решения, в его безопасности, надёжности, корректном функционировании и проверить другие характеристики, описанные в требованиях к продукту.
ПСИ особенно актуальны для проектов, на которых выпуск некачественного продукта может привести к значительным финансовым потерям (к слову, наш проект именно к таким и относится).
Итак, цели проведения ПСИ:
Избежать хаоса в подготовке и проведении ПСИ, развеять сомнения в методах убеждения и их эффективности помогают различные нормативно-правовые документы, которые стандартизируют процессы разработки и тестирования.
Один из таких документов, обязательный для любых приёмо-сдаточных испытаний, – это «Программа и методика испытаний».
Документ «Программа и методика испытаний»: что нужно знать тестировщику
Написанием и форматированием данного документа обычно занимаются специально обученные люди, например, технические писатели.
Однако знать, из чего состоит документ, тестировщику не помешает. Кроме того, подготовка одного из разделов может быть поручена именно тестировщикам.
Обратимся к официальной документации. Согласно межгосударственному стандарту ГОСТ 19.301-79, документ «Программа и методика испытаний» должен иметь следующую структуру:
Какой из разделов под силу подготовить функциональному тестировщику? Конечно же, «Методы испытаний». Об этом поговорим позже, а пока ещё немного теории.
Критерии успешности приёмо-сдаточных испытаний
Как правило, успешность ПСИ определяется на этапе заключения контракта. Одним из таких критериев может быть процент успешно пройденных во время демонстрации проверок. Например, если на проверку выносятся 100 тест-кейсов и критерий pass-rate составляет 80%, то 80 тест-кейсов должно быть успешно пройдено, иначе считается, что продукт приёмку не прошел, а значит, не может быть допущен к опытной и промышленной эксплуатации.
На практике же успешность приёмо-сдаточных испытаний чаще определяется не одним критерием, а совокупностью нескольких. Например, учитывается процент реализованных требований от общего числа и ограничение по количеству дефектов того или иного приоритета. Оперируя данными по этим критериям, принимается решение об успешности ПСИ.
На этом необходимая теория заканчивается. В следующей части расскажем, как приёмо-сдаточные испытания проводила команда a1qa и какие трудности ей пришлось преодолеть.
Каталог публикаций Интернет-изданий
переводы публикаций из социальной сети для учёных ResearchGate и из других открытых источников Интернета
Тестирование PMI (Positive Material Identification)
В настоящее время большинство производителей сплавов, нефтеперерабатывающих заводов и других предприятий, ответственных за проверку марки сплава, используют технологию для быстрого и простого разделения различных марок нержавеющей стали. Наиболее распространенным, портативным и простым в использовании инструментом для этой цели является портативный анализатор XRF (рентгенофлуоресцентный). Эти инструменты очень точны при определении химического состава сплавов и, следовательно, их марки. Более того, они делают это в течение 5 секунд или меньше для большинства марок нержавеющей стали, без значительной пробоподготовки и безопасно. Они окупаются за счет уменьшения путаницы материалов и получения наилучшей цены за идентификацию лома, и им не требуется никакого повышения квалификации для работы. Оператора можно обучить его использованию в течение нескольких часов.
Необходимость тестирования PMI в нефтегазовой и нефтеперерабатывающей отраслях стала очевидна еще в 1992 году, когда OSHA постановило, что необходимо применять PSM или управление безопасностью процесса для особо опасных химических веществ (HHC), чтобы помочь избежать несчастных случаев, травм и смерти. Признавая необходимость в руководстве по повышению безопасности в отношении этих выбросов HHC, OSHA в 2007 году разработало инструктивный документ, описывающий конкретный протокол для реализации Национальной программы акцентов (NEP) в надежде снизить или устранить эти типы опасностей на рабочем месте на нефтеперерабатывающих заводах. и другие химические заводы.
Из-за неотъемлемой опасности анализа материалов, которые находятся в процессе, необходимо использовать неразрушающие приборы. Это испытание квалифицирует анализ как неразрушающий контроль или неразрушающий контроль. Неразрушающий контроль (NDT) показывает, что материал никоим образом не изменен и находится практически в том же состоянии, что и до испытания, без видимых следов или структурных повреждений, оставшихся после анализа. Лучшим инструментом для неразрушающего контроля, когда для оценки не требуется уровень углерода, является портативный XRF.
Но на моем материале уже есть штамп, указывающий на материал?
PMI на каждом этапе: от склада до производства
Поскольку смешивание материалов может произойти на любой стадии процесса от производителя сплава до установки детали на нефтеперерабатывающем заводе, каждый нефтеперерабатывающий завод, химический завод, нефтехимический завод и т.д. Должен разработать программу проверки материалов, чтобы минимизировать это риск. Важно проверять каждый сплав и компонент несколько раз на каждом этапе; это известно как протокол 100% PMI. Программа проверки материалов / процесс PMI должны начинаться на складе поступающих материалов, где продукт может быть протестирован с помощью метода выборочной проверки PMI в рамках процесса получения. Помимо тестирования PMI, программа проверки материалов должна предоставлять полную и точную документацию, показывающую, какие материалы были протестированы и каковы были результаты.
Некоторые операторы заводов и нефтеперерабатывающих заводов исторически полагались на сертификаты состава или отчеты об испытаниях материалов от поставщиков; К сожалению, аудит и опыт показали, что эти методы менее чем на 100% надежны. Помимо отчетов, которые просто неточны, бывают также случаи, когда сертификаты состава или сертификаты анализа сопоставляются с неправильным материалом или просто отделяются от материалов, которым они соответствуют.
Затем необходимо выполнить PMI еще раз перед установкой новых компонентов, трубопроводов и т. Д. Для максимальной эффективности и безопасности должна быть внедрена программа 100% PMI (API 578), чтобы гарантировать, что каждая деталь устанавливается в среде с высокими требованиями к производительности. высокая температура, коррозия, высокое давление и т.д. соответствует требованиям, предъявляемым к требованиям окружающей среды.
Кроме того, может возникнуть необходимость в реализации программы PMI с обратной силой, в которой существующие трубопроводы и компоненты проходят контрольные испытания материалов в процессе производства. При оценке необходимости ретроактивной программы тестирования PMI и о том, как расставить приоритеты для трубопроводов и компонентов, подлежащих тестированию, необходимо учитывать несколько вещей, включая, помимо прочего:
Вероятность смешения материалов во время предыдущего проекта и работ по техническому обслуживанию
Возможные последствия отказа трубопровода или компонента
Тестирование программного продукта
Всем понятно, что программное обеспечение, разработанное для решения определенных задач должно решать эти определенные задачи. К сожалению, часто получается не совсем так. Программа, которая должна была выполнить простое действие, явно указанное на нажатой Вами кнопке, выполняет совсем другое – приводит Вас в ярость.
Содержание
Даже, если Вы настолько терпимы, что можете в течение получаса 18 раз перезапустить программу после сбоя и только после этого метнуть монитор точно в окно, Вы согласитесь с тем, что работа с данной программой была бы более комфортной, если бы она не «падала».
Как же сделать так, что бы случаи падения, зависания, невыполнения нужных действий разработанной Вами программы стали весьма редкими?
Точного ответа на данный вопрос нет. Но на протяжении столетий самые мудрые ученые годами думали на эту тему и, смогли таки, найти средство, которое если и не устраняет всех ошибок программы, то, по крайней мере, создает иллюзию деятельности по их устранению.
И это средство называется ТЕСТИРОВАНИЕ программного продукта.
По мнению мудрых людей, Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта[1].
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт «хорош» с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям.
Когда и кто?
По мнению опытных разработчиков, тестирование программного продукта должно проводиться прям с самого начала его создания. Но при этом, сами опытные разработчики в тестировании не должны принимать участия, так как не царское это дело. Тестировать программный продукт должны специально обученные сотрудники, называемые тестировщиками, ибо даже самый опытный разработчик не сможет увидеть свою ошибку, даже с использованием самых новейших оптических приборов.
Тем не менее, все разработчики сходятся во мнении, что тестирование программного продукта с точки зрения классификации по целям должно делиться на два класса:
Функциональное тестирование
Под функциональным тестированием понимается проверка соответствия программного продукта функциональным требованиям, указанным в техническом задании на создание это продукта. Если говорить проще, то при функциональном тестировании проверяется выполняет ли программный продукт все функции, которые должен.
Итак, Вы таки решились провести функциональное тестирование. Вы заглядываете в техническое задание, читаете функциональные требования и понимаете, что по крайней мере они расположены не в том порядке, в каком можно производить тестирование. Вы будете удивлены, что еще достаточно давно другие уже заметили это несоответствие и придумали как его преодолеть.
Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций.[2]
Обычно, функциональное тестирование проводится на двух уровнях:
Нефункциональное тестирование
Нефункциональное тестирование оценивает такие качества программного продукта, как, например, эргономику или производительность.
Думаю, важность данного вида тестирования понятна и не требует обоснования. Ведь всем понятно, что если, к примеру, производительность системы не достаточна, то пользователям придется по пол дня ждать отклика на свои действия, что может привести к их массовой спячке.
Как следует из названия, при нефункциональном тестировании проверяется соответствие программного продукта нефункциональным требованиям из технического задания на его создание. И, как в случае с функциональным тестированием, для нефункционально разрабатывается программа и методика испытаний.
Тестирование встроенного ПО и соблюдение стандартов в эру Agile
Соблюдение отраслевых стандартов – это не то, чем вы можете пренебречь или заняться позже; это неотъемлемая часть процесса разработки встроенного программного обеспечения (ПО). Для некоторых индустрий, — таких как авионика, автомобилестроение и здравоохранение, — строгое следование стандартам качества при разработке сложных и безотказных встроенных систем становится жизненно необходимым условием выпуска продукта на рынок. Традиционно, тестирование играет важную роль в разработке встраиваемых систем для регулируемых стандартами отраслей. Однако за последние годы устоявшиеся практики и процессы тестирования, их место и роль в подобных проектах значительно преобразились. Это резко изменило все правила игры, а когда правила игры меняются, необходимо меняться вместе с ними, чтобы выиграть.
В условиях постоянного развития новых, ультрасовременных технологий компаниям необходимо быстро предлагать рынку надежные, безопасные, простые в использовании и совместимые с другими системами продукты – просто чтобы не потеряться в быстро меняющемся технологическом мире. В такой ситуации традиционная каскадная модель, где процесс разработки ПО строго последователен и тестирование выполняется в самом его конце, уходит в прошлое. Большую популярность приобретают методы DevOps и Agile, поскольку они позволяют инженерам выполнять задачи, которые раньше следовали друг за другом, одновременно.
Исследование, проведенное Ауригой при поддержке независимой исследовательской компании LTM Research, показывает, что эта эволюция роли тестирования в цикле разработки ПО имеет огромное значение. При постоянном дефиците времени производители по-прежнему не могут пожертвовать качеством, надежностью и безопасностью своего продукта. К примеру, широко обсуждаемые сегодня беспилотные автомобили являются источником повышенной опасности, а значит, требуют неукоснительного соблюдения стандартов. Нельзя обойтись и без тестирования встроенного ПО, поскольку практически все решения в области IoT и Connectivity основаны на встроенных технологиях.
Все отрасли стремятся к инновациям, быстрому развитию и распараллеливанию процессов, и это делает тестирование встроенного ПО еще более важным. Здравоохранение, где стандарты традиционно очень высоки, отличает огромный спрос на сложные и сверхточные алгоритмы – такие как, например, алгоритм автоматического распознавания сердечных ритмов для инновационного дефибриллятора, над которым сейчас трудятся инженеры Ауриги. Новые интеллектуальные больничные системы, «умное» медицинское оборудование и носимые устройства, которые появляются почти каждый день, должны быть безопасными и надежными.
Тестирование производительности
В ходе этапа тестирования производительности в первую очередь проводят нагрузочное тестирование, целью которого является проверка, будет ли система адекватно реагировать на внешние воздействия в режиме, близком к режиму реальной эксплуатации.
Кроме нагрузочного тестирования проводят испытания в условиях минимальных аппаратных средств и максимальной нагрузки – стрессовое тестирование, а также, испытания в условиях предельных объемов обрабатываемой информации – объемное тестирование.
Выделяют еще один вид тестирования: тестирование стабильности и надежности, которое включает в себя не только длительное испытание программного продукта в нормальных условиях, но и способность его возвращаться в нормальный режим функционирования после непродолжительных периодов стрессовых нагрузок.
Документация для тестирования
Как уже было указано выше, тестирование проводится в соответствии с программой и методикой испытаний, которая разрабатывается в соответствии с ГОСТ 34.603-92.
Для проведения тестирования разрабатывается контрольный пример, который должен содержать достаточно данных для проверки всех режимов работы программного продукта. Обычно, контрольный пример создается совместно заказчиком и исполнителем на основе реальных данных.
Для проведения всех видов тестирования производительности чаще всего создается так называемый генератор данных, который позволяет в автоматическом режиме создать достаточное количество данных, для достижения объективного результата при оценке производительности.
В ходе проведения тестирования составляется протокол тестирования, куда заносится информация о прохождении всех этапов и шагов тестирования и замечаниях полученных на испытаниях.
Если результат тестирования отрицательный, проводится устранение недостатков и повторное тестирование.
Исследовательское тестирование
Нагрузочное тестирование
1. Генерация тестовых сценариев
Для эффективного анализа сценарии должны быть наиболее близки к реальным сценариям использования. Важно понимать, что всегда возможны исключения, и даже самый подробный план тестирования может не покрыть отдельно взятого случая.
2. Разработка тестовой конфигурации
Имея сценарии тестирования, важно распределить порядок возрастания нагрузки. Для успешного анализа необходимо выделить критерии оценки производительности (скорость отклика, время обработки запроса и т.д.).
3. Проведение тестового испытания
При проведении тестов важно своевременно следить за исполнением сценариев и откликом тестируемой системы. Для эмуляции высоких нагрузок требуется серьезная аппаратная и программная инфраструктура. В некоторых случаях для удешевления работ применяются методы математического моделирования. За основу берутся данные, полученные при низких нагрузках, и аппроксимируются. Чем выше уровень моделируемой нагрузки, тем ниже точность оценки. Однако подобный способ существенно сокращает расходы.
Автоматизация тестирования
Тестирование юзабилити
Конфигурационное тестирование
Интеграционное тестирование
Если в вашем проекте более одной компоненты, он нуждается в интеграционном тестировании. При сложной архитектуре приложения необходимым условием обеспечения качества является проверка на взаимодействие частей программы. Тестирование достигается путем разработки и проведения «сквозных» кейсов. Интеграционное тестирование проводится после компонентного. Поэтому очень важно учитывать опыт компонентного тестирования, при этом соблюдая бизнес-ориентацию тест-кейсов.
Стресс тестирование
У любой системы есть предел нормального функционирования. При превышении предела система попадает в состояние стресса и значительно меняет свое поведение. Стресс тестирование проверяет работу приложения в условиях превышения предлов нормального функционирования. Особенно это важно для «критичных» программ: банковского ПО, программ авиационной отрасли, медицины. Стресс тестирование проводят не только на стадии разработки программного обеспечения, но и на протяжении всего цикла функционирования с целью получения и обработки данных поведения системы за долгий период времени.
Исследования рынка тестирования ПО
2020: Только 13% российских компаний привлекают QA-специалистов на всех этапах разработки ПО
3 сентября 2020 года компания «Перфоманс Лаб» выпустила ежегодный отчет RQR 2020 (Russia Quality Report), отражающий состояние рынка услуг тестирования ИТ-продуктов и обеспечения их качества в 2020. В RQR 2020 описаны тренды и изменения в области тестирования и обеспечения качества ИТ-продуктов в России в 2020 году по сравнению с предыдущими годами на основе отзывов респондентов из разных областей.
В частности, опросы респондентов показали, что запросы на тестирование ИТ-продуктов растут с каждым годом на отечественном рынке. Бизнес понимает насколько важно для выпуска качественного продукта применять методы тестирования, но широкое распространение, в общем, тестирование ИТ-продуктов пока наблюдается не во всех областях, ввиду незнания процессов, дороговизны использования инструментов тестирования и других причин. Хотя есть много отраслей, где тестирование востребовано сегодня и имеет достаточно высокий спрос.
Как известно, создание программных решений высокого качества невозможно без их тестирования. Необходимо привлечение QA-команды (Quality Assurance) к работе над продуктом на ранних этапах. Такой подход также помогает своевременно выявить критические дефекты и впоследствии выпустить на рынок качественное ИТ-решение.
На момент опроса только 13% российских организаций и компаний привлекают к работе специалистов по тестированию на всех этапах жизненного цикла программного обеспечения. К сожалению, отечественный рынок пока не достиг зрелости в этом отношении. Однако показатель хоть и медленно, но неуклонно увеличивается: по сравнению с результатами предыдущего опроса его рост составил 5%.
В сравнении с опросом 2017-2018 годов, организации стали чаще привлекать отдел тестирования на ранних этапах жизненного цикла ПО. Специалисты по QA подключаются к работе на стадиях эксплуатации и поддержки (в 50% случаев), описания требований (50%), проектирования (46%).
Помимо этапа тестирования, в котором QA-специалисты принимают участие в 91% случаев, этих сотрудников также часто привлекают во время внедрения (61%) и разработки (57%) продукта.
Довольно постоянным показателем остается большое количество опрошенных компаний, которые, в первую очередь, привлекают свой отдел QA к задаче повышения качества ИТ-продуктов. Об этом заявило 80% участников исследования. 69% респондентов в качестве цели работы специалистов QA выбирают повышение удовлетворенности пользователей.
Роль автоматизированного тестирования в ИТ-процессах за последние годы стала многогранной. Заказчики услуги стремятся с ее помощью получить полный контроль над качеством разрабатываемого продукта и сократить время тестирования за счет исключения человеческого фактора.
По словам специалистов «Перфоманс Лаб», автоматизация позволяет обеспечить максимальное тестовое покрытие и эффективность применения тест-кейсов, приводит к оптимизации затрат, росту производительности труда и уменьшению сроков вывода продукта на рынок. Таким образом, автоматизированное тестирование становится оптимальным способом достижения целого ряда QA-целей. Большинство участников опроса (82%) используют для проверки качества разрабатываемых продуктов автотесты. Столько же респондентов занимаются развитием компетенций по автоматизированному тестированию у своих специалистов в области функционального тестирования.
Большинство респондентов (71%) понимают важность процедуры тестирования мобильных приложений и проводят ее.
Респонденты стали больше использовать Agile: число участников исследования, которые жалуются на отсутствие опыта применения гибких методологий, за последние два года сократилось. Гибкие методологии (Agile) продолжают завоевывать симпатии российских компаний и организаций. Еще четыре года назад такой подход применяли всего 43% опрошенных игроков рынка. В 2020 годах их количество увеличилось до 80%. Еще 17% респондентов указали на недостаточное понимание подходов Agile к тестированию.
По наблюдению исследователей, в российских компаниях есть некоторая инерция в вопросе смены инструментов для тестирования, скорее это постепенный процесс. Респонденты отметили, что большинство из них используют одновременно не менее трех различных инструментов. Сложности перехода на новые продукты зачастую связаны для кого-то с высокой стоимостью перехода, незнанием рынка QA-продуктов. По результатам отчета телеком и eCommerсe индустрии выглядят наиболее гибкими и готовы рассматривать отечественные продукты по сравнению, например, с банковским сектором. Только 14% респондентов ограничивают использование зарубежных инструментов для организации тестирования в рамках программы импортозамещения. Несмотря на то, что большая часть игроков российского рынка все еще отдает предпочтение иностранным инструментам тестирования, число компаний и организаций, которые ограничивают их использование, по сравнению с предыдущим отчетом увеличилось на 8%.
В период сбора данных для отчета 2020 года угроза распространения коронавирусного заболевания Covid-19 еще не была столь остра. Однако уже ясно, что пандемия внесла свои изменения в жизнь и в бизнес. Бюджеты, выделенные на сферу ИТ, в общем, и на тестирование, в частности, сокращаются. Одновременно, поставщики услуг и специалистов в сфере QA будут переходить на удаленный формат работы. Также видно, что текущий кризис не нанесет серьезного урона отраслям, связанным, в первую очередь, с цифровым контентом.
Ритейл в большей части удержал свои позиции, проще оказалось тем, кто работает через онлайновые каналы продаж. По eCommerce также прошлась волна кризиса, но не так сильно, как по другим областям.
Все банковские организации, принявшие участие в опросе, проводят тестирование своих ИТ-продуктов. Из таких банковских компаний 81% имеют в штате соответствующих специалистов, 63% содержат профильный отдел и еще 63% пользуются аутсорсинг-услугами в этой сфере.
В целом, по отчетам RQR, собственный отдел по тестированию ПО имеют 67% респондентов. В штате 65% опрошенных компаний и организаций есть соответствующие специалисты. Наконец, 39% игроков рынка, принявших участие в исследовании, пользуются аутсорсинг-услугами для тестирования на регулярной основе.
Представители государственного сектора чаще отмечали, что имеют собственный отдел по тестированию или в крайнем случае используют аутсорсинг-услуги. Системные интеграторы предпочитают держать на проектах необходимых сотрудников. К аутсорсинг-услугам чаще прибегают в финансовом и государственном секторах. Популярность аутсорсинга в сферах телекоммуникации, электронной коммерции и системной интеграции ниже: только четверть опрошенных игроков этих рынков используют такой формат работы для тестирования ПО.
Кроме того, более трети организаций, принявших участие в опросе (38%), имеют в своем штате специалиста, ответственного за цифровую трансформацию. Например, такие сотрудники помогают развивать бизнес 58% респондентам, работающим в банковской сфере. Аналогичный подход исповедуют 50% наших собеседников из государственного и телекоммуникационного секторов. В то же время, ни один из опрошенных системных интеграторов к этой практике не прибегает.
Число российских компаний и организаций, использующих возможности искусственного интеллекта, растет. Так, в 2017-2018 гг. эти технологии не применяли 77% респондентов. По данным RQR 2020, их доля сократилась до 68%. Работает с ИИ 32% участников опроса.
Технологии искусственного интеллекта входят и в область обеспечения качества (QA): чуть менее половины (44%) опрошенных игроков рынка заявили, что уже используют ИИ и аналитику для оптимизации QA. Самой популярной причиной использования искусственного интеллекта является автоматизация: так ответили 62% респондентов. Эти технологии также активно применяются в целях предсказательной аналитики (в практике 31% респондента).
Машинное обучение (Machine learning) – одна из областей искусственного интеллекта, в ней применяются методы по «обучению» аналитических систем посредством решения большого числа похожих задач. Только 19% участников опроса заявили о наличии опыта тестирования продуктов машинного обучения. Быстрее всего эту технологию взяли на вооружение в банковской сфере: о ее применении заявили 33% опрошенных представителей отрасли.
Что касается технологии блокчейн, то ее возможностями пользуются только 3% участников опроса.