Статистический подход в тестировании программного обеспечения

Аннотация. Как и в других сферах деятельности человечества, статистический подход, в тестировании, в обеспечении качества помогает создавать более совершенные стратегии планирования, проведения и завершения процесса тестирования, аккумулируя и анализируя данные в реальных текущих процессах разработки программного обеспечения. Хорошо проанализированная статистика может показать узкие места всего процесса производства программного обеспечения. Принятые меры и изменения процессов разработки программного обеспечения, согласно собранной и проанализированной статистике, могут значительно снизить затраты, сократить сроки поставки и увеличить уровень качества программного обеспечения. Используемый Data driven подход делает такие этапы как, тестирование и разработку эффективной, гибкой и оперативной благодаря четкому отражению в конкретных цифрах текущее положение ваших процессов. В результате, эта исследовательская работа помогает менеджеру отдела тестирования определить текущую ситуацию в организации и поможет им принять лучшее решение для улучшения производительности процесса тестирования, разработки ПО.

Abstract. As in other spheres of human activity, the statistical approach, in testing, in quality assurance, helps to create better strategies for planning, conducting and completing the testing process, accumulating and analyzing data in actual current software development processes. Well-analyzed statistics can reveal the bottlenecks of the entire software production process. Measures taken and changes in software development processes, according to statistics collected and analyzed, can significantly reduce costs, shorten delivery times and increase software quality. Used Data driven approach makes such steps as, testing and development effective, flexible and operational due to a clear reflection in specific numbers of the current position of your processes. As a result, this research work helps the testing department manager determine the current situation in the organization and help them make the best decision to improve the performance of the testing and software development process.

Ключевые слова: Тестирование, Обеспечение качества, data driven подход.

Keywords: Testing, quality assurance, data driven approach.

Введение

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

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

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

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

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

Создание.

• Дизайн - получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля согласно потребностям бизнеса.
• Кодирование - разработка, написание исходного кода
• Тестирование - проверка программы на соответствие всем предъявленным к ней требованиям. Тестирование тесно связано с такими этапами разработки программного обеспечения как проектирование и реализация. В систему встраиваются специальные механизмы, которые дают возможность производить тестирование системы на соответствие требований к ней, проверку оформления и наличие необходимого пакета документации. Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.
• Документирование - передача накопленных знаний пользователям и другим разработчикам.

Модели разработки программного обеспечения

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

• Каскадная (Waterfall)
• Гибкая (Спиральная, Инкрементальная, Итерационная, Scrum, Kanban, ScrumBan)

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

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

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

Таблица 1.

Сравнение гибкого цикла и каскадного цикла разработки ПО

Статистика

Количественный учёт всякого рода массовых случаев явлений.  Слово «статистика» происходит от латинского status — состояние дел. В науку термин «статистика» ввёл немецкий учёный Готфрид Ахенвалль в 1746 году. Есть ряд методологии исследования и обработки материалов: массовые статистические наблюдения, метод группировок средних величин, индексов, балансовый метод, метод графических изображений, кластерный, дискриминантный, факторный и компонентный анализы. В рамках текущей статьи мы будем использовать самый простой метод, метод массового статистического наблюдения.

Предмет наблюдения

В качестве основных сущностей наблюдения, в контексте процессов и процедур разработки и тестирования  ПО, будем рассматривать следующие сущности:

• Баги
• Задачи
• Метрики

Баг.  Жаргонное слово, обычно означает ошибку, дефект в приложении.

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

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

Предлагаемый формат статистики.

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

Найденные баги будем считать в следующих контекстах:

• при тестировании. Количество багов, которые были найдены именно в процессе тестирования, в dev окружении. Можно считать эти данные как оценка деятельности разработчиков-кодеров.
• на продакшине. Количество багов, которые были найдены непосредственно в продуктивной среде. Это будет одним из прямых  показателей деятельности отдела тестирования в организации.
• приоритетные(priority). Количество багов, решение которых является приоритетными с точки зрения бизнеса.
• серьезные(severity). Количество багов, решение которых является приоритетным с точки зрения влияния бага на функционал продукта.
• Общее количество. Количество всех багов найденных за определенный период.

