Должны ли тестировщики самостоятельно исправлять найденные ошибки?

      После долгой работы в одном и том же проекте начинаешь замечать, что одни и те же тривиальные баги появляются снова и снова. И если ты знаешь, как их исправить, то почему бы не исправить? Ошибки в UI, простые проверки для полей ввода и банальные опечатки – все это не требует сверх-навыков в программировании.

      Преимущество подхода «сам нашел – сам исправил» в том, что ошибки правятся гораздо быстрее (практически сразу же после обнаружения!), и для этого не нужно привлекать программистов, которым для исправления бага нужно будет отвлекаться от выполнения текущих задач и вникать в суть ошибки. Замечательно, не так ли? Так почему же все-таки стоит отказаться от такого подхода?

      Если исправить баг слишком быстро, то программист, который допустил эту ошибку, может не заметить, что эта ошибка вообще была и будет делать ее снова и снова.
      Спустя какое-то время программисты привыкнут, что тестировщики сами исправляют ошибки, и станут менее серьезно относиться к качеству кода. «Зачем самостоятельно проверять? Можно отдать для тестирования и код с ошибками. Все равно тестировщики все исправят…».
      Еще одна проблема в самостоятельном исправлении багов в том, что со стороны может казаться, что тестировщики не находят ошибок в программе или же этих ошибок просто нет.
      Следующая проблема связана с тем, что у тестировщика может быть недостаточно квалификации для исправления бага.
      Или, неправильно разобравшись в причинах возникновения ошибки, тестировщик начнет исправлять не то, что нужно.
      Или при исправлении тестировщик может не учесть некоторые соглашения по разработке, принятые среди программистов, просто потому что он не в курсе этих соглашений. Он же не программист, а тестировщик.
      К тому же, когда тестировщики перестают сообщать о багах программистам, резко уменьшается количество коммуникаций в команде. Программистам необходимо получать фидбэк о своей работе, и положительный, и отрицательный!

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

Стандартизация качества ПО

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

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

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

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

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

      Основой регламентирования показателей качества программных средств является международный стандарт ISO 9126 (ГОСТ Р ИСО / МЭК 9126) "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению". Проект состоит из следующих частей под общим заголовком "Информационная технология - характеристики и метрики качества программного обеспечения":

      "Часть 1. Характеристики и субхарактеристики качества",

      "Часть 2. Внешние метрики качества",

      "Часть 3. Внутренние метрики качества",

      "Часть 4. Метрики качества в использовании".

      В первой части стандарта - ISO 9126-1 - определены атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта.

      В части стандарта ISO 9126-1 даются определения с уточнениями из остальных его частей для каждой характеристики программного средства, а также для субхарактеристик качества.

      Вторая и третья части стандарта - ISO 9126-2 и ISO 9126-3 - посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика.

      Четвертая часть стандарта - ISO 9126-4 - предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы (контекста) использования программных средств и группы выбранных метрик для пользователей.

     

      Дополнительно могут быть использованы стандарты ISO серии 9000, в которых описаны общие принципы обеспечения качества процессов производства во всех отраслях экономики.