Выглядеть это будет так, к примеру (цифры придуманы в случайном порядке):

Таблица 2.

Пример статистики по сущности “Найденных багов” в разрезе окружения, приоритетности и серьезности

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

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

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

Закрытые задачи будем считать в следующих контекстах:

• Improvement. Тип задачи, в рамках которого осуществляется какое либо улучшение существующего функционала, оптимизация процессов, оптимизация кода.
• New feature. Тип задачи, в рамках которого разрабатывается новый функционал описывающий новую бизнес идею.
• Epic task. Тип задачи, который по своему размеру является очень большим и является родительским для нескольких задач.
• Bug. Тип задач, в рамках которого чинятся какие либо недочеты и ошибки в продукте.
• Bug no production. Тип задач, в рамках которого чинятся недочеты найденные именно в продуктивном окружении.
• Autotests. Тип задач, в рамках которого, реализуются автоматизированные тесты.
• Technical issues. Такие задачи, как написание логов, миграция таблиц или написания одноразовых скриптов.
• Refactoring issues. Тип задач, в рамках которого, осуществляются рефакторинг кода, возврат технического долга.
• Total closed issues. Общее количество закрытых задач за период времени.

Выглядеть это будет так, к примеру (цифры придуманы в случайном порядке):

Таблица 3.

Пример статистики по сущности “Закрыты задачи” в разрезе типов задач

Таким образом можем наблюдать в динамике тенденции закрываемых задач в разрезе типов задач. К примеру, мы можем понять, сколько % общих задач является починка багов, или какой процент среди всех задач, занимает разработка фич или импрувментов и т.д.  Если, допустим, починка багов занимает больше 30 - 40 % от общего количество закрытых задач, это однозначно проблема, и ее надо решать !

Последняя сущность которую измеряем - метрики. Разновидность метрик будет следующим образом:

• % багов среди всех закрытых задач. Определяется соотношением значении типов задач из предыдущей статистики, см. Таблица 3,

(bug / total closed issues) * 100 %.

• % фичи(новых функционалов) среди всех закрытых задач.  Определяется соотношением значении типов задач из предыдущей статистики,  см. Таблица 3,

(new feature / total closed issues) * 100 %.

• % импрувментов(улучшении) среди всех закрытых задач.  Определяется соотношением значении типов задач из предыдущей статистики,  см. Таблица 3,

(improvement / total closed issues) * 100 %.

• % автотестов среди всех закрытых задач.  Определяется соотношением значении типов задач из предыдущей статистики, см. Таблица 3, 

(autotests / total closed issues) * 100 %.         

• % пропущенных багов.  Определяется соотношением значении из предыдущей статистики “Найденных багов”, см. Таблица 2, 

((на продакшине + СЗП) / total bugs) * 100 %.

• Количество найденных багов на закрытых фич.  Определяется соотношением значении из статистик “Найденных багов” и  “Закрытых задач”, см. Таблица 2, Таблица 3. 

(total bugs / new feature).

• % Эффективность тестирования.  Определяется соотношением значении из предыдущей статистики “Найденных багов” см. Таблица 2. 

(При тестировании / total bugs) * 100 %.

Выглядеть это будет так, к примеру (цифры придуманы в случайном порядке):

Таблица 4.

Пример статистики по сущности метрикам

Анализ данных

Основываясь на таблицах 2, 3 и 4 можем рисовать графики, мониторить где есть просадки а где процесс работает корректно, к примеру

Таблица 5.

График “% пропущенных багов на продакшен”

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

Еще один пример,

Таблица 6.

График “% багов среди всех закрытыз задач”

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

В таблице 7 можно посмотреть на сколько хорошо или плохо обстоят дела с написанием автотестов в команде:

Таблица 7.

Заключение

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