Классификация тестирования. Уровни, виды и типы

      Типы тестирования

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

      - по объектам (элементам) тестирования, часто разделение на виды тестов по данному критерию называют разделением тестирования на уровни;

      - по глубине тестирования, то есть разделение тестовых испытаний на типы проводится в зависимости от количества времени и объема тестируемых компонент программного продукта;

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

      Уровни тестирования

      Модульное тестирование (Автономное или Unit-тестирование). На данном уровне тестируются по отдельности небольшие элементы системы, максимально отделенные от других элементов и, в то же время, пригодные для тестирования.

      Комплексное тестирование (Сборочное тестирование, integration testing или interface testing). На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, чаще всего некоторая взаимодействующая между собой группа элементов. Комплексное тестирование направлено не на проверку функционирования каждого из компонентов, а на проверку взаимодействия компонентов в соответствии с архитектурой системы.

      Системное тестирование (system testing).После того, как система собрана из составляющих компонентов, она должна быть протестирована на соответствие системным спецификациям – реализованы ли все функциональные и нефункциональные требования к разрабатываемой системе. На данном уровне тестируется приложение или система (одно или более приложений) целиком.

      Приемочное тестирование (Приемо-сдаточное тестирование или acceptance testing). На данном уровне завершенное приложение (система) тестируется заказчиком, конечными пользователями или соответствующими уполномоченными с целью определения соответствия системы требованиям заказчика и готовности системы к внедрению. Приемосдаточные испытания оформляют процесс передачи продукта от разработчика заказчику. В зависимости от особенностей продукта и от требований Заказчика они могут проводиться в различной форме.

      Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения – критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

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

      Виды тестирования

      Инсталляционное тестирование (Installation testing). В процессе такого тестирования проверяется корректность установки и деинсталляции программного продукта в среде максимально приближенной к эксплутационной. Проверка правильности установки программного продукта должна быть обязательным элементом проекта по тестированию любого продукта.

      Дымовое тестирование (проверка на дым, Smoke testing). Первый прогон программы (после написания или после внесения существенных изменений). Как правило, используется для определения, готова ли программа для проведения более обширного тестирования. Основная цель такого тестирования - выявление проблем «лежащих на поверхности» – тестируется чаще всего основная бизнес логика программы.

      Функциональное тестирование (Functional testing). Под данным типом тестирования подразумевается проверка соответствия продукта функциональным требованиям и спецификациям.

      Регрессионное тестирование (Regression testing). Повторное тестирование после внесения изменений в программное обеспечение или в его окружение (в новой версии приложения), которое используется длятого чтобы убедиться в том, что функции, которые работали в предыдущей версии системы, по-прежнему работоспособны, а найденные дефекты успешно. Целью регрессионного тестирования является выявление проблем, которые могли возникнуть в результате изменений и проверка исправления найденных ранее дефектов.

      Интеграционное тестирование (Integration testing). Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования

      Тестирование графического интерфейса пользователя (User Interface testing). Тестирование интерфейса – экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс. Цель - обнаружение ошибок в интерфейсе и поиск ошибок в функциональности посредством интерфейса

      Тестирование производительности (Performance testing). Проверка скорости работы системы (время отклика, частота транзакций и другие зависящие от времени) в имитационной и реальной средах.

      Нагрузочное тестирование (Load testing). Это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).

      Стресс тестирование (Stress testing). Является одним из разновидностей тестирования на производительность, при которой проверяется, что система адекватно реагирует нате или иные стрессовые ситуации, например при недостатке ресурсов (дискового пространства, обрывов сети и т.д.).

      Конфигурационное тестирование (Configuration testing). Конфигурационное тестирование – тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения.

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

      Для проверки функциональности (functionality) ПО необходимо испытать приложение на выполнение функциональных требований к нему (сценариев использования и др.). Для этого используются собственно функциональные тесты, а также тесты безопасности, объема и другие.

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

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

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

Классификация тестирования. Технологии и методы

      В настоящее время все существующие технологии тестирования можно условно разделить на статические и динамические.

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

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

      Технологии тестирования используются при применении различных методов тестирования. Среди методов тестирования обычно выделяют два самых распространенных: метод «черного ящика» («black-box» testing) и метод «белого ящика» («white-box» or «glass-box» testing). Различие этих методов заключается в том, имеет ли разработчик тестов и тестировщик доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

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

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

Цикл тестирования

      В общем случае каждый из циклов тестирования включает в себя следующие этапы:

      1) планирование тестов: определение требований к тестам; оценка рисков; разработка стратегии тестирования; определение ресурсов; создание последовательностей выполнения тестов; разработка плана тестирования.

      2) дизайн тестов: анализ объёма работ; определение и описание тестовых случаев; определение и структурирование тестовых процедур; обзор и оценка тестового покрытия.

      3) разработка тестов: запись или программирование тестовых сценариев; создание и подготовка внешних наборов данных.

      4) выполнение тестов: выполнение тестовых процедур; оценка выполнения тестов; восстановление системы после сбойных тестов; проверка результатов; исследование неожиданных результатов; запись ошибок.

      5) оценка тестов: оценка покрытия тестовыми случаями; оценка покрытия кода; анализ дефектов; определение критериев завершения и успешности тестирования.

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

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

Определение тестирования ПО

      В соответствии со стандартом ISO 9126 принято следующее определение тестирования:

      Тестирование — это наблюдение за функционированием ПО в специфических условиях с целью определения степени соответствия ПО требованиям к нему.

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

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

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